OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] WS-ResourceProperties and .NET implementations


Title: Message
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.
 
-----Original Message-----
From: Steve Tuecke [mailto:tuecke@mcs.anl.gov]
Sent: Thursday, March 04, 2004 5:06 PM
To: Jeff Bohren
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] WS-ResourceProperties and .NET implementations

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]