OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Symbol Grounding and Running Code: Is XML Really Extensib

[ 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 
should make that particular news story match "Alaric Snell" or "Snell, 

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



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS