[xsd-users] Attributes not found from imported schemas

[Boris Kolpackov]

Hi Mark,

mhoffm1060 at aol.com <mhoffm1060 at aol.com> writes:

> Another question if I may: is this usual in the XML world (to ignore
> additional imports of the same namespace)?

I know that this is how Xerces-C++ works. I am also pretty sure that
Xerces-J works the same way since they have a similar XML Schema
processor architecture. I don't know about other XML Schema
processors but I would imagine most of them use namespaces to identify
grammars (see below). There is an online service that allows you to
test several XML Schema processors. You may want to try that:

http://www.mel.nist.gov/msid/XML_testbed/validation.html


> I was reading the spec (http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
> see Note an the end of section: 4.2.3 References to schema components across
> namespaces?), and while the spec allows this, it mentions that this
> is risky behavior.

The only proper way to support multi-import'ing is to parse every file
and detect duplicate declarations/definitions. There is no way to use
schemaLocation to figure out if it is the same resource because of
aliasing, etc. So while the spec may say it is risky, processor
implementers may say that it's the only reasonable way to do it
(performance and complexity-wise).


> I'm asking because the entity that we receive these schema from declare
> that they are compliant to the above spec? ( Apparently they are ), but
> if it is an industry practice to ignore the later imports, I'll have
> some leverage to get them to change the structure.

I think, especially in case of XML Schema, it is not very smart to use
the spec as an excuse to do things in ways that don't work across widely-
used schema processors.

Also, for what it's worth, we have a large repository of schemas, both
public and proprietary. I haven't seen a single schema that had the
same property as yours. This makes me think that the industry generally
avoids having such a structure in their schemas for some reason.

Boris