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

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.

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).

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.

We already had a vote of the membership, which is the usual way to 
resolve an issue when consensus is failing due to disagreements in 
principle. 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, 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.

But the debate has reached a state of terminal redundancy.

In the vulgarian wisdom of the vernacular:

It's time to Sh*t or get off the pot.

   -- 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 Thursday, 8 June 2000 11:24:23 UTC