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

Reply via email to