Hi Khaled, Thanx a lot for your overview, it was really helpful. i now have a very good understanding on how XMLSchema processing works and how it could be related to xs:override. Please see some of my comments below .i woud very much appreciate your suggestions as well.
On Tue, Mar 30, 2010 at 5:49 AM, Khaled Noaman <[email protected]> wrote: > > Hi Udayanga, > > Here's a quick overview on how schemas are processed in Xerces-J. > > > 1. We preprocess all include, import and redefine elements and create all >> the necessary grammar objects. This way we have all the schema information >> handy (constructTrees) >> > IMHO..this part is a bit straightfoward..i think we can closely relate this to <REDEFINE> implementation and include necessary control structures here .I would need to include necessary SchemaSymbols and XMLGrammerDescription symbols as needed as well as creating a fOverride2XSDMap , to map override elements with respective schema documents. > 2. We then go through all global declarations in each schema document we >> preprocessed. This is where we do some redefine preprocessing where we >> change the names of redefined components. This process will also store the >> first occurrence of each global component, whether it's a type, an element, >> an attribute, etc. (key is a concat of a component name and its namespace) >> as well as the corresponding schema document for that component. This way >> you can easily check for duplicates and know which global component to >> process when it's referred to by another component during processing of the >> actual components (e.g. <element name="a" type="ns:type1"/>). In that case >> when processing element, "a" we can get access to the representation of >> "type1" if it was not yet processed. This of course will cause some problems >> with xs:override. Since xs:override now has precedence. So, the logic will >> need to change to take xs:override into consideration. >> > I think obviously this is the most tricky part..we have to take into consideration xs:override semantics during the depth-first traversal of schema dependencies ,like you have pointed out.We may have to extend XSDHandler#checkForDuplicateNames() to include necessary control paths for OVERRIDE as well considering the scenarios where duplicate collisions can occur (i think , as dicussed in our initial conversations) and shud take special care in flagging duplicate errors . Additionally i suppose i need to add a function similar to the following, for renaming component overrides as well, since override semantics are different to redefine (excluding component base restrictions , including <include>s and <override> merging ,etc).. #renameOverriddingComponents(currentSchema,childComponent,componentType,oldName,newName) > 3. We then go and process all global components in each schema document we >> have preprocessed. A global component is any schema component (excluding >> <include>, <import>, <redefine>. and <override>) that's a child of the >> <schema> element, e.g. >> <xs:schema .....> >> ... >> <xs:element name="child1" type="xs:string"/> >> <xs:complexType name="ctype1"> >> <xs:sequence> >> <xs:element name="gchild1" type="xs:int"> >> </xs:sequence> >> </xs:complexType> >> </xs:schema> >> >> So, we will process element "child1" and type "ctype1". >> > since <Override> should be included in schema traversal , i would need to extend #traverseSchemas() to take override component structure into account for traversing override information item. I'm not exactly certain how xs:override would affect each individual traverser (ie:- like XSDHandler#getGrpOrAttrGrpRedefinedByRestriction() called by XSDGroupTraverser class which is not applicable to <override> since there's no restriction based semantics ) but i'm sure would be able to figure that as wel when we digg into implementation aspects more closely. > > 4. We then process any local elements components. A local element is a >> usually a child of a component such as complex type or group. So, in the >> above example "gchild1" is a local element. We would process that element >> after we have processed all global components >> >> When implementing xs:override, a lot of considerations has to be taken >> care of during preprocessing. We also need to make sure that when processing >> a global component or a local component that refers to a component that is >> being overriden, that we use the overriding component. >> > yes i admit , various aspects of <override> semantics, would be need to taken care of , while making sure i do not break the existing code. As i progress on to the implementation , would be able to figure out these unknowns and especially places i need to give special attention and i am confident that i would be able to implement it sucessfully .Btw I'll add some of the above details to my GSoc proposal ( http://wiki.apache.org/xerces/gsoc_xs_override_proposal) . looking foward to hearing your feedback regarding that as well... thanx in advance.. Regards, Udayanga
