[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>
> james anderson wrote:
>
> > the programming problem is an artifact of the misconception that names in a
> > namespaced world need be modeled at the application level as tuples. this is
> > no more true than would be the claim that names in a non-namespaced world need
> > to be modeled at the application level as unicode scalar value tuples.
>
> The programming problem is an artefact of the XML Namespaces spec.
> I need three things to define a name with namespaces, a namespace
> name, a qname (which is arguably an embedded tuple), an xmlns
> declaration. There isn't any other specified way to do this, what
> happesn at the applciation level is a second order effect.
>
> >>In other words namespaced elements are tuples after a kind.
> >
> >
> > if one insists on modeling them that way, one is making ones own problems.
>
> 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.
> > cl-xml includes a first cut xml-path processor. it adds to the standard
> > parsing protocol that xml path expressions are interned in the parser's
> > dynamic context. from that point on, the only aspects of the processor - and
> > therefor of application code, which are concerned with lexical properties
> > (prefixes, namespace names, local parts) are those which the xpath standard
> > stipulates must be present - eg to match on local part or on namespace name only.
> >
> > everything else can be expressed in terms of abstract names. no tuples. no
> > lexical properties.
>
> To use XML Path I need an xpath and an xml document first and
> foremost. What happens when evaluating an xpath with a Qname depends
> on which namespaces are in scope via the namespace nodes for that
> element and the expanded name for that element, but the point is
> that the xpath string needs to declare upfront whether it's testing
> for a Qname or not and the processor needs to know whether the in
> context element has an expanded name. Heck even the XPath spec
> defines the expanded name as a tuple. What you're describing sounds
> like a processor for something other than XPath, possibly an
> XPath+macros processor - if I'm missing something perhaps an example
> will enlighten me.
>
> >>In turns out that you can't without incurring a development cost.
> >
> >
> > true, but only in that one would need to fix what appears to be an
> > inappropriate document model.
>
> Strawman objection. This is a not about finding the right document
> model for XML Namespaces, it's about how XML Namespaces models XML
> names.
namespaces in xml does not specify how names are modeled. it specifies how
they are encoded.
> If we're to going have to tease apart a conflation of ad-hoc
> document models with a specification model for XML names, we should
> call it a day, cos we'll be here all weekend talking past each other.
>
> >>There is no canonical (self-describing) form for for a namespaced
> >>element,
> >
> >
> > it must be that i do understand what this is intending to claim, as, as i do
> > understand it, i have thousands of lines of code lying around here which
> > disproves it.
>
> I looked in the XML and XML Namespaces spec and couldn't find such a
> form. Then I looked in the Infoset, just in case. I couldn't find it
> there either, but I did find plenty of tuples. I found a way to
> infer what the name is in terms of it being distinct from other
> names (essentially how expnaded names work in XPath), but I can't
> easily write it down or inscribe it, say on a piece of paper, though
> I'm can use James Clark's {} idiom. Really, I'm interested in the
> Namespaces specs model of an XML element,
namespaces in xml does not specify how names are modeled. it specifies how
they are encoded.
> not cl-xml's object model
> of the Namespaces's specs model of an XML element. The point is
> this: I don't want an encompassing OM (even if it is in clisp) to
> protect me from the details of imho a cost-ineffective standard, I
> want the standard exposed, in the hope that people will stop
> suspending their technical judgement when it comes to using
> namespaces in the first place.
>
> Btw, I went to http://www.cl-xml.org/ - how do I download cl-xml?
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.
>
> >> - technically the XML grammar won't allow it.
> >
> > please amplify. it is not clear how the grammar places this constraint on the model.
>
> URI references can contain characters not allowed in names, so
> cannot be used directly as namespace prefixes. Therefore, the
> namespace prefix serves as a proxy for a URI reference. Prefixes are
> a workaround - they're not even syntax sugar.
>
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.
i repeat, please amplify. it is not clear how the grammar [for the encoding]
places [the claimed] constraint on the model.
...
|
