OK, I
understand now. The QName is of the property to retrieve is not merely a
indication of what attribute to return, but is acutally reference to an XML
element name defined in another schema, indicating that element should be
returned. Did I understand that right? If that is the case then a QName is
appropriate.
I did
understand that if the xsd defines a value to be of type QName, then
you have to specifiy a QName and not a URN. My question was more general than
that. It's more of why are we using this mechanism in the first place. It seems
we are doing something fairly complicated for just asking for a list of
attribute values. Again I apologize if I am bringing old
issues.
There
are other issues besides developers not understanding QNames that need to be
taken into consideration. When doing XMLDSig, I don't believe that exclusive
cononicalization will cononicalize attribute values or element value. Thus if a
requestor signed a GetMultipleResourcePropertiesRequest, the service may not be
able to verifiy the signature if any namespace mappings
occured in between. I'm not sure if that usage would ever be an issue in
WSDM, but it's an issue we should take into consideration.
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.
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
|