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

+1 .. have we crossed the 1000 page mark on the primer yet?

Sanjiva.

----- Original Message ----- 
From: Prasad Yendluri
To: David Orchard
Cc: Mark Nottingham ; Roberto Chinnici ; www-ws-desc@w3.org
Sent: Thursday, June 17, 2004 4:20 AM
Subject: Re: Issue 225: accommodating non-XML data models (proposal)


+1.

That way we don't have to get it precise or fight over dotting i's and
crossing t's if it goes in the spec. It would serve the purpose of showing
people how to use extensibility to accomplish this. It would not be as
taxing on our schedule if this were to go in the main spec.

Regards, Prasad

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.

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

Received on Wednesday, 16 June 2004 23:22:19 UTC