RE: XML Schema requires a type in addition to name to identify an element

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: XML Schema requires a type in addition to name to identify an element

Jonathan Marsh-2

Thanks for your comment.  The WS Description Working Group tracked this issue as a CR078 [1].

 

The Working Group, in part because of the late stages of development we’re in, was unable to reach consensus to add functionality to address your scenario.  We note a few workarounds, some more attractive than others, which you might consider in addressing your scenario

1)     Use element=”#any”.  This reduces the descriptiveness completely, which is at odds with the desire to describe a specific FpML structure.

2)     Use element=”fmpl:FpML”.  This allows only FpML documents, but doesn’t further constrain the precise structure of FpML.  This isn’t unreasonable, as it doesn’t circumvent the kind of flexibility for which the schema was originally designed, yet it doesn’t support the use case of specifying a subset of the possible structures that is intended for the operation.

3)     Wrap the FpML types in a set of wrapper elements (unfortunately not named FpML), so the content of the element can be precisely determined.  Unfortunately this morphs the root element name on the wire, so the messages conform to the wrapped schema, but not directly to the unwrapped FpML schema.

4)     Use an extension of your own invention to specify further validation constraints (such as the allowed values of xsi:type).  This is slightly more machine-readable than specifying the further constraints in text.

5)     Consider an extension framework, such as SAWSDL [2], to encode higher level semantics and constraints upon the message exchanges.

 

Unless you let us know otherwise by the end of October, we will assume you agree with the resolution of this issue.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR078

[2] http://lists.w3.org/Archives/Public/public-ws-semann-comments/

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Sunday, August 06, 2006 9:25 AM
To: [hidden email]
Cc: [hidden email]; Steve Ross-Talbot; [hidden email]
Subject: XML Schema requires a type in addition to name to identify an element

 


 


This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

Reply | Threaded
Open this post in threaded view
|

RE: XML Schema requires a type in addition to name to identify an element

Matthew Rawlings

Thank you for considering this implementation issue. I understand this occurred at a late stage of development. I agree with the resolution for this version of WSDL.

 

Matthew Rawlings

+44 791 539 7824


From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonathan Marsh
Sent: 20 October 2006 21:57
To: [hidden email]
Cc: [hidden email]; Steve Ross-Talbot; [hidden email]; [hidden email]
Subject: RE: XML Schema requires a type in addition to name to identify an element

 

Thanks for your comment.  The WS Description Working Group tracked this issue as a CR078 [1].

 

The Working Group, in part because of the late stages of development we’re in, was unable to reach consensus to add functionality to address your scenario.  We note a few workarounds, some more attractive than others, which you might consider in addressing your scenario

1)     Use element=”#any”.  This reduces the descriptiveness completely, which is at odds with the desire to describe a specific FpML structure.

2)     Use element=”fmpl:FpML”.  This allows only FpML documents, but doesn’t further constrain the precise structure of FpML.  This isn’t unreasonable, as it doesn’t circumvent the kind of flexibility for which the schema was originally designed, yet it doesn’t support the use case of specifying a subset of the possible structures that is intended for the operation.

3)     Wrap the FpML types in a set of wrapper elements (unfortunately not named FpML), so the content of the element can be precisely determined.  Unfortunately this morphs the root element name on the wire, so the messages conform to the wrapped schema, but not directly to the unwrapped FpML schema.

4)     Use an extension of your own invention to specify further validation constraints (such as the allowed values of xsi:type).  This is slightly more machine-readable than specifying the further constraints in text.

5)     Consider an extension framework, such as SAWSDL [2], to encode higher level semantics and constraints upon the message exchanges.

 

Unless you let us know otherwise by the end of October, we will assume you agree with the resolution of this issue.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR078

[2] http://lists.w3.org/Archives/Public/public-ws-semann-comments/

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Sunday, August 06, 2006 9:25 AM
To: [hidden email]
Cc: [hidden email]; Steve Ross-Talbot; [hidden email]
Subject: XML Schema requires a type in addition to name to identify an element

 


 


This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.