You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Frank Budinsky <fr...@ca.ibm.com> on 2010/01/07 16:26:00 UTC

Re: Why the static sdo is processed like a xsd defined global element? but not Type?

This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you
have this schema:

<element name="A" type="ns:AT">
<complexType name="AT">
  ...
</complexType>

and you  serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")

  save((DataObject)a, "http://test/choice", "B")

then the generated XML will look like this:

  <B xsi:type="AT"> ... </B>

If, on the other hand, you use element "A" to serialize:

  save((DataObject)a, "http://test/choice", "A")

then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".

  <A> ... </A>

Now, in the case of an anonymous type:

<element name="A">
  <complexType>
    .....
  </complexType>
</element>

In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:

  <B xsi:type="????"> ... </B>

So the instance would be invalid XML and the value type would be lost.

Frank.


"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:

> [image removed]
>
> Why the static sdo is processed like a xsd defined global element?
> but not Type?
>
> ext2
>
> to:
>
> user
>
> 01/07/2010 03:28 AM
>
> Please respond to user
>
>
> Hi:
>
> According to my- understand , the sdo specification ask for  static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
>
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated  static java  is process like a global
element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect.
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if  saving the  static sdo to xml , the
argument
> provided specifiy element name will affect;
>
> For example , if xsd like this:
> <element name="A">
>    <complexType>
>     .....
>    </complexType>
> </element>
>
> A static sdo interface as A.java will generate, but if I save the
instance
> to xml like follow : save((DataObject)a,  "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
>
> But if xsd like this:
>
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
>
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name.
>
> So why does Tuscany keep this as un-consistency? A bug ? Or there are
some
> way I can control?
>
> Thanks for any suggest
>
>

Re: Why the static sdo is processed like a xsd defined global element? but not Type?

Posted by ext2 <xu...@tongtech.com>.
A trivial suggestion, maybe when save anonymous sdo to a different name, it
should report a exception instead of save to different xml silently. 

 

  _____  

Sender:ext2 [mailto:xuhb@tongtech.com] 
Date: 2010年1月8日 11:27
Receiver:user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?

 

Thanks Frank Budinsky:

         If focus on xml specification, you are right. 

 But the real world is sophisticate, some other Java-XML process technical
will presume a name for the anonymous type(according to name of element).
But anyway this is just the application ‘s response to resolve this by
change xsd manually , it shouldn’t be the tuscany’s response and Tuscany
shouldn’t simulate it;

 

Thanks  a lot

 

 

  _____  

Sender: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Date: 2010-1-7 23:26

Receiver:user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?

 

This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you have
this schema:

<element name="A" type="ns:AT">
<complexType name="AT">
 ...
</complexType>

and you serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")

  save((DataObject)a, "http://test/choice", "B")

then the generated XML will look like this:

<B xsi:type="AT"> ... </B>

If, on the other hand, you use element "A" to serialize:

  save((DataObject)a, "http://test/choice", "A")

then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".

<A> ... </A>

Now, in the case of an anonymous type:

<element name="A">
 <complexType>
   .....
 </complexType>
</element>

In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:

<B xsi:type="????"> ... </B>

So the instance would be invalid XML and the value type would be lost.

Frank.


"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:

> [image removed] 
> 
> Why the static sdo is processed like a xsd defined global element? 
> but not Type?
> 
> ext2 
> 
> to:
> 
> user
> 
> 01/07/2010 03:28 AM
> 
> Please respond to user
> 
> 
> Hi:
> 
> According to my- understand , the sdo specification ask for  static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
> 
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated  static java  is process like a global element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect. 
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if  saving the  static sdo to xml , the
argument
> provided specifiy element name will affect;
> 
> For example , if xsd like this:
> <element name="A">
>    <complexType>
>     .....
>    </complexType>
> </element>
> 
> A static sdo interface as A.java will generate, but if I save the instance
> to xml like follow : save((DataObject)a,  "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
> 
> But if xsd like this:
> 
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
> 
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name. 
> 
> So why does Tuscany keep this as un-consistency? A bug ? Or there are some
> way I can control? 
> 
> Thanks for any suggest
> 
> 


Re: Why the static sdo is processed like a xsd defined global element? but not Type?

Posted by ext2 <xu...@tongtech.com>.
Thanks Frank Budinsky:

         If focus on xml specification, you are right. 

 But the real world is sophisticate, some other Java-XML process technical
will presume a name for the anonymous type(according to name of element).
But anyway this is just the application 's response to resolve this by
change xsd manually , it shouldn't be the tuscany's response and Tuscany
shouldn't simulate it;

 

Thanks  a lot

 

 

  _____  

Sender: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Date: 2010-1-7 23:26

Receiver: user@tuscany.apache.org
Subject Re: Why the static sdo is processed like a xsd defined global
element? but not Type?

 

This is really an XML issue. In XML, When you serialize a value that is
different than the type of the element, an xsi:type attribute needs to be
specified to indicate the actual type of the value. For example, if you have
this schema:

<element name="A" type="ns:AT">
<complexType name="AT">
 ...
</complexType>

and you serialize an instance of type "AT" using a different element, like
"B" (assuming "B" is not also declared as an element of type "AT")

  save((DataObject)a, "http://test/choice", "B")

then the generated XML will look like this:

<B xsi:type="AT"> ... </B>

If, on the other hand, you use element "A" to serialize:

  save((DataObject)a, "http://test/choice", "A")

then the xsi:type is not needed because the type of the value ("AT") is the
same as specified in the schema definition of the element "A".

<A> ... </A>

Now, in the case of an anonymous type:

<element name="A">
 <complexType>
   .....
 </complexType>
</element>

In this case, the type has no name, so it can only be serialized using the
element "A" - that's presumably why it was defined anonymously in the first
place. If you try to serialize the type using a different elemnent ("B"),
there's no type name that can be used to identify the value type in the
xsi:type attribute:

<B xsi:type="????"> ... </B>

So the instance would be invalid XML and the value type would be lost.

Frank.


"ext2" <xu...@tongtech.com> wrote on 01/07/2010 03:27:44 AM:

> [image removed] 
> 
> Why the static sdo is processed like a xsd defined global element? 
> but not Type?
> 
> ext2 
> 
> to:
> 
> user
> 
> 01/07/2010 03:28 AM
> 
> Please respond to user
> 
> 
> Hi:
> 
> According to my- understand , the sdo specification ask for  static java
> type should only be generate for global types in xsd, and should not
> generate for element, is it true?
> 
> But using Tuscany, I found a surprising thing. If I using a anonymous
> complex type, the generated  static java  is process like a global element
> of xsd. That's if I save the static sdo to xml, the argument provided
> specify element name doesn't affect. 
> But if I using a named complex type, only static sdo is generated for the
> global complex type of xsd , and there are no static sdo is generate for
> global element of xsd. And if  saving the  static sdo to xml , the
argument
> provided specifiy element name will affect;
> 
> For example , if xsd like this:
> <element name="A">
>    <complexType>
>     .....
>    </complexType>
> </element>
> 
> A static sdo interface as A.java will generate, but if I save the instance
> to xml like follow : save((DataObject)a,  "http://test/choice", "B"). The
> element's name B will never take affect, and saved xml 's element name is
> always be A;
> 
> But if xsd like this:
> 
> <element name="A" type="ns:AT">
> <complexType name="AT">
> ...
> </complexType>
> 
> Only global type "AT" is generate to a AT.java , and save the AT 's sdo
> instance will take affect if we provide element name. 
> 
> So why does Tuscany keep this as un-consistency? A bug ? Or there are some
> way I can control? 
> 
> Thanks for any suggest
> 
>