Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

XMLSchema at XML4Pharma writes:

> Our extension mechanism is based on the "import" and "redefine"
> elements of XML-Schema.

> [see] http://www.altova.com/forum/default.aspx?g=posts&m=1000005665

> We now want to escalate the issue to the W3C itself, and would like
> to know what the mechanism is to do so.

We can only try to clarify and persuade -- we have no authority to
compel anyone.

I can only explain how/why XSV behaves as it does, and offer my
understand of the spec.

The spec. allows (note, _not_ requires) implementations to ignore
attempts to import schema documents for namespaces for which a schema
document is already known:

  "Given that the schemaLocation [attribute] is only a hint, it is
   open to applications to ignore all but the first <import> for a
   given namespace, regardless of the ·actual value· of
   schemaLocation, but such a strategy risks missing useful
   information when new schemaLocations are offered." [1]

XSV follows this strategy.  In the case of the CDISC schemas, this
means the xs:import of ODM1-2-1.xsd is skipped, because a schema
document (namely define-1.0.0.xsd) is already known for the odm/v1.2
namespace.

In the case of the Altova example, this means the xs:import of
XSD2.xsd is skipped, because a schema document (namely XSD1.xsd) is
already known for the no-target-namespace case.

In other words, in neither case is the behaviour of XSD to do with how
it resolves redefine/import conflicts.

But note that any schema processor which _does_ follow all
schemaLocation hints, and therefore does import multiple documents for
the same target namespace, is perfectly conformant as well.

So, what about redefine/import conflicts?

The spec. contains no explicit guidance.  Furthermore, it is impossible to
construct an example which would provoke such a conflict in XSV,
because it would require two imports of the same targetNamespace (the
reason for this is left as an exercise for the reader -- if I've
missed a way to bring this about, I owe the first person to point out
how a beer :-).

We can however construct an example of conflicting redefine/include in
XSV, by making small modifications to the XSD3.xsd document given in
the Altova example:

XSD3.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified" attributeFormDefault="unqualified"
  targetNamespace="http://XSD3" xmlns:x="http://XSD3">
<xs:include schemaLocation="XSD2.xsd"/>
<xs:include schemaLocation="XSD1.xsd"/>
<xs:element name="elt" type="x:CT"/>
</xs:schema>

We're now chameleon including/redefining, and the result works with
XSV 3.1, regardless of the order of the two include statements.  By
'works', I mean
 a) The schema is judged to be OK;
 b) The instance is judged to be bad.

I read the spec. as _requiring_ this behaviour, because it says

  "The modifications have a pervasive impact, that is, only the
   redefined components are used, even when referenced from other
   incorporated components, whether redefined themselves or not." [2]

What this means is that no conflict occurs between the redefined and
non-redefined components, because the later are not part of the schema
used for validation.  The same argument seems to me to apply to the
redefine/import case.

I would be interested to know how other products behave with the
redefine/include conflict example given above.

Summary: I believe the spec. intends the redefine semantics to 'trump'
the include and import semantics wrt which components are present in
cases of conflict, but I do not disagree that this is not so clear as
to be uncontestable.

I also think it is unfortunate that all implementors cannot agree on a
single interpretation.  If it is true, as alleged, that the situation
is that many implementations agree on the interpretation but one does
not, that's particularly unfortunate.

ht
  
[1] http://www.w3.org/TR/xmlschema-1/#src-import
[1] http://www.w3.org/TR/xmlschema-1/#modify-schema
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKwh4EkjnJixAXWBoRAsVuAJ9PFjtJMUNAycnVwR3WlFIrJVCI3wCfVeQX
c0UQGS14hYnXrTq2lW2ADVE=
=m9RM
-----END PGP SIGNATURE-----

Received on Tuesday, 29 September 2009 14:48:07 UTC