Hi Khaled, thnx for being my mentor on the project..really appreciate your help... so i did go through the discussions you had with Mukul and Hiranya...i do understand how xs:override works in general..from what i get ,it's very much similar to semantics of class/protoypical inheritance (ie:- inherit/include + override only if component to be overridden exists in the overridden schema )... i also have several things to be clarified against the example 5 you have mentioned...
> 5. Since xs:override applies to included schema(s) in the overriden schema, > you could end up with duplicate components (especially if you have a > circular case of include and override). Let's consider the following case: > schema A include schema B, schema B overrides schema C, and schema C include > schema B. In this case we will end up with two versions of schema B (the one > included by schema A, call it B [1], and the one overriden by C, call it B' > [2]). This means that we will process duplicate components (common > components in B and B' and need to flag these as errors). > here if we take the following example corresponding to your description... Schema A <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:include schemaLocation="schemaB.xsd"/> ........ </xs:schema> Schema B <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:override schemaLocation="schemaC.xsd"> <xs:element name="e1" type="xs:int"/> <xs:element name="e2" type="xs:date"/> <xs:override> <xs:element name="e2" type="xs:string"/> </xs:schema> Schema C <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:include schemaLocation="schemaB.xsd"/> <xs:element name="e1" type="xs:float"/> </xs:schema> therefore after preprocessing/overriding (according to the example 5 description) ,i assume B [1](one included by A) is the following [B] <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:include schemaLocation="schemaC'.xsd"/> <xs:element name="e2" type="xs:string"/> </xs:schema> schema C' <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:include schemaLocation="schemaB'.xsd"/> <xs:element name="e1" type="xs:int"/> </xs:schema> and B'(one overriden by C) [2] is , [B'] <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:include schemaLocation="schemaC'.xsd"/> <xs:element name="e2" type="xs:date"/> </xs:schema> if the above criteria is correct (or is this not what u meant ?), we end up with duplicates of xs:element e2 in B and B'...hence this is invalid according to the spec (no 2 elemnts with the same name) and therefore no override can happen..(pls correct me on this if i'm wrong...). if this is the case i presume ,similar scenarios could occur in circular overrides as well...so when it comes to implementation do we go and check for similar cyclic dependencies before applying override transformations to detect any errors and cancel the processing?? appreciate you comments regarding this..... Btw i' am still getting familiar with Xerces-j inorder to get a good overall understanding on Xerces and Schema processing . It would be great if you could tell me any specific areas i would need to look into , which would be especially useful in implementing xs:override according to spec. Hiranyas patch [*1] mostly concentrates on modifying XSDHandler (org.apache.xerces.impl.xs.traversers) class and it's attributes. do i need to follow a similar approach as well ? thnx in advance.... regards, Udayanga [*1]https://issues.apache.org/jira/browse/XERCESJ-1341 On Wed, Mar 24, 2010 at 3:09 AM, Khaled Noaman <[email protected]> wrote: > > Hi Udayanga, > > If you are interested in implementing xs:override, I would be happy to > mentor you. > > > Regards, > Khaled > > > > > From: > udayanga wickramasinghe <[email protected]> > To: > [email protected] > Date: 03/23/2010 05:06 PM Subject: Re: About Xerces projects for GSoc 2010 > ------------------------------ > > > > Hi Michael, > thnx again for your information. i went through the discussion appeared on > last year's mail archive. yes it seems like xs:override is not fully > implemented yet (atleast apart from the patch submitted by Hiranya[1]). > According to Noaman[2] there's fair bit of consideration to be done on > xs:override acording to the latest xml-schema 1.1 spec as well . Since Mukul > and Hiranya started this work i think it would be more appropriate if i > write to them as well, describing my intentions of implementing > "xs:override" this as a GSoc project for 2010 . May be they'll be willing to > mentor me on the project... > > [1]*https://issues.apache.org/jira/browse/XERCESJ-1341*<https://issues.apache.org/jira/browse/XERCESJ-1341> > [2]* > http://markmail.org/thread/tv3qtoofzya4ts7l#query:+page:1+mid:xckecvw2mwtd3n43+state:results > *<http://markmail.org/thread/tv3qtoofzya4ts7l#query:+page:1+mid:xckecvw2mwtd3n43+state:results> > > > Regards, > Udayanga > > On Tue, Mar 23, 2010 at 10:59 PM, Michael Glavassevich <* > [email protected]* <[email protected]>> wrote: > Hi Udayanga, > > udayanga wickramasinghe > <*[email protected]*<[email protected]>> > wrote on 03/23/2010 08:53:14 AM: > > > > Hi Michael, > > Thnx for your helpful feedback on Xerces projects available. Yes i > > do went through Apache proposed projects list under Xerces (i was > > frankly surprised to see SCD this year as well...thought it was > > completed in last year's GSoc) , and wanted to know if there are > > some additional ideas you might have , since most f the proposed > > project appeared to have been undertaken. > > Certainly doesn't have to be limited to what's been posted so far. I can > think of at least a few other areas (e.g. xml:id [1] and StAX serialization) > which haven't been tackled yet and possibly other feature requests that have > been made over the years that are still active in JIRA. You're also welcome > to come up with your own ideas. > > > > I think Ishan plans to do the part ,the derivation of a canonical > > SCP , given a shemaComponent,Namespace ctxt and the corresponding > > XSModel . (If you go through his recent posts , he has already > > defined #getCanonicalSCP(XSObject, > > XSModel,NamespaceContext) under the set of interfaces he's going to > > implement) .I'm just curious as to how exactly it's going to be > > worked out...since it's the reverse problem of resolving a SCP > > expression (which IMHO is a bit straightfoward than deriving a SCP > > for a scehma component) , can there be a 1:n correspondence? ie:- > > for a respective schema component on a given XSModel is there a > > possibility for several SCP expressions existing?? > > The canonical path is supposed to uniquely identify the schema component so > there should be only one such expression. > > > > Btw among the ideas you have mentioned, i'm interested in the > > implementation of XML Schema 1.1.spec , xs:override(http:// > > *www.w3.org/TR/xmlschema11-1/#override-schema*<http://www.w3.org/TR/xmlschema11-1/#override-schema>). > I find it to be very > > interesting and would indeed be a useful addition for Xerces as well. I > would > > very much appreciate if you could please further elaborate on the > > project requirement..ie:- the scope , technical challenges, related > > work that might be useful(i see it is a bit similar to > > xs:redefine..) ,etc , so that i would be able to get a much clear > > idea n get things started.Thnx in advance.... > > Yes, xs:override is similar to xs:redefine except that it allows > unconstrained replacement of schema components. Given the problems > implementers and users of XML Schema have had with xs:redefine I would > expect that once it's available that it would become the recommended way to > replace schema components. The scope of the project would be to implement > this feature. There's a discussion [2] from last year that you may find > helpful, particularly the response from Khaled Noaman on the challenges of > implementing xs:override. Hiranya [3] (his patch is for a much earlier XML > Schema 1.1 draft; the spec has changed quite a bit since then so would no > longer apply), Mukul and Khaled have looked at this before but I don't > believe anyone has been working on an implementation lately. I believe most > of the work still needs to be done. > > We would welcome the help. > > > -Udayanga > > Thanks. > > [1] > *https://issues.apache.org/jira/browse/XERCESJ-1113*<https://issues.apache.org/jira/browse/XERCESJ-1113> > [2] > *http://markmail.org/thread/tv3qtoofzya4ts7l*<http://markmail.org/thread/tv3qtoofzya4ts7l> > [3] > *https://issues.apache.org/jira/browse/XERCESJ-1341*<https://issues.apache.org/jira/browse/XERCESJ-1341> > > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: *[email protected]* <[email protected]> > E-mail: *[email protected]* <[email protected]> > > > > -- * > **http://www.udayangawiki.blogspot.com*<http://www.udayangawiki.blogspot.com/> > > -- http://www.udayangawiki.blogspot.com
