Lists Home |
Date Index |
Mike Champion <firstname.lastname@example.org> wrote:
| a) what specific ways do namespaces bite people who understand them and
| use software that supports them properly?
It's not so much an issue of "do" as "will". Namespaces will bite hard
when it comes to associating more than one significant name to the same
data value. (Why did it have to be xlink:href **VERSUS** html:src, for
instance?) It's an implicit assumption of namespaces that only one name
ever applies to any value - that factoring into *disjoint* "namespaced"
components is the only meaningful way to look at the content of compound
This is counterfactual enough to be ludicrous. It is normal for data to
have information value in multiple taxonomies simultaneously, which is why
all markup is fundamentally annotative, not ontologically declarative, and
why all names used in markup are instrumental, not immanently universal or
whatever. (After a year of enduring relentless and insensate babbling on
"globally unique names" and G*d knows what else in the way of amateur
philosophizing on the now defunct w3c-xml-sig, I really don't have the
stomach for any more.)
One common workaround is introducing extra element structure, carefully
crafted to avoid invited complications such as extraneous white space (as
pretty printers could innocently create), and indeterminate opacity (why
do you ignore only the *tagging* of other namespaces?), such as the first
example ("book review") here:
Note how stuff like
<h:td><xdc:author>Simon St. Laurent</xdc:author></h:td>
really needs to be on one line with the tags cheek by jowl (Why? Because
two syntactically distinct elements are being used to annotate exactly the
same *value*). We also really shouldn't get into why the <h:>'s all have
the <xdc:>s within them (does this meet *any* understanding of content as
Compare the reworking:
and note that colonified names are utterly and completely unnecessary.
I'll concede that, to people immersed in namespace theology, this is not
obvious. Attribute-based processing is still undiscovered - oops, that
should be unreinvented - in the XML world.
As usual, the only way we learn is the hard way. Give it a couple of
years, at least.
| b) What should one do to avoid being bitten, given that they are
Drop the mindset. What makes you *think* namespaces will solve the
problems you face?
| c) How would one do it differently in 20:20 hindsight?
Not rush into premature "standardization".