Resolution to XML Protocols Last Call Issue 353

Micah

In the email at [1] you raised on behalf of the XForms working group a set
of issues, several of which the XML Protocols Workgroup identified
collectively as it's last call issue number 353 [2].  This note represents
the official response of the XML Protocols workgroup to your request.

Here is a brief summary of our decisions regarding your individual
suggestions:

>> n) [Part2 2.1 Graph Edges & 2.2 Graph Nodes]
>> In the above sections, please provide an examples of non-XML data
>> structures, such as a 'struct' and 'array' from a programming language,
and
>> how these map to abstract nodes and edges, or alternately include a
>> hyperlink to such examples in a separate document.

Our general intention has been to minimize the inclusion of tutorial
material in the normative portion of the specification.  In addition, we
note that the recommendation does not in fact define a mapping from
programming languages, but only from an abstract data model.  Finally, we
generally try to avoid examples involving particular programming languages,
as it is difficult to avoid implicitly supporting or undermining the
interests of various member organizations that base their investments on
particular programming languages or technologies.  Accordingly, we
respectfully decline this suggestion.

>> o) [Part2
>>   3.1.1 Encoding graph edges and nodes &
>>   3.1.2 Encoding simple values &
>>   3.1.3 Encoding compound values &
>>   3.1.4 Computing the Type Name property &
>>   3.1.5 Unique identifiers &
>>   3.1.6 arraySize Attribute Information Item]
>> For each of the above sections, please include at least one example, or
>> alternately include a hyperlink to an example in a separate document.

Here too, we respectfully decline to include examples in the normative
parts of the recommendation.

>> p) [Part2 3.1 Rules for encoding Graphs in XML]
>> "The encodings are described below from the perspective of a
de-serializer."
>> Not only does this point of view conflict with the section name, it also
>> makes understanding the encoding unnecessarily difficult. Please
re-write
>> this section from the point of view of an XML serializer.

I was involved, along with one other editor, in drafting this section.  Our
original approach was indeed to adopt the perspective of the serializer.
In fact, this proved extremely difficult, and the current formulation
proved much more straightforward.  Though there are a number of subtleties,
the essence of the reason is that there is a 1-to-many relationship of
graphs to encodings:  the same graph can in general be represented many
ways (for example, the placement in the xml of targets of a ref= attribute
is in many cases not significant.  Conversely, each serialized encoding
represents exactly one graph.  Accordingly, we start with a serialization
and say essentially "this is THE graph it represents".  We then say in
effect "to serialize a graph, you can use any of the representations the
decode to the correct graph."

We agree that the title of the section was misleading, and have therefore
in response to your suggestion we have renamed it:  "Mapping between XML
and the SOAP Data Model".

>> q) [Part2 3.1.1 Encoding graph edges and nodes]
>> The first sentence of this section is strongly worded, and suggests that
>> element information items *only* represent edges, when in fact they at
times
>> represent a combined edge and node. (for example in the first sentence
of
>> 3.1.3) Please correct this.

As you suggest, the text in section 3.1.1 has been updated [3].  It now
reads:

"1. If the element information item representing the edge does not have a
ref attribute information item (see 3.1.5.2 ref Attribute Information Item)
among its attributes then that element information item is said to
represent a node in the graph and the edge terminates at that node.

In such cases the element information item represents both a graph edge and
a graph node."

>> Bullet 4 mentions "a graph edge [that] does not terminate in a graph
node".
>> This is confusing, and seemingly in conflict with the first sentence in
2.1:
>> " Edges in the graph are said to originate at a graph node and terminate
at
>> a graph node."

In closing issue 302 [4], the workgroup has verified its decision that
edges can be "dangling" at either the source or the destination end.  The
note resolving that issue is at [5], and it includes a statement of our
intention to:

"close this issue by adding the following
text to Section 2.1[6] {<== reference number changed...NRM}

"An edge MAY have only an originating graph node, that is be outbound only.
An edge MAY have only a terminating graph node, that is be inbound only."

We hope that these resolutions are acceptable.  If not, please inform the
workgroup as soon as possible.  Thank you very much.

Noah Mendelsohn

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0090.html
[2] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x353
[3]
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#encodingedgesandnodes
[4] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x302
[5] http://lists.w3.org/Archives/Public/xmlp-comments/2002Oct/0011.html
[6] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#graphedges

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 8 October 2002 15:31:59 UTC