Namespaces aside, absolutizing is none of _X_Path's business

At 05:50 PM 2000-06-03 -0400, Clark C. Evans wrote:
>
>To clarify,  I am concerned about the XPath specification *redefinition* 
>of the the namespace identity operation by specifically requiring that 
>the nsattrib be absolutized before it checked byte-by-byte.  IMHO,
>either the absolutization requirement should move from the XPath spec 
>into the NS spec, or it should be removed from the XPath spec.  
>
>This example of *layering* is not consistent and coherent.
>

Going into hypothetical mode, here.  That is to say, without attempting to
render judgement on the framing of this discrepancy formulation, let's just
explore:  "Assuming that this is a valid beef, what avenues are open for
remediation?"

John Cowan raised an interesting idea when he expanded the InfoSet options
from _either_ literal or absolutized to "either or _both__."  It would be
tempting to say in juridical hindsight that:

- In automatically transforming the ns-attr to absolutized form, XPath is
straying into InfoSet turf.  XPath should be walking, here, whatever graph
is determined to be the InfoSet for the document.

- The InfoSet model that it presumes breaks processing in accordance with
the normative provisions of the Namespaces Rec.

and the repair would be

* InfoSet adopts the 'both' option by accepting the ns-attr text value
literally into the InfoSet and capturing into the InfoSet whatever BASE
information is recoverable from the context in which the InfoSet is extracted.

* XPath retreats and is able to address the literal ns-attr as an InfoSet
memeber or "information item within the XML fabric of the document."  

* Layered applications seeking to process the ns-attr as a semantic
URI-reference will have the support [should the ns-attr be of a relative
URI construction] of BASE information from the XML document context as an
aid in completing the 'recover resource' transaction.

By the way, It doesn't seem we need all the global context to determine
what to do on this point.  On general architectural or
separation-of-concerns principles, it would seem that XPath should back off
on the absoutizing anyway.  

XPath is [in my naive perspective] about how to trace and write out paths
whithin XML document structures.  It should not fold in a segment of
"following the path through URI space" as an un-severable component of an
XPath-atomic path segment.  The boundary point where one turns the corner
from traveling through XML space and starts traveling through URI space
should be honored in the scoping of XPath functionality.  The absolutizing
of a relative URI is a step through URI space, not XML space.  It is in a
separate major partition of the architecture from the path-tracing through
XML syntax; a different leg of the three legs of the Web milking stool:
hyper-media, URIs, multiprotocol/multiformat clients.  The _Path through
the XML_ ends at [the literal text value of] the attribute.

So, no matter how right or wrong Namespaces was to create this thing that
looks like a URI-reference, and _almost_ works like a URI-reference; XPath
was wrong to inject absolutizing at this point.  It is clearly not part of
the XPath function and shouldn't be in the implicit InfoSet model that
XPath runs over.  Changing that is repairing an erratum in XPath,
independently from what one may think about the Namespaces functionality
that it breaks.


You may have noticed that I am not totally keen about the foundation that
Namespaces has laid for us to build a semantically rich web on.  But I
would not be inclined to think that sustaining what looks like an
off-the-reservation adventure on the part of XPath is the way to fix it.

Al

Received on Sunday, 4 June 2000 13:40:12 UTC