Re: Layering XPath/XSLT namespaces is unacceptable

At 5:16 PM -0500 6/14/00, Al Gilman wrote:
>At 04:31 PM 2000-06-14 -0400, Michael Champion wrote:
>>
>>OK, but I'm not sure how this is affected by my perceived need to keep XML
>>and XPath/XLST on the same page as far as namespace semantics are concerned.
>>I'm beginning to feel as though only people with near-genius IQ's will ever
>>be able to figure out the accessible, internationalized, semantic Web well
>>enough to actually *use* it, however ... The more we can hold constant --
>>such as forbidding relative URIs in namespace names throughout the *core* of
>>the XML spec family -- the more likely this stuff is to be implemented and
>>used by ordinary mortals.  Can you clarify/simplify the implications of this
>>that concern you?
>>
>
>What concerns me is having the syntactic foundations make things impossible.
>
>If it's impossible in the core syntax, it can't be added later.  It's just
>GONE.
>
>That is the beef with forbid.

Actually, forbid leaves things more open. Currently relative URI 
references are allowed with a well-defined, but confusing comparison 
criterion (literal comparison). If we deprecate and later forbid 
relative URI references, or forbid them right now, and just deal with 
the fallout of the seemingly small number of documents that would 
break, then we actually have cleared the decks so that relative URI 
references can be introduced in a new version of XML, with a 
well-thought-out semantics.

This discussion has perhaps proved that absolutization is not a quick 
fix that will make everyone happy, because even people who think that 
fetching resources from namespace URIs is a good idea, differ as to 
what is needed to make it effective. TBL believes that there is 
benefit in making such retrieval standard procedure even without 
defining what the results should be. Rick Jeliffe and I believe that 
without a protocol defining what is returned, this is a step 
backwards. In either case, the issues that need to be discussed there 
seem not to have easy answers.


>Is that clear enough?
>
>The knock on relative URI-references is a semantic concern.  Deal with it
>in semantics.  Don't break the simplicity of the syntax to cure this
>semantic concern.  It's a meat-axe solution.

It's not at all clear to me that this is true, and I remain 
persistently confused as to your notion of semantics. XML is _all_ 
syntax, and that's one if its major virtues as a standard; at the 
same time of course, it's all about enabling an infinitely-expanding, 
detectable universe of semantic spaces.

>Dave Kesselman has referred to a 90:10 rule or some would even quote 80:20.
>  This is out of place in defining the syntactic core.  There is no place
>for disallowing even 10% of candidate applications in the syntactic
>foundation.  That's the point.  The easy should be _easy_ but the hard
>should be possible.  Not only the easy should be possible.

I've not seen any serious examples yet of anything that anyone knows 
how to do today that would be blocked by a "forbid" strategy. If we 
forbid now, we have that syntax available in the future once we know 
what we want to do with it.

>By the way, forbid is not keeping things constant.

There's no reason that one can't refer to the definition of a UIR and 
not a URI reference and not be consistent (I'm assuming that by 
"constant" you meant consistent, as otherwise I can't understand what 
you're saying).


>Fixing XPath so one can get at the literal namespace attribute sounds like
>it has a reasonable claim to restoring continuity and orderly layering.

It seems to add complexity with no clearly defined use case. The few 
examples of documents that user relative URI references in namespace 
declarations do not move me very much. John Cowan believes as a 
matter of principle that even one document is justification for 
keeping the old syntax legal, but I'm not convinced. Incompatible 
changes are sometimes the least-disturbing way forward.

And of course a strategy like "deprecate now, forbid in a new rev, 
and leave it to future versions to re-enable relative references if 
they are needed," even avoids offending that scruple directly, though 
it does impose a burden. I'd expect almost everyone in the world to 
immediately jump to namespaces 2.0, given the practical impact, as 
seen from the discussion so far, so in practice, I don't think it 
makes any difference.

>Forbid is just tinkering.

It's just a way to reclaim the syntax for thoughtful, planned re-use 
rather than hastily resolving the problem in a way that we may well 
regret.

We need not recapitulate the whole history of the namespace 
recommendation in the debate of this single issue, unless we want to.

   -- David
-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Wednesday, 14 June 2000 18:14:05 UTC