Moreover, the W3C TAG has made the it clear:
[
Whatever the architectural ramifications of using QNames as identifiers in
contexts other than XML element and attribute names, it is already established
practice.
It is simply not practical to suggest that this usage should be forbidden on
architectural grounds.
]
And in this case QName is used to refer to XML elements, so it is even less
questionable.
<GetMultipleProperties
xmlns:mows="http://www.oasis-open.org/tc/wsdm/sepcifications/muws/0.5/datetime/other/whatever">
<property>mows:ServiceTime</property>
<property>mows:NumberOfRequests</property>
<property>mows:NumberOfSuccessfulRequests</property>
<property>mows:NumberOfFailedRequests</property>
<GetMultipleProperties>
is clearly better and easier to process with any XML parser than
<GetMultipleProperties>
<property>http://www.oasis-open.org/tc/wsdm/sepcifications/muws/0.5/datetime/other/whatever##myWSDMseparator##ServiceTime</property>
<property>http://www.oasis-open.org/tc/wsdm/sepcifications/muws/0.5/datetime/other/whatever##myWSDMseparator##NumberOfRequests</property>
<property>http://www.oasis-open.org/tc/wsdm/sepcifications/muws/0.5/datetime/other/whatever##myWSDMseparator##NumberOfSuccessfulRequests</property>
<property>http://www.oasis-open.org/tc/wsdm/sepcifications/muws/0.5/datetime/other/whatever##myWSDMseparator##NumberOfFailedRequests</property>
<GetMultipleProperties>
Any WSDL compiler will get you
GetMultipleProperties(XmlQualifiedName[] property)
in the first case and
GetMultipleProperties(string[] property)
in the second case. One would have to do tons of extra processing
specific to WSDM URI to QName mapping to fill-in or parse the string[] propety
array.
-----Original Message----- From: Sedukhin, Igor S
Sent: Fri 3/5/2004 10:50 AM To: Jeff Bohren;
wsdm@lists.oasis-open.org Cc: Subject: RE: [wsdm]
WS-ResourceProperties and .NET implementations
I don't think you can do
<qname>urn:aa:A</qname>
and interoperably map it back to the QName which is
(urn:aa,A). Remember that the namespace of the QName could be http://my.org/spec123
XML Schema has a data type xsd:QName and there is a
reason for having it. Most of other specs e.g. XML Schema, WSDL, etc. use
xsd:QName types to designate references to other defined components. That's
the way to go. That is semantically and technically right.
The SAML interop just showed that people may not have
understood what the QName is. They should just read XML and XML Schema specs
better. Noone ever uses the lexical representation of the QName in its XML
serialized form. You are supposed to resolve perfix to QName and build a
tuple. Any XML parser will do it for you. Any DOM Node has local name and
namespace. Those have to be used.
-----Original Message----- From: Jeff Bohren
[mailto:jbohren@opennetwork.com] Sent: Fri 3/5/2004 8:37 AM
To: wsdm@lists.oasis-open.org Cc: Subject:
RE: [wsdm] WS-ResourceProperties and .NET
implementations
My
concern is not with using QNames for the elements themselves, but with using
QNames for element and attribute values.In other words:
<GetMultipleResourcePropertiesRequest>
<qname
xmlns:a="aa">urn:aa:A</qname>
<qname
xmlns:b="bb">urn:bb:B</qname> </GetMultipleResourcePropertiesRequest>
Is fine,
but:
<GetMultipleResourcePropertiesRequest>
<qname
xmlns:a="aa">a:A</qname>
<qname
xmlns:b="bb">b:B</qname> </GetMultipleResourcePropertiesRequest>
Is going to cause problems.
At
the SAML 1.1 Interop at the RSA 2004 conference last week, this absolutely
caused interoperability problems and several vendors had to make code
changes on site to handle QNames that had different prefixes than they
expected (but where legal).
That is not to say that QNames names could not be made to work. But
the question is since URNs would accomplish the same thing as QNames in this
context, and don't have the issues that QNames have, why would we use QNames
instead of URNs?
Jeff Bohren
Product Architect
OpenNetwork Technologies,
Inc
Try the
industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
If I
understand this document correctly, it can be summarized as, "You should
really only use qnames to refer to element and attribute names." A
resource property is simply an element. Therefore, referring to the
resource property by the qname of its element name seems to be fit just
fine within the valid uses allowed by this
document.
-Steve
At 02:03 PM 3/4/2004, Jeff Bohren
wrote:
I apologize if this issue was raised already, but
why are we planning on using QNames for the resource property names
instad of URNs? It was my understanding that this was discouraged by the
W3C as indicated in: http://www.w3.org/2001/tag/doc/qnameids.html Jeff Bohren Product
Architect OpenNetwork Technologies,
Inc Try the industry's
only 100% .NET-enabled identity management software. Download your free
copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval.
- -----Original Message-----
- From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
- Sent: Monday, March 01, 2004 11:03 PM
- To: MURRAY,BRYAN (HP-Seattle,ex1); MURRAY,BRYAN
(HP-Seattle,ex1); wsdm@lists.oasis-open.org
- Subject: RE: [wsdm] WS-ResourceProperties and .NET
implementations
- Bryan,
- On #2, I've tried high an low in the past few days. I could do a
rather ugly work around on the server side, but never on the client
side. There is no such construct in WSDL or schema that would allow a
generated client to serialize it properly. You say [you may need to get the namespace list for the
current message]. That is right, but unless one is assembling
the whole message "manually" that is not actually possible.
- I want to make sure that manageability Web service can be used by
.NET applications and business processes right now. I understand there
is a bug in .NET, but nevertheless, I believe achieving broad
interoperability is of the utmost importance. Otherwise we can keep
sending SNMP traps among our software :).
- Another thing. The intention of the WSRP spec could be interpreted
as a need to have an array of QNames which is then modeled as a simple
list. I don't think it is possible to say that it must be a list or an
array as there is no clear difference between those. There are other,
more interoperable, representations of an array.
- So I suggest that in order to get past this issue we just work out
the most easily interpretable solution which is
- <GetMultipleResourcePropertiesRequest>
- <qname xmlns:a="aa">a:A</qname>
- <qname xmlns:b="bb">b:B</qname>
- </GetMultipleResourcePropertiesRequest>
- One may say that
- <GetMultipleResourcePropertiesRequest xmlns:a="aa"
xmlns:b="bb">a:A
b:B</GetMultipleResourcePropertiesRequest>
- is better, but I don't see any justification of why is it
necessarily better, except the personal preferences. The former could
actually be more efficient for SAX ser/deser.
- -----Original Message-----
- From: MURRAY,BRYAN (HP-Seattle,ex1) [mailto:bryan.murray@hp.com]
- Sent: Mon 3/1/2004 9:57 PM
- To: Sedukhin, Igor S; MURRAY,BRYAN (HP-Seattle,ex1);
wsdm@lists.oasis-open.org
- Cc:
- Subject: RE: [wsdm] WS-ResourceProperties and .NET
implementations
- Igor,
- Regarding #3 you are right.
I had a local copy of the .xsd file when I tried this. In fact with
the wsewsdl tool I am not convinced it supports either import or
include for either WSDL or schema.
- For #2 I don't think you
need to assemble your own SOAP messages. I think if you define the
following (I have not tried it yet) you should have code that accepts
messages that complies with the schema definition and works around the
deficiencies of the wsdl tool.
- [WebMethod]
- public XmlElement[]
GetMultipleResourceProperties(string nameList)
- {
- string[] names =
nameList.Split(new char[2]{' ', '\t'});
- XmlQualifiedName[]
qnames = new XmlQualifiedName[names.Length];
- // Its possible that
you may need to get the namespace list for the current message and
look up the prefix
- for (int i = 0; i
< names.Length; ++i) qnames[i] = new
XmlQualifiedName(names[i]);
- return
GetMultipleResourceProperties_Future(qnames);
- }
- private XmlElement[]
GetMultipleResourceProperties_Future(XmlQualifiedName[]
names)
- {
- . . .
- }
- It seems like the right
answer for supporting the XML list mechanism would be to define the
XmlListAttribute which then gets used by the serializer. Sigh - maybe
in Indigo.
- Bryan
- -----Original Message-----
- From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
- Sent: Monday, March 01, 2004 12:13 PM
- To: MURRAY,BRYAN (HP-Seattle,ex1);
wsdm@lists.oasis-open.org
- Subject: RE: [wsdm] WS-ResourceProperties and .NET
implementations
- Bryan,
- #1 ok, ##other is
fine
- #2 I'm not worried about the
software that we write, but if WSDM 0.5 cannot be implemented or used
using existing tools, then that is the problem. And I do not consider
assembling SOAP message manually as an XML document as "using tools".
So, if there is a WSDM 0.5-enabled manageable WS somewhere, without
fixing #2, noone having VS.NET as their development environment will
be able to build make use of that WS unless they hand code SOAP
messages and discard WSDL. That is not reasonable.
- There are lot of things that
one could to with the schema and I don't know which is right. I don't
think anyone has the authority to say whoch is right, but we can tell
which is interoperable and which is not right now. So,
- <manyQnames>a:A
b:B</manyQnames>
- and
- <manyQnames>a:A</manyQnames><manyQnames>b:B</manyQnames>
- and
- <manyQNames><qname>a:A</qname><qname>b:B</qname></manyQNames>
- are essentially equivalent,
the later is simpler to serialize.
- #3 [schemaLocation attribute
with just the file name - make it only WS-ResourceProperties.xsd. With
this change it should work.]
- No it will not work. You'd
get
- [Error: A schema
with the namespace 'http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties'
has already been added.]
- I know it is porobably bug
in .NET, but I'd like people using VS.NET to be able to add a Web
reference to the manageability service just like they add a Web
reference to any other service.
- So, one way to solve this is
to inline the whole WSRP schema directly in WSDL (which is what I did
and it works), or, which is more appropriate define schema in one
namespace and WSDL in another and then import schema namespace in
WSDL. That also works.
- -- Igor Sedukhin .. (igor.sedukhin@ca.com)
- --
(631) 342-4325 .. 1 CA
Plaza, Islandia, NY 11788
- From: MURRAY,BRYAN (HP-Seattle,ex1)
[mailto:bryan.murray@hp.com]
- Sent: Friday, February 27, 2004 2:07 PM
- To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
- Subject: RE: [wsdm] WS-ResourceProperties and .NET
implementations
- Igor,
- My approach would be to make
minor changes to the WS-RP WSDL and schema to make it work as it
appears to be intended by the specification. In order to do this we
temporarily need to have our own copies of the WS-RP files. For .NET
the WSDL tool used should be from the WSE 2.0 toolkit (wsewsdl) rather
than the one shipped with the .NET Framework - there are several bug
fixes in it. For the specific problems you discovered I propose the
following solutions:
- #1: I agree with you that
the current WSDL does not reflect the intent of the specification as
shown in the example SOAP messages. Your suggested change should be
incorporated into the WSDL except that namespace="##other" should be
added to the any element.
- #2: I think the WSDL here is
correct and any implementation complying to this WSDL should
interoperate just fine. Clearly it is the intent of the spec to have a
list of QNames as an argument to GetMultiple... So, rather than
changing the operation here, I would suggest that for platforms that
do not support the list construct in schema, that they code around it.
This means that argument would be interpreted as a string by the code
and split into a list internally. This will still interoperate on the
message level with platforms that do support the list construct. I
suggest no change here.
- #3: This seems to be a bug
in the .NET WSDL tool (including wsewsdl). Since we temporarily need
our own copies of the WSDL and schema files, we can work around this
problem by replacing the value of the schemaLocation attribute with
just the file name - make it only WS-ResourceProperties.xsd. With this
change it should work. I am not sure what the right answer is when
WS-RP files have been fixed and have a final home. The same change is
OK in final files as long as the WSDL and schema files are located in
the same directory. The right answer is to get Microsoft to fix the
tool.
- Bryan
- -----Original Message-----
- From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
- Sent: Wednesday, February 25, 2004 8:43 PM
- To: wsdm@lists.oasis-open.org
- Subject: [wsdm] WS-ResourceProperties and .NET
implementations
- I have spent some time trying to see if
the subj. could be implemented and it provides to be quite a
challenge. Here are my findings that I wanted to share with the group
and see if anyone else tried it with a better outcome.
- #1
- I'm not sure that the following is
right
- [<xsd:element name="GetResourcePropertyResponse" type="xsd:anyType"/>]
- This definition requires SOAP serializer
to include xsi:type *of the element itself*. This definition
contradicts what the specifications says. What the spec says it should
be
- [<GetResourcePropertyResponse><abc:property>value</abc:property></GetResourcePropertyResponse>]
- According to the above element
declaration, it will *always* be serialized as
- [<GetResourcePropertyResponse
xsi:type="whateverAbcPropertyType">value</GetResourcePropertyResponse>]
- The response element should be declared as
a container.
- [
- <xsd:element name="GetResourcePropertyResponse">
- <xsd:complexType>
- <xsd:sequence>
- <xsd:any minOccurs="0" maxOccurs="1" />
- </xsd:sequence>
- </xsd:complexType>
- </xsd:element>
- ]
- #2
- The following does not appear to be
interoperable at all.
- [
- <xsd:element name="GetMultipleResourcePropertiesRequest">
- <xsd:simpleType>
- <xsd:list itemType="xsd:QName" />
- </xsd:simpleType>
- </xsd:element>
- ]
- The simple type list definition is merely
ignored and looks like this [System.Xml.XmlQualifiedName
GetMultipleResourcePropertiesRequest]
in the code.
- We can, of course, wait until it is fixed
by Microsoft, but I don't think we can, and so WS-ResourceProperties
must be fixed. Following is one possibility.
- [
- <xsd:element name="GetMultipleResourcePropertiesRequest">
- <xsd:complexType>
- <xsd:sequence>
- <xsd:element name="qname" type="xsd:QName" />
- </xsd:sequence>
- </xsd:complexType>
- </xsd:element>
- ]
- #3
- [
- <wsdl:types>
-
<xsd:schema
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- targetNamespace=
- "http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties">
- <xsd:include
schemaLocation=
- "http://www-106.ibm.com/developerworks/webservices/library/ws-resource/WS-ResourceProperties.xsd"
- />
- ]
- Tools think that two definitions of the
same namespace exist. Both this schema and the included schema define
the same namespace.
- Inlining schema in the WSDL of
WS-ResourceProperties helps resolve this. Another approach is to
xsd:import and introduce dummy namespace in WSDL types
section.
- -- Igor Sedukhin .. (igor.sedukhin@ca.com)
- --
(631) 342-4325 .. 1 CA
Plaza, Islandia, NY 11788
|