[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] WS-ResourceProperties and .NET implementations
+1
Jeff Bohren wrote:
> 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* <http://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
>> <http://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
--
John DeCarlo, The MITRE Corporation, My Views Are My Own
email: jdecarlo@mitre.org
voice: 703-883-7116
fax: 703-883-3383
DISA cube: 703-882-0593
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]