Re: IDREF vs HREF for graph edges in SOAP encoding

OK, so we're talking about attributes with fixed local names. And we're
ruling out direct references to anything outside
<soap:Envelope>...</soap:Envelope>

So the real change is from a referent type of anyURI to a referent type of
IDREF

Gudge

----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: "Marc Hadley" <marc.hadley@sun.com>; "XML dist app"
<xml-dist-app@w3c.org>; <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 2:43 PM
Subject: 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:58:50 UTC