[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>
> 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?
the one in terms of which operations in your processing-environment-of-choice
are expressed.
>
> 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.
parsing and serializing xml is "simpler and cheaper" where there are no
namespaces in the document. namespaces make it "harder and more expensive" to
code against a model which is in terms of lexical properties. so why do it?
while a parser/serializer must, there is nothing which requires that an
application do so.
> That cost is there because namespace
> are not syntactic - they neccessitated a model of a universal name,
> not a token for a universal name.
not correct. "namespaces in xml" contains things like the bnf productions
[1] NSAttName ::= PrefixedAttName | DefaultAttName
[2] PrefixedAttName ::= 'xmlns:' NCName
[3] DefaultAtName ::= 'xmlns'
[6] QName ::= (Prefix :)? LocalPart
[9] STag ::= '<' Qname (S Attribute)* S? '>'
[12] Attribute ::= NSAttName Eq AttValue | Qname Eq AtValue
these constrain the encoding. not the model. the only constraint which the
document places on the model things analogous to
(eq (name (first-attribute (parse "<x a:name='' xmlns:a='ns' />")))
(name (first-attribute (parse "<x b:name='' xmlns:b='ns' />")))
must be true. [ignoring for the moment the issue of equivalence across
document instances.] it says nothing about how the model and the respective
operators accomplish that.
>
> > 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.
i thought that's what i wrote. [modulo that element dominance is the scoping
mechanism. uri-syntaxed strings are used to identify sets of 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.
yes, within the parser/serializer. within the parser/serializer only.
> 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.
that would be a context-free syntactic form. that namespaces in xml specifies
a context-sensitive syntactic form does not mean that it specifies anything
other than syntax.
if namespaces in xml had said that, if a model operation interjects a name
which had been decoded with a given prefix into an element which has a binding
for that prefix which differs from the binding which was apparent in the
name's original lexical context, then the model must behave so as to change
the identity of the name, then you would have some basis for your claims.
namespaces in xml does not say 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.
if you can do the latter, then you don't need to be able to do the former.
>
> > 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.
they complicate parsers and serializers. that is not the same as "code".
> So far I'm not being refuted.
i've been posting code examples on this topic to xml-dev for years.
please reread the example i posted this morning.
please show how the application code changed because prefix/namespace bindings
and qualified names are present in the document. the same function was applied
to the two documents. how many counter-demonstrations do you require?
...
|
