RE: SOAP MIME Type

My inclination is that I personally would like to see XMLP do more legwork
to produce a proposal to satisfy XMLP's requirements.  I think XMLP's
solution will be generalizable to XML .  I personally also favour a system
whereby vocabulary authors have a lower barrier to entry for exchanging
vocabularies.

A reasonable position would be that this should be brought to the TAG now.
I see two significant downsides.  The first is simply scheduling.  The TAG
appears to be overloaded right now.  The second is that I personally prefer
architecture groups to do actual spec work typically only in the cases of
where there aren't other contributers that are qualified and willing.  I
think we have both qualified and willing contributors in XMLP so I'd like to
see some more work progress.

I do think that our solution will have a favorable response from the TAG,
but I think that I'd like to have that discussion after more pen to paper.
I'm worried about potential conflicts with other groups - whom you can
imagine - if there isn't something more concrete.  There is a chance that
the TAG might be somewhat unfavorable given that there is clear guidance
about performing media type registration.  The registration process came up
again in today's call and a number of TAG members were sympathetic to the
difficulties of the process, while one member thought the process was
acceptable and simple.  My humble reading of the tea leaves is that a
majority would like a simpler approach for xml vocabulary authors to
exchange self-describing representations.

Just my $.02 worth, and I haven't talked about this with other TAG members.

Cheers,
Dave
> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Monday, May 12, 2003 6:36 PM
> To: Burdett, David
> Cc: 'Don Box'; 'Mark Baker'; David Orchard; 'John Kemp'; 'Mark
> Nottingham'; 'Xml-Dist-App@W3. Org'
> Subject: RE: SOAP MIME Type
>
>
>
> I'm wondering whether this is the point where this discussion
> should move
> to another thread?  David O., any sense of where the TAG
> would like to see
> this play out?  Thanks.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> "Burdett, David" <david.burdett@commerceone.com>
> 05/12/2003 09:12 PM
>
>
>         To:     "'noah_mendelsohn@us.ibm.com'"
> <noah_mendelsohn@us.ibm.com>, David Orchard
> <dorchard@bea.com>
>         cc:     "'Don Box'" <dbox@microsoft.com>, "'Mark
> Baker'" <distobj@acm.org>, "'John
> Kemp'" <john.kemp@earthlink.net>, "'Mark Nottingham'"
> <mark.nottingham@bea.com>, "'Xml-Dist-App@W3. Org'"
> <xml-dist-app@w3.org>
>         Subject:        RE: SOAP MIME Type
>
>
> Noah said ...
>
> >>>I think it might be useful to step back and gather some
> requirements
> and
> use cases before inventing new mechanisms<<<
>
> Here's a couple of use cases that come from other groups:
>
> MESSAGE CONTENT DEPENDS ON CONTEXT
> This comes from UBL [1]. The basic ideas is that 80-90% (or
> more) of the
> data in business documents is always the same, e.g. an order,
> has buyer
> information, seller information, line items, etc. However
> there is 10-20%
> of
> the data that is different depending on the "context". Examples of
> "context"
> include:
> * Including VAT information for invoices in europe -
> geography depdendent
> info
> * Including shoe size when ordering shoes -  industry dependent info
> ... plus another six different types of "context".
>
> The point is that you can "mix and match" these contexts, YET, in the
> instance you need to know which contexts have been applied
> for validation
> purposes. The question is how do you communicate the
> information, in the
> URI
> ... perhaps.
>
> ABSTRACT MESSAGES
> This comes from WS-CHOR [2]. The basic idea is that when you are
> specifying
> a choreography, the messages identify the "type" of data they
> contain,
> e.g.
> an order, but not the exact structure as it can vary (see
> previous point).
>
> ABSTRACT SERVICE DEFINITIONS
> This has not (I think been discussed), but the idea is that
> you want to be
> able to define servics that can accept different versions of the same
> content, e.g. different versions of order. Again the service
> would not be
> tied to a single input format.
>
> Hope this helps.
>
> David
>
>
>
> [1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
> [2]
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Mar/0245.html
>
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Monday, May 12, 2003 10:35 AM
> To: David Orchard
> Cc: 'Don Box'; 'Mark Baker'; 'John Kemp'; 'Mark Nottingham';
> 'Xml-Dist-App@W3. Org'
> Subject: RE: SOAP MIME Type
>
>
>
> Not wanting to overcomplicate this, but I have felt for some
> time that the
>
> current MIME type system is way too limited to do what we may
> be about to
> ask of it.  For example, consider a purchase order in a SOAP
> envelope.
> Before we get to assigning it a type, let's ask what is it?
> Well, in
> some fundamental sense, it's a purchase order.  Note that you
> can't find
> that out from the root QName.  Of course, it's equally
> fundamentally a
> SOAP message. And it's an XML document.  And it's, by the
> way, a UTF 8 or
> UTF-16 encoding of Unicode.  If it has a routing header it's also  a
> "routable message".
>
> I honestly view the natural semantics of these things as more
> of a "mixin"
>
> sort of model.  It seems to me that we keep trying to take
> little slices
> through this mixin space, and then we always find out we need
> something
> else.  I have no constructive suggestions for exactly what to do,
> organizationally or technically, except that I think it might
> be useful to
>
> step back and gather some requirements and use cases before
> inventing new
> mechanisms.
>
> I don't want to cross-post, but David you are welcome to
> relay this or
> point it out to the TAG if useful.  Both lists are public.  Thanks.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> "David Orchard" <dorchard@bea.com>
> Sent by: xml-dist-app-request@w3.org
> 05/10/2003 02:08 PM
>
>
>         To:     "'Mark Nottingham'"
> <mark.nottingham@bea.com>, "'Don Box'"
>
> <dbox@microsoft.com>, "'John Kemp'" <john.kemp@earthlink.net>
>         cc:     "'Mark Baker'" <distobj@acm.org>,
> "'Xml-Dist-App@W3. Org'"
>
> <xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        RE: SOAP MIME Type
>
>
>
> Yeah, that darned TAG ought to solve some of these issues. :-)
>
> <snip/>
> > That having been said, there's no regular way to turn a QName
> > into a URI
> > [1], which I think is what Don wants to do. So, in the
> > meantime, we could
> > do something like
> >  XML-Dialect: "http://example.com/foo.xsd"; localname="Bar"
> > making the localname parameter optional, so that we can drop
> > it once the
> > QName mapping issue is solved to everyone's satisfaction.
> >
> > This also has bearing on TAG issue 9 [2], and should be
> > considered in that
> > context.
> >
> > 1. http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6
> > 2. http://www.w3.org/2001/tag/ilist#uriMediaType-9
>
> Cheers,
> Dave
>
>
>
>
>
>

Received on Tuesday, 13 May 2003 01:41:36 UTC