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: [email protected] E-mail: [email protected] udayanga wickramasinghe <[email protected]> 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
