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 10:10:44 UTC