- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 16 Jun 2004 15:35:46 -0700
- To: "David Orchard" <dorchard@bea.com>
- Cc: Roberto Chinnici <Roberto.Chinnici@Sun.COM>, "<www-ws-desc@w3.org>" <www-ws-desc@w3.org>
On Jun 16, 2004, at 3:15 PM, David Orchard wrote: > A suggestion: could we gather up these kinds of extensions and put > them in our Primer as an advanced topic? I could see this being a > primer section on how to use WSDL extensibility for non xml data > models. If not the primer, we could even have an "advanced topics > Note" or something like that. Agreed; I'm writing a proposal now to confine the changes to those places where the spec is confusing regarding this, not accommodate anything additional. > > I'm roughly trying to do the same thing with my scenarios: write it up > as a primer material and go into detail. > > Dave > >> -----Original Message----- >> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On >> Behalf Of Mark Nottingham >> Sent: Wednesday, June 16, 2004 12:11 PM >> To: Roberto Chinnici >> Cc: www-ws-desc@w3.org >> Subject: Re: Issue 225: accommodating non-XML data models (proposal) >> >> >> >> So, you're saying that it's the case that if I wanted to use >> a non-XML >> data model in WSDL, I would be able to use interfaces, interface >> operations, and message reference components, but would omit the >> element AII, as well as the corresponding {element} property on the >> message reference component? Furthermore, that doing so would not >> violate any requirements, and therefore still result in conformant >> WSDL? >> >> For example, I could define extensions to do something like: >> >> <description> >> <types> >> <myDataModelSchemaLanguage >> name="blah">...</myDataModelSchemaLanguage> >> </types> >> <interface name="foo"> >> <operation name="bar"> >> <input content="#blah"/> >> </operation> >> </interface> >> </description> >> >> If so, this isn't obvious from reading the specification, especially >> because the requirements for and relationships between >> components are >> distributed among their definitions as well as their >> serialisations. It >> may be that this could be remedied by some much more modest text >> changes and the resolution to issue 213 [1]. >> >> Specifically: >> >> 1) This text in section 2.1.1 is too constraining: """Type system >> components are element declarations drawn from some type >> system. They >> define the [local name], [namespace name], [children] and >> [attributes] >> properties of an element information item.""" >> >> While that's true in the case defined by WSDL today, if we >> indeed want >> to allow this type of extensibility, it doesn't work. The second >> sentence needs to go, or at least be moved to be specific to the >> <types> element. >> >> 2) The name of <types> isn't specific enough here; it isn't an >> all-encompassing repository of types, it's for those types >> based on an >> Infoset model. I propose that <types> be changed to <elements> (this >> has the added benefit of meshing nicely with the element AII used >> elsewhere, as well as the {element} properties.). >> >> 3) Finally, the binding framework should require bindings to >> enumerate >> the data models they're compatible with, and the bindings we define >> should do so (i.e., those in part 3 should specify that they only >> understand Infosets). >> >> Regards, >> >> >> 1. >> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd- >> issues.html#x213 >> >> >> On Jun 16, 2004, at 11:44 AM, Roberto Chinnici wrote: >> >>> No, what I'm asserting is that the WG considered the issue >> of non-XML >>> data models and was satisfied with the present solution, which >>> accomodates them, allows the use of attributes other than @element >>> in the syntax but encourages mapping them to element declarations >>> in the model. None of the additional information I've seen warrants >>> reopening the discussion on the level of support we provide. >>> >>> Roberto >>> >>> >>> Mark Nottingham wrote: >>>> If that were the case, the resolutions of those issues >> indicates that >>>> the WG supports accommodation of non-XML data models; >>>> 143: "Reaffirmed our desire to provide guidance on how to support >>>> non-XML type systems." >>>> issue-allow-nonxml-typesystems: "non-XML type systems are >> allowed via >>>> extensibility attributes of message/part elements." >>>> In this view, the WG has already determined that WSDL >> shouldn't be >>>> constrained to the Infoset data model, but the drafts >> don't reflect >>>> that decision. >>>> Is this what you're asserting? >>>> On Jun 16, 2004, at 11:12 AM, Roberto Chinnici wrote: >>>>> The issue on "non XML type systems" was literally about >> type systems >>>>> describing un-XML-/un-infoset-like data models, e.g. the Java type >>>>> system. >>>>> >>>>> Roberto >>>>> >>>>> >>>>> Mark Nottingham wrote: >>>>> >>>>>> These issues seem to be about non-XML Schema type systems, not >>>>>> non-Infoset data models (the language used in them is >> not precise). >>>>>> On Jun 16, 2004, at 10:31 AM, Roberto Chinnici wrote: >>>>>> >>>>>>> >>>>>>> Two of them actually: 143 [1] and "issue allow nonxml >> typesystems" >>>>>>> [2]. >>>>>>> >>>>>>> Roberto >>>>>>> >>>>>>> [1] >>>>>>> >> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd- >>>>>>> issues.html#x143 >>>>>>> >>>>>>> [2] >>>>>>> >> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd- >>>>>>> issues.html#xissue%20allow%20nonxml%20typesystems >>>>>>> >>>>>>> >>>>>>> Mark Nottingham wrote: >>>>>>> >>>>>>>> Reopen what issue number? >>>>>>>> On Jun 16, 2004, at 8:46 AM, Roberto Chinnici wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> +1 from me too. There is no need to reopen this issue >> at this >>>>>>>>> time. >>>>>>>>> >>>>>>>>> Mark asked: >>>>>>>>> >>>>>>>>>> Should RDF Schema be either disallowed from >> describing WSDL >>>>>>>>> messages, >>>>>>>>>> or forced to unnaturally contort itself somehow to >> fit into an >>>>>>>>>> Infoset data model? >>>>>>>>> >>>>>>>>> The latter. And it only needs to contort itself a >> little, since >>>>>>>>> all >>>>>>>>> we're asking for is a global element declaration or its >>>>>>>>> equivalent. >>>>>>>>> Moreover, that declaration doesn't have to represent >> faithfully >>>>>>>>> *all* >>>>>>>>> the information in the RDF Schema -- it can be as >> shallow as one >>>>>>>>> wants >>>>>>>>> -- so the burden is minimal. The leanness of the >> media type spec >>>>>>>>> is >>>>>>>>> a further confirmation of this fact. >>>>>>>>> >>>>>>>>> Roberto >>>>>>>>> >>>>>>>>> >>>>>>>>> Sanjiva Weerawarana wrote: >>>>>>>>> >>>>>>>>>> ARGH! Major +1 to Tom .. don't fix what ain't broken. >>>>>>>>>> Sanjiva. >>>>>>>>>> ----- Original Message ----- From: "Tom Jordahl" >>>>>>>>>> <tomj@macromedia.com> >>>>>>>>>> To: <www-ws-desc@w3.org> >>>>>>>>>> Sent: Wednesday, June 16, 2004 7:37 PM >>>>>>>>>> Subject: RE: Issue 225: accommodating non-XML data models >>>>>>>>>> (proposal) >>>>>>>>>> >>>>>>>>>>> Mark wrote: >>>>>>>>>>> >>>>>>>>>>>> 4) Throughout - Change instances of "element >> declaration" to >>>>>>>>>>>> "content >>>>>>>>>>>> declaration", the {element} property to {content}, and >>>>>>>>>>>> instances of the >>>>>>>>>>>> "element" Attribute Information Item to "content". >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Amy wrote in response: >>>>>>>>>>> >>>>>>>>>>>> Hmm. 13 instances of "{element}", 27 of "element >>>>>>>>>>>> declaration". Harder >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>>>> count instances of "element" attribute information >> item. But >>>>>>>>>>>> this AII >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>>>> associated with XML Schema, is it not? Do we >> *really* need >>>>>>>>>>>> to change >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> it? >>>>>>>>>> >>>>>>>>>>>> Again? The element AII appears in faults and in >> messages. >>>>>>>>>>>> In messages, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I would not be in favor of resolving issue 225 by make the >>>>>>>>>>> kind of change >>>>>>>>>>> that Mark is proposing. It strikes me that this >> could have a >>>>>>>>>>> major ripple >>>>>>>>>>> effect throughout the specification at a very bad time. >>>>>>>>>>> >>>>>>>>>>> It also seems that changes like these make the spec >> much more >>>>>>>>>>> obscure for >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> a >>>>>>>>>> >>>>>>>>>>> use case that has not been proven to be a >> requirement. Didn't >>>>>>>>>>> we (or the >>>>>>>>>>> architecture working group) define a Web Service to >>>>>>>>>>> specifically include >>>>>>>>>>> XML? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Tom Jordahl >>>>>>>>>>> Macromedia Server Development >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Mark Nottingham Principal Technologist >>>>>>>> Office of the CTO BEA Systems >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Mark Nottingham Principal Technologist >>>>>> Office of the CTO BEA Systems >>>>> >>>>> >>>>> >>>> -- >>>> Mark Nottingham Principal Technologist >>>> Office of the CTO BEA Systems >>> >>> >> >> -- >> Mark Nottingham Principal Technologist >> Office of the CTO BEA Systems >> >> >> -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Received on Wednesday, 16 June 2004 18:35:51 UTC