- From: Burdett, David <david.burdett@commerceone.com>
- Date: Mon, 12 May 2003 18:12:54 -0700
- 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>
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 Monday, 12 May 2003 21:12:58 UTC