Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Pragmatic namespaces

From: Kurt Cagle <kurt.cagle@-----.--->
To: Amelia A Lewis <amyzing@--------.--->
Date: 8/2/2009 7:32:00 PM
Amelia,

The previous post was intended for the list overall (as is this post), the
only flaw in mailman type architectures.

However, concerning your post, I agree strongly with you about the need to
avoid namespace registries, which is the danger that I see in any "default"
mechanism. It's potential to fragment the web is disturbing, especially as
it effectively puts the decision about what technologies to keep or avoid
solely in the hands of the browser vendors.

Overall, I'm going to raise this question again - what exactly is it about
namespaces that the HTML crowd doesn't like? If it's the use of complex
namespace URIs, then frankly the ideal solution to that is to provide
guidance on what constitutes a good web URI. If it's the requirement of
using prefixes, then an extension of Micah's pragmatic namespaces solution
seems to be a good start, so long as there is a formal mechanism for
insuring that ANY namespace can be introduced in this matter.

However, if it is simply a desire by a group of people (notably the WHATWG
group) to control the standard at its most conservative, then nothing that
the XML community does, no matter how well intentioned, will make any
difference. This becomes a formal W3C matter (which it ultimately should be)
- not Google, not Ian Hixie, not any of us here individually ... or has the
W3C's focus on the Semantic Web blinded it to the fact that its initial,
primary and ultimate mandate was to act as the custodian of the HTML
standard?

I'm sorry about being harsh about this, but frankly the whole issue is
beginning to piss me off. As far as I'm concerned, by allowing the HTML 5
process to move forward in the first place, there is an open, tacit
admission that the SGML DTDs underlying HTML are once again open for
modification. Maybe this is the time to incorporate namespaces into the
formal DTD, since the DTD emerged before namespaces did. If a different
notation is needed for backward compatibility, that's fine, but this
unthinking idiocy of feeling that namespaces in some form should not be a
part of HTML is just politics for the sake of control.

The language NEEDS an extension mechanism. There are more than 10,000
different XML vocabularies currently in existence at the present time, and
HTML is still, far and away, the primary carrier for the bulk of them. The
whole AJAX movement has the potential, with XBL or otherwise, to provide
behavioral support for those extension elements, as appropriate, and without
this philosophy in place, then we just see the unabated movement towards
JavaScript becoming a morass of APIs that destroy the whole notion of
declarative architectures.

I think we should pursue Micah's proposals, but frankly even at the
Extensibility F2F in September it should ... it must ... include an
open-ended extensibility model as an absolute minimum requirement ... and
that the W3C should decide as a body whether it wishes to control the future
of HTML or cede that authority to a handful of vendors. Because if it
chooses to cede this point, then for all intents and purposes the XML
movement is dead.

Kurt Cagle
Managing Editor
XMLToday.org


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent