[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Lessons learned from the XML experiment

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: Michael Kay <mike@saxonica.com>
  • Date: Thu, 14 Nov 2013 15:59:26 +0000 (GMT)

Re:  Lessons learned from the XML experiment
Michael Kay wrote:
"Yes, I am serious. Programmers have no difficulty with the idea that data.xml is a different file depending on what directory it is in, or that Logger is a different Java class depending on what package it is in; they would have no difficulty understanding that <title> within an SVG context means something different from <title> in a MathML context, where the context is defined by an ancestor element. This would be vastly easier to cope with than the current namespace machinery. The vast majority of users would never have to worry about it because most documents use a single vocabulary, so unlike namespaces it would impose no complexity cost on users who don't need it."

Oh Michael - but this cannot be compared at all! Who am I to tell you that the gist of the matter, when it comes to XML, is not human eyes contemplating a string. Chief design goal of XML is to support XML processing, which ordinarily deals with megabytes, if not gigabytes - there is no "looking" involved. The issue is how to support complex processing which traverses millions of items and must not at any point rely on an "understanding" as it comes easy to a human. When you hint at how bad things have been done and that it could have been done better, you must make sure that the hinted alternative offers the same precision and reliability. When you come up with a name containing dots, I am simply at a loss how you might possibly achieve the precision offered by namespace attributes. To achieve global uniqueness, short strings won't do. Very long strings are out of the question as element names. So you have the choice of not-too-long identifiers which do not uniquely identify a vocabulary, or long identifiers (URIs) for which a mapping to a short placeholder is required. Namespace attributes keep this mapping cleanly apart from anything else. Would you seriously prefer to shift the mapping into the element names?

Hans-Juergen




Michael Kay <mike@saxonica.com> schrieb am 15:49 Donnerstag, 14.November 2013:

On 14 Nov 2013, at 13:46, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

Michael Kay wrote:

"Namespaces account for a very significant chunk of user difficulties with XML, a great deal of the complexity of specifications like XSD and XSLT, a similar proportion of the complexity of APIs, and a vast amount of the code in implementations of these specs. And they aren't necessary! The world could have managed perfectly well with a convention where the element name <org.w3c.svg> means "in this subtree, I'm using SVG element names"."

Michael, you are not serious, are you? Would you suggest that users start to parse names and, depending on whether the name string matches some "convention", infer that something means an apple, rather than a pear?

Yes, I am serious. Programmers have no difficulty with the idea that data.xml is a different file depending on what directory it is in, or that Logger is a different Java class depending on what package it is in; they would have no difficulty understanding that <title> within an SVG context means something different from <title> in a MathML context, where the context is defined by an ancestor element. This would be vastly easier to cope with than the current namespace machinery. The vast majority of users would never have to worry about it because most documents use a single vocabulary, so unlike namespaces it would impose no complexity cost on users who don't need it.

(But I'm not seriously suggesting that I can change the world, if that's what you mean: there's a difference between knowing where you want to be and knowing how to get there).

Michael Kay
Saxonica








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.