Re: [xml-dev] RE:Namespaces are flawed

[Bill de hÓra <bill@dehora.net>]

Michael Kay wrote:
>>    This is the second time in this thread I've seen it written that
>>    Namespaces are flawed. 
> 
> 
> It used to be a permathread on this list, but everyone's given up moaning
> except when they discover some new implication.
> 
> The biggest problem is that the spec tries to make prefixes non-significant
> and fails.

I'll see that and raise you default namespaces.


> Another problem is that the spec is vague as to what constitutes a valid
> namespace URI (and whether it is ever meaningful to dereference a namespace
> URI, resolve it against another URI, etc)

This goes back to an issues with specs/stands/reccs. Nobody's talked
about implicitness v explicitness in specifications.

Implicitness fails us I think. There's a correlation between bozo
technology and implicit or axiomatic approaches to specification.
Personally speaking, I think I have wasted a lot of time since coming
into this industry in having to decipher the consequences of specs or
interpret things through to some form of conclusion that may or may not
be what was expected. And then to go back to the source or the community
only to be told that's not the preferred interpretation. And then watch
the bugs and interop reports come in. At that point the typical response
is that it that it's too late to fix now. When I think of a spec written
in implicit form I tend to think of XML Namespaces.

Being able to reason conveniently about the consequences is a useful
operational definition of simplicity. Implicitness gets in the way of
that by leaving to much to the imagination. XML namespaces is quite
short, yet  it's difficult to reason about because so much is left
unsaid. I think a number of the specs layered onto XML that people see
as "small" fit into this category - xml:base and xml:id come to mind.

You can look at how people use words as a leading indicator of implicit
specification.  My working trigger terms for this are "implementation
detail", "implementors guide"* and "best practice". They suggest what I
would call design smells in specifications insofar as they're claims
worth pushing back on and probing further. Unless you've got the guide,
the practice, or the code handy of course.

The math always gets done. If you can't or won't do basic logical
implication you will end up outsourcing the formal analysis to tools
developers, who are obliged take an empirical approach to see how the
spec's theories stand up. If that's your approach then I think you
should outsource early and often :)

In terms of supposed simple mechanisms in the XML canon, defaulting and
inclusion are the ones I would call out as problematic as they seems
endless in their ability to surprise and confuse. Here are some off the
the top of my head: xml:base, default namespaces, c14n, derivation by
restriction, imports, xml:id, qnames, xml in xml, xinclude. inheritence
of feed level metadata to entries. I claim the problem in each case is
that the spec writers didn't stress out the logic of their
specifications and thus didn't pick up on the implications. These
mechanisms were probably specified implicitly and left at that.


> The root cause of the problem is that the layering is wrong: naming is
> fundamental to XML, and you can't add something fundamental as an optional
> layer on top of the core. At any rate, you shouldn't.

+1. That namespaces have no syntactic form is the first clue something
is awry. And the way XML namespaces went about this (macro expansion) is
misguided imo.

cheers
Bill