[
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
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
|
