W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Re: Issue 225: accommodating non-XML data models (proposal)

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 16 Jun 2004 15:35:46 -0700
Message-Id: <82367022-BFE5-11D8-8A84-000A95BD86C0@bea.com>
Cc: Roberto Chinnici <Roberto.Chinnici@Sun.COM>, "<www-ws-desc@w3.org>" <www-ws-desc@w3.org>
To: "David Orchard" <dorchard@bea.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT