Re: ETF: Issue 47 (SOAP Data Model)

Shouldn't the data model specifically call out the names and value spaces 
of the simple types from XML Schema Datatypes, pointing out that support 
for the builtins is mandatory and that derivations are allowed as well? As 
it stands, we are putting limits on the nature of structured types in the 
model, but not simple types. 

There's even a bit more subtlety we might want to consider:  are the 
lexical forms of a simple type carried in the node?  From the point of 
view of the graph, can I distinguish the integer "01" from the integer 
"1".  I would say the answer has to be "no", or else you wouldn't be able 
to store the node in a Java int.  Still, there is always confusion on this 
point when schema datatypes are used.  My recommendation would be:  the 
graph data model deals only in the value space, the standard encoding uses 
the lexical forms.

In any case, I think the model should say something explicit about all of 
this.  Thanks.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Marc Hadley <marc.hadley@sun.com>
Sent by: xml-dist-app-request@w3.org
12/19/01 07:31 AM

 
        To:     "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
        cc: 
        Subject:        Re: ETF: Issue 47 (SOAP Data Model)


Attached is a new version of the proposed text for the "SOAP Data Model"
section in part 2 of the specification. This addresses comments against
the previously proposed text[1].

The new text retains the reference to "multistructs" pending resolution
of this issue.

Comments, flames etc ?

Regards,
Marc.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0219.html

--
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.


3 SOAP Data Model

The SOAP data model represents information as a graph of typed
objects. The type system used in the SOAP data model is a
generalization of the common features found in type systems in
programming languages, databases and semi-structured data. A type is
either a simple (scalar) type or is a compound type constructed as a
composite of several other typed parts. Examples of simple types are
"string," "integer," enumeration, etc.

Compound types are described as follows:

1. Within a compound type, each part is potentially distinguished
by a name, ordinal or both. This is called its "accessor". It is
possible to have compound types with several accessors each
named the same, as for example, RDF does.

2. An "array" is a compound type in which ordinal position serves
as the only distinction between member parts.

3. A "struct" is a compound type in which accessor name is the
only distinction among member parts, and no accessor has the
same name as any other.

4. In some cases it may be necessary for more than one accessor to
reference the same instance of part of a compound type. If only
one accessor references it, an instance is considered
"single-reference". If referenced by more than one it is
"multi-reference."

Section 4 (SOAP Encoding) describes how to serialise instances of data
that conform to this data model for inclusion in SOAP messages. See
section 5 (Using SOAP for RPC) for an example use of this data model.

Received on Wednesday, 19 December 2001 11:08:21 UTC