W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

RE: Options for dealing with IDs

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Fri, 31 Jan 2003 12:48:56 -0800
Message-ID: <92456F6B84D1324C943905BEEAE0278E02F44417@RED-MSG-10.redmond.corp.microsoft.com>
To: <noah_mendelsohn@us.ibm.com>, "Chris Lilley" <chris@w3.org>
Cc: "Norman Walsh" <Norman.Walsh@sun.com>, <www-tag@w3.org>

WRT is soap:ID a real ID, I think I agree with Noah. The thing which
really indicates that soap:id is not a pukka xsd:ID is the text in [1]:

"The value of a ref attribute information item MUST also be the value of
exactly one id attribute information item."

Which states that when resolving a soap:ref attribute one ONLY looks for
soap:id attributes. Other attributes of type xsd:ID are NOT considered.
It also states that soap:id attributes only need to be unique within the
set of soap:id attributes, again other attributes of type xsd:ID are NOT
considered.

Hope this helps,

Gudge

[1] http://www.w3.org/TR/soap12-part2/#uniqueidconstraints


> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: 31 January 2003 02:30
> To: Chris Lilley
> Cc: Norman Walsh; www-tag@w3.org; Martin Gudgin
> Subject: Re: Options for dealing with IDs
> 
> 
> Long ago and far away, in a note much earlier in this thread, 
> Chris Lilley 
> wrote:
> 
> > NW> Hmm. I don't think I'd seriously considered the possibility that
> other
> > NW> specs would solve the problem by saying "in FooML, all 
> attributes 
> > NW> named 'id' are of type ID by definition and must appear in the
> infoset
> > NW> with that [attribute type]". But maybe they would.
> > 
> > I cite exhibit A, the SOAP specification, as an existence proof.
> 
> Actually, speaking for myself and not the XMLP WG:  I think 
> the error if 
> any is in SOAP encoding claiming that soapEnc:ID is of type 
> xsd:ID.  I 
> think what's intended in SOAP encoding is that the soapEnc:IDs and 
> soapEnc:IDREFs be much more like key and keyref.   Why? Becuase the 
> encoding is really just creating a graph that's embedded in the SOAP 
> envelope.  >The only elements that can be referenced are those which 
> themselves represent nodes in the encoded graph.<   So:
> 
>         <soap:Envelope soapEnc:id="X">
> 
>         </soap:Envelope>
> 
> is incoherent and is disallowed.   So is:
> 
>         <soap:Envelope>
>                 <soap:Header soapEnc:id="Y">
>                         ...
>                 </soap:header>
>         </soap:Envelope>
> 
> The envelope is not a meaningful graph node.  Neither is the 
> markup that 
> starts header sections:    Yet, if what you want is XPointers 
> into a SOAP 
> envelope, then you do want to be able to do something like:
> 
>         <soap:Envelope>
>                 <soap:Header xml:id="Y">
>                         ...
>                 </soap:header>
>         </soap:Envelope>
> 
> so you can make an XPointer to the header element labeled 
> with "Y".  As I 
> recall, there was not much careful consideration on the 
> assignment of the 
> type for soapEnc:id.  It seemed generally like an ID, and we 
> claimed it to 
> be, but this discussion suggests to me that we made a bit of 
> a mistake.
> 
> So, if you agree with this line of reasoning, soapEnc:id is not an 
> existence proof (or disproof) for the temptation to have 
> specifications 
> type ID attributesby fiat.  (Well, we were tempted, but I 
> claim now that 
> our reasoning was poor.)
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
Received on Friday, 31 January 2003 15:50:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT