Hi,

Some time ago we have a similar problem in a project with one schema per
"concept" aproach project, we create almost 3500 schema-s. (GEL-XML ).

The XML-Spy validator is so different (so good)  to other parsers, so you
have o create (readable) schema-s  for all parsers implementations, even
worse to all code generators (e.g. jaxb, .net, etc), in order to be usable-s
in the real world.

The solution was to ban redefines and to use hierarchical proxy-schema-s
(libraries), so the parser read one time and only one time the imported
library with an unique namepace and/per location.

The other (administrative) solution was to define one unique parser-brand to
validate the schema-s.

Cheers,

César



On Tue, Sep 29, 2009 at 9:47 AM, Henry S. Thompson <ht@i...> wrote:

> -----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 <http://xsd3/>" xmlns:x="http://XSD3<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@i...
>                       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-----
>
>