Hi Hiranya, Right, I think what I suggested should be sufficient. There's no value in renaming the original declaration since it's never going to be processed.
Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] "Hiranya Jayathilaka" <[EMAIL PROTECTED]> wrote on 11/26/2008 04:37:13 AM: > 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
