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 <[email protected]>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: [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 > -- http://www.udayangawiki.blogspot.com
