[
Lists Home |
Date Index |
Thread Index
]
9/27/2002 7:42:51 AM, Arjun Ray <aray@nyct.net> wrote:
>
>
>The case when all kids agree that only one kid can play in the sandbox.
>(The supposed necessity of colonification rests on the dogmatic premise
>that name mapping is *un*necessary.)
>
It seems to me that the time might be ripe for a reconsideration (in xml-dev,
academia, various monasteries and mad scientist laboratories) of how
XML++ might work without colonified namespaces. Sure its the "dogma"
in the mainstream, but it's had only 4 years to ossify our neurons.
Considering all the other once-dear truths that the burst of the Internet
Bubble has forced us to rethink, this might not be a major act of heresy.
It would be a bit much to say that namespaces are XML's "Vietnam"
[I'm on a roll, after comparing the TAG to the Kentucky legislature
trying to fix the value of PI, eh?] but I'm reminded of a 1960's
protest song that had the line "But just before the end,
even treason might be worth at try". Likewise,
HLink and John Cowan's AF NG stuff has brought some of the HyTime ideas
(which I admit to never having understood in their heydey) back to a certain
respectability.
So, HLink shows us a sketch of what an XLink without colonified namespaces might
look like. CSS has no need for colonified namespaces. DOM has (for better or
worse!) resisted the temptation to drive namespace awareness too deeply into the
API or data model. AFAIK, RELAX NG treats colonified namespaces as an afterthought,
and could easily accomodate alternative pattern-based "typing" approaches.
What about XSLT? SOAP/WSDL? Other specs that appear on the
surface to depend heavily on colonified namespaces? How much baby would have to
be thrown out with the XML Namespaces 1.0 bathwater, assuming that such a
thing made sense? Or maybe XSLT *does* illustrate a good special case in which
the colons ("sanely" applied, in Joe English's sense, of course) make sense.
Or maybe there are a *small* number of prefixes that just need to be universally
recognized to ease the job of infrastructure specs, but name mapping is
a better approach for merging application vocabularies.
I don't have many preconceptions about what will really work,
I just don't want promising ideas to languish just because the W3C stamped
"Recommendation" on the alternative. The XHTML/XLink debate (not to mention the
URI debate, the RDF/TM debate, the RPC/REST debate ...) makes it clear that
these things don't go away just because the W3C has spoken. In fact,
I would argue that the whole purpose of the w3C is NOT to speak
authoritatively on matters of technology, but simply to help the industry
explore possibilities in a way that maximizes interoperability,
minimizes marketing-driven gratuitous differentiation, and leverages
the network effect. So, I wouldn't see something like this as a rebellion
against the W3C's authority, because it has no "authority", just good offices
to help companies "prevent their own marketing departments from destroying
the value inherent in the Web through their own, and their competitors',
short-sighted, quarterly-revenue-driven pursuit of profits" (in the immortal
words of Roy Fielding).
So, I for one am getting sick of spending energy cursing the darkness. Maybe it
would be more fun to light some candles and explore the passageways that were
abandoned during the XML goldrush. If the main passage of XML (namespaces,
WXS schemas, XQuery, etc.) continues to yield pay dirt, this couldn't hurt
much, and might help "them" (which is also "us" of course) Lead XML to its
Full Potential without being whined at so much. And if the ore runs
out in the main passage, maybe they could join whoever finds a rich
vein in a side passage that just needed to be exposed more clearly.
[speaking as a private citizen, needless to say.]
|
