Re: RSVP: Resolution to issue #29 satisfactory?

Already done...

IBM Silicon Valley Laboratory
Internet Address: bprice@us.ibm.com
Phone: (408)463-4289


Dan Brickley <danbri@w3.org> on 10/30/2001 12:54:40 PM

To:   Barbara Price/Santa Teresa/IBM@IBMUS
cc:   Jacek Kopecky <jacek@systinet.com>, David Fallside/Santa
      Teresa/IBM@IBMUS, <www-archive@w3.org>, <em@w3.org>, Stephen
      Brodsky/Santa Teresa/IBM@IBMUS
Subject:  Re: RSVP: Resolution to issue #29 satisfactory?




Glad we agree. Getting the SOAP object model formalised looks to be
something of a priority.

I've just forwarded my response to xml-dist-app. Could you copy a reply to
this msg over there too, so we surface our offlist discussions to the
WG...?

Dan

On Tue, 30 Oct 2001, Barbara Price wrote:

>
> I agree with Dan - using a pluggable encoding for MOF/UML models is a
> minimal solution that should work, but the preferred solution is to
provide
> a mapping from MOF/UML into the SOAP object model.  We have already done
> something like this between MOF/UML and XML Schema, and believe it should
> be possible here too.  I will open an issue in the OMG XMI Task Force for
> this, and stay involved on the w3c side.
>
>              Barbara
>
> IBM Silicon Valley Laboratory
> Internet Address: bprice@us.ibm.com
> Phone: (408)463-4289
>
>
> Dan Brickley <danbri@w3.org> on 10/30/2001 12:27:49 PM
>
> To:   Jacek Kopecky <jacek@systinet.com>
> cc:   Barbara Price/Santa Teresa/IBM@IBMUS, David Fallside/Santa
>       Teresa/IBM@IBMUS, <www-archive@w3.org>, <em@w3.org>
> Subject:  Re: RSVP: Resolution to issue #29 satisfactory?
>
>
>
> (+cc: public www-archive, ericm)
>
> Hi Jacek,
>
> thanks for this. I've been trying to compose a response. As things stand
I
> can't represent anyones views other than my own, ie. I can't speak for
the
> RDF groups. I'll get a reply out asap. Also I'll send heads-up to SemWeb
> CG and RDF Core WG.
>
> Short preview: I agree that pluggable encodings allows RDF etc to be
> serialized. But there is a large cost associated with using alternate
> encodings, so we should invest some effort in mapping RDF into SOAP's
> object model. Maybe the resolution of the issue could be refined to ack
> that we don't encourage folks to diverge from using the default SOAP
> Encoding model/syntax.
>
> what's your view?
>
> dan
>
> On Tue, 30 Oct 2001, Jacek Kopecky wrote:
>
> > (this is a resend with a new deadline information)
> >
> >  Hello Barbara, Dan,
> >  we kindly request your opinion on whether the following proposed
> > resolution to our issue #29 [1] is satisfactory for RDF and UML -
> > the groups you seemed to represent in our debate "re: Exist
> > non-serialisable data models?". The proposal is copied from my
> > message [2].
> >
> >  The proposal:
> >  "SOAP specifies how to encode data from the object-graph data
> > model. SOAP also allows the encoding of other data models
> > representable in XML using custom encoding rules identified in
> > the encodingStyle attribute information item in a message.
> > Therefore no data models exist that are serializable to XML but
> > not serializable to SOAP."
> >
> >  Please note that the issue 29 is based on our requirement R402
> > [3], therefore we ask you whether you see any obstacles in SOAP
> > that would prevent you from serializing data in your models, RDF
> > and UML, as data inside SOAP messages.
> >
> >  The XMLP Working Group will discuss this issue on its telecon on
> > Wednesday Nov 7, so we'd like you to respond by close of business
> > on Monday, Nov 5. In the absence of any issues raised by you (or
> > by anyone, of course) we'll consider the resolution satisfactory.
> >
> >  Sincerely,
> >
> >                    Jacek Kopecky
> >
> >                    Senior Architect, Systinet (formerly Idoox)
> >                    http://www.systinet.com/
> >
> > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x29
> > [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0192.html
> > [3] http://www.w3.org/TR/xmlp-reqs/#z402
> >
> >
>
>
>
>

Received on Tuesday, 30 October 2001 16:49:21 UTC