OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Vocabulary Combination and optional namespaces

[ Lists Home | Date Index | Thread Index ]

james anderson wrote:
> Bill de hÓra wrote:
>>The 'problem' lies squarely in the Namespaces spec.
> not correct. the namespaces in xml, specifies how universal names are encoded.
> it does not specify the nature of the abstract data model. if one insists that
> the abstract data model be in terms of lexical properties, one is making their
> own problem.

Which 'the abstract data model' would that be?

Attempting to get me to engage at the level of abstract models or 
telling me I'm causing my own problems doesn't change the simple 
fact that coding against XML is simpler and cheaper when there are 
no namespaces in the document. That cost is there because namespace 
are not syntactic - they neccessitated a model of a universal name, 
not a token for a universal name.

> namespaces in xml does not specify how names are modeled. it specifies how
> they are encoded.

No. It specifies how to encode a universal name which in turn is 
predicated on using URI as the scoping mechanism, in a syntax that 
does not allow URIs to appear as names. Hence the need for a 
proxying prefix, hence the need to bind URIs to prefixes at the 
document scope, hence the need to infer and manage the names instead 
of merely tokenizing them. If namespaces were a purely syntactic 
device (ie if you changed the XML grammar to accomodate URI refs), 
imo I wouldn't be here whining about code management, but I suspect 
lots of people would be whining about seeing URIs everywhere.

Then again there is no specification of how one might inscribe such 
a name  in single production (as a token, or sequence of tokens) 
rather than the model of the name (as a non-sequential colelction of 
tokens) that need to evaluated and combined (as with expanded names 
in XPath). I think someone should, because we could hold that 
grammar up against XML and greatly clarify matters.

> there's a sentence on that page which reads something like
> "Source archives are available for the MCL, Lispworks, and Allegro
> implementations of Common Lisp. A separate document provides the download
> paths and details on the implementation status."
> in which the word "document" is associated with a link to the download page. i
> need to update the page: the present version also supports cmucl. note also
> that 0.949 does not include xpath code. you need to pull an older version in
> order to get that.


> the original passage was:
> "There is no canonical (self-describing) form for for a namespaced 
>  element, ie there is no way to treat it like a regular XML name so 
>  the code reflects the difference. You can't get to such a form for a 
>  namespaced element for two reasons
>   - technically the XML grammar won't allow it.
>   - socially, it seems people don't want deal with URIs as element 
>  names at the syntax level."
> i take the passage "form for for a namespaced ... the code reflects the
> difference" to refer to the representation in the application model and
> application code.

Take it any way, but I'm concerned about syntactic matters. I can't 
write down a universal name with an XML Namespace, but yes I can 
encode a model of a universal name for decoding later.

> i repeat,  please amplify. it is not clear how the grammar [for the encoding]
> places [the claimed] constraint on the model.

I'm claiming namespaces complicate code for precious little benefit. 
So far I'm not being refuted.

Bill de hÓra


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS