Re: Grinding to a halt on Issue 27.

Roy Fielding writes:

>>  No, the heart of the matter is whether the XML 
>> Namespaces specification has the authority to 
>> say that normalization is not allowed, which is
>> what the text currently says because it is 
>> over-specifying the matter.

I wonder whether we need to distinguish the license we might give an 
application to do normalization, vs. any latitude in the mechanisms of XML 
and Namespaces themselves.  Consider this example:

        <e p:a="1" q:a="2" xmlns:p="http://example.org/x" 
xmlns:q="http://EXAMPLE.ORG/x" />

Does this or does it not violate the Uniqueness of Attribute constraint of 
Namespaces 1.1 [1]?  I hope we have an unambiguous answer to that 
question.  Roy, are you implying that there should be lattitude for some 
processors to accept the document and others not?  I suggest that for 
Uniqueness of Attributes and similar purpose we need a single, 
interoperable answer.  The document is either OK or it's not.  My 
preferred answer would be "strcmp applies, the above document is OK".  In 
that sense, the namespaces 1.1 CR  is OK as it stands, I think. 

I have no objection to a formulation that grants lattitude for higher 
level applications to consider the two URIs above to be the same (per 
2396), and thus at the application level to consider the two attributes 
above as being duplicates.  I don't think I want to require XML processors 
to detect them as duplicate, or for XML schema to decline to allow 
separate declarations for them.  So, the core XML mechanisms will 
unfortunately do a poor job of helping applications to do the right thing. 
 This all seems to be an area where the demands of both performance and 
manageability (I.e. the difficulties in deploying new software to handle 
URI canonicalization rules for newly invented schemes) make it difficult 
to do what would otherwise be architecturally correct:  to follow RFC 2396 
in all cases where URI comparison is to be done.  So, we should not be 
surprised that the solutions are in some respects ugly;  the core XML 
mechanisms will be somewhat out of sync with what might otherwise be 
desireable.

Noah

[1] http://www.w3.org/TR/2002/CR-xml-names11-20021218/#uniqAttrs

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 29 April 2003 19:24:53 UTC