RE: Grinding to a halt on Issue 27.

Joshua Allen writes:

> True; if they happen to use the same schema *and* the
> same schema-validation tools, and they do make sure
> that the schema is associated with a namespace name
> explicitly (not always the case), then they ought to be
> bug-compatible, yes.

I'm a little confused:  are you suggesting that there are any conforming 
(or even plausible buggy) implementations of XML schema that would 
validate the attribute:

        <e2 p:a="1" xmlns:p="http://example.org/x"/>

against a schema with:

        <xsd:schema targetNamespace="http://EXAMPLE.ORG/x">
          ...
            <xsd:attribute name="a">...</xsd:attribute>
          ..
        </xsd:schema>

I hope the schema recommendation is quite clear that doing such a 
validation would be incorrect, though I will defer to Henry Thompson, who 
tends to know these things best (Henry: you may need to check the TAG 
archive to get the context on this.)  I've certainly never heard it 
suggested that schema processors had any latitude to do scheme-sensitive 
"canonicalizations" or the like at any of the processing steps that 
pertain to this example (I.e. starting with the characters literally 
present in the targetNamespace attribute, prepare a schema component for 
the attribute declaration with a value for its {target namespace} 
property, then use that property to resolve the declaration to be used in 
validation.)  Since the URI in the example input infoset is already in 
canonical form, I think it's fair to say that nobody would suggest that 
its input infoset would somehow turn out to have the DNS name in uppercase 
either.  So if neither the mechanisms of schema nor the processing of the 
input document into an Infoset causes the namespace strings to match, I 
think it's clear that the attribute doesn't validate. 

Similarly, a schema declaring targetNamespace="http://EXAMPLE.ORG/x" could 
import another declaring http://example.org/x and these would in all 
respects be treated as separate target namespaces by the Schema 
recommendation.   You could use such a combined schema to validate both 
the attributes in the original example:

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

I'm not for a minute saying it would be good practice for users to do 
this, but I'm very surprised to hear a suggestion that there is any 
ambiguity or question of correct behavior for conforming processors.

Skirting for the moment Roy's question about whether the mechanisms of 
Namespaces or Schema are intended to solve a syntactic vs semantic problem 
(I'm not sure that's a distinction that the XML, Namespaces, or for these 
purposes Schema recommendations tend to draw), I think we need clear 
answers to certain questions:  which documents are unambiguously well 
formed?  which ones are unambiguously in error?  for which do processors 
have discretion to decide?  Is element <e> above conformant with 
namespaces 1.1 or not?   Similarly in the case of validation examples such 
as the e2 example above:  my view is that the clear intention of the 
schema workgroup was that the attribute not be validated by the example 
schema.  If the recommendation is unclear on that point, I would view it 
as an erratum.  In any case, I would strongly argue for a single answer, 
and to avoid a situation where conforming processors have the option to 
validate or not.  Thank you.
 

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





        "Joshua Allen" <joshuaa@microsoft.com>
        Sent by: www-tag-request@w3.org
        04/30/2003 04:13 PM
 
                 To: "Paul Prescod" <paul@prescod.net>
                 cc: <robin.berjon@expway.fr>, <www-tag@w3.org>, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
                 Subject: RE: Grinding to a halt on Issue 27.



> > Two different divisions in the same company may use what they
*think* is
> > the same namespace for their documents (and when they click on the
> > namespace name it sure enough connects them to the right place, so
how
> > are they to know differently?).
> 
> If they share schemas and schema-validate the schema will tell them
> differently. If they don't schema-validate then they are liable to run

True; if they happen to use the same schema *and* the same
schema-validation tools, and they do make sure that the schema is
associated with a namespace name explicitly (not always the case), then
they ought to be bug-compatible, yes.

Received on Wednesday, 30 April 2003 17:21:00 UTC