Re: IDREF vs HREF for graph edges in SOAP encoding

I may be missing some context for this discussion but...

Wouldn't using IDREFs *REQUIRE* DTD or Schema processing of SOAP messages?

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.
>
>

Received on Wednesday, 16 January 2002 08:56:31 UTC