[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]