Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Do namespaces address all use cases well

From: rjelliffe@-------.---.--
To: "'XML Developers List'" <xml-dev@-----.---.--->
Date: 7/9/2009 6:24:00 AM
> But how well they address all use cases I do not know.  I would be
> interested to hear about use cases where Xml namespaces fail and rough
> sketches of better technologies.

<rant>Namespaces are another example of how comprehensively W3C has messed
up XML.

Just as HTML stagnated for a decade, so XML has stagnated. RDF still
cannot play with XML (RDFa, which could work, isn't defined over XML.) 
XSD is as far from being straightforward to use or implement as is
technically possible, and there are no plans to improve it except by
adding more bits.</rant>

We are now at the stage where we have the third or fourth generation of
major XML vocabularies, and we have no way to declare the relationship
between vocabularies, or that one vocabulary is a subset or superset or
dialect of another. (I don't see that SKOS is enough.)

This is really hurting the ODF and OOXML efforts, and indeed you can see
the same thing with HTML: the only answer they have to all these dialects
is to make more! <rant>These problems exist because there are no
vocabularies to describe the relationships, and IMHO there are no
vocabularies because of a basic blindspot at W3C, for all its other
strengths. I think this is that the W3C views the Web as a set of links
and resources rather than a publishing platform: they cannot see the wood
for the trees; the effect is that publishing kinds of issues such as
maintainability get sloughed off as an issue for private enterprise: I
don't think quality (in the industrial sense) is much on their radar
actually. </rant>

So actually I welcome attempts to develop XML & HTML in interesting and
useful directions: go for it! <rant>I have long thought there should have
been a more HTML-ish dialect of XML and even implemented this in some
products (ECS).  But I hope they don't deny that the needs for a forgiving
syntax for casual data is matched by the need for a stricter syntax for
mission-critical data. And I hope they will start to treat this as an
engineering problem, not a market research problem.

Of course, the answer from the protocol people will be to put the
namespaces in the HTTP headers. Just as the answer for HTML people will be
to put it in the html/head section. And as the answer for XML people was
to annotate the elements directly. The fruit does not fall far from the
tree, so people will try to make things fit neatly: XML people should no
more be telling HTML or protocol people where to stick their namespaces
than those people should be telling XML people. There needs to be the
basic respect of other people's use cases: plurality.

(And I will try to be amused by the number of people saying "XML needs to
get away from SGML" who have no actual knowledge of SGML. When James Clark
said it, he had a good idea of what he was talking about. And he has come
full circle to be interested in variant syntaxes with DSL recently
anyway.)</rant>

Cheers
Rick Jelliffe

_______________________________________________________________________

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



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