Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Web Tools Project (WTP) » EMF XSD Parser Bug for SimpleType Definition in case of List and Union
EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210155] Tue, 11 March 2008 07:34 Go to next message
Eclipse UserFriend
Originally posted by: Keshavrao.veerapaeni.sap.com

The Bug is with EMF XSD parser for XSDSimpleTypeDefinition in union and
the list case.

For example i have a simple type type deinfition 'B' which is of union
type and it has two memberTypes defined as string and iteger, and also
one anonymous type definition.
in this case the parser should return the anonymous type definition in
the 'contents', and string, integer and anonymous type definition as
'memeberTypeDefinitions'.This is working fine but if now i have another
simple type definition 'A' which extends 'B', in this case for 'A' the
memberTypeDefinitions and the contents should not exist because they
are defined as a part of the super type which is 'B'. But now i am
also getting the memberTypeDefinitions and the contents of the super
type in 'A' also.
Same thing is also happening with the list type definition where i am
getting the 'itemTypeDefinition' of the super type in the child type.

I have pasted the above mentioned example here-

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
blockDefault="#all" elementFormDefault="qualified"
version="1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xml:lang="EN"
xmlns="SimpleTypeDefinitionExtendingUnion.xsd">

<xs:simpleType name="B">
<xs:union memberTypes="xs:string xs:integer">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="undefined"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>

<xs:simpleType name="A">
<xs:restriction base="B">

</xs:restriction>
</xs:simpleType>
</xs:schema>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210190 is a reply to message #210155] Tue, 11 March 2008 12:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------090308030402060903060806
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Keshavrao,

It sounds correct to me. According to
http://www.w3.org/TR/xmlschema-2/#rf-defn the properties for a simple
type definition are as follows:

{variety}
One of {/atomic/, /list/, /union/}. Depending on the value of
{variety} <http://www.w3.org/TR/xmlschema-2/#defn-variety>, further
properties are defined as follows:

atomic

{primitive type definition}
A
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210204 is a reply to message #210190] Tue, 11 March 2008 14:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dcarver.starstandard.org

As Ed has said, the xs:SimpleTypeA with the xs:restriction base="B"
basically acts like an extension if you only include the the
restriction. If you want to further restrict it, you must include
either a pattern or enumeration or other facet like maxlength, minLength
to further restrict the contents. With out these it imports all the
contents of the restriction into the new simpleType definition.

Dave

Ed Merks wrote:
> Keshavrao,
>
> It sounds correct to me. According to
> http://www.w3.org/TR/xmlschema-2/#rf-defn the properties for a simple
> type definition are as follows:
>
> {variety}
> One of {/atomic/, /list/, /union/}. Depending on the value of
> {variety} <http://www.w3.org/TR/xmlschema-2/#defn-variety>, further
> properties are defined as follows:
>
> atomic
>
> {primitive type definition}
> A ·built-in·
> <http://www.w3.org/TR/xmlschema-2/#dt-built-in> ·primitive·
> <http://www.w3.org/TR/xmlschema-2/#dt-primitive> datatype
> definition).
>
> list
>
> {item type definition}
> An ·atomic· <http://www.w3.org/TR/xmlschema-2/#dt-atomic> or
> ·union· <http://www.w3.org/TR/xmlschema-2/#dt-union> simple
> type definition.
>
> union
>
> {member type definitions}
> A non-empty sequence of simple type definitions.
>
>
> So to my reading, this implies that a type of variety list ought to have
> an item type definition and a type of variety union ought to have a non
> empty sequence of member type definitions. Perhaps I'm reading too much
> between the lines of a complex specification, but it seems like a useful
> and reasonable interpretation to me...
>
>
> Keshavrao Veerapaneni wrote:
>> The Bug is with EMF XSD parser for XSDSimpleTypeDefinition in union
>> and the list case.
>>
>> For example i have a simple type type deinfition 'B' which is of union
>> type and it has two memberTypes defined as string and iteger, and also
>> one anonymous type definition.
>> in this case the parser should return the anonymous type definition in
>> the 'contents', and string, integer and anonymous type definition as
>> 'memeberTypeDefinitions'.This is working fine but if now i have another
>> simple type definition 'A' which extends 'B', in this case for 'A' the
>> memberTypeDefinitions and the contents should not exist because they
>> are defined as a part of the super type which is 'B'. But now i am
>> also getting the memberTypeDefinitions and the contents of the super
>> type in 'A' also.
>> Same thing is also happening with the list type definition where i am
>> getting the 'itemTypeDefinition' of the super type in the child type.
>>
>> I have pasted the above mentioned example here-
>>
>> <?xml version='1.0' encoding='UTF-8'?>
>> <xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
>> blockDefault="#all" elementFormDefault="qualified"
>> version="1.0"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> xml:lang="EN"
>> xmlns="SimpleTypeDefinitionExtendingUnion.xsd">
>>
>> <xs:simpleType name="B">
>> <xs:union memberTypes="xs:string xs:integer">
>> <xs:simpleType>
>> <xs:restriction base="xs:NMTOKEN">
>> <xs:enumeration value="undefined"/>
>> </xs:restriction>
>> </xs:simpleType>
>> </xs:union>
>> </xs:simpleType>
>>
>> <xs:simpleType name="A">
>> <xs:restriction base="B">
>>
>> </xs:restriction>
>> </xs:simpleType>
>> </xs:schema>
>>
>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210240 is a reply to message #210204] Wed, 12 March 2008 08:14 Go to previous messageGo to next message
Keshavrao  is currently offline Keshavrao Friend
Messages: 34
Registered: July 2009
Member
Hi David,
I thought that Ed was telling that my interpretation was right that
the parser should not provide the derived contents.
And whatever you have said is very much rigt when you go by the
semantics of the specification. Ok so if you take the below example, then
from whatever you have mentioned for the simpletype definition here the
parser should have returned the contents of the "type1" as well in "type2"

here

<xs:complexType name="type1">
<xs:sequence>
<xs:element name="element1" "xs:string/>
</xs:sequence>
</xs:complexType>

<xs:complexType name="type2">
<xs:complexContent>
<xs:extension base="type1">
<xs:sequence>
<xs:element name="element2" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210248 is a reply to message #210204] Wed, 12 March 2008 08:17 Go to previous messageGo to next message
Keshavrao  is currently offline Keshavrao Friend
Messages: 34
Registered: July 2009
Member
David Carver wrote:

> As Ed has said, the xs:SimpleTypeA with the xs:restriction base="B"
> basically acts like an extension if you only include the the
> restriction. If you want to further restrict it, you must include
> either a pattern or enumeration or other facet like maxlength, minLength
> to further restrict the contents. With out these it imports all the
> contents of the restriction into the new simpleType definition.

> Dave

> Ed Merks wrote:
>> Keshavrao,
>>
>> It sounds correct to me. According to
>> http://www.w3.org/TR/xmlschema-2/#rf-defn the properties for a simple
>> type definition are as follows:
>>
>> {variety}
>> One of {/atomic/, /list/, /union/}. Depending on the value of
>> {variety} <http://www.w3.org/TR/xmlschema-2/#defn-variety>, further
>> properties are defined as follows:
>>
>> atomic
>>
>> {primitive type definition}
>> A ·built-in·
>> <http://www.w3.org/TR/xmlschema-2/#dt-built-in> ·primitive·
>> <http://www.w3.org/TR/xmlschema-2/#dt-primitive> datatype
>> definition).
>>
>> list
>>
>> {item type definition}
>> An ·atomic· <http://www.w3.org/TR/xmlschema-2/#dt-atomic> or
>> ·union· <http://www.w3.org/TR/xmlschema-2/#dt-union> simple
>> type definition.
>>
>> union
>>
>> {member type definitions}
>> A non-empty sequence of simple type definitions.
>>
>>
>> So to my reading, this implies that a type of variety list ought to have
>> an item type definition and a type of variety union ought to have a non
>> empty sequence of member type definitions. Perhaps I'm reading too much
>> between the lines of a complex specification, but it seems like a useful
>> and reasonable interpretation to me...
>>
>>
>> Keshavrao Veerapaneni wrote:
>>> The Bug is with EMF XSD parser for XSDSimpleTypeDefinition in union
>>> and the list case.
>>>
>>> For example i have a simple type type deinfition 'B' which is of union
>>> type and it has two memberTypes defined as string and iteger, and also
>>> one anonymous type definition.
>>> in this case the parser should return the anonymous type definition in
>>> the 'contents', and string, integer and anonymous type definition as
>>> 'memeberTypeDefinitions'.This is working fine but if now i have another
>>> simple type definition 'A' which extends 'B', in this case for 'A' the
>>> memberTypeDefinitions and the contents should not exist because they
>>> are defined as a part of the super type which is 'B'. But now i am
>>> also getting the memberTypeDefinitions and the contents of the super
>>> type in 'A' also.
>>> Same thing is also happening with the list type definition where i am
>>> getting the 'itemTypeDefinition' of the super type in the child type.
>>>
>>> I have pasted the above mentioned example here-
>>>
>>> <?xml version='1.0' encoding='UTF-8'?>
>>> <xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
>>> blockDefault="#all" elementFormDefault="qualified"
>>> version="1.0"
>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> xml:lang="EN"
>>> xmlns="SimpleTypeDefinitionExtendingUnion.xsd">
>>>
>>> <xs:simpleType name="B">
>>> <xs:union memberTypes="xs:string xs:integer">
>>> <xs:simpleType>
>>> <xs:restriction base="xs:NMTOKEN">
>>> <xs:enumeration value="undefined"/>
>>> </xs:restriction>
>>> </xs:simpleType>
>>> </xs:union>
>>> </xs:simpleType>
>>>
>>> <xs:simpleType name="A">
>>> <xs:restriction base="B">
>>>
>>> </xs:restriction>
>>> </xs:simpleType>
>>> </xs:schema>
>>>
>>
Hi David,
I thought that Ed was telling that my interpretation was right that
the parser should not provide the derived contents.
And whatever you have said is very much rigt when you go by the
semantics of the specification. Ok so if you take the below example, then
from whatever you have mentioned for the simpletype definition here the
parser should have returned the contents of the "type1" as well in "type2"

here

<xs:complexType name="type1">
<xs:sequence>
<xs:element name="element1" "xs:string/>
</xs:sequence>
</xs:complexType>

<xs:complexType name="type2">
<xs:complexContent>
<xs:extension base="type1">
<xs:sequence>
<xs:element name="element2" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210260 is a reply to message #210248] Wed, 12 March 2008 11:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Keshavrao,

Comments below.


Keshavrao Veerapaneni wrote:
> David Carver wrote:
>
>> As Ed has said, the xs:SimpleTypeA with the xs:restriction base="B"
>> basically acts like an extension if you only include the the
>> restriction. If you want to further restrict it, you must include
>> either a pattern or enumeration or other facet like maxlength,
>> minLength to further restrict the contents. With out these it
>> imports all the contents of the restriction into the new simpleType
>> definition.
>
>> Dave
>
>> Ed Merks wrote:
>>> Keshavrao,
>>>
>>> It sounds correct to me. According to
>>> http://www.w3.org/TR/xmlschema-2/#rf-defn the properties for a
>>> simple type definition are as follows:
>>>
>>> {variety}
>>> One of {/atomic/, /list/, /union/}. Depending on the value of
>>> {variety} <http://www.w3.org/TR/xmlschema-2/#defn-variety>, further
>>> properties are defined as follows:
>>>
>>> atomic
>>>
>>> {primitive type definition}
>>> A ·built-in·
>>> <http://www.w3.org/TR/xmlschema-2/#dt-built-in> ·primitive·
>>> <http://www.w3.org/TR/xmlschema-2/#dt-primitive> datatype
>>> definition).
>>> list
>>>
>>> {item type definition}
>>> An ·atomic·
>>> <http://www.w3.org/TR/xmlschema-2/#dt-atomic> or
>>> ·union· <http://www.w3.org/TR/xmlschema-2/#dt-union> simple
>>> type definition.
>>> union
>>>
>>> {member type definitions}
>>> A non-empty sequence of simple type definitions.
>>>
>>> So to my reading, this implies that a type of variety list ought to
>>> have an item type definition and a type of variety union ought to
>>> have a non empty sequence of member type definitions. Perhaps I'm
>>> reading too much between the lines of a complex specification, but
>>> it seems like a useful and reasonable interpretation to me...
>>>
>>>
>>> Keshavrao Veerapaneni wrote:
>>>> The Bug is with EMF XSD parser for XSDSimpleTypeDefinition in union
>>>> and the list case.
>>>>
>>>> For example i have a simple type type deinfition 'B' which is of union
>>>> type and it has two memberTypes defined as string and iteger, and also
>>>> one anonymous type definition.
>>>> in this case the parser should return the anonymous type definition in
>>>> the 'contents', and string, integer and anonymous type definition as
>>>> 'memeberTypeDefinitions'.This is working fine but if now i have
>>>> another
>>>> simple type definition 'A' which extends 'B', in this case for 'A' the
>>>> memberTypeDefinitions and the contents should not exist because they
>>>> are defined as a part of the super type which is 'B'. But now i am
>>>> also getting the memberTypeDefinitions and the contents of the super
>>>> type in 'A' also.
>>>> Same thing is also happening with the list type definition where i am
>>>> getting the 'itemTypeDefinition' of the super type in the child type.
>>>>
>>>> I have pasted the above mentioned example here-
>>>>
>>>> <?xml version='1.0' encoding='UTF-8'?>
>>>> <xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
>>>> blockDefault="#all" elementFormDefault="qualified"
>>>> version="1.0"
>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> xml:lang="EN"
>>>> xmlns="SimpleTypeDefinitionExtendingUnion.xsd">
>>>> <xs:simpleType name="B">
>>>> <xs:union memberTypes="xs:string xs:integer">
>>>> <xs:simpleType>
>>>> <xs:restriction base="xs:NMTOKEN">
>>>> <xs:enumeration value="undefined"/>
>>>> </xs:restriction>
>>>> </xs:simpleType>
>>>> </xs:union>
>>>> </xs:simpleType>
>>>> <xs:simpleType name="A">
>>>> <xs:restriction base="B">
>>>> </xs:restriction>
>>>> </xs:simpleType>
>>>> </xs:schema>
>>>>
>>>
> Hi David,
> I thought that Ed was telling that my interpretation was right
> that the parser should not provide the derived contents.
No, I was saying what's happening now looks right to me.
> And whatever you have said is very much rigt when you go by the
> semantics of the specification.
It's especially nice when thats entirely clear. I think we can
definitely agree that the variety of the type is union. Doesn't that
imply it must have a members type definitions property? And doesn't the
wording for that property imply that is must contain one or more members?
> Ok so if you take the below example, then from whatever you have
> mentioned for the simpletype definition here the parser should have
> returned the contents of the "type1" as well in "type2"
What do you mean by specifically by "should have returned the
contents"? I'm also not sure how this is relates to whether a union
derived from a union (which definitely has variety union, since it's not
atomic and isn't a list) should have a populated member type definitions
property? I can see that the specification might be interpreted
different ways, but my reading of the property is quite simple: when
the variety is union, the member type definitions property is present,
and when present, it must contain one or more types. Subsequent wording
isn't entirely clear/explicit about the propagation of the item type or
the member types from the base to the derived though. But to me it
seems odd to have a union type without members or a list type without an
item type. With respect to the example below, indeed if you get the
content type you'll see element1 and element2.
>
> here
> <xs:complexType name="type1">
> <xs:sequence>
> <xs:element name="element1" "xs:string/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:complexType name="type2">
> <xs:complexContent>
> <xs:extension base="type1">
> <xs:sequence>
> <xs:element name="element2" type="xs:string"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210293 is a reply to message #210260] Wed, 12 March 2008 15:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dcarver.starstandard.org

This is how a Union is typically expressed:

<xsd:simpleType name="A">
<xsd:restriction base="xsd:normalizedString">
<xsd:enumeration value="A1"/>
<xsd:enumeration value="A2"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="B">
<xsd:restriction base="xsd:normalizedString">
<xsd:enumeration value="B1"/>
<xsd:enumeration value="B2"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="UnionAB">
<xsd:union memberTypes="A B" />
</xsd:simpleType>

Which combines the two enumerations.

You can also do a union on any of the primitives defined, however if you
want to restrict the range value, I would suggest setting up other
simpleTypes and doing a union on those values that have been restricted.

So your original example:



<xs:simpleType name="B">
<xs:union memberTypes="xs:string xs:integer">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="undefined"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="A">
<xs:restriction base="B">
</xs:restriction>
</xs:simpleType>
</xs:schema>


So for your original example, I would do:

<xsd:simpleType name="StringRestriction">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="undefined"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="UnionStringInteger">
<xsd:union memberTypes="StringRestriction xsd:integer"/>
</xsd:simpleType>

<xsd:element name="example" type="UnionStringInteger"/>

Which would give the valid values for "example" being, the "undefined"
enumerated value and any valid integer.

If you wanted limit the scope of the integers, I'd setup a separate
simpleType, and union on that simpleType.



Dave
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210341 is a reply to message #210260] Thu, 13 March 2008 05:57 Go to previous messageGo to next message
Keshavrao  is currently offline Keshavrao Friend
Messages: 34
Registered: July 2009
Member
Please clarify if my understanding is correct w.r.t. parser about how to
find if the membertypedefinitions are part of the base union type or the
derived type-

if the simple type variety is union and if its base type is anySimpleType
then in this case the membertypedefinitions and the contents are defined
as a part of the current simple type.


else if the base type is other than anySimpleType and if the variety is
union then in that case the membertypedefinitions are the part of the base
type but not the current type.
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210347 is a reply to message #210190] Thu, 13 March 2008 07:06 Go to previous messageGo to next message
Franz Forsthofer is currently offline Franz ForsthoferFriend
Messages: 1
Registered: July 2009
Junior Member
Hello Ed,

throughout the XSD ecore meta model the method getContents() returns the
components which are associated via a containment relation to the calling
component. For example, XSDComplexTypeDefinition.getAttributeContents()
returns the attribute declarations directly defined on the complex type
definition. If a complex type definition “A” is derived from a complex
type definition “B”, and if you call B.getAttributeContents(), then you
will not get the attribute declarations defined on “A”.

Therefore, in my opinion, the method XSDSimpleTypeDefinition.getContents()
should work in a similar way.

If you have a situation as Keshavrao described (I removed the xs:string in
the memberTypes to make the example more simple):

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
blockDefault="#all" elementFormDefault="qualified"
version="1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xml:lang="EN"
xmlns="SimpleTypeDefinitionExtendingUnion.xsd">
<xs:simpleType name="B">
<xs:union memberTypes="xs:integer">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="undefined"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="A">
<xs:restriction base="B">
</xs:restriction>
</xs:simpleType>
</xs:schema>

Then, if getContents() is executed on the simple type definition B
(B.getContents()), you get the the anonymous simple type restricting
NMTOKEN and the simple type “string”, as expected.

However, if you execute A.getContents(), then you again get the same
result. This is not in accordance with the behavior of the method
getContents() or getContent() on other components (like
XSDComplexTypeDefinition.getAttributeContents() mentioned above). I would
have expected that A.getContents(), returns an empty collection.
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210355 is a reply to message #210341] Thu, 13 March 2008 12:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Keshvarao,

Yes, that's how I did it in XSDEcoreBuilder, e.g., if the variety of a
type is different from the variety of the base type definition, that's
the point at which the item type or the member type definitions have
been concretely introduced into the hierarchy.

st.getVariety() != st.getBaseTypeDefinition().getVariety

Note that the technique works for both unions and list.


Keshavrao Veerapaneni wrote:
> Please clarify if my understanding is correct w.r.t. parser about how
> to find if the membertypedefinitions are part of the base union type
> or the derived type-
>
> if the simple type variety is union and if its base type is
> anySimpleType then in this case the membertypedefinitions and the
> contents are defined as a part of the current simple type.
>
>
> else if the base type is other than anySimpleType and if the variety
> is union then in that case the membertypedefinitions are the part of
> the base type but not the current type.
>
>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210363 is a reply to message #210347] Thu, 13 March 2008 12:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------090005000306000106080001
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Franz,

Comments below.


Franz Forsthofer wrote:
> Hello Ed,
>
> throughout the XSD ecore meta model the method getContents() returns
> the components which are associated via a containment relation to the
> calling component. For example,
> XSDComplexTypeDefinition.getAttributeContents() returns the attribute
> declarations directly defined on the complex type definition. If a
> complex type definition ?A? is derived from a complex type definition
> ?B?, and if you call B.getAttributeContents(), then you will not get
> the attribute declarations defined on ?A?.
That's right.
>
> Therefore, in my opinion, the method
> XSDSimpleTypeDefinition.getContents() should work in a similar way.
I believe it does.
>
> If you have a situation as Keshavrao described (I removed the
> xs:string in the memberTypes to make the example more simple):
>
> <?xml version='1.0' encoding='UTF-8'?>
> <xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
> blockDefault="#all" elementFormDefault="qualified"
> version="1.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xml:lang="EN"
> xmlns="SimpleTypeDefinitionExtendingUnion.xsd">
> <xs:simpleType name="B">
> <xs:union memberTypes="xs:integer">
> <xs:simpleType>
> <xs:restriction base="xs:NMTOKEN">
> <xs:enumeration value="undefined"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:union>
> </xs:simpleType>
> <xs:simpleType name="A">
> <xs:restriction base="B">
> </xs:restriction>
> </xs:simpleType>
> </xs:schema>
>
> Then, if getContents() is executed on the simple type definition B
> (B.getContents()), you get the the anonymous simple type restricting
> NMTOKEN and the simple type ?string?, as expected.
I think that's what it does.
>
> However, if you execute A.getContents(), then you again get the same
> result. This is not in accordance with the behavior of the method
> getContents() or getContent() on other components (like
> XSDComplexTypeDefinition.getAttributeContents() mentioned above). I
> would have expected that A.getContents(), returns an empty collection.
I do expect that too. Looking in the sample editor, the lack of a + to
expand the contained children makes me thing it's working that way too:




--------------090005000306000106080001
Content-Type: multipart/related;
boundary="------------060205070505010909080400"


--------------060205070505010909080400
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Franz,<br>
<br>
Comments below.<br>
<br>
<br>
Franz Forsthofer wrote:
<blockquote
cite="mid:074df82241d09a6b779a326c3753c3e4$1@www.eclipse.org"
type="cite">Hello Ed,
<br>
<br>
throughout the XSD ecore meta model the method getContents() returns
the components which are associated via a containment relation to the
calling component. For example,
XSDComplexTypeDefinition.getAttributeContents() returns the attribute
declarations directly defined on the complex type definition. If a
complex type definition &#65533;A&#65533; is derived from a complex type definition
&#65533;B&#65533;, and if you call B.getAttributeContents(), then you will not get
the attribute declarations defined on &#65533;A&#65533;.
<br>
</blockquote>
That's right.<br>
<blockquote
cite="mid:074df82241d09a6b779a326c3753c3e4$1@www.eclipse.org"
type="cite"><br>
Therefore, in my opinion, the method
XSDSimpleTypeDefinition.getContents() should work in a similar way.
<br>
</blockquote>
I believe it does.<br>
<blockquote
cite="mid:074df82241d09a6b779a326c3753c3e4$1@www.eclipse.org"
type="cite"><br>
If you have a situation as Keshavrao described (I removed the xs:string
in the memberTypes to make the example more simple):
<br>
<br>
&lt;?xml version='1.0' encoding='UTF-8'?&gt;
<br>
&lt;xs:schema targetNamespace="SimpleTypeDefinitionExtendingUnion.xsd"
<br>
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210371 is a reply to message #210363] Thu, 13 March 2008 16:54 Go to previous messageGo to next message
Keshavrao  is currently offline Keshavrao Friend
Messages: 34
Registered: July 2009
Member
Hi ed,
Yes the parser doesnt return the contents of parent type on the
derived type but it does return the membertypedefinitions of the parent
type in the child type.
Re: EMF XSD Parser Bug for SimpleType Definition in case of List and Union [message #210379 is a reply to message #210371] Thu, 13 March 2008 17:28 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Keshavrao,

Indeed. It also returns the effective facets collected from the entire
type hierarchy. Generally, in order to work abstractly with a specific
simple type, you only need to look at the information directly available
on that type without further analysis of the type hierarchy.


Keshavrao Veerapaneni wrote:
> Hi ed,
> Yes the parser doesnt return the contents of parent type on the
> derived type but it does return the membertypedefinitions of the
> parent type in the child type.
>
Previous Topic:content assist, folding , hiding
Next Topic:JSDT: types scoping differs from browsers
Goto Forum:
  


Current Time: Fri Nov 28 23:13:38 GMT 2014

Powered by FUDForum. Page generated in 0.10409 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software