Or may be as Michael suggested some time back simply hiding the components that are being overridden would be enough. I'll give it a try and see.
Thanks Best Regards, Hiranya On Wed, Nov 26, 2008 at 12:04 PM, Hiranya Jayathilaka <[EMAIL PROTECTED]>wrote: > 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 >> > >
