Scope of IDs

Congratulations on the publication of the ID Requirements working draft
[1].  Although this comment relates in part to SOAP, it is my personal
opinion and does not represent an official position of the XMLP WG (or my
employer, for that matter).

My concern is that the working draft should clarify the scope of the ID
mechanisms to be considered, and thus the should make clear the use cases
to be handled.

Traditional XML IDs are effectively scoped to the document:  ID's must be
unique to the document, and IDREFs or fragment identifiers "targeting" such
an ID are basically used to pick out markup within the document.  The
situation in XML Schema is somewhat complicated by the fact that Schema
validation can in principle be attempted on any particular element
information item [3], but schema does its best to reproduce the document
scoping of XML [4].  In the common case where the root of the schema
assessment is the root element of a document, the xsd:ID type has
uniqueness constraints and reference scope similar to those of XML id.

By contrast, and I think this is the source of some confusion, SOAP IDs [5]
are not scoped to a whole document, at least not quite in the sense above.
SOAP IDs are an aspect of and scoped to the SOAP encoding, which must be
"activated" by use of an "encodingStyle"  attribute.  Thus in the following
document, only some of the ids and hrefs can be used (comments in the
document show which are OK).

<soap:Envelope>

  <!-- NOT OK:  no IDs on Envelope Markup -->
  <soap:Header enc:id="E">
  </soap:Header>

  <soap:Body>
   <myelement1
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
     <!-- OK, in the scope of encoding style-->
     <a enc:id="A"/>
     <!-- OK -->
     <q enc:href="A"/>
   </ymelement1>

   <myelement2>
     <!-- NOT OK: not in scope of SOAP encoding -->
     <x enc:id="x"/>
   </myelement2>

   <myelement3
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
     <!-- OK -->
     <b enc:id="B"/>
   <myelement3 >

   <myelement4 >
     <!-- NOT OK: not in scope of SOAP encoding -->
     <r enc:href="A"/>
   </myelement3 >

  </soap:Body>

</Soap:Envelope>

For the record, such tangled activation and deactivation of encoding would
be very unlikely in practice,  Most users open the encoding scope once and
do all their work within that.  Still, the key point is that the whole
purpose of SOAP ids is different from XML and Schema IDs, or at best it's a
constrained use of the concept.  The purpose of SOAP IDs is to mark up a
particular type of graph encoding, and the SOAP syntax says that such graph
nodes may be defined only by markup within the scope of a suitable encoding
style.  To see why this is important, consider a situation in which someone
someday invents a second encoding style, perhaps for a slightly different
sort of graph, and both are used in the same document:

<soap:Envelope>

  <soap:Header >
   <myheader soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
     <!-- OK -->
     <a enc:id="A"/>
     <!-- OK -->
     <q enc:href="A"/>
   </myheader>
  </soap:Header>

  <soap:Body>
   <myelement2 soap:encodingStyle="http://www.w3.org/2006/01/NEWENCODING2">
     <!-- OK -->
     <a enc2:id="A"/>
     <!-- OK -->
     <q enc2:href="A"/>
   </myelement2>
  </soap:Body>

</Soap:Envelope>

Here we have two completely disjoint graphs, one in myheader encoded with
today's encoding, another in the body encoded with the new encoding.  The
specification for NEWENCODING2 has the freedom to define it's own reference
markup (enc2:id, enc2:href) and to decide that it represents an ID scope
disjoint from the one defined by the current soap encoding.  Thus, the fact
that the body uses another id="a" might not be a conflict.  This is in fact
very handy if SOAP messages are to be composed modularly;  it would be a
nuisance to have to rewrite all the IDs in the body just to avoid conflict
with the header.

Thus, SOAP IDs are really solving a different (though related) problem from
XML IDs, which is why in my opinion the XMLP group adopted its own
attributes.  I think it would be helpful if your requirements document
acknowledged these sorts of use cases and made clear whether they are in or
out of scope for your work.  My suggestion would be:  you should focus
mainly on document scope and traditional uses of XML ID;  you should
consider use cases like SOAP at least enough to convince yourself that
separate mechanisms are indeed the right way to solve SOAP's problem.  If
so, say so and keep working on the document level problem.  If you decide
that a unifying mechanism is appropriate for all such use cases, then I
think you have to take on the whole problem.  In case, I think you should
set a requirement or goal to clearly outline in any final recommendation or
finding the intended range of uses for any mechanisms you might propose.

Thank you as always for the opportunity to comment.  I am taking the
liberty of cross posting to both the schema and distApp mailing lists, but
I suggest that further responses be sent only to public-xml-id to avoid a
cross-posting-mess.

Noah

[1] http://www.w3.org/TR/2003/WD-xml-id-req-20030806/
[2] http://www.w3.org/TR/REC-xml#id
[3] http://www.w3.org/TR/xmlschema-1/#validation_outcome
[4] http://www.w3.org/TR/xmlschema-1/#cvc-id
[5] http://www.w3.org/TR/soap12-part2/#encodingedgesandnodes

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

Received on Thursday, 14 August 2003 11:28:13 UTC