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
|