Hi Michael, thnx for the feedback you have given. yes i should have put "override.xslt" file inside Xerces sources and load it as a internal System Resource..thnx for pointing that out. :-) .I'll do the necessary modifications...
Regards, Udayanga On Tue, Jul 20, 2010 at 9:34 AM, Michael Glavassevich <[email protected]>wrote: > Hi Udayanga, > > I've had a chance to look at your patch. Really great work! Looking forward > to trying this out. > > One comment about the JAXP transform approach ... I noticed you're reading > the location of override.xslt from a system property which one presumably > has to set. I think the stylesheet could be inlined in the source code or a > file included in xercesImpl.jar. Then Xerces would always know where to load > it from and wouldn't have to depend on any external sources to find it. > > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [email protected] > E-mail: [email protected] > > udayanga wickramasinghe <[email protected]> wrote on 07/08/2010 > 02:23:48 PM: > > > > Hi Michael , Hi devs, > > XML Schema 1.1 override implementation is progressing and i have > > been able to implement most of the core parts needed for the > > implementation. One major requirement for the xs:override was to > > perform override transformations on a given <schema> document. As i > > did discuss in this list , my initial intention was to use > > override.xslt[1] style sheet to perform transforms on the schema > > documents. But as it turned out ,currently there is no xslt 2.0 > > schema aware processor to do the necessary transformations as > > specified in [1]. Therefore i had to go for a programmatic > > transformation that does all override transformations on a given > > schema document by passing Elements on a Schema Document and doing > > necessary modifications to the tree itself to reflect <override> > > semantics. However i have also implemented a JAXP compatible > > override transformer which would enable to plug in any appropriate > > xslt processor if need arises in the future.... :-) > > > > Implementation also needs to focus on evaluating dependencies during > > an override transformation path (ie:- A-->B'-->C'-->A'-->B''....) > > since there can be invalid documents generated (bcoz of schema > > component collisions,etc) due to <override> semantics. This also > > include eliminating any cycles in a dependency path. A dependency > > analysing Implementation is in place for this , and Khaled and I are > > currently in the stage of reviewing the implementation code and > > testing it against different scenarios. Still work needs to be done > > on error/collisions handling , integrating <override> > > transformations with different stages of Xerces schema processor,etc. > > > > I would like to thank Khaled as well for the tremendous support and > > feedback he has provided throughout this period . Btw I attached a > > recently taken patch of my implementation here as well. thanks. > > > > Regards, > > Udayanga > > > > [1]http://www.w3.org/TR/xmlschema11-1/#override-xslt > > > > > On Thu, Jul 8, 2010 at 9:35 PM, Michael Glavassevich < > [email protected] > > > wrote: > > Hi all, > > > > It's been awhile since I've seen mailing list discussion on the GSoC > > projects. Mid-term evaluations are coming up next week. I'm > > wondering how things are going in general. > > > > Ishan / Udayanga / Sanjaya, > > > > Can each of you share a bit on your progress? Things you've > > accomplished? Challenges you might be having, possibly that we could > > help you with? > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [email protected] > > E-mail: [email protected] > > > > > > > > -- > > http://www.udayangawiki.blogspot.com[attachment > > "override_new2.patch" deleted by Michael Glavassevich/Toronto/IBM] > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > -- http://www.udayangawiki.blogspot.com
