Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Edwin Ortega" <ortegae@wns.net>
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>; "Christopher Ferris"
<chris.ferris@sun.com>
Cc: "Martin Gudgin" <marting@develop.com>; "Marc Hadley"
<marc.hadley@sun.com>; "XML dist app" <xml-dist-app@w3c.org>
Sent: Wednesday, January 16, 2002 1:27 PM
Subject: Re: IDREF vs HREF for graph edges in SOAP encoding


>
> ----- Original Message -----
> From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
> To: "Christopher Ferris" <chris.ferris@sun.com>
> Cc: "Martin Gudgin" <marting@develop.com>; "Marc Hadley"
> <marc.hadley@sun.com>; "XML dist app" <xml-dist-app@w3c.org>
> Sent: Wednesday, January 16, 2002 7:09 AM
> Subject: Re: IDREF vs HREF for graph edges in SOAP encoding
>
>
> > .. only insofar as basic types are concerned, as far as I understand.
> >
> > Jean-Jacques.
> >
> >
> > Christopher Ferris wrote:
> >
> > > Only if one wanted to leverage the internal subset,
> > > other than that, you could treat them in the same
> > > manner as href and id. It would certainly be much
> > > more convenient for implementations that did choose
> > > to leverage DTD processing. Given that we're talking
> > > about encoding, which leverages XML Schema types, it
> > > is pretty clear to me that we're also imposing schema
> > > processing anyway, no?
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > 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 14:07:32 UTC