Hi Khaled, There seems to be some formatting error(on quoted text) , on the mail i sent u earlier (may b becoz i copy pasted..). please rerfer it under <uw/>.. really sorry for the inconvenience...
<uw> > 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. > </uw> 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) >>> >> <uw> > 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 > </uw> > > >> 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. >>> >> > <uw> > 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) > </uw> > > >> 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". >>> >> <uw> 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. </uw> > > >> >> 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. >> >> <uw> > 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 > </uw> -- http://www.udayangawiki.blogspot.com
