Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Marc Hadley" <marc.hadley@sun.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>; <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 7:10 AM
Subject: Re: IDREF vs HREF for graph edges in SOAP encoding


> Martin Gudgin wrote:
>
> > 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
> >
>
> Yes, with the clarification that the restriction on "direct references"
> would only apply to graph edges within the encoding. Element content
> could still be of type anyURI and refer to anything.
>
> Marc.
>
>
> >
> >>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.
> >> > >
> >> > >
> >> >
> >>
> >
>
>
>
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Centre, Sun Microsystems.
>
>
>

Received on Wednesday, 16 January 2002 12:41:29 UTC