Re: IDREF vs HREF for graph edges in SOAP encoding

Martin Gudgin wrote:

> I'm not sure I understand the entry under IDREF in row 6 of the table.
> Surely with IDREF there are no external links? Or are you refering to the
> proposed extra level of indirection in row 7?
> 

Correct, with IDREF there would be no external links as graph edges, but 
external links could still be carried as values as shown in row 7 for 
SwA support.

Cheers,
Marc.


> Gudge
> 
> ----- Original Message -----
> From: "Marc Hadley" <marc.hadley@sun.com>
> To: "XML dist app" <xml-dist-app@w3c.org>
> Sent: Thursday, January 10, 2002 2:28 PM
> Subject: IDREF vs HREF for graph edges in SOAP encoding
> 
> 
> 
>>All,
>>
>>On last nights telcon, Jacek and I took an action to start discussion on
>>the list about the merits of using IDREFs instead of generic HREFs for
>>representing graph edges in the SOAP encoding.
>>
>>Attached is a table and commentary in HTML format listing a number of
>>problems and issues concerned with the use of links as graph edges.
>>Possible solutions are also shown for the two cases: graph edges as
>>IDREFs or generic hrefs.
>>
>>Note that switching to IDREFs for graph edges does not preclude use of
>>arbitrary links in encoded data. The switch only affects the kind of
>>links used for encoded graph edges.
>>
>>Comments, flames, etc ?
>>
>>Marc and Jacek.
>>
>>--
>>Marc Hadley <marc.hadley@sun.com>
>>XML Technology Centre, Sun Microsystems.
>>
>>Jacek Kopecky <jacek@systinet.com>
>>Senior Architect, Systinet (formerly Idoox)
>>
>>
>>
>>
>>
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> 
>>Problems of hrefs vs. IDREFsProblems of hrefs vs. IDREFs
>>     Problem Description Solution
>>
>>      IDREF HREF
>>      1 Type of Node.  Currently the type of a node is specified using
>>
> xsi:type either explicitly or via a schema. This may not be the case for the
> targets of external links. No change required. Remove the requirement that
> all values are typed, possibly adding other means of deriving the xsi:type,
> e.g. from the resources MIME type.
> 
>>      2 Dereferencing When, or if, to attempt to dereference links. All
>>
> graph edges are internal to the envelope. Therefore deserialisation
> MUST/SHOULD dereference all links, any failure MUST generate a fault. Some
> graph edges may be external to the envelope. Deserialisation layer
> MUST/SHOULD dereference internal links, MAY dereference external links and
> MAY/SHOULD/MUST fault when an link is not dereferenceable. Should the
> faulting semantics be different for internal and external graph edges ?
> 
>>      3 Representation of external data in programming languages Internal
>>
> data with xsi:type is mapped naturally into programming language types, how
> about external data? Not applicable. The implementation represents binary
> data in byte arrays or streams, XML data is represented as usual.
> 
>>      4 Serialising internal vs external links. During serialisation, the
>>
> SOAP processor has to decide what to include as internal content and what is
> left as an external resource. Not applicable. Either the SOAP processor has
> to be told or has to have some ad-hoc rules.
> 
>>      5 Distinction between internal and external links The SOAP processor
>>
> has to be able to work out which links are internal and which are external.
> Not applicable. SOAP processor has to implement logic based on the URI
> schemes supported.
> 
>>      6 Full implementation of external link support in core. If external
>>
> links are permitted in the encoding then every generic SOAP processor must
> be able to handle them. Not applicable, any external links are just node
> values. External link support required.
> 
>>      7 Support for SOAP with attachments Currently the SOAP with
>>
> attachments specification uses the href attribute to refer to attachments
> from within the envelope. A new higher level construct is required, e.g. :
> 
>>      <parameter xsi:type="soapatt:att">
>>          cid:....
>>      </parameter>
>>
>>      i.e. SOAP with attachments support is layered on top of the core
>>
> encoding.
> 
>>     No change required
>>
>>Remarks
>>Only the problem no. 2 requires some added language in case we should
>>
> choose IDREFs and that language is IMHO crisper and less vague (prone to
> misinterpretation) than the current text for the href case.
> 
>>So actually going with hrefs requires us to specify a lot (solving
>>
> problems 1, 2, 3, 4, 5) and results in more complicated implementation,
> while going with IDREFs requires us to change/specify a relatively little
> (2, 7) and the implementation is simplified. By the way, we consider the
> change to attachments a cleanup change.
> 
>>
> 



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

Received on Wednesday, 16 January 2002 10:40:07 UTC