Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Redefine and Import used together - is this valid?

From: "Michael Kay" <mike@--------.--->
To: "'Danny Vint'" <dvint@----.---------.--->, <xmlschema-dev@--.--->, <xml-dev@-----.---.--->
Date: 9/15/2006 6:38:00 PM

The rule imposed by XML Schema is that you can't use two different types
with the same name in the same validation episode. So you can't use a type
and its redefinition.

Many products have a schema cache of one kind or another. Whether such a
cache allows you to have more than one type with the same name is very much
implementation-defined, because the spec confines itself to the behaviour of
a single validation episode. Saxon, for example, will prevent you redefining
a type if the base type in the schema cache has already been used for
validation, even in a previous episode.

Michael Kay
http://www.saxonica.com/ 


> -----Original Message-----
> From: xmlschema-dev-request@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Danny Vint
> Sent: 15 September 2006 16:41
> To: xmlschema-dev@w...; xml-dev@l...
> Subject: Redefine and Import used together - is this valid?
> 
> 
> I have the following situation:
> 
> 1) Base industry standard schema (ACORD)
> 2) A schema that imports the ACORD schema (to reuse data 
> types and some
> elements) that defines my organizations new elements and 
> aggregates (ACME)
> 3) A schema that redefines #1 ACORD to modify existing 
> elements and aggregates to include my new ACME elements.
> 
> I then have a docuemnt instance the references #3.
> 
> Xerces and XSV say my document and schemas are valid. When I 
> run this with XMLSpy">XMLSpy I can validate the schemas standalone, 
> but when I try to validate the document based upon the 
> schemas, Spy reports that my redefined elements in #3 have 
> already been defined and this is an error.
> 
> Becasue I knew Spy uses more than one parser (different views 
> use different parsers) I figured the parser valdiating the 
> document was incorrect. Well the Altova folks say their 
> schema validation is wrong in this case. Can I get some 
> confirmation of this one way or another from this group?
> 
> If Altova is correct then I think the Schema working group 
> has some serious work to fix this problem. I'm assuming that 
> I should be able to reuse an industry schema in this manner. 
> We want to both use the same datatypes from ACORD as well in 
> some places to add ACORD elements into our new elements when 
> the definitions are appropriate. If I have to recreate all 
> these types and elements, I loose much of that promise of resuability.
> 
> Any light you can shed on this situation is much appreciated. 
> Meanwhile I'll be tryiing to read the spec on this topic.
> 
> ...dan
> 
> --------------------------------------------------------------
> -------------
> Danny Vint
> 
> Specializing in Panoramic Images of California and the West 
> http://www.dvint.com
> 
> Voice:510:522-4703
> FAX: 801-749-3229
> 
> 


From dvint@s... Fri Sep 15 17:39:16 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w


transparent
Print
Mail
Like It
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