Subject: Re: Internet-Draft: Media Feature - xmlns
From: MURATA Makoto <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 30 Jan 2002 13:38:38 +0900 (JST)
List-Id: <ietf-xml-mime.imc.org>

From: Ian Graham <[email-masked]>
Subject: Re: Internet-Draft: Media Feature - xmlns
Date: Thu, 24 Jan 2002 23:45:29 -0500 (EST)

> 
> 
> On 24 Jan 2002, Simon St.Laurent wrote:
> 
> > 
> > On Wed, 2002-01-23 at 22:14, Ian Graham wrote:
> > > My only suggestion, for what it's worth, would be to allow for the
> > > declaration (and please don't overinterpret that word ;-) ) of the 'root'
> > > namespace for a document.  That seems a reasonable distinction to make,
> > > although you'd then have to define how such a statement interacts with
> > > content-type declarations such as application/xml+mathml (would that, in
> > > some twisted way, imply a default 'root'-level namespace, and if so,
> > > how?).
> > 
> > Personally, I believe that the root namespace is not a definitive guide
> > to the contents of the document.  The XSLT case is prominent, but there
> ...
> 
> Well, in practice there is only one namespace distinction you can make --
> between the 'root' namespace and all others.  Specifying both classes thus
> provides, _all_ the namespace information you can provide in the absence
> of the complete document instance.  It seemed to me silly to avoid
> providing this information when it's so easy to (notationally) do so. 

I do not think that importance of a "root" namespace is that 
obvious.

Some people (including me) would like to allow an XML document to have
a sequence of "root" elements rather than a single root element.  Such
XML will be much more appropriate for log files.  I even heard that
one widely-used XML parser already has a hidden option to allow such
XML documents.  If such an extension becomes part of XML, a document
may have more than one top-level namespace.

Cheers,

Makoto

Date: Thu, 24 Jan 2002 23:51:27 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: Mark Baker <[email-masked]>
cc: "Simon St.Laurent" <[email-masked]>, Ian Graham <[email-masked]>, [email-masked]
Subject: Re: Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

On Thu, 24 Jan 2002, Mark Baker wrote:

> > Personally, I believe that the root namespace is not a definitive guide
> > to the contents of the document.
> 
> I agree.  It *can* be used as an indicator of the first processor to
> be handed the document (after the one dispatched from the media type),
> but it need not as we've seen.
> 
> FWIW, my new media type will require that content expects that it will
> be processed in this manner.  But */xml and */*+xml don't have any
> such requirement.

IN retrospect I realize that XML content-types really just define a 'most
important' namespace, in the sense that they reference the first layer of
'xml-aware' software that should handle the resource.

Following on this model, I find that Simon's draft makes more sense (to
me) if I think of it as defining the 'relative importance' of different
namespaces in the data, particularly when 'q' values are used to define
quality parameters.

Looking at it this way make the content-features header a more natural
extension on information provided by the  content-type.

So, in a sense, this takes the set of namespaces in a document (root + all
others)  and maps them into a different set that weights the different
namespaces in an application-specific manner....

Ian

Date: Thu, 24 Jan 2002 23:45:29 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Ian Graham <[email-masked]>, [email-masked]
Subject: Re: Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

On 24 Jan 2002, Simon St.Laurent wrote:

> 
> On Wed, 2002-01-23 at 22:14, Ian Graham wrote:
> > My only suggestion, for what it's worth, would be to allow for the
> > declaration (and please don't overinterpret that word ;-) ) of the 'root'
> > namespace for a document.  That seems a reasonable distinction to make,
> > although you'd then have to define how such a statement interacts with
> > content-type declarations such as application/xml+mathml (would that, in
> > some twisted way, imply a default 'root'-level namespace, and if so,
> > how?).
> 
> Personally, I believe that the root namespace is not a definitive guide
> to the contents of the document.  The XSLT case is prominent, but there
...

Well, in practice there is only one namespace distinction you can make --
between the 'root' namespace and all others.  Specifying both classes thus
provides, _all_ the namespace information you can provide in the absence
of the complete document instance.  It seemed to me silly to avoid
providing this information when it's so easy to (notationally) do so. 

Ian

Subject: Re: Internet-Draft: Media Feature - xmlns
To: [email-masked] (Simon St.Laurent)
Date: Thu, 24 Jan 2002 12:14:24 -0500 (EST)
Cc: [email-masked] (Ian Graham), [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> Personally, I believe that the root namespace is not a definitive guide
> to the contents of the document.

I agree.  It *can* be used as an indicator of the first processor to
be handed the document (after the one dispatched from the media type),
but it need not as we've seen.

FWIW, my new media type will require that content expects that it will
be processed in this manner.  But */xml and */*+xml don't have any
such requirement.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Subject: Re: Internet-Draft: Media Feature - xmlns
From: "Simon St.Laurent" <[email-masked]>
To: Ian Graham <[email-masked]>
Cc: [email-masked]
Date: 24 Jan 2002 12:04:38 -0500
Sender: [email-masked]

On Wed, 2002-01-23 at 22:14, Ian Graham wrote:
> My only suggestion, for what it's worth, would be to allow for the
> declaration (and please don't overinterpret that word ;-) ) of the 'root'
> namespace for a document.  That seems a reasonable distinction to make,
> although you'd then have to define how such a statement interacts with
> content-type declarations such as application/xml+mathml (would that, in
> some twisted way, imply a default 'root'-level namespace, and if so,
> how?).

Personally, I believe that the root namespace is not a definitive guide
to the contents of the document.  The XSLT case is prominent, but there
are other cases where the root namespace has a tenuous connection or no
connection to the content's processing.  Other mechanisms for
establishing the MIME Media Type seem to be more effective in these
cases, especially for the XSLT case.

On the other hand, I wouldn't heartily oppose a registration of
"rootxmlns" or somesuch.  I suspect it rates a separate registration
document, however, as the issues it raises are both more substantive
than (potential conflict with Media Type) and different from the issues
raised by a simple list of namespace URIs.

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

Subject: new release of Registration of xmlns Media Feature Tag
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked]
Date: 24 Jan 2002 11:53:52 -0500
Sender: [email-masked]

The IETF has just published a new draft of "Registration of xmlns Media
Feature Tag".  

http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-01.txt

This new version fixes a number of typos, notably missing colons in the
examples.  It also adds a section on "Relation to MIME Media Types".

I'm also maintaining both an archive of these drafts and the currently
open (unsubmitted) draft at:
http://simonstl.com/ietf/

Current modifications include making it explicit that order doesn't
matter in use of the xmlns feature, and adding support for "no default
namespace" (xmlns="").

Comments and suggestions are welcome.

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

Date: Thu, 24 Jan 2002 15:33:09 +0900 (JST)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Internet-Draft: Media Feature - xmlns
From: MURATA Makoto <[email-masked]>
Sender: [email-masked]

> My only suggestion, for what it's worth, would be to allow for the
> declaration (and please don't overinterpret that word ;-) ) of the 'root'
> namespace for a document.  That seems a reasonable distinction to make,

I am not convinced.  In the case of XSLT, the root of an XSLT
stylesheet do not always belong to the XSLT namespace.  Why is the
top-level namespace so important?  

>although you'd then have to define how such a statement interacts with
>content-type declarations such as application/xml+mathml (would that, in
>some twisted way, imply a default 'root'-level namespace, and if so,
>how?).

I think that this is a good reason NOT to introduce special 
handling of the top-level namespace.

Cheers,

Makoto

Date: Wed, 23 Jan 2002 22:14:26 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked]
Subject: Re: Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

My only suggestion, for what it's worth, would be to allow for the
declaration (and please don't overinterpret that word ;-) ) of the 'root'
namespace for a document.  That seems a reasonable distinction to make,
although you'd then have to define how such a statement interacts with
content-type declarations such as application/xml+mathml (would that, in
some twisted way, imply a default 'root'-level namespace, and if so,
how?).

Ian 
(who is very loopy after a long day at work cut off from the
surrealistic world of xml-dev)

On 21 Jan 2002, Simon St.Laurent wrote:

> 
> I'm happy to announce the availability of an Internet-Draft,
> Registration of xmlns Media Feature Tag, which:
> ---------------------
>    registers a media feature tag 'xmlns', per RFC 2506,
>    intended for use in a Content-features header to indicate
>    the XML namespaces used in an XML document.  This information
>    augments MIME content-type information, providing a finer granularity
>    of content description for XML documents.
> ---------------------
> http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-00.txt
> 
> This is different work from the XML Media Types work done in RFC 3023,
> but this list seems the most appropriate place to discuss it.
> 
> -- 
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
> 
> 

Subject: Internet-Draft: Media Feature - xmlns
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked]
Date: 21 Jan 2002 18:29:47 -0500
Sender: [email-masked]

I'm happy to announce the availability of an Internet-Draft,
Registration of xmlns Media Feature Tag, which:
---------------------
   registers a media feature tag 'xmlns', per RFC 2506,
   intended for use in a Content-features header to indicate
   the XML namespaces used in an XML document.  This information
   augments MIME content-type information, providing a finer granularity
   of content description for XML documents.
---------------------
http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-00.txt

This is different work from the XML Media Types work done in RFC 3023,
but this list seems the most appropriate place to discuss it.

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

Date: Sun, 20 Jan 2002 17:16:43 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: Ian Graham <[email-masked]>, [email-masked]
Subject: Re: Media types
Sender: [email-masked]

On Fri, 18 Jan 2002, Graham Klyne wrote:

> 
> At 08:51 PM 1/17/02 -0500, Ian Graham wrote:
> >MIME really doesn't give you a nice way of defining multipe properties for
> >a single resource, other than the media features extension described
> >in RFC 2912. Using this extension (Designed for a different purpose, BTW)
> >you could write something like:
> 
> Not so very different...
> 
> >Content-Type: text/xml;
> >Content-features:
> >         (& (primary-namespace="uri1")
> >            (secondary-namespace="uri2")
> >            ...
> >         )
> >
> >The question then is -- does that really give you anything particularly
> >useful over text/xml+whatever?  Once I started to think through some
> >uses, I honestly couldn't think of a compelling advantage ...
> 
> ... it gives fine grained content feature description with sufficient 
> detail to form a basis for content negotiation.   The work had (some of) 
> its roots in recognition of the fact that the content type alone was 
> insufficient for effective content negotiation in HTTP.

....

> (I'm not suggesting all this is relevant to the current debate, just trying 
> to answer the question you raise.)

I do agree, but at the same time I couldn't, in the context of projects I
was working on, find a use case that cried out for this approach. In many
cases it seemed easier to user XML messaging to do the content
negotiation, and use a 'base' XML dialect to bootstrap content
negotiation, for example. Thus my 'no compelling advantage' comment.

The arguement for the current approach over this (or any other) extended
approach was apparently based on pragmatics:  most existing MIME type
handlers only pay attention to the content type, and moreover ignore any
property extension added to the field (e.g., content-type:
text/xml;namespace="foo")  Thus, the application/xml+svg was the 'easiest'
solution that would work with a minimum of fus with essentially all mime
handlers.

(I'm paraphrasing this argument from correspondence by Simon St. Laurent
and "MURATA, Makoto" -- I accept full blame for any misrepresentations)

Best --

Ian

Date: Fri, 18 Jan 2002 11:41:21 +0000
To: Ian Graham <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Media types
Cc: [email-masked]
Sender: [email-masked]

At 08:51 PM 1/17/02 -0500, Ian Graham wrote:
>MIME really doesn't give you a nice way of defining multipe properties for
>a single resource, other than the media features extension described
>in RFC 2912. Using this extension (Designed for a different purpose, BTW)
>you could write something like:

Not so very different...

>Content-Type: text/xml;
>Content-features:
>         (& (primary-namespace="uri1")
>            (secondary-namespace="uri2")
>            ...
>         )
>
>The question then is -- does that really give you anything particularly
>useful over text/xml+whatever?  Once I started to think through some
>uses, I honestly couldn't think of a compelling advantage ...

... it gives fine grained content feature description with sufficient 
detail to form a basis for content negotiation.   The work had (some of) 
its roots in recognition of the fact that the content type alone was 
insufficient for effective content negotiation in HTTP.

It also allows one a (limited) capability to describe dependencies between 
features (e.g. raw text in English and French, HTML in English only, or an 
image with Japanese content).

(I'm not suggesting all this is relevant to the current debate, just trying 
to answer the question you raise.)

#g

--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   ([email-masked])
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Date: Fri, 18 Jan 2002 11:23:11 +0000
To: "Simon St.Laurent" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Media types
Cc: [email-masked]
Sender: [email-masked]

At 07:53 PM 1/17/02 -0500, Simon St.Laurent wrote:
>On Thu, 2002-01-17 at 18:32, Graham Klyne wrote:
> > Well, we now have ways to express other (non-primary) content types.
> >
> > E.g., per RFC 2912, RFC 2913, ...
> >
> >    Content-Type: multipart/mixed; boundary="break"
> >    Content-features:
> >      (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") )
>
>Can we simply say (for an XHTML document also containing SVG, MathML,
>SMIL, and XLink):
>
>Content-Type: application/xhtml+xml
>Content-features: (&
>(xmlns="http://www.w3.org/1999/xhtml")
>(xmlns="http://www.w3.org/2000/svg")
>(xmlns="http://www.w3.org/1998/Math/MathML")
>(xmlns="http://www.w3.org/2001/SMIL20/")
>(xmlns="http://www.w3.org/1999/xlink")
>)

Sure... if feature tag xmlns is registered (per RFC 2506).  (Something like 
this is almost anticipated by CC/PP, which mentions a "schema" attribute - 
described in terms of schema identification rather than namespaces).

>If so, then we may already be out of the brush, though my reading of RFC
>2913 suggests that we would need to add xmlns to RFC 3023's existing
>structure.

RFC 2913 and RFC 3023 are almost orthogonal ... there's arguably a very 
small overlap of functionality (between RFC 2912+2913 and RFC 3023), but 
nothing about using RFC 2913 that I can see requires any change to RFC 
3023.  Note that RFC 2913 specifically excludes use of content-type 
parameters, so adding xmlns to RFC 3023 wouldn't change that, and would 
create a more significant overlap.

#g

--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   ([email-masked])
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Subject: Re: Media types
To: [email-masked] (Roy T. Fielding)
Date: Thu, 17 Jan 2002 21:17:44 -0500 (EST)
Cc: [email-masked] (Simon St.Laurent), [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> Let's say you have two resources that both resolve to the same content.
>    GET one and the response is always sent as image/cvg+xml.
>    GET two and the response is always sent as application/xml.
> Those are separate semantics, and thus separate resources.  It doesn't
> prevent the UA from taking the content and choosing to manipulate it
> in different ways, but it does define the semantics from the perspective
> of the person who created the two separate URI used to access those
> two resources containing the same content.

I understand that view.  It's equivalent to sending HTML as text/plain
and not expecting that it be displayed as HTML.  It's a reasonable
argument, primarily because the specification of */xml doesn't say what
to expect, plus not all XML uses namespaces.  Assuming no dispatch would
at least provide some consistentcy.

So let's say we define a new media type for which this dispatching
behaviour is required.  Then publishers describing their content with
that type would expect that the first processor (other than the one
for the media type) to see the content would be, in your example, an SVG
processor.

How's that sound?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Date: Thu, 17 Jan 2002 20:51:31 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Media types
Sender: [email-masked]

On 17 Jan 2002, Simon St.Laurent wrote:

> 
> 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.
> 

For me, the main points (which simon has nicely captured) for XML and
MIME are::
  * using URIs to reference vocabulary definitions
  * XML documents can reference multiple vocabulary definition
  * The mime mechanism can capture only one of these vocabularies

(note how this dances carefully away from the word 'type' ;-) )

MIME really doesn't give you a nice way of defining multipe properties for
a single resource, other than the media features extension described
in RFC 2912. Using this extension (Designed for a different purpose, BTW)
you could write something like:

Content-Type: text/xml;
Content-features:
        (& (primary-namespace="uri1")
           (secondary-namespace="uri2")
           ...
        )

The question then is -- does that really give you anything particularly
useful over text/xml+whatever?  Once I started to think through some
uses, I honestly couldn't think of a compelling advantage ...

Ian

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked], [email-masked]
Date: 17 Jan 2002 21:16:10 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 20:00, Mark Baker wrote:
> > Therefore, it is not useful to send something as application/xml unless
> > the sender specifically wishes it to be processed as generic XML.
> 
> Fair enough.  So what if we define "generic XML" to include dispatch
> to processors keyed on namespace declarations?  Wouldn't that make
> it more semantically significant?

I think I'm going to write up an initial draft using Content-features
for an xmlns feature, so we should have some "semantic significance" in
a MIME-specific context to discuss shortly.

Hopefully I'll have it written by end of day tomorrow - this doesn't
look especially tough, at least for an initial draft.

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

Subject: Re: Media types
To: [email-masked] (Roy T. Fielding)
Date: Thu, 17 Jan 2002 20:00:04 -0500 (EST)
Cc: [email-masked] (Simon St.Laurent), [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> Therefore, it is not useful to send something as application/xml unless
> the sender specifically wishes it to be processed as generic XML.

Fair enough.  So what if we define "generic XML" to include dispatch
to processors keyed on namespace declarations?  Wouldn't that make
it more semantically significant?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Date: Thu, 17 Jan 2002 16:16:30 -0800 (PST)
From: [email-masked]
Subject: RE: Media types
To: "Simon St.Laurent" <[email-masked]>
Cc: Graham Klyne <[email-masked]>, Mike Dierken <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> On Thu, 2002-01-17 at 18:32, Graham Klyne wrote:
> > Well, we now have ways to express other (non-primary) content types.
> >
> > E.g., per RFC 2912, RFC 2913, ...
> >
> >    Content-Type: multipart/mixed; boundary="break"
> >    Content-features:
> >      (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") )

> Can we simply say (for an XHTML document also containing SVG, MathML,
> SMIL, and XLink):

> Content-Type: application/xhtml+xml
> Content-features: (&
> (xmlns="http://www.w3.org/1999/xhtml")
> (xmlns="http://www.w3.org/2000/svg")
> (xmlns="http://www.w3.org/1998/Math/MathML")
> (xmlns="http://www.w3.org/2001/SMIL20/")
> (xmlns="http://www.w3.org/1999/xlink")
> )

You can if xmlns is already defined. AFAIK it isn't, but defining it should
be easy.

> If so, then we may already be out of the brush, though my reading of RFC
> 2913 suggests that we would need to add xmlns to RFC 3023's existing
> structure.

Adding an additional attribute does not constitute a structural change.

					Ned

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: 17 Jan 2002 20:20:24 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 19:08, Roy T. Fielding wrote:
> On Thu, Jan 17, 2002 at 07:31:10PM -0500, Simon St.Laurent wrote:
> > On Thu, 2002-01-17 at 18:18, Roy T. Fielding wrote:
> > > I think the mistake is in assigning such messages a type that implies
> > > it should be handled by a generic XML processor.  There is no such thing,
> > 
> > No such thing?  There are all kinds of processing gidgets and storage
> > systems that work on XML generically.  You might want to choose more
> > precise language.
> 
> There are all types of procesing gadgets and storage systems that work on
> bytes generically.  If that was a useful distinction at the message level
> then there wouldn't have been any need for media types.  

Sure.  But I hope you've noticed that XML is perhaps slightly more than
bytes - and perhaps even a "useful distinction at the message level".

If not, I'm not sure I really want to send my nouns to your limited set
of verbs.

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

Date: Thu, 17 Jan 2002 16:09:21 -0800 (PST)
From: [email-masked]
Subject: Re: Media types
To: Keith Moore <[email-masked]>
Cc: "Roy T. Fielding" <[email-masked]>, Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> actually, the dispatching is not implied by the content-type -
> the recipient agent is free to dispatch each content as it sees fit.
> the content-type really is just labelling the data representation
> used by the content.

Labelling is definitely the intent, but that has always been filtered by a
desire to use the label as a basis for various sorts of actions. So yes,
dispatching isn't implied, but the labels are constructed to facilitate
dispatching. This has had mixed results -- the primary type concept, for
example, has worked well in some cases and poorly in others.

Additionally, we have been reluctant to go much beyond labelling the
representation of the data in the content type field. Information about
whether an image is black and white or color, what Postscript features
are employed, and so on belong somewhere else. We didn't address where that
was in the original MIME work, but the content-features work has done this.

				Ned

Date: Thu, 17 Jan 2002 15:52:09 -0800 (PST)
From: [email-masked]
Subject: RE: Media types
To: Graham Klyne <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Mike Dierken <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> At 07:22 PM 1/17/02 -0500, Simon St.Laurent wrote:
> > > > At what point does it make sense to move beyond MIME?
> > > >
> > >
> > > Is it MIME or just the singular Content-Type that is a problem?
> >
> >Singular content-type.  I don't think the rest of MIME (except some
> >encoding issues) causes much trouble.

MIME content-types are intended to be acted on. Their descriptive capabilities
are secondary, and are extended and supplemented by other content fields,
including content-disposition and content-features.

> Well, we now have ways to express other (non-primary) content types.

> E.g., per RFC 2912, RFC 2913, ...

>    Content-Type: multipart/mixed; boundary="break"
>    Content-features:
>      (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") )

Exactly. This is the solution I suggest the last time this topic came up on
this list. Features are extensible to include new "axes" of description,
including things that come from XML.

People seem to think MIME is the same now as it was in 1993. Not so. We've
added a lot, including but not limited to facilities for describing content
that consists of  multiple formats.

					Ned

Subject: Re: Media types
To: [email-masked] (Tim Bray)
Date: Thu, 17 Jan 2002 18:56:46 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> At 04:11 PM 17/01/02 -0500, Mark Baker wrote:
> >Almost exactly what I was thinking.  My strawman media type was
> >application/xmlns-dispatch+xml (not very catchy, I know).  
> 
> None of the arguments I've read here lead me to see this as
> a value-add over application/xml.  It seems we think that
> applications should when processing XML resources dispatch
> based on namespaces... except when they can't, which I guess
> is the point of the worry about XSLT.

Yes.  If it weren't for XSLT (and that we haven't gone looking for other
cases like it), I'd be suggesting we do this with */xml and maybe +xml
too.

What I primarily want to accomplish is documenting the rules of
containment and dispatch.  Which media type(s) we bind those too can be
determined later.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Subject: RE: Media types
From: "Simon St.Laurent" <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: Mike Dierken <[email-masked]>, [email-masked], [email-masked]
Date: 17 Jan 2002 19:53:46 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 18:32, Graham Klyne wrote:
> Well, we now have ways to express other (non-primary) content types.
> 
> E.g., per RFC 2912, RFC 2913, ...
> 
>    Content-Type: multipart/mixed; boundary="break"
>    Content-features:
>      (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") )

Can we simply say (for an XHTML document also containing SVG, MathML,
SMIL, and XLink):

Content-Type: application/xhtml+xml
Content-features: (& 
(xmlns="http://www.w3.org/1999/xhtml") 
(xmlns="http://www.w3.org/2000/svg")
(xmlns="http://www.w3.org/1998/Math/MathML")
(xmlns="http://www.w3.org/2001/SMIL20/")
(xmlns="http://www.w3.org/1999/xlink")
)

If so, then we may already be out of the brush, though my reading of RFC
2913 suggests that we would need to add xmlns to RFC 3023's existing
structure.

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

From: Keith Moore <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Media types 
Date: Thu, 17 Jan 2002 18:38:30 -0500
Sender: [email-masked]

> > 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?
> 
> That's not always true. MIME uses the content-type to indicate what type
> of handler should be selected for the message body.  The same content can
> be sent for different purposes by using different media types. E.g.,
> image/jpeg vs application/octet-stream, multipart/alternative vs
> multipart/mixed, etc.

actually, the dispatching is not implied by the content-type -
the recipient agent is free to dispatch each content as it sees fit.
the content-type really is just labelling the data representation
used by the content.

the same is true for application/octet-stream - this just happens
to be the type name for "unknown", and the multipart/* types just
happen to use MIME framing internally.  

it's not as if labelling a content as image/jpeg implies that the 
image should be displayed whereas labelling it as application/octet-stream 
implies that it should not be displayed (even if it often works out
that way) we have content-disposition to specify presentation hints.

> > the fact that XML picked a means of labelling content that is
> > incompatible with MIME's content-type is hardly MIME's fault.
> 
> I think the mistake is in assigning such messages a type that implies
> it should be handled by a generic XML processor.  There is no such thing,
> even though it is possible to view all XML types via generic XML tools.

well, I'd agree with that.

> A more architecturally fitting course of action would be to create a
> top-level media type of xml and then have xml/* subtypes, but for
> some reason (deployed apps, I presume) the top-level namespace has been
> frozen for ages.

that wouldn't have been consistent with the MIME content-type
labelling architecture either. whether a content uses XML as a
presentation layer is orthogonal to the type of the content.
after all, XML can certainly be used to represent text, images, 
application data, audio or video.

the most "architecturally fitting course of action" (for MIME) would 
have been to define a separate facet for the nature of the underlying
content (say content-presentation-layer to pick a hasty example) 
and put this in a separate header field.  but people wanted to be
able to dispatch on content-type alone (even though that's unrealistic), 
and HTTP doesn't make a clean separation between facets of the content
and attributes of the bearer protocol.  so we're kind of stuck.

Keith

Date: Thu, 17 Jan 2002 23:32:32 +0000
To: "Simon St.Laurent" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Media types
Cc: Mike Dierken <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 07:22 PM 1/17/02 -0500, Simon St.Laurent wrote:
> > > At what point does it make sense to move beyond MIME?
> > >
> >
> > Is it MIME or just the singular Content-Type that is a problem?
>
>Singular content-type.  I don't think the rest of MIME (except some
>encoding issues) causes much trouble.

Well, we now have ways to express other (non-primary) content types.

E.g., per RFC 2912, RFC 2913, ...

   Content-Type: multipart/mixed; boundary="break"
   Content-features:
     (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") )

#g

--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   ([email-masked])
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: 17 Jan 2002 19:31:10 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 18:18, Roy T. Fielding wrote:
> I think the mistake is in assigning such messages a type that implies
> it should be handled by a generic XML processor.  There is no such thing,

No such thing?  There are all kinds of processing gidgets and storage
systems that work on XML generically.  You might want to choose more
precise language.

> even though it is possible to view all XML types via generic XML tools.

Viewing is just one possibility.

> A more architecturally fitting course of action would be to create a
> top-level media type of xml and then have xml/* subtypes, but for
> some reason (deployed apps, I presume) the top-level namespace has been
> frozen for ages.

That proposal went over like a lead ballon - see the ietf-xml-mime
archives for much more detail.  +xml, a 'lesser' though similar notion,
wasn't exactly easy to put across either.
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

Date: Thu, 17 Jan 2002 15:19:24 -0800
To: [email-masked], [email-masked], [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Media types
Sender: [email-masked]

At 04:11 PM 17/01/02 -0500, Mark Baker wrote:
>Almost exactly what I was thinking.  My strawman media type was
>application/xmlns-dispatch+xml (not very catchy, I know).  

None of the arguments I've read here lead me to see this as
a value-add over application/xml.  It seems we think that
applications should when processing XML resources dispatch
based on namespaces... except when they can't, which I guess
is the point of the worry about XSLT.

Before launching the quest for a new media type, I think
we need a clearer explanation of the use case where this
is used and application/xml or anything/anything+xml isn't
appropriate, and why. -Tim

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Media types 
Date: Thu, 17 Jan 2002 18:20:59 -0500
Sender: [email-masked]

> > > 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.
> > 
> > I don't see an inability of MIME to handle labelled content, I see
> > XML's deliberate decision to use a means of content-labelling which
> > was incompatible with MIME, while still expecting to use MIME
> > framing to convey XML from one place to another.
> 
> How would you have proposed that XML's developers create a
> MIME-compliant form of content labelling?
> 
> Or would you simply have banned the notion of mixing different
> vocabularies into a single document?

I'm not saying that MIME's notion of content-labelling could have 
satisified all of the desired goals for XML; I'm saying that there's
an impedance mismatch between the purposes for which MIME was designed
and the way that XML folks want to use it.  You can think of that as
a limitation of MIME, and in a sense that's true, but the bottom line
is that MIME wasn't designed for that purpose.  And had we tried to
design MIME for that purpose it would have taken several more years
to finish it.
 
> > MIME does have its limitations
> 
> Anything with only two levels is pretty well guaranteed to run into a
> need for three or more.

Some of us think in retrospect that two levels was one too many - 
the top-level has been misused more often than not.  But adding
more levels wouldn't have solved the "mixing vocabularies" problem.

> > On the other hand, it might be worth the trouble to define a
> > different transmission format for the sole purpose of shipping
> > XML around.  It's not as if either SMTP or HTTP is ideal for
> > this purpose either.
> 
> No, they're not very efficient.  I'm not convinced however, that sending
> XML over separate pipes is particularly sensible either.

Nor am I convinced that the existence of HTTP obviates the need for
other applications.  As for "separate pipes", there is no need - 
the pipes that are in place already have a very flexible mechanism 
for multiplexing different kinds of data.  It's called IP.

Keith

Subject: RE: Media types
From: "Simon St.Laurent" <[email-masked]>
To: Mike Dierken <[email-masked]>
Cc: [email-masked], [email-masked]
Date: 17 Jan 2002 19:22:12 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 18:05, Mike Dierken wrote:
> > At what point does it make sense to move beyond MIME?
> > 
> 
> Is it MIME or just the singular Content-Type that is a problem?

Singular content-type.  I don't think the rest of MIME (except some
encoding issues) causes much trouble.

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

From: Mike Dierken <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Media types
Date: Thu, 17 Jan 2002 15:05:24 -0800
Sender: [email-masked]

> -----Original Message-----
> From: Simon St.Laurent [mailto:[email-masked]] 

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

Is it MIME or just the singular Content-Type that is a problem?

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: 17 Jan 2002 19:04:38 -0500
Sender: [email-masked]

On Thu, 2002-01-17 at 17:54, Keith Moore wrote:
> > 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.
> 
> I don't see an inability of MIME to handle labelled content, I see 
> XML's deliberate decision to use a means of content-labelling which 
> was incompatible with MIME, while still expecting to use MIME 
> framing to convey XML from one place to another.

How would you have proposed that XML's developers create a
MIME-compliant form of content labelling?  

Or would you simply have banned the notion of mixing different
vocabularies into a single document?

> MIME does have its limitations

Anything with only two levels is pretty well guaranteed to run into a
need for three or more.

MIME is a legacy technology.  It works well for what it did and does. 
That doesn't mean it'll work well going forward.  (And the same may well
happen to XML over a similar period of time.)

> On the other hand, it might be worth the trouble to define a
> different transmission format for the sole purpose of shipping
> XML around.  It's not as if either SMTP or HTTP is ideal for 
> this purpose either.

No, they're not very efficient.  I'm not convinced however, that sending
XML over separate pipes is particularly sensible either.

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

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Media types 
Date: Thu, 17 Jan 2002 17:54:24 -0500
Sender: [email-masked]

> 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.

I don't see an inability of MIME to handle labelled content, I see 
XML's deliberate decision to use a means of content-labelling which 
was incompatible with MIME, while still expecting to use MIME 
framing to convey XML from one place to another.

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

It depends on the purpose for which MIME is being used.

MIME does have its limitations, but the installed base of mail 
clients and servers, and web clients and servers, is so large that 
it would take a very compelling gain in functionality to make it
worth these applications abandoning MIME for some other format -
and the issues associated with transition would be considerable.
( not to mention the effort needed to support both formats for 
the duration that such messages would be used - probably decades.)

On the other hand, it might be worth the trouble to define a
different transmission format for the sole purpose of shipping
XML around.  It's not as if either SMTP or HTTP is ideal for 
this purpose either.

Keith

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: 17 Jan 2002 18:50:19 -0500
Sender: [email-masked]

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

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: 17 Jan 2002 18:49:06 -0500
Sender: [email-masked]

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
applications have fair warning?

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

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Media types 
Date: Thu, 17 Jan 2002 17:36:15 -0500
Sender: [email-masked]

> 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

Subject: Re: Media types
To: [email-masked] (Simon St.Laurent)
Date: Thu, 17 Jan 2002 16:11:59 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

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.

> > Does the above help to alleviate those concerns?  I'm not suggesting we
> > prevent anybody from doing what they're already comfortable with.  I'm
> > only suggesting we attempt to define a generic dispatch model triggered
> > from a generic XML media type, which would likely be useful to lots of
> > people, especially those working with multi-namespace documents.
> 
> If that is to happen - and I think it would be a good thing - I'd much
> prefer such information appears in metadata provided before an
> application goes to the trouble of downloading a document.  More
> information sooner is - I think - always going to be the better option. 
> For now, that means MIME types like image/svg+xml rather than plain old
> application/xml, if only because both graphics programs and XML
> processors will be happier.
> 
> Documents containing multiple namespaces are a substantial challenge to
> the foundations of MIME content types.  It may be that we need a new
> MIME type (application/extensible+xml?)

Almost exactly what I was thinking.  My strawman media type was
application/xmlns-dispatch+xml (not very catchy, I know).  But it would
really help its chance for success if we could bind this behaviour to
application/xml.  XSLT makes that tough, but it would be worth digging
to see how common this use of XSLT is (I fear it's common).
Alternately, it could be bound to "+xml", but we'd have to check to see
that it's consistent with deployed processors.  Also, it might be
confusing to people (or just plain wrong?) if "+xml" is used to specify
this behaviour, but */xml is not.

I'll start with a new media type.

> and a header or parameter or
> plural thereof to identify namepace URIs.

I'm not so sure.  I expect lots of discussion about this point though.

>  Getting there will require a
> lot of long but worthwhile discussions at the IETF. 
> [email-masked] is the place to start that.

Let the games begin!  I'll try to have my draft out shortly, but my time
has been at a premium recently.  Luckily it should be a short draft.

> (There may also have been an Internet-Draft about this at some point,
> but I don't remember where/if it went.)

Hmm, I don't recall one but I could have missed it.

 [1] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0070.html 

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Subject: Re: Media types
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: 17 Jan 2002 16:05:09 -0500
Sender: [email-masked]

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
capable of supporting the diversity XML makes possible.

It seems like XML is effectively using URIs for vocabulary
identification, though this isn't entirely explicit in the namespaces
specification.  The problem with the compromise we managed to reach on
ietf-xml-mime during the RFC 3023 work is that even image/svg+xml or
application/soap+xml doesn't say enough to make clear decisions about
the nature of a document without actually reading it.  We did what we
could under the historical, technical, and political circumstances to
communicate as much information as possible.

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

It's a good idea, but only a start, given all the possibilities of that
XHTML document's content.  I don't believe the "root namespace" is an
adequate identifier.  Beyond that, I worry about lots of cases where a
namespace may appear in a document, and an application needs to
understand its use, but only some of its functionality is used.

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 agree in principle with the notions that dispatching on
> > namespaces is a good thing, and that the namespace of the root
> > element of an XML document has a special status, but I'm highly
> > unconvinced that serving everything that has XML syntax as
> > application/xml is a good direction to take.
> 
> Does the above help to alleviate those concerns?  I'm not suggesting we
> prevent anybody from doing what they're already comfortable with.  I'm
> only suggesting we attempt to define a generic dispatch model triggered
> from a generic XML media type, which would likely be useful to lots of
> people, especially those working with multi-namespace documents.

If that is to happen - and I think it would be a good thing - I'd much
prefer such information appears in metadata provided before an
application goes to the trouble of downloading a document.  More
information sooner is - I think - always going to be the better option. 
For now, that means MIME types like image/svg+xml rather than plain old
application/xml, if only because both graphics programs and XML
processors will be happier.

Documents containing multiple namespaces are a substantial challenge to
the foundations of MIME content types.  It may be that we need a new
MIME type (application/extensible+xml?) and a header or parameter or
plural thereof to identify namepace URIs.  Getting there will require a
lot of long but worthwhile discussions at the IETF. 
[email-masked] is the place to start that.

(There may also have been an Internet-Draft about this at some point,
but I don't remember where/if it went.)
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

Subject: I-D ACTION:draft-baker-soap-media-reg-00.txt (fwd)
To: [email-masked]
Date: Wed, 16 Jan 2002 17:38:56 -0500 (EST)
From: Mark Baker <[email-masked]>
Sender: [email-masked]

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.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

From: Mike Dierken <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Media types
Date: Fri, 11 Jan 2002 09:26:59 -0800
Sender: [email-masked]

[...re-sending...]

> -----Original Message-----
> From: Mark Baker [mailto:[email-masked]] 
> 
[...]

> 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

and

Content-Type: application/x-java-serialized-object
Content-Model: java:org.apache.sample.user.profile

Mike

Subject: Re: Media types
To: [email-masked] (David Orchard)
Date: Thu, 10 Jan 2002 13:03:43 -0500 (EST)
Cc: [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

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

  application/xml; xmlns="http://www.w3.org/2001/12/soap-envelope"

would only be allowed to be dispatched to a generic XML processor
anyhow, who would then be tasked with further dispatch based on the
namespace.  So the parameter doesn't add a lot of value in that case
beyond what would be possible with just "application/xml", except as
a quicker lookup mechanism, which itself comes at the cost of the
complexity of duplicating that information and handling additional
error cases.

I think the need for it (or not) would come mostly from the email
community, which I unfortunately don't have nearly enough knowledge
about.

> The way I see it, media types are broken for multiple namespace'd xml
> documents, especially documents that are targetted to be frameworks like
> soap.  The "+" syntax for media-types simply doesn't scale to these kinds of
> documents.  I don't know how, but we have to find someway of either
> expressing a manifest, or the name of a profile that is a reference to a
> manifest.  At least with the use of xmlns we have some notion of versions as
> well, given the namespace name would be used.

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.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Date: Wed, 09 Jan 2002 22:32:24 +0000
To: Mark Baker <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Media types
Cc: [email-masked]
Sender: [email-masked]

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
<[email-masked]>

Subject: Re: Media types
To: [email-masked]
Date: Wed, 9 Jan 2002 16:55:19 -0500 (EST)
Cc: [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

[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
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com