Re: IDREF vs HREF for graph edges in SOAP encoding

 Gudge,
 I may be mistaken, but I always thought that even with no schema
or DTD an application can choose to treat attributes as IDREFs
and IDs, and that SOAP Encoding can mandate that implementations
so choose.
 Therefore the knowledge that the attributes are of types IDREF 
and ID would be built into the software.
 Actually, adding IDREFs would not add the issue we're discussing
here since SOAP (at least since 1.1) uses ID already and having
IDREFs and IDs should not necessitate DTD or Schema processing
any more than having IDs alone.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 16 Jan 2002, Martin Gudgin wrote:

 > 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 09:43:54 UTC