- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Tue, 15 Jul 2003 13:52:39 -0700
- To: Jim Webber <jim.webber@arjuna.com>
- CC: "'Savas Parastatidis'" <Savas.Parastatidis@newcastle.ac.uk>, public-ws-desc-state@w3.org
- Message-ID: <3F146997.7040708@oracle.com>
Jim Webber wrote: > Umit: > > The proposal allows the following: > > <attribute name="foo"> > <get body="x:fooType"/> > <set body="x:barType"/> > </attribute> > > I think you might be right. But I think the spirit of what Savas and > Sanjiva have said is probably right too. How about a simple syntactic > resolution to Savas's suggestion: > > <attribute name="ncname" access="get|set|both" > [(body="qname") | (element="qname")]> > [<xsd:complexType> ... </xsd:complexType>] > </attribute > > Jim, This looks like what I suggested [1]. I think putting the keyword as access is a good idea. It also implies whether a particular attribute is queriable or settable. :-) > Thus you'd have attribute declarations like: > > <attribute name="foo" access="set" body="f:FooType"/> > I would like to explore answers to my questions further as posted in [1]. -- The exact content of the get message exchange -- The set message exchange. -- SOAP HTTP binding and name resolution (with respect to keywords.) We need to do this regardless of whether we satisfy the multi attribute query requirement from [2]. > Now the other issues about where WSDL stops and other specs start I > think is actually relatively clear cut. I think if WSDL can allow > third party specifications to achieve what they want to achieve (the > Grid community immediately springs to mind as a group that WSDL > can/will be able to support), then that's as far as it needs to go. At > the moment there is a strong push from some user communities (In fact > this mailing list is symptomatic of that push :-)) to refactor some of > their own "vertical" issues into the "horizontal" WSDL. That is not to > say that such feedback is invalid, but care should be taken by the WG > that it does not become the vehicle for the advancement of one > particular use-case at the expense of others. > > Personally I believe that the extensibility model in WSDL is the way > that third parties should primarily embrace and extend WSDL. I would > be all ears if people talked about improving the extensibility model > since it would benefit all user communities. However some significant > elements of the feedback to the WG doesn't seem to be pitched at the > meta-level, and instead suggests changes to the nuts and bolts of WSDL > which others may rely on. Thus the scope of the WG may have to be, > necessarily, brutally defined to prevent feature creep from verticals. > I think you may consider talking to the properties and features folks. Their focus is to allow extensibility in a more pluggable way. The problem is one person's nuts and bolts is the other person's extension :-). What you may consider is a vertical is not necessarily a vertical, it just looks like this because one group may see the need for nuts and bolts, can not find it in WSDL and instead develops a spec for it elsewhere. This is especially problematic if several groups start building similar extensions, not in WSDL, but elsewhere. There are many specifications that extend WSDL today. I personally find it particularly problematic, especially for interoperability. When vendors have to build several layers of the web services stack, you immediately know the holes. Therefore, I think WSDL will benefit from incorporating some of this type of work as the nuts and bolts, instead of leaving it to extensions. Again, this is a philosophical conversation and I would prefer we first tackle the problem at hand, namely the message structure and content for attributes. > Jim > --umit References: [1]http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jul/0043.html [2]http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jun/0061.html > -- Umit Yalcinalp Consulting Member of Technical Staff ORACLE Phone: +1 650 607 6154 Email: umit.yalcinalp@oracle.com
Received on Tuesday, 15 July 2003 16:53:08 UTC