W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

[Bug 2218] R-226: Must the content of schemaLocation be a resolvable URL?

From: <bugzilla@wiggum.w3.org>
Date: Wed, 13 Feb 2008 00:01:22 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1JP53y-0005B7-5M@wiggum.w3.org>


------- Comment #4 from noah_mendelsohn@us.ibm.com  2008-02-13 00:01 -------
If I'm looking at the right part of the proposed revised spec, it says:

> It is not an error for such an attempt to
> fail, but failure may cause less than complete
> ·assessment· outcomes.

The phrase "less than complete" doesn't seem quite right.  Let's say I list a
few schema documents in schemaLocations and some of them resolve and some of
them don't.  I think the possible consequences include:

* Things that should have validated don't (e.g. because we were doing strict
validation and couldn't find a declaration)

* Things that shouldn't validate did (e.g. the missing schemaDocument would
have redefined some type, restricting it to validate less than the original)

* Schema composition failed (e.g. some type referenced another as its base, and
the definition for the base was never found)

* In the case of LAX validation, an element that would otherwise have been
validated against an expicit element declaration was not.

* Probably others.

I can see why we might describe the LAX case as resulting in a "less than
complete outcome", but I'm not convinced that phrase is the right choice for
the other cases.  If my analysis is correct, I wonder if it might be better to

"...but failure may affect the determination of validity for some or all
elements or attributes, may result in validity not being assessed at all for
some or all elements or attributes, or may create a situation in which a schema
suitable for use in assessment could not be constructed."

Wordy, but more accurate I think.  If someone can propose something shorter
that seems effective, I'd probably be in favor of that.  

Received on Wednesday, 13 February 2008 00:01:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:07 UTC