Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Symbol Grounding and Running Code: Is XML Really Extensib
 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@a...</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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
