| |
On Thu, Sep 09, 2004 at 05:31:49AM +0000, Kelly McKiernan wrote:
> So there are several potential methods of describing how such a list
> could be maintained and still retain usability and flexibility. Here
> are a couple, please let me know if there's anything obvious I've
> missed. Remember, this is based on RSS 2 /Atom 0.3, so it has to work
> with those formats.
>
> First possibility: [XSD, XML Schema Definition]. I believe RSS 2.0
> supports XSD, but I'm not absolutely sure. I know 0.92 doesn't, and
> I'm staying as far away from RDF-centric RSS 1.0 as possible. Also, I
> think Atom can be extended to use XSD, but again, I'm not sure. Any
> clarification is helpful.
I like this solution. The schema can be used not only for validation,
but can be pulled to get the list of possible values. Quick question
though - can't the list of allowed values be specified in the DTD, which
we're going to maintain anyway? I guess you were refering to that in
the parts I snipped before, saying you don't want to release a new
version of the DTD every time we need to modify the theme list.
Does it matter that much though? A new ver of the DTD, that just has
changes in the allowed values, doesn't mean it's a new version of the
spec... Or at least, not in a significant way (minor version update, as
opposed to a new major number).
...
> Now, this doesn't actually physically restrict anybody from putting
> "Galidor" in their feed, even if it isn't in the xs:enumeration list.
> It just means that if somebody tries to validate that feed, it would
> not validate. But maybe that's enough.
It will phisically stop non-themes from being published, if the tool
publishing reads the schema before asking the user for input, and
therefor displays only valid options. Nothing we do will stop invalid
feeds from being published, of course, but with a good API in place, we
can at least make it really easy to publish valid feeds.
> Another way of doing this is a ["roll-your-own" method], since I
> haven't found anything else. It would make software development a bit
> easier, I think, although I'm surprised that I couldn't find anything
> like this after searching for a couple of hours.
Why re-invent the wheel? The roll-your-own method ends up being pretty
similar to the schema, but it takes away the ability to use standard
libraries for parsing it (except for plain XML libs). IMO, the
difference in effort for developers would be negligable.
...
> This would basically act as a plugin to software that would suck in
> the XML file and use it for parsing. It's really just metadata, but
> the nice thing is it would remove hardcoding from software sources
> when interest lists were updated.
Right - either way would.
> The bad thing, of course, is requiring an external function, relying
> on a file that might or might not be available in the future. The
> whole thing about LENNI as a "spec" is that it should not require
> external resources, so although this would be way cool, it's also sort
> of a compromise to the independence of the project as a whole. Of
> course, software developers could just use this XML as a reference
> source and have their own local copy, and check the list at regular
> intervals for updates, which would be preferred. So maybe I'm just
> being uppity.
I agree - the spec should probably specify that a local cache should be
kept, and maybe even how often updates should be checked for.
But I like the solution in general - a way to keep the standard list of
options, easy to update, and easy to propagate.
--
Dan Boger
dan@peeron.com
|
|
Message has 1 Reply:
 | | Re: Another LENNI Question (geek alert)
|
| (...) Right, no need to force software updates every time we add to the list. Hopefully it'll be all back-end. My only real concern right now would be how stable is XSD? I keep running across people trashing it on the various blog sites. But I don't (...) (20 years ago, 12-Sep-04, to lugnet.publish)
|
Message is in Reply To:
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
