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

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.

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. 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.

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". 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.

Roberto


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
>

Received on Wednesday, 16 June 2004 15:57:08 UTC