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
 In the Parallel case there are is a refinement you should consider. When a nested vocabulary can be ignored by certain consumers but is an extension of the nesting vocabulary in other contexts. An example of this is SQLXML annotated XSD mapping schemas[0] where extension attributes are ignored for the purposes of validation of XML documents but are used when the schema is used for mapping XML to a relational database. In the Embedded case the problem is presented in its simple form, when the information items in a vocabulary are processed in a uniform manner and contribute to a single task. Adding new information items that are similarly uniformly processed and contribute to the main task is straightforward. However for vocabularies whose constituent information items are not meant to be processed in a uniform manner [such as RSS] the embedding process is not as straightforward. Assuming that all items in a feed are for human consumption and can just be rendered or styled does not jibe woth current practice. Besides those nitpicks I agree with the divisions you describe. [0] http://msdn.microsoft.com/library/en-us/sqlxml3/htm/ssxsdannotations_0gqb.asp ________________________________ From: Alaric B Snell [mailto:alaric@a...] Sent: Thu 8/14/2003 12:22 AM To: Dare Obasanjo Cc: Bruce.Cox@U...; clbullar@i...; xml-dev@l... Subject: Re: Symbol Grounding and Running Code: Is XML Really Extensible? Dare Obasanjo wrote: > Nope. Alaric proposes solutions to specific instances of the general > problem of mixing arbitrary XML vocabularies. I don't think solutions to > the general problem are feasible and definitely do not think any of the > current discussions even point in the right direction to solving such a > problem on a decentralized network like the WWW. Well, I gave a few specific instances as examples, but I'm hoping that the same general process could be applied in any application domain - thus making it a general solution. The requirement there is that, in any situation where mixing vocabularies makes sense, one can define - in the abstract - what that particular *class* of mixing could be modelled by and thus use this as a system of dispatch to semantic handlers grabbed from some registry somewhere (and this registry could be as simple as pointers in RDDL from the namespace URI or a purely local list of 'what modules I have installed'). Now, I see two classes of namespace mixing in documents: 1) Parallel. Take RDDL. You can view it as XHTML (ignoring the RDDL) or RDDL (ignoring the XHTML). In which case it's a bit like a MIME multipart/alternative; your app can ignore the bits it doesn't understand, and there's no relation between the meaning [I would say semantics but there are accusations of people meaning different things by that] of the different "overlaid documents". Because of this it doesn't matter if your app only understands some of them - a web browser will understand the XHTML, but there's nothing that useful it can do with the RDDL. The RDDL is meant for non-human consumption. 2) Embedded. Take MathML. When it appears in some XHTML, a magical process takes place. a) The point in the XHTML tree where it appears corresponds to a point in a CSS box model, due to the meaning of element nesting in XHTML. b) The MathML element and its children could be passed off to a seperate MathML renderer, returning a CSS box object that the XHTML renderer could then tuck into its flow. Clearly, this process can be generalised with an extensible lookup table to allow one to ship a module for web browsers that allows them to display, say, directly embedded SVG or RDF (as a graph of clickable links for nodes and arrows between them or something). XHTML itself would be just such a module; so some other renderer could find bits of XHTML embedded in it's input document as labels or something and pass control (via the lookup table) to the XHTML renderer for those. Thus, the web browser's rendering engine would boil down to invoking the correct module for the namespace of the root element and letting that module handle dispatch to other modules where appropriate. The hard part for being able to define an extension architecture for every XML application domain (rendering, searching, etc) is choosing a generic API and a general meaning of 'embedding' for that application domain. Can this in general be done? I'd say "probably". However, expect problems where people overspecify stuff and accidentally produce non-extensible module APIs (perhaps something more general than the CSS box model is required to base rendering upon. Perhaps XSL-FO would be better). 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
|
|||||||||
