[
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.
Thanks.
> 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
|
