RE: implementing redefinitions

> Reading the spec, plus the mail archives I learned - and wonder -
> the following:
> 
> - Redefines are pervasive with regard to references. I.e.
>   all references to components, wherever they may be
>   will resolve to the redefined components only.

Yes: except that the phrases "all references" and "wherever they may be"
demand some notion of a processing model which can't be found in the specs
themselves. For example, in a database environment I wouldn't expect that
running a query that does "import schema" on a schema that contains a
redefines causes the schemas stored persistently in the database to change.

I'm struggling with this a bit in Saxon. I think the rule I have to adopt is
that once a schema component has been used for validating documents that
exist in the current "environment" (that is, whose PSVIs I can reach),
redefinition of that schema component is banned.

> Tests
> -----
> 
> I would _really_ be nice if you could spare the time to
> comment the results of the tests.
> 
> Validation of instance.xsd with final.xsd
> --------------------------------------------
> Xerces-J:
> base.xsd:3,29: (Error) sch-props-correct.2: A schema cannot 
> contain two
> global components with the same name; this schema contains two
> occurrences of ',base_fn3dktizrknc9pi'.
> 
> XSV: no errors
> 
> This would fall into the category: first apply redefinitions, then
> include the components. Looks like this should not fail.

Saxon says: Error on line 3 of file:/c:/temp/derived.xsd:
  Duplicate type {base} - previously defined on line 2 of
file:/c:/temp/base.xsd

If you include two schema documents and they contain different schema
components with the same name, then you get an error. That's what's
happening here, and I believe this error message is reasonable.

> 
> Validation of instance.xsd with final2.xsd
> ------------------------------------------
> Xerces-J:
> final2.xsd:13,30: (Error) sch-props-correct.2: A schema cannot contain
> two global components with the same name; this schema contains two
> occurrences of ',base'.
> 
> XSV: no errors
>

Saxon says:
Error on line 10 of file:/c:/temp/final2.xsd:
  Duplicate type {base} - previously defined on line 3 of
file:/c:/temp/final2.xsd
Error on line 3 of file:/c:/temp/final2.xsd:
  Duplicate type {base} - previously defined on line 10 of
file:/c:/temp/final2.xsd

Again, I think this error is reasonable.
 
> 
> Validation of instance.xsd with final3.xsd
> ------------------------------------------
> Xerces-J:
> derived2.xsd:4,30: (Error) sch-props-correct.2: A schema 
> cannot contain
> two global components with the same name; this schema contains two
> occurrences of ',base_fn3dktizrknc9pi'.
> 
> XSV: no errors

Saxon:
Error on line 3 of file:/c:/temp/derived.xsd:
  Duplicate type {base} - previously defined on line 3 of
file:/c:/temp/derived2.xsd

> 
> Validation of instance.xsd with final4.xsd
> ------------------------------------------
> Xerces-J:
> derived3.xsd:4,30: (Error) sch-props-correct.2: A schema 
> cannot contain
> two global components with the same name; this schema contains two
> occurrences of ',base_fn3dktizrknc9pi'.
> 
> XSV: no errors

Saxon:
Error on line 3 of file:/c:/temp/derived.xsd:
  Duplicate type {base} - previously defined on line 3 of
file:/c:/temp/derived2.xsd

Saxon treats definitions as identical only if they are defined in the same
node in the same schema document.
> 
> Validation of instance.xsd with final5.xsd
> ------------------------------------------
> Xerces-J:
> base.xsd:3,29: (Error) sch-props-correct.2: A schema cannot 
> contain two
> global components with the same name; this schema contains two
> occurrences of ',base_fn3dktizrknc9pi'.
> 
> XSV: no errors

Saxon:
Error on line 2 of file:/c:/temp/base.xsd:
  Duplicate type {base} - previously defined on line 4 of
file:/c:/temp/final5.xsd
Error on line 4 of file:/c:/temp/final5.xsd:
  Duplicate type {base} - previously defined on line 2 of
file:/c:/temp/base.xsd
Error on line 4 of file:/c:/temp/final5.xsd:
  Duplicate type (NULL) - previously defined on line 2 of
file:/c:/temp/base.xsd
Error on line 4 of file:/c:/temp/final5.xsd:
  Duplicate type (NULL) - previously defined on line 2 of
file:/c:/temp/base.xsd

The multiple error messages are clumsy, but the meaning is fairly clear.
> 
> Validation of instance.xsd with final6.xsd
> ------------------------------------------
> Xerces-J: no errors
> XSV: no errors
> 

Saxon: no errors.

Michael Kay

Received on Saturday, 13 August 2005 08:36:46 UTC