You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Hiranya Jayathilaka <hi...@gmail.com> on 2008/11/25 06:57:39 UTC
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
Re: Question On xsd:redefine Implementation
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Hiranya Jayathilaka" <hi...@gmail.com> 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
<hiranya911@gmail.com
> > 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 <jk...@ca.ibm.com> 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" <hi...@gmail.com>
> 25/11/2008 12:57 AM
>
> Please respond to
> j-dev@xerces.apache.org
>
> To
>
> j-dev@xerces.apache.org
>
> 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
Re: Question On xsd:redefine Implementation
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>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 <jk...@ca.ibm.com> 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" <hi...@gmail.com>*
>>
>> 25/11/2008 12:57 AM
>> Please respond to
>> j-dev@xerces.apache.org
>>
>> To
>> j-dev@xerces.apache.org 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
>>
>
>
Re: Question On xsd:redefine Implementation
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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 <jk...@ca.ibm.com> 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" <hi...@gmail.com>*
>
> 25/11/2008 12:57 AM
> Please respond to
> j-dev@xerces.apache.org
>
> To
> j-dev@xerces.apache.org 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
>
Re: Question On xsd:redefine Implementation
Posted by John K Chan <jk...@ca.ibm.com>.
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" <hi...@gmail.com>
25/11/2008 12:57 AM
Please respond to
j-dev@xerces.apache.org
To
j-dev@xerces.apache.org
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