Re: Layering XPath/XSLT namespaces is unacceptable

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.

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.

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. 

By the way, forbid is not keeping things constant.

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

Forbid is just tinkering.

Al

Received on Wednesday, 14 June 2000 17:00:13 UTC