Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: implementing redefinitions

From: "Michael Kay" <mike@--------.--->
To: "'Kasimier Buchcik'" <kbuchcik@---------.-->, "'XML-SCHEMA'" <xmlschema-dev@--.--->
Date: 8/13/2005 10:37:00 AM
> 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



From K.Buchcik@4... Mon Aug 15 11:12:18 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1E4ct8-0005wg-Ov
	for xmlschem


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent