- From: Dan Brickley <danbri@w3.org>
- Date: Fri, 19 Apr 2002 11:16:46 -0400 (EDT)
- To: <w3c-rdfcore-wg@w3.org>
- cc: <em@w3.org>
As I just mentioned in the teleconference, the XMLP WG are currently
finalising their designs for the SOAP Encoding Data Model and its concrete
XML syntax. Their current published TR doesn't include their Data Model,
but I'm told the unpublished editors draft is considered stable. There is some
interest (and discussion within the SemWeb and Web Service CGs) about
ensuring RDF folk take a look at this work. Eric Miller is responsible for
arranging this.
As an informal nod in that direction, I just wanted to point the WG at the
relevant part of their spec for arrays/containers.
Context:
The SOAP Data Model
http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html#datamodel
SOAP Encoding
http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html#soapenc
in particular, arrays:
http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html#arraySizeattr
BTW I am working on an implementation that converts SOAP
Encoding into RDF; I hope to complete it while SOAP is in Last Call, and
report my findings. I've not figured out how to map between the SOAP and
RDF container constructs yet. Max Froumentin at W3C has some XSLT that
implements some of this mapping, but there is much work to do re
datatypes, uris, containers. And also some bits of the SOAP spec we didn't
understand.
More context below; some (selected) excerpts to give a flavour of their
design. I encourage anyone looking into this closely to work from their
document (and note the version number), not from my quick excepting job
below.
This part of the SOAP spec is often used in an RPC context. The container
machinery provides mechanisms for representing portions of a partially
transmitted array. I am unfamiliar with the details, but this is my basic
understanding of what they're doing.
Currently this is sent as a FYI for those looking at inter-WG issues
surrounding containers, and at tweaking the RDF container design to better
anticipate WebOnt's contribution.
Dan
Excerpts:
[[
2. The SOAP Data Model
The SOAP Data Model represents application-defined data as a directed,
edge-labeled graph of nodes. Section 3. SOAP Encoding describes how to
encode instances of data that conform to the data model for inclusion in
SOAP messages. Section 4. SOAP RPC Representation defines a convention for
how to use the data model for representing RPC calls and responses.
The purpose of the data model is not to introduce a programming model in
SOAP but rather to provide a mapping of non-XML based instance data to
some wire representation. It is important to note that use of the SOAP
Data Model, the accompanying SOAP Encoding (see 3. SOAP Encoding), and the
SOAP RPC Representation (see 4. SOAP RPC Representation) is optional.
Applications which already model data in XML, for example using W3C XML
Schema [4],[5], may never have any need for using the SOAP Data Model.
Because of the optionality of using the SOAP datamodel, the SOAP Encoding,
and the SOAP RPC Representation, it is NOT a requirement to implement it
as part of a SOAP node.
]]
[[
3. SOAP Encoding
SOAP Encoding describes how to encode instances of data that conform to
the data model described in 2. The SOAP Data Model for inclusion in SOAP
messages. This encoding MAY be used to transmit data in SOAP header blocks
and/or SOAP bodies. Other data models, alternate encodings of the SOAP
model, as well as unencoded data MAY also be used in SOAP messages ( see
SOAP Encoding Attribute for specification of alternate encoding styles ),
( see 4. SOAP RPC Representation for restrictions on data models and
encodings used to represent SOAP Remote Procedure Calls).
....
3.1 Rules for Encoding Graphs in XML
XML allows very flexible encoding of data. SOAP Encoding defines a
narrower set of rules for encoding the graphs desribed in 2. The SOAP Data
Model. This section defines the encoding at a high level, and the next
section describes the encoding rules in more detail.
...
3.1.3 Encoding compound values
...
#
For a graph edge which is distinguished by position ( "array" or "generic"
):
*
The ordinal position of the graph edge corresponds to the position
of the element information item relative to its siblings
*
If outbound edges are distinguished only by position ("array") then
the local name and namespace name properties of the element information
item are not significant.
#
The following rules apply to the encoding of a graph node that represents
an "array":
*
The element information item representing an array node MAY have
amongst its attributes an itemType attribute information item (see 3.1.4.1
itemType Attribute Information Item).
*
The element information item representing an array node MAY have
amongst its attributes an arraySize attribute information item (see 3.1.6
arraySize Attribute Information Item).
...
3.1.6 arraySize Attribute Information Item
The type of the arraySize attribute information item is arraySize
Value of enc:arraySize
[1] arraySizeValue ::= ("*" | concreteSize) nextConcreteSize*
[2] nextConcreteSize ::= " " concreteSize
[3] concreteSize ::= non negative integer
Each item in the list of sizes represents the size of each of the array's
dimensions (unspecified size in case of the asterisk). The number of items
in the list represents the number of dimensions in the array. The
asterisk, if present, MUST only appear in the first position in the list.
]]
Received on Friday, 19 April 2002 11:16:46 UTC