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

On Jun 16, 2004, at 12:57 PM, Roberto Chinnici wrote:

> The example you list is not valid. It should be something along the
> lines of:
>
> <description>
>   <myNs:myTypeSystem>
>     <myNs:myDataModelSchemaLanguage 
> name="blah">...</myNs:myDataModelSchemaLanguage>
>   </myNs:myTypeSystem>
>   <interface name="foo">
>     <operation name="bar">
>        <input myNs:myContent="#blah"/>
>     </operation>
>   </interface>
> </description>
>
> I.e. if you choose not to embed your data model into an infoset-based
> one, then you have to provide an extension element that works in a way
> analogous to wsdl:types as well as an extension attribute that plays
> the role of @element. Plus, invisible in the syntax, one or more
> component model properties to go with them.

Agreed.

> I agree with your last point, namely that it would be good to clarify
> in the bindings which data model / type system they support, although 
> it
> goes almost without saying that a normative binding will support the
> normative infoset-based data model.

Agreed.

>  I'm less enthusiastic about
> renaming the wsdl:types element because users are familiar with it
> from WSDL 1.1; nevertheless, we should at least highlight in the spec
> the fundamental infoset-centric assumption that we're making.

Hmm, that doesn't seem to have stopped the WG WRT interface, etc. Do 
others have thoughts here?

FWIW, the "elements" attribute and its relationship to the "types" 
element has always been one of the more non-intuitive things in WSDL to 
me, and I'd very much like to correct this, if we can. Telling people 
who are familiar with WSDL 1.1 that "types" is now "elements" doesn't 
seem like a great stretch, at all.

Also, do you object to adjusting the sentence re: data model so that 
it's specific to the types section (my #1)?

> Perhaps the best way to clarify these issues would be to have an
> appendix along the lines of E but focusing on "specifications of
> extension elements for alternative type system (or data model)
> support".

That might work; I'll try to come up with a proposal.

> If the example was based on a data model readers
> of the spec were likely to be familiar with, as opposed to some
> obscure one, it would go a great way in showing how such
> data models should be handled.

Understood.


Thanks,


> Mark Nottingham wrote:
>> 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 16:14:15 UTC