Re: On, and on, and on... was: Mechanism, not policy [was: Attribute uniqueness...]

"David G. Durand" wrote:
> 
> At 4:59 PM -0500 6/7/00, Dan Connolly wrote:
> >David Carlisle wrote:
> 
> >SNIP
> 
> >  > No. You always know whether a a string is being used as a namespace
> >>  name or as a resource identifier, so the fact that these two disjoint
> >>  concepts happen to use the same set of strings is no problem.
> >
> >Of course it's no problem... it's something to be exploited!
> 
> Once there's an interoperable way to handle multiple schema languages
> and definitions, it can be exploited. Without the proper MIME-types
> (to enable content-negotiation), or a catalog format (to enable
> indirection), such dereferencing creates more interoperability
> problems than it solves. Rick Jelliffe has explained this very
> clearly.
> 
> For an example of a system that provided the proper hooks, but
> insufficient sets of standard data formats, feel free to read about
> HyTime. While HyTime had hooks for data format labelling, the lack of
> a populated namespace made those hooks much less useful than they
> could have been. Note, that I'm not claiming that this was the
> only/major problem with securing adoption for HyTime, just a
> contributing factor.
> 
> >  > You may _wish_ the namespace to be the resource identified by the
> >>  namespace name considered as a URI, but in general (and probably
> >>  always) that is not the case.
> >
> >Yes, I do wish it were so, and I sincerely hope we will remove
> >the typo from the namespace spec that says otherwise.
> 
> This misrepresents the history significantly. There was a typo that
> allowed relative URI references, in an attempt to allow only for the
> presence of fragment identifiers. The fact that URIs, as used for
> namespaces, were not required to have any dereferencing semantics was
> a clear and consistent goal of the group working on the standard, and
> of Microsoft in proposing it (at least from an early date). The fact
> that you have consistently disagreed with this notion is _not_
> justification for calling it a "typo".
> 
> >  > I see no way that the namespace
> >>  mechanism could possibly be altered to make it the case.
> >
> >The mechanism is pretty much fine as is, except in the way
> >that implementations treat relative URI references.
> >
> >Just change
> >       ns_name = elem.getattr('xmlns')
> >to
> >       ns_name = urlparse.urljoin(baseURI, elem.getattr('xmlns'))
> >in the implementations, and that's it.
> 
> Or simply forbid relative URI references, and that's it.
> 
> Or simply deprecate relative URI references, and slate them for
> destruction, and that's it.
> 
> Or simply live with the status quo, and explain the dangers of
> relative URI references in that case, and deprecate them permanently.
> 
> Or simply leave the status quo, and point out the dereferencing a
> relative URI reference for a namespace is officially undefined, leave
> people to do what they want, and that's it.
> 
> Or....
> 
> There are many "simple" solutions, none of them satisfactory to everyone.

His claim was there there were no solutions. Only one example
counters that claim. You have provided others, and I agree
those are in the solution space.


> I think the space of possible solutions has been clear since the
> beginning of the discussion, before, indeed, thanks to Michael
> Sperberg-McQueen's summary in the original discussion (that followed
> the established procedure for resolving questions like this).

I haven't seen any radically new solutions in the discussion,
but I have seen considerable changes in what is "clear" to
various parties.


> We continue to have basic disagreements as to which solutions are
> most tolerable, and which issues are important, like ensuring that,
> if the recommendation is revised, documents created according to the
> letter of the law will remain conformant at least to that version of
> the standard.

Yes...

> We already had a vote of the membership,

no, we have not. We had a straw poll.

> which is the usual way to
> resolve an issue when consensus is failing due to disagreements in
> principle.

I don't think there was anything usual about the straw poll.

> It's rare that anyone can happily compromise on their
> principles, and that's why voting is available: to decide the
> question when someone simply has to lose the argument, and a decision
> has to be made. We could also have an autocratic resolution, where a
> choice is simply imposed from the top-down.
> 
> I have been dipping in and out of this discussion, and in addition to
> its internal repetitiveness, I have seen nothing that was not
> discussed ad nauseam in the previous W3C-internal discussions.
> 
> We've now made this formerly internal debate public. I don't see that
> there's enough agreement to warrant overturning the decision already
> made once,

Which decision? I recall a decision of the XML CG to forbid relative
URI references in namespace declarations, which the XML plenary wasn't
satisifed with. Then there was a decision, made by the plenary chair,
informed by a straw poll, to take a sort of "literal string"
interpretation, which many are not satisfied with because, among
other things, it seems to say that the specification of the
namespace-uri() function in XPath needs to be changed.

I'd like to reach closure soon too. But I'd like to avoid
papering over significant differences while we're at it this
time, if we can possibly afford to.

> but that's just my take on it. I can live with things as
> they are, though I'd prefer to require URIs for namespaces, and
> abandon URI references as a bad idea for the moment. If they come in
> later one, with the appropriate protocol elements in place to support
> their use and the dereferencing of namespaces, then that's fine.

I could live with that.

> But the debate has reached a state of terminal redundancy.

I'm satsified that I understand your position, and between
you and me, I'm pretty sure we could choose a solution that is
mutually acceptable.

But I'm not sure I understand the position of many other
participants in this list; I continue to see
misunderstandings of the essential specs, such as the
distinction between resources and entities[1], and
I find it worthwhile to (try to) clear these up[2] and
understand the arguments better.


[1] Graham Klyne's message of Thu, 08 Jun 2000 09:05:56 +0100
http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0362.html

[2] my message of Thu, 08 Jun 2000 09:28:10 -0500
http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0374.html

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 8 June 2000 13:15:41 UTC