[
Lists Home |
Date Index |
Thread Index
]
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@alaric-snell.com]
Sent: Thu 8/14/2003 12:22 AM
To: Dare Obasanjo
Cc: Bruce.Cox@USPTO.GOV; clbullar@ingr.com; xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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
|
