Hi John, Thanks for the detailed reply. I think I understand now. I also think I can use the same technique in the implementation of xsd:override support.
Thoughts? Thanks Best Regards, Hiranya On Wed, Nov 26, 2008 at 1:34 AM, John K Chan <[EMAIL PROTECTED]> wrote: > > Hi Hiranya, > > I think the purpose of mapping the original type to be modified to a new > name (the type name appended with the REDEF_IDENTIFIER) is due to the way > the parsing is implemented in xerces. When we traverse a global component, > we set the node to be hidden so we later know when we try to retrieve this > global component that either we have already built this component (it will > return this component) or we are in the process of building it (there is a > circular reference). > > A redefine component redefines either a simpleType, a complexType, an > attributeGroup, or a group. In the redefined types, we either have a > restriction or an extension to the original type. In the redefined group or > attributeGroup, we again refer to the original group defining new > elements/attributes or marking the original elements/attributes as > prohibited. For example if we are redefining a simpleType named numberType, > the child element under the redefine element would be <simpleType > name="numberType">. As we traverse this, the parser has marked this node to > be hidden. Inside this simple type, we will encounter either a restriction > element or an extension element like this: <restriction > base="ns:numberType">. In the current implementation, as we build the dom, > we change the base attribute of this element to the targetLName, which is > the base attribute value appended with the REDEF_IDENTIFIIER. Had we not > done this, we would try to retrieve this type and encounter a circular > reference error. > > Hope this helps. Please correct me if I'm wrong. > > Thanks, > John > > > > *"Hiranya Jayathilaka" <[EMAIL PROTECTED]>* > > 25/11/2008 12:57 AM > Please respond to > [email protected] > > To > [email protected] cc > Subject > Question On xsd:redefine Implementation > > > > > Hi Folks, > > I'm in the middle of implementing xsd:override support. Since this feature > is pretty much similar to xsd:redefine I'm using xsd:redefine implementation > as a reference. However while studying how xsd:redefine support is > implemented I came across the following static variable defined in the > XSDHandler. > > // this string gets appended to redefined names; it's purpose is to be > // as unlikely as possible to cause collisions. > public final static String REDEF_IDENTIFIER = "_fn3dktizrknc9pi"; > > The above value is appended to all the target name values as follows. > > String targetLName = DOMUtil.getAttrValue(redefineComp, > SchemaSymbols.ATT_NAME)+REDEF_IDENTIFIER; > > I'm a bit confused about this. Can somebody please help me understand the > purpose of doing the above? > > Thanks > > Best Regards, > Hiranya >
