Hi Udayanga, According to your example, B and B' would be considered 2 different documents and we would end up with conflicting components, not just e2 (assuming B.xsd had other global components). The reason we consider B and B' as different documents is the facet that B' now contain a different declaration for e2. If xs:override did not apply from C->B, then in that case we can consider B and B' the same and there would be no duplicate components.
You would need to apply override to check for cyclical dependencies. As I mentioned above if override does not modify the overridden schema, then 2 similar schema documents (B and B') would be treated as similar (in other words, no duplicates). Consider the following case: A include B and C, B and C override D. Now you end up with 2 versions of D (D' included by B and D'' included by C). If neither B or C changes D, then both D' and D'' are considered the same. It would be great if you can start by looking at the following packages in Xerces-J: * org.apache.xerces.impl.xs.traversers - schema processing classes (XSDHandler is a starting point) * org.apache.xerces.impl.xs - classes representing the different schema components as well the main class for schema validation (XMLSchemaValidator) * org.apache.xerces.impl.xs.models - content model classes (e.g. DFA. all, empty) The above packages would be a good starting point. Regards, Khaled From: udayanga wickramasinghe <[email protected]> To: [email protected] Date: 03/24/2010 10:28 AM Subject: Re: About Xerces projects for GSoc 2010 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 [2] 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]> wrote: Hi Udayanga, udayanga wickramasinghe <[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). 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 [2] http://markmail.org/thread/tv3qtoofzya4ts7l [3] https://issues.apache.org/jira/browse/XERCESJ-1341 Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] -- http://www.udayangawiki.blogspot.com -- http://www.udayangawiki.blogspot.com
