Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Martin Gudgin" <marting@develop.com>
To: "Jacek Kopecky" <jacek@systinet.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 6:57 AM
Subject: 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 12:41:28 UTC