Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xerces Wiki" for change notification.
The "gsoc_xs_override_proposal" page has been changed by uswick. http://wiki.apache.org/xerces/gsoc_xs_override_proposal?action=diff&rev1=8&rev2=9 -------------------------------------------------- == Description == . XML schema specification version 1.1 specifies syntax and semantics of “Overriding component definitions<override>”[3] or xs:override under “Schemas and Namespaces: Access and Composition” . The new component definition is a powerful addition to the XML schema composition framework which tries to mitigate some of the constraints present in similar constructs such as xs:redefine or <redefine> schema components. The <redefine> construct defined in “Including modified component definitions (<redefine>) “[4] on XMLSchema specification is useful in schema evolution and versioning. It can be used only when there exists some restriction or extension relation between the old component and the new redefined component. But there are occasions when the schema author simply wants to replace old components with new ones without any constraint. Also, existing XSD processors have implemented conflicting and non-interoperable interpretations of <redefine>. And to add to the trouble <redefine> construct is declared •deprecated• in XML Schema 1.1 [2]. Hence as mentioned in the beginning , <override> construct tries to avoid these bottlenecks and allow unconstrained replacement as and when needed. - . <<BR>>According to the XMLSchema 1.1 specification xs:override schema component is specified in the following form (override information item) ,<<BR>> + . According to the XMLSchema 1.1 specification xs:override schema component is specified in the following form (override information item) , - . <override<<BR>> id = ID<<BR>> schemaLocation = anyURI<<BR>> {any attributes with non-schema namespace . . .}><<BR>> + . {{{ + <override + id = ID + schemaLocation = anyURI + {any attributes with non-schema namespace . . .} + > - . Content: (annotation | (simpleType | complexType | group | attributeGroup | element | attribute | notation))*<<BR>></override><<BR>> + Content: (annotation | (simpleType | complexType | group | attributeGroup | element | attribute | notation))* - . Here “schemaLocation” indicates the location of the overriding schema document while “Content” corresponds to the types/groups/attributes/elements this schema will be overriding on the schemas available at corresponding “schemaLocation” . xs:override semantics are very much similar to class/prototypical inheritance where after successful application , corresponding overridden schemas replaces their old schemas by the new overriding schemas contained within a <xs:override> element. Following describes the criteria of xs:override on a general overview that should be considered in the implementation of xml schema composition on xs:override . - . * 1. override only applies if the schema component within <xs:override> exists in the overridden schema (corresponding to the respective schema Location defined). If this condition is not true, there’s no effect on the overriden schema location and overriding grammer won’t exist in the final schema representation. + </override> + }}} - * 2. + . . . Here “schemaLocation” indicates the location of the overriding schema document while “Content” corresponds to the types/groups/attributes/elements this schema will be overriding on the schemas available at corresponding “schemaLocation” . xs:override semantics are very much similar to class/prototypical inheritance where after successful application , corresponding overridden schemas replaces their old schemas by the new overriding schemas contained within a <xs:override> element. Following describes the criteria of xs:override on a general overview that should be considered in the implementation of xml schema composition on xs:override . - . a)Each and every <override> schema information element would be subjected to “override transformation”[5] . However when target namespaces of overriding and overridden schemas don’t match “chameleon inclusion transformation”[6] is also performed prior to the override transform. Override transformation itself is pervasive and therefore would be applied to <include> information items on the overridden schema.(ie:- if schema A overrides B and B includes C then C will also be overridden accordingly ).Further more override transformation applies to <override> information items present on the overridden schema by merging. . . b)after step a) is executed ,<xs:override> schema component will be replaced with <xs:include> in which it’s “SchemaLocation” attribute would correspond to the transformed schema from step a) .Although the idea behind xs:override seems to be rather simple , several scenarios need to be considered where some complications would inevitably arise. + . . {{{ + 1. + override only applies if the schema component within <xs:override> exists in the overridden schema (corresponding to the respective schema Location defined). If this condition is not true, there’s no effect on the overriden schema location and overriding grammer won’t exist in the final schema representation. + }}} - . • Circular includes and overrides would end up creating duplicate components that should be flagged as errors . (ie:- if Schema A include B , B override C and C intern include B then we could endup with different versions of B included in both A and C . Versions of B included in A and C will only be considered same if C->B override transformation does not apply ) . . • This scenario could occur in circular overrides as well (ie:- if schema A overrides B and B overrides A , then if B->A override transformation affects schema A then duplicate errors will occur) . . • In general if overriding schemas produce same override transformation schema result for inclusion, then they would be considered the same other wise duplicates will occur .(ie:- If schema A includes B,C and B,C both inturn override D ,then B,C would include same version of D if B->D and C->D override transform doesn’t affect D OR if B,C both got same override schema components )Implementation of xs:override should take into account the aforementioned factors so that dependencies are correctly evaluated and necessary schema preprocessing is performed. + . {{{ + 2. + a)Each and every <override> schema information element would be subjected to “override transformation”[5] . However when target namespaces of overriding and overridden schemas don’t match “chameleon inclusion transformation”[6] is also performed prior to the override transform. Override transformation itself is pervasive and therefore would be applied to <include> information items on the overridden schema.(ie:- if schema A overrides B and B includes C then C will also be overridden accordingly ).Further more override transformation applies to <override> information items present on the overridden schema by merging. . . + }}} + + . + . Although the idea behind xs:override seems to be rather simple , several scenarios need to be considered where some complications would inevitably arise.Following are several such considerations. + + . {{{ + Circular includes and overrides would end up creating duplicate components that should be flagged as errors . (ie:- if Schema A include B , B override C and C intern include B then we could endup with different versions of B included in both A and C . Versions of B included in A and C will only be considered same if C->B override transformation does not apply ) . . + }}} + + . {{{ + This scenario could occur in circular overrides as well (ie:- if schema A overrides B and B overrides A , then if B->A override transformation affects schema A then duplicate errors will occur) . . + }}} + . {{{ + In general if overriding schemas produce same override transformation schema result for inclusion, then they would be considered the same other wise duplicates will occur .(ie:- If schema A includes B,C and B,C both inturn override D ,then B,C would include same version of D if B->D and C->D override transform doesn’t affect D OR if B,C both got same override schema components ) + }}} + . Implementation of xs:override should take into account the aforementioned factors so that dependencies are correctly evaluated and necessary schema preprocessing is performed. == Things I have Done So far == . Since this project is about implementing a XMLSchema 1.1 specification construct , I had to go through this specification docs several times to understand the exact structure and semantics of the component I’m going to implement which I think is of vital importance when it comes to the design n implementation. Previous discussions (that has happened in Xerces-j-dev mail archives) about this xs:override support , online articles and tutorials also helped a lot in this cause. I also interacted with Xerces mailing list (especially with my mentor) to clarify critical points and implementation details. Since knowing Xerces and it’s internal framework(XNI) is obviously essential for the implementation I had to dig into various documentation, API information ,samples regarding Xerces Design,architecture and especially XML schema processing. I did download source code of Xerces2-j from trunk and build the code inorder to try and test out some samples to get a hang on the flow of things related to schema loading and processing. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
