W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2004

RE: [xml-dev] using more then one schema within one XML

From: Alessandro Triglia <sandro@mclink.it>
Date: Thu, 4 Nov 2004 16:37:38 -0500
To: "'John Cowan'" <jcowan@reutershealth.com>
Cc: "'Chiusano Joseph'" <chiusano_joseph@bah.com>, "'pat'" <pat@xvalheru.org>, "[Public XML Schema-DEV]" <xmlschema-dev@w3.org>
Message-ID: <006b01c4c2b6$84ed7f10$6702a8c0@aldebaran>



> -----Original Message-----
> From: John Cowan [mailto:jcowan@reutershealth.com] 
> Sent: Thursday, November 04, 2004 15:43
> To: Alessandro Triglia
> Cc: 'Chiusano Joseph'; 'pat'; 'XML :: dev'
> Subject: Re: [xml-dev] using more then one schema within one XML
> 
> 
> Alessandro Triglia scripsit:
> 
> > 4 xsi:schemaLocation and xsi:noNamespaceSchemaLocation 
> [attributes] can
> > occur on any element. However, it is an error if such an 
> attribute occurs
> > after the first appearance of an element or attribute 
> information item
> > within an element information item initially .validated. 
> whose [namespace
> > name] it addresses. [...]   
> > ---------------------
> > 
> > In other words, if a parser encounters a 
> xsi:noNamespaceSchemaLocation at
> > some place, then validates an element with no namespace, 
> then encounters
> > another xsi:noNamespaceSchemaLocation further on, it should 
> issue an error.
> 
> No, "it is an error" means that a document that does that is 
> in error.  There
> is no obligation on the part of a parser to notice the error 
> or to behave
> in any particular way.  


I have searched for all occurrences of "error" in Part 1, and I am surprised
by the result.

There is a key paragraph in 5.1:

---------------------------
The three cases described above are the only types of error which this
specification defines.   With respect to the processes of the checking of
schema structure and the construction of schemas corresponding to schema
documents, this specification imposes no restrictions on processors after an
error is detected.   However .assessment. with respect to schema-like
entities which do not satisfy all the above conditions is incoherent.
Accordingly, conformant processors must not attempt to undertake
.assessment. using such non-schemas.
---------------------------

The first sentence is not true, because there is at least another type of
error which this specification defines:  the error (in the instance)
specified in 4.3.2 regarding xsi:schemaLocation and
xsi:noNamespaceSchemaLocation.

The rest of the paragraph says that if a schema (or an XML representation of
a schema) has an error, it is not a schema, and must not be used as a
schema.  Even though the specification does not say what a processor must do
when it encounters an error in a schema (or in an XML representation of a
schema), it says what a processor must not do: perform assessment.

I haven't found any place in the Recommendation discussing the case of
*errors in the instance*.  (Again, the statement above regards strictly the
case of *errors in the schema*.)  

There is an interesting statement in clause 5 related to this issue:

-----------------------------
This specification distinguishes between errors in schema construction and
structure, on the one hand, and schema validation outcomes, on the other.
-----------------------------

The above is also not true, because there is a third kind:  errors in
instances.

I wonder what is the point in stating that "an instance has an error"
without specifying how this relates to the outcome of validation.
Intuitively, if an instance has an error, it is worse than invalid - it is a
non-instance, which cannot be validated.  Just like a schema that has an
error is a non-schema.  An "error" in the instance seems something half-way
between an XML 1.0 well-formedness error and a validity issue.

Why not just say that an overriding "xsi:schemaLocation" makes the whole
instance invalid?  Or alternatively, why not just say that an overriding
"xsi:schemaLocation" is non-significant but allowed?  Why was the term
"error" used at all for this case?

All the trouble comes from this use of the term "error" for something that
is wrong in the instance.  In all other cases, the term "error" is used for
something that is wrong in the schema.

Alessandro Triglia



> It can throw an exception, ignore the 
> new declaration,
> accept the new declaration, or make demons fly out of your nose.
> 
> -- 
> What is the sound of Perl?  Is it not the       John Cowan
> sound of a [Ww]all that people have stopped     
> jcowan@reutershealth.com
> banging their head against?  --Larry            
> http://www.ccil.org/~cowan
> 
Received on Thursday, 4 November 2004 21:41:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:40:23 UTC