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 ]

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 

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 



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

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