You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by udayanga wickramasinghe <ma...@gmail.com> on 2010/05/05 22:40:58 UTC
Implementing XML Schema 1.1 Overriding Component Definitions
Hi Devs,
As you may know , I am currently engaged in implementing XML Schema 1.1
overriding component definitions [2] (<xs:override>) as a Gsoc project for
Xerces XML Schema. I have been working on a good design plan for
implementing xs:override semantics within XML Schema processor. My idea of
implementation at the moment is described below. Although i can think of
several approaches for implementing this (including introducing a new phase
to Xerces schema processor) , i think following approach would be much more
flexible and convenient... Please feel free to put forward you
ideas,suggestions,improvements,etc regarding them .
following are the basic steps of the implemenation i came up with...
1) Prerequisite : making necessary xs:override schema symbols,XSDescription
constructs ,etc available to XSDHandler , which is the main schema
processing class...
2) I am planning to use #constructTrees() phase of XSDHandler ,for applying
necessary xs:override transformations . Since what #constructTrees does is
building a dependency tree for included and imported schemas , i think we
can use it to our advantage. This is because end result of override
transformation would be an inclusion of the augmented schema document which
override element points to. So in brief, whenever an override element is
encountered ,corresponding schema location will be resolved (schema D) and
the augmented schema is generated (D') and included in the dependency map.
And as usually , constructingTrees will be recursively applied to augmented
schemas as well so that complete dependency tree will be generated.
-One important consideration will be how transformations are done on the
respective overridden schemas .At the moment I'm thinking of using the
override.xslt [1] transformation on schema DOM objects rather than doing it
programatically .I guess i can use javax.xml.transform library to do the
necessary transformations on a DOM element taking override schema component
and overriden schema document as parameters. However i am planning to
provide necessary extensions so that anyone can plug in a custom transform
mechanism of their own . For example , plugging in programatic override
transformation algorithm using native Xerces Dom (ie:-NodeImpl)
Implementation.
-Another would be introducing of component TransformationManager[2]. Rather
than implementing this component inside XSDHandler class (which is already
big and has lot of things being handled) i'm thinking of delegating the
responsibility to a class such as OverrideTransformationManager . It's main
method would be
OverrideTransformationManager#transform(overrideElem,overridenSchema)
which will be responsible for applying necessary transformations. I am keen
to know your views regarding this as well. what wud be the suitable package
(ie:- org.apache.xerces.impl.xs.traversers ) to include such a class?
(3) Just applying transformations would be inadequate inside
#constructTrees() phase.This is bcoz , there wud be different versions of
overridden schema included during transformations and also cyclic
dependencies can happen with name collisions. So every time new augmented
schemas are generated , it would be checked against a map
(fSystemId2OverridenDocMap) to see if duplicates are encountered and also to
check if they are valid schemas (ie:-inclusion of augmented/overriden schema
versions D' and D'' can be considered valid if they are identical) . This
structure should be able to map SystemId's to their schemaDocuments .By
doing so we shud be able to detect different augmented versions of a schema
document while in the process of applying transformation.Additional
structures(ie:-override2XSDMap) and logic will be needed within
#constructTrees phase to map other relations, detect cycles(ie:-if augmented
schema inclusions repeat ) and if so (ie:- if same schema inclusion repeats)
stop further transformations being happening.
-#checkDuplicateSchema(schemaElement) would be the main function used for
this purpose. This would be part of the DependencyAnalyzer[2] component i
discussed.
(4)Since after construction of dependency tree , #buildGlobalRegistries
phase can be used to , detect general name collisions , process redefine
components, etc. However we may now encounter duplicate errors due to
multiple augmented schema versions bcoz of the override preprocessing
happened in the prior stage. Hence i need to modify the current duplicate
checking code in #checkForDuplicateNames() to exclude multiple valid
versions of overriden schemas,etc being taken into account. Maps and data
structures generated in the #constructTrees phase can be used here to handle
such scenarios.
5)if all goes well on the above steps ,following phases #traverseSchemas and
#traverseLocalElements in XSDHandler would build the grammer from the schema
sources accordingly.
Above is the basic implementation strategy i can think of now , but i guess
i would encounter additional requirements as i move on to the implementation
as well..hence i will really appreciate your thoughts on the above..thanks
in advance..
Regards,
Udayanga
[1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
[2]http://wiki.apache.org/xerces/gsoc_xs_override_proposal
--
http://www.udayangawiki.blogspot.com
Re: Implementing XML Schema 1.1 Overriding Component Definitions
Posted by udayanga wickramasinghe <ma...@gmail.com>.
Hi Michael,
yes, i get to know this problem when started implementing override
transformation . I also discussed this with Khaled and we decided to go with
programmatic DOM implementation since it is the only option available for
now. Anyway i have kept the partially completed JAXP transformation
implementation as it is , since we can always implement the rest when a
appropriate xslt2.0 processor would be available for Xalan or any other JAXP
compatible xslt implementation. Thnaks for ponting this out :-) ..
Regards,
Udayanga
On Sun, Jun 6, 2010 at 11:19 PM, Michael Glavassevich
<mr...@ca.ibm.com>wrote:
> Hi Udayanga,
>
> I think Khaled may have already mentioned this to you, but thought I'd
> point out that the stylesheet for xs:override requires an XSLT 2.0 processor
> and the transformer you'll get through javax.xml.transform only supports
> XSLT 1.0. Due to this limitation I believe you would have to do the
> transformation programmatically on the DOM. This would also avoid the
> introduction of a circular dependency on Xalan.
>
> Thanks.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> udayanga wickramasinghe <ma...@gmail.com> wrote on 05/05/2010
> 04:40:58 PM:
>
>
> > Hi Devs,
> >
> > As you may know , I am currently engaged in implementing XML Schema
> > 1.1 overriding component definitions [2] (<xs:override>) as a Gsoc
> > project for Xerces XML Schema. I have been working on a good design
> > plan for implementing xs:override semantics within XML Schema
> > processor. My idea of implementation at the moment is described
> > below. Although i can think of several approaches for implementing
> > this (including introducing a new phase to Xerces schema processor)
> > , i think following approach would be much more flexible and
> > convenient... Please feel free to put forward you
> > ideas,suggestions,improvements,etc regarding them .
> >
> > following are the basic steps of the implemenation i came up with...
> >
> > 1) Prerequisite : making necessary xs:override schema
> > symbols,XSDescription constructs ,etc available to XSDHandler ,
> > which is the main schema processing class...
> >
> > 2) I am planning to use #constructTrees() phase of XSDHandler ,for
> > applying necessary xs:override transformations . Since what
> > #constructTrees does is building a dependency tree for included and
> > imported schemas , i think we can use it to our advantage. This is
> > because end result of override transformation would be an inclusion
> > of the augmented schema document which override element points to.
> > So in brief, whenever an override element is encountered
> > ,corresponding schema location will be resolved (schema D) and the
> > augmented schema is generated (D') and included in the dependency
> > map. And as usually , constructingTrees will be recursively applied
> > to augmented schemas as well so that complete dependency tree will
> > be generated.
> >
> > -One important consideration will be how transformations are done on
> > the respective overridden schemas .At the moment I'm thinking of
> > using the override.xslt [1] transformation on schema DOM objects
> > rather than doing it programatically .I guess i can use
> javax.xml.transform
> > library to do the necessary transformations on a DOM element taking
> > override schema component and overriden schema document as
> > parameters. However i am planning to provide necessary extensions so
> > that anyone can plug in a custom transform mechanism of their own .
> > For example , plugging in programatic override transformation
> > algorithm using native Xerces Dom (ie:-NodeImpl) Implementation.
> >
> > -Another would be introducing of component TransformationManager[2].
> > Rather than implementing this component inside XSDHandler class
> > (which is already big and has lot of things being handled) i'm
> > thinking of delegating the responsibility to a class such as
> > OverrideTransformationManager . It's main method would be
> > OverrideTransformationManager#transform
> > (overrideElem,overridenSchema) which will be responsible for
> > applying necessary transformations. I am keen to know your views
> > regarding this as well. what wud be the suitable package (ie:-
> > org.apache.xerces.impl.xs.traversers ) to include such a class?
>
> >
> > (3) Just applying transformations would be inadequate inside
> > #constructTrees() phase.This is bcoz , there wud be different
> > versions of overridden schema included during transformations and
> > also cyclic dependencies can happen with name collisions. So every
> > time new augmented schemas are generated , it would be checked
> > against a map (fSystemId2OverridenDocMap) to see if duplicates are
> > encountered and also to check if they are valid schemas (ie:-
> > inclusion of augmented/overriden schema versions D' and D'' can be
> > considered valid if they are identical) . This structure should be
> > able to map SystemId's to their schemaDocuments .By doing so we shud
> > be able to detect different augmented versions of a schema document
> > while in the process of applying transformation.Additional
> > structures(ie:-override2XSDMap) and logic will be needed within
> > #constructTrees phase to map other relations, detect cycles(ie:-if
> > augmented schema inclusions repeat ) and if so (ie:- if same schema
> > inclusion repeats) stop further transformations being happening.
> >
> > -#checkDuplicateSchema(schemaElement) would be the main function
> > used for this purpose. This would be part of the DependencyAnalyzer
> > [2] component i discussed.
> >
> > (4)Since after construction of dependency tree ,
> > #buildGlobalRegistries phase can be used to , detect general name
> > collisions , process redefine components, etc. However we may now
> > encounter duplicate errors due to multiple augmented schema versions
> > bcoz of the override preprocessing happened in the prior stage.
> > Hence i need to modify the current duplicate checking code in
> > #checkForDuplicateNames() to exclude multiple valid versions of
> > overriden schemas,etc being taken into account. Maps and data
> > structures generated in the #constructTrees phase can be used here
> > to handle such scenarios.
> >
> > 5)if all goes well on the above steps ,following phases
> > #traverseSchemas and #traverseLocalElements in XSDHandler would
> > build the grammer from the schema sources accordingly.
> >
> >
> > Above is the basic implementation strategy i can think of now , but
> > i guess i would encounter additional requirements as i move on to
> > the implementation as well..hence i will really appreciate your
> > thoughts on the above..thanks in advance..
> >
> > Regards,
> > Udayanga
> >
> > [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
> > [2]http://wiki.apache.org/xerces/gsoc_xs_override_proposal
> >
> > --
> > http://www.udayangawiki.blogspot.com
>
--
http://www.udayangawiki.blogspot.com
Re: Implementing XML Schema 1.1 Overriding Component Definitions
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Udayanga,
I think Khaled may have already mentioned this to you, but thought I'd
point out that the stylesheet for xs:override requires an XSLT 2.0
processor and the transformer you'll get through javax.xml.transform only
supports XSLT 1.0. Due to this limitation I believe you would have to do
the transformation programmatically on the DOM. This would also avoid the
introduction of a circular dependency on Xalan.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
udayanga wickramasinghe <ma...@gmail.com> wrote on 05/05/2010
04:40:58 PM:
> Hi Devs,
>
> As you may know , I am currently engaged in implementing XML Schema
> 1.1 overriding component definitions [2] (<xs:override>) as a Gsoc
> project for Xerces XML Schema. I have been working on a good design
> plan for implementing xs:override semantics within XML Schema
> processor. My idea of implementation at the moment is described
> below. Although i can think of several approaches for implementing
> this (including introducing a new phase to Xerces schema processor)
> , i think following approach would be much more flexible and
> convenient... Please feel free to put forward you
> ideas,suggestions,improvements,etc regarding them .
>
> following are the basic steps of the implemenation i came up with...
>
> 1) Prerequisite : making necessary xs:override schema
> symbols,XSDescription constructs ,etc available to XSDHandler ,
> which is the main schema processing class...
>
> 2) I am planning to use #constructTrees() phase of XSDHandler ,for
> applying necessary xs:override transformations . Since what
> #constructTrees does is building a dependency tree for included and
> imported schemas , i think we can use it to our advantage. This is
> because end result of override transformation would be an inclusion
> of the augmented schema document which override element points to.
> So in brief, whenever an override element is encountered
> ,corresponding schema location will be resolved (schema D) and the
> augmented schema is generated (D') and included in the dependency
> map. And as usually , constructingTrees will be recursively applied
> to augmented schemas as well so that complete dependency tree will
> be generated.
>
> -One important consideration will be how transformations are done on
> the respective overridden schemas .At the moment I'm thinking of
> using the override.xslt [1] transformation on schema DOM objects
> rather than doing it programatically .I guess i can use
javax.xml.transform
> library to do the necessary transformations on a DOM element taking
> override schema component and overriden schema document as
> parameters. However i am planning to provide necessary extensions so
> that anyone can plug in a custom transform mechanism of their own .
> For example , plugging in programatic override transformation
> algorithm using native Xerces Dom (ie:-NodeImpl) Implementation.
>
> -Another would be introducing of component TransformationManager[2].
> Rather than implementing this component inside XSDHandler class
> (which is already big and has lot of things being handled) i'm
> thinking of delegating the responsibility to a class such as
> OverrideTransformationManager . It's main method would be
> OverrideTransformationManager#transform
> (overrideElem,overridenSchema) which will be responsible for
> applying necessary transformations. I am keen to know your views
> regarding this as well. what wud be the suitable package (ie:-
> org.apache.xerces.impl.xs.traversers ) to include such a class?
>
> (3) Just applying transformations would be inadequate inside
> #constructTrees() phase.This is bcoz , there wud be different
> versions of overridden schema included during transformations and
> also cyclic dependencies can happen with name collisions. So every
> time new augmented schemas are generated , it would be checked
> against a map (fSystemId2OverridenDocMap) to see if duplicates are
> encountered and also to check if they are valid schemas (ie:-
> inclusion of augmented/overriden schema versions D' and D'' can be
> considered valid if they are identical) . This structure should be
> able to map SystemId's to their schemaDocuments .By doing so we shud
> be able to detect different augmented versions of a schema document
> while in the process of applying transformation.Additional
> structures(ie:-override2XSDMap) and logic will be needed within
> #constructTrees phase to map other relations, detect cycles(ie:-if
> augmented schema inclusions repeat ) and if so (ie:- if same schema
> inclusion repeats) stop further transformations being happening.
>
> -#checkDuplicateSchema(schemaElement) would be the main function
> used for this purpose. This would be part of the DependencyAnalyzer
> [2] component i discussed.
>
> (4)Since after construction of dependency tree ,
> #buildGlobalRegistries phase can be used to , detect general name
> collisions , process redefine components, etc. However we may now
> encounter duplicate errors due to multiple augmented schema versions
> bcoz of the override preprocessing happened in the prior stage.
> Hence i need to modify the current duplicate checking code in
> #checkForDuplicateNames() to exclude multiple valid versions of
> overriden schemas,etc being taken into account. Maps and data
> structures generated in the #constructTrees phase can be used here
> to handle such scenarios.
>
> 5)if all goes well on the above steps ,following phases
> #traverseSchemas and #traverseLocalElements in XSDHandler would
> build the grammer from the schema sources accordingly.
>
>
> Above is the basic implementation strategy i can think of now , but
> i guess i would encounter additional requirements as i move on to
> the implementation as well..hence i will really appreciate your
> thoughts on the above..thanks in advance..
>
> Regards,
> Udayanga
>
> [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt
> [2]http://wiki.apache.org/xerces/gsoc_xs_override_proposal
>
> --
> http://www.udayangawiki.blogspot.com