- From: <keshlam@us.ibm.com>
- Date: Wed, 12 Jul 2000 09:46:34 -0400
- To: xml-uri@w3.org
>>If it returns different results each time, or different >>data for each user, or keeps an access count or other side-effect data, >>that's up to it and is out of the scope of the URIs and schemes. >So whose scope is it? It's the scope of whoever defines the schemes and/or the services that respond to those schemes. URIs only define an address space. The objects that occupy that address space have their own specifications. > Does this imply that Namespaces in XML was reckless >for failing to specify further expectations? No. It reflects the fact that Namespaces chose a specific problem to address -- that of providing a naming convention which will work across document types (including non-validated documents) -- and left the field completely open for other folks to build on that base. Namespaces are a syntax enhancement. That's all they are. It may or may not be desirable to associate additional information with them, but the namespace spec itself says nothing about what information may be associated or how that association is asserted and processed; at most, it provides a hook upon which further specs may be built. We may adopt a standard for how to bind namespaces to metadata, and what kinds of metadata can be bound to. Or we may adopt several, to suit different needs (just as no one XML language fits all tasks). Or we may continue to see experimentation with custom solutions. The Namespace spec has no opinion on that, any more than the XML 1.0 spec does. > Or that we should take >literal comparison at face value and assume that literals are all the >expectations we should have? That's largely independent of the question of meaning... unless we reach agreement that one of the meanings that the W3C wants to actively support actually requires relative syntax in namespace declarations. At that time, we will have to decide how those values are to be stored, presented, and compared. I think it's clear that we need a clearer consensus on an architectural vision before attempting to nail down the behavior of specific syntax. It's probably worth continuing to explore that issue. In the meantime, the Deprecate/Undefined proposal seems to be the only stopgap we're likely to agree upon -- it explicitly admits that more work is needed in this area before any definitive statements can be made, tells folks who require portability what values to avoid until this is resolved, and leaves room for experimentation. It also leaves room for divergence. But I think our problem is that there's already a divergence of expected applications. Some group needs to sit down with these, work through them, determine what their real requirements are (independent of the syntax in which those requirements are addressed), and then decide how the behaviors which address those requirements are to be expressed in XML. Personally, I suspect that a serious attempt to go back to first principles and basic requirements will discover that relative syntax in namespace declarations is, in fact, not necessary and causes more trouble than it solves. But we won't know until we have a real design in progress. Until then, we're just waving our hands -- which is a bad way to try to fly.
Received on Wednesday, 12 July 2000 09:47:30 UTC