Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 9, 2005, at 4:54 PM, John Boyer wrote:
>> so I hope you forgive me for rejecting *identified* as having
>> the meaning you suggest.
>
> Fair enough.  The only problem I have with it is that this is
> what the word means in the dictionaries to which I have access
> as well as in computer science texts.
>
> So, given the field we're in, 'identified' is the wrong word to use
> to achieve your interpretation.  I think your interpretation
> would correspond more to
>
> a collection of names "[currently] associated with" a URI

Umm, I've already quoted text on this mailing list from a
dictionary that directly contradicts what you said above, but
that doesn't matter since it has been answered normatively:

<http://gbiv.com/protocols/uri/rfc/rfc3986.html#sec_1_1>

   Identifier

     An identifier embodies the information required to distinguish
     what is being identified from all other things within its scope
     of identification. Our use of the terms "identify" and
     "identifying" refer to this purpose of distinguishing one
     resource from all other resources, regardless of how that purpose
     is accomplished (e.g., by name, address, or context). These terms
     should not be mistaken as an assumption that an identifier
     defines or embodies the identity of what is referenced, though
     that may be the case for some identifiers. Nor should it be
     assumed that a system using URIs will access the resource
     identified: in many cases, URIs are used to denote resources
     without any intention that they be accessed. Likewise, the
     "one" resource identified might not be singular in nature
     (e.g., a resource might be a named set or a mapping that
     varies over time).

   A URI is an identifier consisting of a sequence of characters
   matching the syntax rule named <URI> in Section 3. It enables
   uniform identification of resources via a separately defined
   extensible set of naming schemes (Section 3.1). How that
   identification is accomplished, assigned, or enabled is
   delegated to each scheme specification.

>> In my opinion, you should put aside the process issues and state
>> clearly what the technical benefits/drawbacks are of allowing a
>> new name to be added to an existing namespace.
>
> OK.  For one, if XML markup that was signed can be processed
> differently after the signature was affixed relative to when
> the signature was affixed, then XML signatures becomes insecure.

Well, no, they just wouldn't work.  So we should list that as
one of the drawbacks because such processing is required by
the presence of a new attribute even though that new attribute
does not appear within the signed content, right?

I believe it is an error in the digital signature specification
to specify an algorithm that is impacted by changes outside
the content (such as any changes influenced by context). That
error should be fixed regardless of the namespaces discussion.

>> Merely claiming "it is defined that way in Namespaces" doesn't
>> really argue for anything more than changing the Namespaces
>> recommendation to better suit the architecture.
>
> Merely claiming that it is defined a particular way in namespaces
> doesn't merely argue for a namespace erratum.  It argues that
> either a namespaces erratum be issued (and fixes to any specs
> that may have counted on the meaning being corrected) OR for
> correcting the use of namespaces within the W3C going forward.

Right, one or the other (the other being less).

> The job of the TAG is to think about all the Recs they have
> and choose.

No, the TAG is not bound by existing Recs.  We are here to help
the WGs make forward progress towards the technical nirvana of
the W3C mission.

> This thread started out because a large number in the W3C
> community did not even believe that a change was required,
> other than an erratum from some obscure little spec.  Even
> the suggestion that a fix could occur by an erratum to
> Namespaces is significant progress.  Still, it'd break things.

Yep, omelette all over the place.  If you know of more examples
of breakage, please continue to send them to the list.  At some
point we just have to decide what is better: the breakage as
described or the ability to extend existing namespaces.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Thursday, 10 February 2005 02:30:23 UTC