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 10:13:09 UTC