Amy,

I like your analysis (a lot!). My own comments are inline:

Strongly agreed.  In that regard, I'm deeply reluctant to accept the
> "shortcuts" (registry) that Micah proposed, because it seems to me that
> these would soon become the only things supported.
>
> Now ... even something like Flash, now so widespread, would have had no
> chance of adoption and uptake without *extensibility* (and I will
> perhaps be excused for emphasizing the word, since I am prouder of
> having worked for the company of that name than of any other).  I will
> grant that IE offers a poor platform for namespace-based (or
> equivalent) extensibility, but it seems to me that in order to enable
> the future of the web, to make it a place where small, dedicated groups
> can introduce something game-changing, that extensibility paradigm is
> of paramount importance.
>

Yup. IE's playing catch-up now, however, and I suspect that with Chris
Wilson
moving on, it may very well be to IE's advantage to actually be the advocate
for namespaces moving forward; the opportunity of using namespaces as
flags for specific schematic-oriented sub-processing is simply too obvious
not to
take advantage of, and it is already a fairly significant feature of
XAML/WPF.


> I think it's verbosity as much as complexity.  You will note, I hope,
> the "namespace minimization" that I mentioned in my post; why should I
> have to tell the processor the *namespace prefix* of the element that
> I'm closing any more than I should have to repeat the attributes of
> that element?  I'm persuaded that permitting those to be dropped would
> have no impact on well-formedness (although I admit that discussions of
> minimization are likely to lead into a swamp, because well formedness
> and minimization are clearly at odds, in a large number of cases that
> can't be dismissed as "corner").  Arguably, XML's verbosity
> (effectively requiring the equivalent of a comment on every equivalent
> of a closing brace in C } /* if */ } /* while */) is precisely what
> makes it robust enough to have achieved the levels of adoption that it
> has seen.
>
> In terms of verbosity, the idea of using something like XLink rather
> than "href" in attributes (XLink is, in my opinion, vastly
> overspecified/overengineered for the common case, leading to dismissal
> of the opportunities that it provides for more sophisticated usage) is
> equally damning.  And neither DTD nor W3C XML Schema make it easy or
> convenient to say "oh, you can use any attribute from a different
> namespace on any element here".  It's painful in DTD; it's exceedingly
> tedious (and consequently likely to not happen, for at least some
> elements) in WXS.
>

Verbosity has long been my biggest problem with namespaces as currently
implemented (and yes, xlink is a perfect example of that). I think a lot of
people are thinking now about scoping or umbrella variables, and this
"crisis" may very well be the catalyst for that.


> Okay, you've triggered a rant.  Those of you who are partisans of the
> Namespaces in XML Specification are hereby warned: the following will
> annoy you.  I'm going to be offensive (although more offensive to the
> W3C folks who forced URIs onto the Working Group than to the Working
> Group members themselves).
>   ...


> The insistence of the W3C on URIs (that aren't, in fact, URIs) as
> namespace identifiers is, to my mind, the worst thing that could have
> happened to XML.  Because the URI specifications are not in the control
> of W3C, and the BNF for URI (however widely ignored in detail) cannot
> drop multiple characters otherwise illegal in XML element names, the
> Namespaces in XML specification was forced to introduce
> namespace-to-prefix mappings, and the subsequent use of prefixes in
> element and attribute content poisoned the well completely.  James
> Clark's (brilliant) suggestion for expanded names, {uri}localname,
> simply never saw adequate adoption (in part, perhaps, because W3C XML
> Schema defined anyURI and NCName and QName, but not ExpName (or JCName
> :-)).
>

Wow! Okay, I definitely agree with the crux of the rant.

There are times I feel we don't have enough meta-characters. The biggest
problem with {uri}localname was the role that angle brackets play in both
XSLT and later XQuery. I've often thought that [uri]localname works better
though, both because there are considerably fewer collisions for square
brackets in XML processing languages and because it's become something of a
convention in email: "[xml-dev] This is my title" has a natural, intuitive
feel. It also makes <[org.w3.xsl.transform]stylesheet> feel similarly
intuitive and somewhat easier to read than most of the other schemes I've
seen.


> While the XML 1.0 specification is (a thing of beauty and a joy
> forever) one that I point out to others (whenever I am engaged in that
> horrible perversion, specificating, in company :-), the best that I can
> say for Namespaces in XML is "well, yes, that's clear enough; it can be
> implemented."  Whoever forced URIs on the working group--very likely
> TimBL or Roy Fielding or their disciples--did them a disservice.  XML
> namespace identifiers do not need that generality, and should have
> chosen a representation that allowed compact (but unique, with
> distributed authority) indication within an element name.  Perhaps,
> rather than the dotted-on pattern that Micah has proposed, they could
> have made "qualified names" use colons in place of dots in domain names
> and in place of slashes in paths (com:w3:org:1999:xlink:link).  Still
> verbose (Micah's "using" syntax is rather ... nice), but not as painful
> as NiXML.
>

I think the dot notation has an incredible degree of merit ... the use of
dot-notation has become standardized as a representation of class and
package hierarchies in most languages, and I suspect that its use in XML
would go at least a part of the way of assuaging the large number of
JavaScript programmers that XML isn't really evil. I'd also point to e4X
notation (as well as Linq, which follows a similar format) as a way of
specifying child notation.

The biggest argument against the adoption of XML in HTML has generally been
the cumbersome DOM interfaces, which I've brought up before. They served
their purpose back in the early days, but in the process of trying to
develop generalized APIs, somewhere along the line simplicity got lost. The
namespace problem is a direct artifact of that.


>
> I agree that this is fundamental, and also worry (though I'm not
> familiar with HTML 5 or WHATWG people sufficiently to judge) that the
> intent of HTML 5's restriction of permitted namespaces is for the
> purpose of controlling (that is, limiting) extensibility.
>
> > The language NEEDS an extension mechanism.
> > The language NEEDS an extension mechanism.
> > The language NEEDS an  extension mechanism.
>
> You won't mind if I quote this multiple times, will you?  I can't think
> of a better way to indicate how much importance I accord to it.
>
> > The language NEEDS an extension mechanism.
> > The language NEEDS an extension mechanism.
> > The language NEEDS an extension mechanism.
>

Heh!! I don't think this is important enough to you ;-)


I really, really wish that someone from the HTML 5 working group would
> come forward with an indication of what, in the WG's opinion, the fatal
> flaws of XML namespaces are.  I can guess at a number of them (the fact
> that many, many people new to XML cannot understand that elements are
> scoped by the schema (and namespace-qualified) while attributes are
> scoped by the element (and hence unqualified) by default is one;
> verbosity, incomprehensibility ... well, I'm not a big fan of
> Namespaces in XML apart from the rather insipid encomium, "yes, that
> can be implemented"), but ... I'd like to see HTML 5's "non-XML" syntax
> permit a lossless transformation into the XML syntax and back.  It
> doesn't need *XML* namespaces to do that, but it does need ...
> something with the good qualities of Namespaces in XML.
>

Yup.


> > chooses to cede this point, then for all intents and purposes the XML
> > movement is dead.
>
> Oh ... I can't really agree with that.  I mean, I saw that the HTML 5
> working group was defined *in terms of the DOM* and Boggled and Fell
> Down.  Does anyone who does XML for a living have any respect for the
> DOM APIs?  And yet ... it's clear that those are core to the browser
> experience (which is why they suck so hard for any other usage, in my
> opinion), so it's really perfectly reasonable that the browser folks
> should start from the DOM.  In any other application of XML, a mutable
> tree API is at best a dead weight, but in the browser, it has
> utility--utility to the point of necessity.
>

Let me explain my argument here. In an ideal world,


>
> Bifurcation?  Certainly.  HTML could become a non-XML dialect.  I'd
> hate that, but it looks as though there's at least a part of the HTML 5
> working group who would welcome it.  Killing XML?  Nah.  The HTML 5
> working group can miss an opportunity (and it seems likely that they
> will), but distancing HTML from XML won't kill either one, it will just
> annoy the folks who have to develop the techniques to reconcile them.
>
> Amy!
> --
> Amelia A. Lewis                    amyzing {at} talsever.com
> Do you ever feel like putting your fist through a window just so you
> can feel something?
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>