Lists Home |
Date Index |
Joe Gregorio <email@example.com> wrote:
| Well, in the given example there isn't an _XML_ problem, since we *know*
| that there won't be any name collisions.
Name collision is an illusion. The illusion stems from an ill-considered
application of *defaulted* understandings of the single vocabulary case to
that of multiple vocabularies.
Basically, when multiple vocabularies are in play, you can't automatically
assume - i.e. as a default - the vocabulary to which a generic identifier
(or attribute name) should be imputed; or for that matter, that there is
only one relevant generic identifier for the particular element. You need
control information associated with the use of each vocabulary at every
start tag (i.e. for each element structure):
- whether a generic identifier applies (for that vocabulary) and if so
where to get it; which *could* be the "expected" generic identifier
position in the tag but need not be.
- whether any attribute specifications apply, and if so, how to find
them (just like the gi identification consideration above).
- whether immediate text content is part of the vocabulary specific
partition of the document.
Note that the single vocabulary case is just a matter of defaulting these
three considerations ("Yes, the GI is where you ordinarily expect it to
be; yes, all the atribute specifications count as is; and yes, include the
text content") so that no *explicit* control information need be encoded
in any tag. (But you *do* have to declare this fact, somehow)
By contrast, when you already know that defaults *don't* work, you can use
the control information to shuffle things around so they don't get in each
other's way. This necessarily means having to find vocabulary specific
names in places other than the now obviously inapplicable defaults.
By way of illustration, consider this reworking of the example in the OP.
It's unnecessarily verbose, but it shows how control information can be
used to "disambiguate" as the author may desire:
<B hn="head"><C hn="title">Book Review</></>
<D hn="body" xn="bookreview">
<E xn="title" ht="no">XML: A Primer</>
<G hn="tr" foo="center" ha="align foo">
<H hn="td" xt="no">Author</><I hn="td" xt="no">Price</>
<J hn="td" xt="no">Pages</><K hn="td" xt="no">Date</></>
<L hn="tr" bar="left" ha="align bar">
<M hn="td" xn="author">Simon St. Laurent</>
<N hn="td" xn="price">31.98</>
<O hn="td" xn="pages">352</>
<P hn="td" xn="date">1998/01</>
Note that *none* of the syntactically visible names belong to either of
the two relevant vocabularies. They don't have to: the control attributes
completely reconstruct the vocabulary specific views.
If you want to use vocabulary specific names in syntactically visible
positions, you could do something like this:
<title ha="!gi !nil" ht="no" xa="!gi !gi">XML: A Primer</>
<td xt="no">Author</><td xt="no">Price</>
<td xt="no">Pages</><td xt="no">Date</></>
<td xn="author">Simon St. Laurent</>
Note the <title> just under <body> ;-)
Any vocabulary specific view can be read off by following the pattern of
control attributes for that vocabulary only. Like I said, name collision
is an utter and complete illusion.
| The problem comes about if you tried to combine RSS with another XML
| vocabulary whose elements also resided in the nil namespace.
No problem as long as markup is used to tell the difference. Heck, that's
what markup is for!
The interesting fact is that not only are colons or multi-part names not
needed for this, but also such syntactically intrusive devices can
complicate or preclude solving the problem in the general case.
In fact, I've demonstrated a class of methods (using control attributes)
to solve these problems:
1. Allow any vocabulary to be mapped to any partition of the document.
2. Allow this for multiple vocabularies uniformly, catering to both
exclusion and overlap.
Not just that, I've done it with nary a colonified name in sight. Never
mind that I don't even have "xlink:href versus html:src" problems here!
And for that, I'm supposed to be a troll? Sheesh.