[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) wrote:
>>Anyone can come up with an namespace-based extension
>>architecture for a specific XML vocabulary where extensions perform a
>>single specific task. The RELAX NG folks have shown us how to do it
>>already with pluggable datatypes based on namespace URIs. Something
>>similar could be built into XSLT and W3C XML Schema engines if the user
>>demand for such features was that significant.
>
>
> Can it be built into ANY XML application engine? That would be
> progress.
I'm reckoning it probably can. As long as the architecture of the
generic semantics of the problem class can be specified well enough to
define how multiple 'implementations' can fit together - eg, schema
checking can be realised as a function mapping an XML document to a
(possibly empty) list of errors; then the generic schema checker would
consist of looking up the implementation attached to the namespace on
the root node of the schema and dispatching to that implementation.
However, each different schema language can have ways of saying "And
this subtree - verify it with a different schema language", at which
point another namespace-directed dispatch can take place.
That's one architecture for composing schemas from different schema
languages. Another one that would complement the above well
(particularly with that schema language that's a list of XPaths that
must or mustn't match - Schematron?) is to treat a multilingual schema
as a set of schemas which must all match - taking the set of errors to
be the union of the sets of errors from all the embedded schemas.
For rendering, it's easier; the problem decomposes quite logically once
you've agreed on something like the CSS box model.
>>However such specific implementations aren't really relevant to the
>>original discussion which was about how to signify "meaning" in
>>something like a syndication feed which could be extended in any
>>possible direction as opposed to one narrowly focused direction.
The most common semantics of a syndication feed could best be expressed
extensibly in CSS... for each namespace, provide CSS for the elements of
that namespace. Syndication feeds are mainly displayed for humands to
read in one of a number of ways, all of which CSS ought to handle :-)
Other uses for which the feed might be put are:
1) Searching. Say somebody is searching a huge news database for "Alaric
Snell". If an extension to RSS that provided a kind of 'cast list' for a
news story had a list of names and roles (protaganist, victim,
commentator, etc), then it might know that
"<victim><firstname>Alaric</firstname><lastname>Snell</lastname><email>alaric@alaric-snell.com</email></victim>"
should make that particular news story match "Alaric Snell" or "Snell,
Alaric".
2) Specialist metadata extraction. Again, say that we have some
extensions to RSS to bring out the names of people involved. How might
we generalise this so that this system might be extensible? We probably
want to allow RSS extension namespaces to provide an interface for "link
extraction" or something, so they can be queried to see if their
extension to a particular item provides any links (be they people's
names or URIs). How about extracting dates to generate nice timeline
diagrams, or cause and effect links between news stories syndicated in
RSS? Is it worth abstracting these things behind interfaces so they can
be extended, or will one XML syntax for listing people and things
involved in a news story suffice for everyone without needing extending?
> len
ABS
|
