Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: "'Christopher Ferris'" <chris.ferris@sun.com>
Cc: <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 10:24 AM
Subject: RE: IDREF vs HREF for graph edges in SOAP encoding


> Chris, Henrik,
>
> I think that whats important is the interpretation of the data and not the
> artifact (processor) that does the interpretation. As I understand it the
> SOAP Data Model and Encoding style was created with the intent of encoding
> programming language data structures and to be interpreted as such. Our
> spec. needs to say what a chunk of SOAP style encoded data means in the
> context of the SOAP Data Model (note - not what the resulting graph means
to
> the application but what graph value is encoded).
>
> The (little) fly in the ointment for me is whether there are different
Data
> Models/interpretations that we have ambition to share the same Encoding
> Rules. For, there was some work (from Henrik) to explore the use of the
SOAP
> encoding to encode an RDF Graph [1,2]. That would yield a different data
> model, different interpretation, but would/could generate an encoding that
> shared the same syntactic rules. It is *not* clear to me whether or not
such
> dual/multiple use of the encoding is a goal that the WG is subscribed to
or
> whether for example it is a requirement that the RDF Core WG would like us
> to address.
>
> If there is an ambition to make multiple use of this encoding we should be
> clear about that. The particular choice of IDREF/AnyURI values for
denoting
> graph edges *might* make a difference to what other uses our encoding may
be
> put to.... this may also be FUD on my part. I have not studied [1,2]
enough
> to know whether the choice of IDREFs for graph edges would preclude such
> re-use.
>
> Summary... if the sole purpose of the Data Model and Encoding is for
> encoding programming constructs exchanged in RPC invocations then we need
> not be concerned with its use for other purpose. If we have ambition that
> the encoding be able to be used to encode other graph like things as well,
> we might need to know a little more about those other possible uses before
> we can make this choice.
>
> Regards
>
> Stuart
> [1]
>
http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/SOAP-RDF_
> files/frame.htm
> [2]
>
http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/soaprdf.h
> tml
>
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > Sent: 16 January 2002 17:15
> > To: xml-dist-app@w3.org
> > Subject: Re: IDREF vs HREF for graph edges in SOAP encoding
> >
> >
> > Henrik,
> >
> > I'm trying to understand what you're suggesting here.
> >
> > Are you suggesting that the SOAP spec(s) don't define
> > an entity equivalent to the "SOAP (de|en)coding processor"
> > and hence we have nothing to say about it? Or, are you
> > suggesting that in your view, the (de|en)coding function
> > is exclusively an "application" function and hence we have
> > nothing to say about it?
> >
> > While it might be reasonable to state that there *might not be*
> > a separate entity that performs (de|en)coding of application
> > data, I don't believe that we should therefore preclude the
> > opposite (that there *might be* a separate function, independent
> > of the application context).
> >
> > I think that while it is likely that many do have in their
> > mind an implementation design that incorporates a separate
> > function that performs (de|en)coding of application data,
> > that that is a perfectly reasonable way to view the problem
> > so long as it doesn't necessarily preclude alternate
> > solutions that do not share a similar design center.
> >
> > What you seem to be suggesting here is that there cannot/must not
> > be a separate (de|en)coding process that is independent of
> > the application. I'm not so sure that many would agree with
> > this position.
> >
> > Cheers,
> >
> > Chris
> >
> > Henrik Frystyk Nielsen wrote:
> >
> > > It seems that the fundamental reason for the request of
> > changing from
> > > the current situation is the assumption that that there is a special
> > > SOAP encoding/decoding processor that does things
> > independently of the
> > > application data whose data it encodes/decodes. That is,
> > for decoding in
> > > particular, the SOAP encoding processor decodes the data
> > and passes it
> > > to the application in some internal representation.
> > >
> > > I disagree this is the case - we have exactly one processor
> > which is the
> > > SOAP envelope processor. There is in my opinion no such
> > thing as a SOAP
> > > encoding/decoding processor. The transport task force went through
> > > considerable discussion on a related issue of whether the protocol
> > > binding provides a processor or not and came to the
> > conclusion that it
> > > does not. I don't think the situation is any different for
> > the encoding.
> > >
> > > One of the arguments seems to be that it makes things
> > simpler for this
> > > "SOAP encoding processor" to deal with an instance if it
> > doesn't have to
> > > make the choice of whether to dereference a URI reference or not.
> > >
> > > IMO this is a clear example of implementation choices
> > creeping into our
> > > considerations. Whether a URI reference is dereferenced or not
> > > regardless of the type of the reference is a choice of the
> > application
> > > and not of SOAP. The application should make that
> > determination based on
> > > the semantics of the data of which, by definition, SOAP is unaware.
> > >
> > >
> > >>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.
> > >>
> > >
> > > Henrik
> > >
> > >
> >
> >
>
>

Received on Wednesday, 16 January 2002 14:40:09 UTC