RE: SOAP MIME Type

Here's my $0.02c on some of the issues ...

WHERE MIME TYPES WORK WELL
MIME Types are useful when they provide all the information you need to know
in order to determine what to *initially* do with the data, i.e. if there is
any additional information required in order to proccess the data, then it
is contained in the data, usually at the start.

WHERE MIME TYPES DON'T WORK WELL
MIME types don't work well when additional information is required that is
not contained in the data. For example schema definitions for XML, or,
context rules applied to a document instance (as in the example I gave
below). It is generally accepted that URIs are good ways of identifying the
additional metadata but then it requires a number of problems to be solved,
for example ...

THE SEMANTICS OF THE URI
You need to know what the URI means, i.e. does it identify a namespace,
context rules, message definition, etc. Firstly, the URI will always (?) be
defined as part of some schema, for example, the namespace in a schema
definition has a specific meaning. Similarly, the designer of a business
document could specify that a particular URI contains the context rules
applied to the creation of that document. As any schema definition should
contain clear definitions of the semantics of each element/attribute, then
the designer of the schema has the responsibility to explain its meaning. 

RETRIEVING THE DEFINITION
Sometimes there will be metadata associated with a URI, e.g. a schema
definition associated with a namespace that is needed in order to interpret
the data. This presents the problem of how to resolve URI to the associated
definition. One way (which I don't like) is to encode the definition in the
URI, this is possible, but only works if there is limited amounts of
information. The better way is to retrieve the definition from some
location, e.g over the net or from a local cache. However, unless the URI is
specified as HTTP, there is no obvious way of resolving the URI in the
general case.

Since, I guess, there will be many different types of standard definitions
that will need to be retrieved, providing a standard way of doing this
retrieval is, I think, a good idea. Using UDDI though is, IMO, overkill.

Any thoughts?

David


-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Monday, May 12, 2003 10:43 PM
To: noah_mendelsohn@us.ibm.com; 'Burdett, David'
Cc: 'Don Box'; 'Mark Baker'; 'John Kemp'; 'Mark Nottingham';
'Xml-Dist-App@W3. Org'
Subject: 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 12:41:47 UTC