Mark Baker | 9 Jan 2002 22:55
Picon
Favicon
Gravatar

Re: Media types


[I should have CCd ietf-xml-mime on the initial post, but it didn't
occur to me.  Anyhow, that post can be found here;
http://lists.w3.org/Archives/Public/www-tag/2002Jan/0063.html ]

Speaking for myself now,

> Q. 3; What is, or what should be, the relationship between a media type
> and an XML namespace?

One of the thoughts that I had quite a while ago (that I believe came
from something I saw from Dan Connolly), was of being able to migrate
from media types to namespaces by exposing the namespace through an
optional namespace parameter on a generic XML media type, for example
XHTML could be described with;

  application/xml; xmlns="http://www.w3.org/1999/xhtml"

instead of with the custom type, application/xhtml+xml.

I raised this with the authors of RFC 3023 long ago, but they rejected
it.  But I believe it remains worth considering.  It seems to me to be
a nice bridge, similar to the one the XMLP WG has taken with
"relocating" SOAPAction to a parameter on the proposed SOAP media
type[1].

 [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0029.html

MB
--

-- 
(Continue reading)

Graham Klyne | 9 Jan 2002 23:32

Re: Media types


At 04:55 PM 1/9/02 -0500, Mark Baker wrote:
>I raised this with the authors of RFC 3023 long ago, but they rejected
>it.  But I believe it remains worth considering.  It seems to me to be
>a nice bridge, similar to the one the XMLP WG has taken with
>"relocating" SOAPAction to a parameter on the proposed SOAP media
>type[1].

I think I understand why it was rejected in the discussions for RFC 3023, 
and I think those reasons were valid in that context.  But I don't think 
that means the idea is completely without merit.  I think there is some 
concern about how well Content-type parameters are handled by deployed MIME 
applications, but that seems less of an issue for newer Web applications.

I remain agnostic.

#g
--

-------------------
Graham Klyne
<GK <at> NineByNine.org>

Mark Baker | 10 Jan 2002 19:03
Picon
Favicon
Gravatar

Re: Media types


Hi Dave,

> Mark,
> 
> The same concerns I raised in xmlp apply here.  The slippery slope of
> manifests appears.  What about other namespaces and vocabularies?  For
> example, SOAP with my foo vocabulary using xml schema data types would be:
>  application/xml; xmlns="soapns" xmlns="foons" xmlns="datatypesns"
> 
> or perhaps
>  application/xml; xmlns="soapns foons datatypens"
> 
> This would have to duplicata all the xmlns decls in the document.
> 
> Does this make sense?

I understood the slippery slope argument around the "+xml" convention
because the syntax didn't (and couldn't) preclude other "+" things.
But "xmlns" would be restricted to a single URI value identifying
the root namespace.

Note that I'm not really sold on this myself, it just looks pretty. 8-)
An issue with it is that every tool I'm familiar with that enables an
app to be bound to a media type, doesn't permit me to bind different
apps to different parameter values of the same type.  So for example;

  application/xml; xmlns="http://www.w3.org/1999/xhtml"

and
(Continue reading)

Mike Dierken | 11 Jan 2002 18:26

FW: Media types


[...re-sending...]

> -----Original Message-----
> From: Mark Baker [mailto:distobj <at> acm.org] 
> 
[...]

> I agree that media types aren't suitable for multi-namespaced 
> documents.
> That's why I'm all for making the transition from media types to
> namespaces with either vanilla "application/xml", or adorned with the
> root namespace.

Does a namespace alone indicate the semantic meaning of an XML document? 
Is it 'enough' of a hint to do useful things?
Or do you need the name of the root element as well?

Would schema+rootElement be a better alternative?
Would that sufficiently identify the 'model' of the message content?
Could XML documents without schema use namespace in place of schema
reference?

Is there a more general idea of 'content-model' that might apply to multiple
content-type representations?

Example:

Content-Type: application/xml
Content-Model: http://www.w3.org/2001/12/soap-envelope#Envelope
(Continue reading)

Mark Baker | 16 Jan 2002 23:38
Picon
Favicon
Gravatar

I-D ACTION:draft-baker-soap-media-reg-00.txt (fwd)


FYI

Forwarded message:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: The 'application/soap+xml' media type
> 	Author(s)	: M. Baker, M. Nottingham
> 	Filename	: draft-baker-soap-media-reg-00.txt
> 	Pages		: 
> 	Date		: 15-Jan-02
> 	
> This document defines the 'application/soap+xml' media type which can
> be used to describe SOAP 1.2 messages serialized as XML.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt

MB
--

-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker <at> planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Simon St.Laurent | 17 Jan 2002 22:05
Favicon

Re: Media types


Sorry to come to this discussion late. (Those reading this on
ietf-xml-mime may want to visit
http://lists.w3.org/Archives/Public/www-tag/2002Jan/index.html and read
the Media Types thread.)

On Thu, 2002-01-17 at 13:41, Mark Baker wrote:
> >[Tim Bray]
> > Hm... you're creeping in the direction of deprecating media type
> > MIME headers in the case where the resource body is XML.
> 
> Not deprecating, just creating a parallel alternative.  But if it's
> done well, it could become a 90+% solution.
> 
> >  To start
> > with, should such a discussion happen at least partly over in the
> > IETF?
> 
> For sure.  This won't happen without the IETF.

It would be difficult for such a thing to happen without the IETF, but 
making changes to MIME of any fundamental sort is intensely difficult. 
Despite the work I put into RFC 3023, and the very rough consensus we
managed to achieve there, I think XML is demonstrating the limitations
of MIME on a regular basis.

I wrote briefly about this last year
(http://www.xml.com/pub/a/2000/06/21/disruption/index.html), but suspect
that it may be time to move past two-part MIME Content-Type identifiers
entirely, and start moving toward identification approaches which are
(Continue reading)

Mark Baker | 17 Jan 2002 22:11
Picon
Favicon
Gravatar

Re: Media types


Simon,

> It would be difficult for such a thing to happen without the IETF, but 
> making changes to MIME of any fundamental sort is intensely difficult. 
> Despite the work I put into RFC 3023, and the very rough consensus we
> managed to achieve there, I think XML is demonstrating the limitations
> of MIME on a regular basis.

Definitely.  Though what I'm proposing should ruffle the feathers of any
media type folk, I wouldn't think.  I'm not proposing anything like
"+xml", just a (possibly) new media type for XML that would be used to
describe content which follows certain rules about how it expects to be
handed to processors bound to namespaces.

> Mark earlier proposed:
>  application/xml; xmlns="http://www.w3.org/1999/xhtml"

I like to think that I "tossed it out for discussion".  I have
reservations about it myself[1].

> XLink is a great case of that, as most implementations I've encountered
> focus only on simple linking, and leave off the more complex stuff for
> now.  XSLT provides a lot of interesting and difficult cases as well.
> RDDL (http://rddl.org) may be an important ingredient in the mix.

Yes, I haven't given these the attention they deserve yet.  Perhaps I'll
just write down what I'm thinking (an I-D is under way) and let others 
add to it.

(Continue reading)

Keith Moore | 17 Jan 2002 23:36
Picon

Re: Media types


> It would be difficult for such a thing to happen without the IETF, but
> making changes to MIME of any fundamental sort is intensely difficult.
> Despite the work I put into RFC 3023, and the very rough consensus we
> managed to achieve there, I think XML is demonstrating the limitations
> of MIME on a regular basis.

that's a pretty bizarre statement.  perhaps it's truer to say that XML 
is trying to misuse MIME on a regular basis?

or that expecting the MIME content-type to convey the action that 
should be performed by a recipient, rather than a description of 
the content, is a bit of a mis-application of MIME?

the fact that XML picked a means of labelling content that is
incompatible with MIME's content-type is hardly MIME's fault.

Keith

Simon St.Laurent | 18 Jan 2002 00:49
Favicon

Re: Media types


On Thu, 2002-01-17 at 17:36, Keith Moore wrote:
> > It would be difficult for such a thing to happen without the IETF, but
> > making changes to MIME of any fundamental sort is intensely difficult.
> > Despite the work I put into RFC 3023, and the very rough consensus we
> > managed to achieve there, I think XML is demonstrating the limitations
> > of MIME on a regular basis.
> 
> that's a pretty bizarre statement.  perhaps it's truer to say that XML 
> is trying to misuse MIME on a regular basis?
> 
> or that expecting the MIME content-type to convey the action that 
> should be performed by a recipient, rather than a description of 
> the content, is a bit of a mis-application of MIME?
> 
> the fact that XML picked a means of labelling content that is
> incompatible with MIME's content-type is hardly MIME's fault.

It's not MIME's fault that it was designed in an era when no one
expected the possibility of creating such labelled content.  However,
such content is useful, and MIME's inability to handle such things
definitely feels like a limitation from the perspective of people who
like such things.

Kind of like, say, 7-bit ASCII feels to people trying to use Unicode's
upper reaches.  

At what point does it make sense to move beyond MIME?

And is there a way to signal such "moving beyond" so that MIME
(Continue reading)

Simon St.Laurent | 18 Jan 2002 00:50
Favicon

Re: Media types


On Thu, 2002-01-17 at 17:36, Keith Moore wrote:
> or that expecting the MIME content-type to convey the action that 
> should be performed by a recipient, rather than a description of 
> the content, is a bit of a mis-application of MIME?

Oops.  Forgot this bit.  Listing namespaces in a document is just
describing the content.  Action on such namespaces is up to the
recipient.

--

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com


Gmane