Re: Layering XPath/XSLT namespaces is unacceptable

At 11:37 AM 2000-06-14 -0400, Michael Champion wrote:
>I've supported the notion of "layering", i.e., that specs built on top of
>XML might insist that their implementations absolutize namespace URI
>references even though relative URI references are deprecated, forbidden,
>literalized, or whatever in XML itself.  I still agree that this might be
>useful for RDF, but have become convinced that XPath/XSL must not "layer" a
>different namespace URI interpretation from XML's.
>
>This is based on an important practical consideration: XPath and XSLT are at
>the very core of what our company, and many others, use to build XML
>implementations and applications. An XSLT/XPath implementation should build
>upon the events/node-tree from the namespace-enabled XML
>parser.   Such a parser could (and in many cases does)
>intern names so that identical names can be comparied by
> reference.  If XSLT/XPath requires a different notion of
>"naming" than the lower layers, it invalidates work done
>by the lower layer.  

Please break this down into cases.

What we have got to is that comparison of namespace names across BASE
contexts is not safe to do with the literal attribute values alone in
ignorance of the context(s) if the literal values are of the syntactic form
of a relative URI-reference.

The InfoSet contains syntactic information as to the literal namespace
attribute and non-syntactic information concerning the BASE for the current
scope.

Are you suggesting that XSLT should be unaware of this information?

"naming" is a semantic construct which is always re[de]fined every time you
add a layer.  What is it that you feel should be invariant in the products
of the lower layer(s) in this process?

>Also, this would make it difficult for
>XPath results to be returned to another, othogonal service, since all of the
>names would be different...
>
>We see XPath/XSLT as core infrastructure items, which will
>be implemented in conjunction with the parser and
>schema validation system.  XPath/XSLT is *not* in
>the "application" layer and thus does not have the
>right to re-define the meaning of "qname".   RDF seems to use XML more as
>a serialization format, and hence *is* in the application layer,
>AFAIK.
>

Warning: we may have an accessibility problem, here.

Locking the standard method of view extraction for presentation [XSLT] to
being dumb text processing and not schema-aware would not [so far as we
know yet] comport well with defining document types which transform
gracefully into the user interface configurations required to support
people with disabilities.


I have spoken repeatedly about table semantics.  This is just a posterkid,
a case it is easy to talk about.  Having the view extraction flexible, so
that it takes its input from not a fixed, low layer but an abstract
interface which optionally rolls in the prior application of schemata,
would seem to be the desirable functional flow for "accessible by
construction" documents.  In particular, the output writer should ideally
have graph-to-tree, and not just tree-to-tree, capability.  We could
benefit from an ability to flow the application domain graph for the
document content into an audio-suitable output tree and not be stuck with
something reachable through tree transformations from the input tree that
is an accident of the GUI composition of the visual presentation.  

The requirements for an audio-suitable tree are stricter than for a
GUI-suitable tree, and we can't count on the author to have done much to
satisfy the stronger requirements for a narrative flow.  A domain model, if
the document type system links to it, can aid in reflowing the data without
breaking the message.  So the XSL input should be inclusive of cases where
it is applied with or without schema processing done first.

Or we may have something to talk about.

You may not mean to make the XML layer limited to what I call "dumb text
processing" i.e. syntax-directed transformation.  You mention schema
processing as inside the tightly bound in XML domain, but schema processing
is undefined at present.   I reserve the right to be cautious as to what
you may include or exclude in schema processing.  Would it cover the
definitions of table columns and headers-as-metadata?

Al

Received on Wednesday, 14 June 2000 16:07:08 UTC