Subject: updated xmlns media feature
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked]
Date: 28 Feb 2002 15:48:53 -0500
List-Id: <ietf-xml-mime.imc.org>

A new Internet-Draft of Registration of xmlns Media Feature Tag is
available:
http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt

This document specifies an xmlns Media Feature per RFC 2506 for
identifying some or all of the URIs defining XML namespaces in a
given XML resource, and the relative importance of these namespaces.
This feature is designed primarily for use with the XML Media Types
defined in RFC 3023, to provide additional hints as to the
processing requirements of a given XML resource.

This draft includes clarifications in its introduction, more explicit
notice that the order in which features are listed is unimportant, and a
new author (Ian Graham).

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

Date: Wed, 20 Feb 2002 21:59:07 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Mark Nottingham <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

I concur with Simon here.  As has been noted before, the root namespace is
often not the one you want to 'dispatch' based on.

I think it makes more sense to think of the namespace 'set' specified in a
MIME header as representing a 'processing signature hint' for the
data. But note that this hint is not unique for a document -- it can
vary depending on how you want the data to be processed. 

Looked at this way, the root namespace is no longer that important -- it's
just one potential namespace part of the overall signature. 

Hope this makes sense --

Ian

On 19 Feb 2002, Simon St.Laurent wrote:

> 
> On Tue, 2002-02-19 at 19:20, Mark Nottingham wrote:
> > Might I suggest that any revision of RFC3023 include a new parameter
> > for application/xml and text/xml (say, 'rootNS') that contains the
> > root element's namespace URI, to allow HTTP content negotiation with
> > current implementations? Yes, this won't address cases where there is
> > a need to negotiate on more than one namespace in the document, but
> > it will certainly help with the simple cases, where dispatch is based
> > upon the root element's namespace (which seems to be the direction
> > things are going in).
> 
> You're welcome to register a rootNS content feature.  
> 
> I have to admit that I don't understand or sympathize with the
> fascination with root element namespaces, and don't believe that RFC
> 3023 needs to add any XML-specific parameters, but a content feature
> should take care of what you're looking for.
>  
> -- 
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
> 
> 

Subject: Re: Revised Internet-Draft: Media Feature - xmlns
To: Mark Nottingham <[email-masked]>
Date: Tue, 19 Feb 2002 22:24:59 -0500 (EST)
CC: [email-masked], "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
From: John Cowan <[email-masked]>
Sender: [email-masked]

Mark Nottingham scripsit:

> True. However, there are many formats (especially XML-based) which
> are neither vendor-specific or 'personal'; instead, the represent
> loose consensus among a number of partners or other interested
> parties.

There is no reason why lightweight "vendors" cannot be created for
such situations.  A media type emerging on the xml-dev list,
for example, might very well have a name like
application/vnd.xml-dev.fubar+xml.

-- 
John Cowan           http://www.ccil.org/~cowan              [email-masked]
To say that Bilbo's breath was taken away is no description at all.  There
are no words left to express his staggerment, since Men changed the language
that they learned of elves in the days when all the world was wonderful.
        --_The Hobbit_

Date: Tue, 19 Feb 2002 17:29:56 -0800
From: Mark Nottingham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

Is it possible to negotiate a content feature with current HTTP
implementations? AFAIK it isn't, but it would be possible to do so on
a media type attribute, using server-driven negotiation.

If I'm missing something, a reference would be very much appreciated.

Cheers,

On Tue, Feb 19, 2002 at 09:28:05PM -0500, Simon St.Laurent wrote:
> On Tue, 2002-02-19 at 19:20, Mark Nottingham wrote:
> > Might I suggest that any revision of RFC3023 include a new parameter
> > for application/xml and text/xml (say, 'rootNS') that contains the
> > root element's namespace URI, to allow HTTP content negotiation with
> > current implementations? Yes, this won't address cases where there is
> > a need to negotiate on more than one namespace in the document, but
> > it will certainly help with the simple cases, where dispatch is based
> > upon the root element's namespace (which seems to be the direction
> > things are going in).
> 
> You're welcome to register a rootNS content feature.  
> 
> I have to admit that I don't understand or sympathize with the
> fascination with root element namespaces, and don't believe that RFC
> 3023 needs to add any XML-specific parameters, but a content feature
> should take care of what you're looking for.
>  
> -- 
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
> 

-- 
Mark Nottingham
http://www.mnot.net/

Subject: Re: Revised Internet-Draft: Media Feature - xmlns
From: "Simon St.Laurent" <[email-masked]>
To: Mark Nottingham <[email-masked]>
Cc: [email-masked], [email-masked]
Date: 19 Feb 2002 21:28:05 -0500
Sender: [email-masked]

On Tue, 2002-02-19 at 19:20, Mark Nottingham wrote:
> Might I suggest that any revision of RFC3023 include a new parameter
> for application/xml and text/xml (say, 'rootNS') that contains the
> root element's namespace URI, to allow HTTP content negotiation with
> current implementations? Yes, this won't address cases where there is
> a need to negotiate on more than one namespace in the document, but
> it will certainly help with the simple cases, where dispatch is based
> upon the root element's namespace (which seems to be the direction
> things are going in).

You're welcome to register a rootNS content feature.  

I have to admit that I don't understand or sympathize with the
fascination with root element namespaces, and don't believe that RFC
3023 needs to add any XML-specific parameters, but a content feature
should take care of what you're looking for.
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

Date: Tue, 19 Feb 2002 17:07:48 -0800 (PST)
From: [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
To: Mark Nottingham <[email-masked]>
Cc: [email-masked], "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> True. However, there are many formats (especially XML-based) which
> are neither vendor-specific or 'personal'; instead, the represent
> loose consensus among a number of partners or other interested
> parties.

So? This sort of stuff is registered under vnd and prs all the time.

> These probably fall most accurately under prs, but there are some
> (human) implications to 'personal' that seem to make people avoid it
> for these uses. Yes, this is largely psychological.

I'd have to say "delusional" is closer to the mark. I would be the first to
agree that the names "vendor" and "personal" are far from perfect names. But we
had to pick something, this is what we came up with, at the time nobody was
able to suggest anything better.

Regardless, the bottom line is all the facet name does is tie the collection to
a particular set of registration rules. Fretting about name perception is a
case of the perfect being the enemy of the good enough.

> Additionally, there is still a need to have a one-to-one mapping
> between media types and namespaces when so desired by the
> application. The most effective way to do this IMHO is to include the
> namespace URI in the media type as a parameter, rather than forcing
> translation between a registered type and a URI (Yes, I'm aware that
> there is reasoning behind the cost of registering a media type).

Perhaps. However, I was merely pointing out that your assertion that RFC
publication is needed to register a type is just not true.

				Ned

Date: Tue, 19 Feb 2002 17:06:28 -0800
From: Mark Nottingham <[email-masked]>
To: [email-masked]
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

True. However, there are many formats (especially XML-based) which
are neither vendor-specific or 'personal'; instead, the represent
loose consensus among a number of partners or other interested
parties.

These probably fall most accurately under prs, but there are some
(human) implications to 'personal' that seem to make people avoid it
for these uses. Yes, this is largely psychological.

Additionally, there is still a need to have a one-to-one mapping
between media types and namespaces when so desired by the
application. The most effective way to do this IMHO is to include the
namespace URI in the media type as a parameter, rather than forcing
translation between a registered type and a URI (Yes, I'm aware that
there is reasoning behind the cost of registering a media type).

Cheers,

On Tue, Feb 19, 2002 at 04:43:33PM -0800, [email-masked] wrote:
> > This seems at odds with XML's easy extensibility and the lost
> > overhead of using XML namespaces; to do conneg on any format that I
> > create, I have to write an I-D, get it approved as Informational, and
> > then register it with IANA.
> 
> You need do nothing of the sort. RFC publication and IESG approval is only
> required for things in the IETF tree. Vendor and personal tree entries are as
> simple as filling out a Web form at IANA:
> 
>    http://www.iana.org/cgi-bin/mediatypes.pl
> 
> The recent shift from isi.edu to iana.org has caused a lot of delay in
> registration approvals, but that should be done by now.
> 
> 				Ned

-- 
Mark Nottingham
http://www.mnot.net/

Date: Tue, 19 Feb 2002 16:43:33 -0800 (PST)
From: [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
To: Mark Nottingham <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> This seems at odds with XML's easy extensibility and the lost
> overhead of using XML namespaces; to do conneg on any format that I
> create, I have to write an I-D, get it approved as Informational, and
> then register it with IANA.

You need do nothing of the sort. RFC publication and IESG approval is only
required for things in the IETF tree. Vendor and personal tree entries are as
simple as filling out a Web form at IANA:

   http://www.iana.org/cgi-bin/mediatypes.pl

The recent shift from isi.edu to iana.org has caused a lot of delay in
registration approvals, but that should be done by now.

				Ned

Date: Tue, 19 Feb 2002 16:20:07 -0800
From: Mark Nottingham <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Revised Internet-Draft: Media Feature - xmlns
Sender: [email-masked]

I like Simon's proposal [1], with one important caveat;

  It's currently difficult/impossible to do HTTP content negotiation
  on an XML-based format unless you define a media type for it.

One could arrange to do negiotiation on Content-Features, but AFAIK
this isn't defined for HTTP, and certainly not implemented.

This seems at odds with XML's easy extensibility and the lost
overhead of using XML namespaces; to do conneg on any format that I
create, I have to write an I-D, get it approved as Informational, and
then register it with IANA.

Might I suggest that any revision of RFC3023 include a new parameter
for application/xml and text/xml (say, 'rootNS') that contains the
root element's namespace URI, to allow HTTP content negotiation with
current implementations? Yes, this won't address cases where there is
a need to negotiate on more than one namespace in the document, but
it will certainly help with the simple cases, where dispatch is based
upon the root element's namespace (which seems to be the direction
things are going in).

Cheers,

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

-- 
Mark Nottingham
http://www.mnot.net/

Date: Fri, 01 Feb 2002 18:40:15 +0900 (JST)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [nsMediaType-3] Principles and corner cases
From: MURATA Makoto <[email-masked]>
Sender: [email-masked]

In [1], Tim wrote:
> - there is the whole issue of the charset header.

0. Introduction

There have been a lot of discussion about the encoding issue.  Rather
than repeating it, we have to begin with a better understanding of the
current situation.  Here is my attempt to clarify the current (messy)
status.  Although this memo is still incomplete, I hope this has some
points.

1. Textual resources

Many types of WWW resources are textual.  Since many charsets are 
in use, we have to determine the charset of each textual resource 
so as to handle it correctly .  

1.1 Documents

XML, HTML, and CSS of W3C have textual representations.  Plain text 
is certainly textual.

1.2 Programs

Source programs are textual and written in some encoding.  When we
transmit source programs or compile/execute them on the fly, encoding
issues will arise.

- VBScript received from the server, 
- Javascript received from the server, 
- JSP source files at the server,
- perl programs at the server, etc.

1.3 Generation of documents by programs

On the www server, programs generate documents on the fly.  These
programs have to specify encoding for such documents.  APIs of most 
programming languages allow charset specification

Furthermore, programs have to embed in-band signature, when it is
necessary.  Most APIs and programming languages do not provide any
support.  Rather, programmers have use "print" carefully so as to
create in-band signatures (e.g., meta tags).

- CGI programs,
- Servlets,
- Applets,
- XSLT stylesheets

1.4 Form data

Finally, text typed in forms of HTML and sent as multipart/form-data
via HTTP also reqiure encoding information.

- text typed in <textarea> of HTML,
- text typed in <input type="text"> of HTML, and
- file uploaded by <input type="file"> of HTML,

2. Current situation

There are already too many methods for determining the encoding.  
I show a list of such methods and further show which 
is used for which type of resource.

A: the charset parameter of MIME entities

B: in-band declaration (META tags of HTML, @charset of CSS, 
   encoding declarations of XML),

C: the charset attribute of the referring element (XML or HTML)
  in the referring resource,

D: the charset of the referring resource (typically HTML), 

E: the charset of the HTML document containing the <input> or 
   <textarea> element,

F: guessing based on bit patterns

G: configuration files

H: Manual intervention

2.1 XML documents received from the HTTP server 

A: the charset parameter of media types such as 
   text/xml and application/xml

B: the encoding declaration in XML documents

Note: RFC 3023 certainly says A > B.

2.2 HTML documents received from the HTTP server 

A: the charset parameter of the media type
   text/html

B: Meta tags

F: Some browsers sniff the charset.

H: the menu for choosing the encoding

Note: The HTML 4.01 recommendation blesses both A and B, but 
RFC 2854 (text/html) strongly recommends A only.  However, 
RFC 2854 references to HTML 4.

2.3 CSS stylesheets received from the HTTP server 

A: the charset parameter of media types such as 
   text/css

B: @encoding in CSS stylesheets

C: the attribute "charset" of LINK elements of HTML 4.01; 
   the charset attribute of the stylesheet-linking PI.

F: Some browsers sniff the charset.

Note: The CSS recommendation blesses both A and B,
but RFC 2318 (text/css) merely mentions A.

2.4 XSLT stylesheets received from the HTTP server 

A: the charset parameter of media types such as 
   text/xml and application/xml

B: the encoding declaration in XML documents

C: the charset attribute of the stylesheet-linking PI

Note: Use of C is incorrect.

2.5 plain text received from the HTTP server 

A: the charset parameter of the media type text/plain

F: Some browsers sniff the charset.

H: the menu for choosing the encoding

2.6 XML documents which are stored at the server but have 
    not been transmitted to the client yet

B: the encoding declaration in XML documents

G: Apache provides the directive AddCharset for configuration 
   files.

2.7 HTML documents which are stored at the server but have 
    not been transmitted to the client yet

B: META tags in this document

C: This document may be referenced by some anchor elements 
   of HTML 4.01, which specify the charset attribute.

G: Apache provides the directive AddCharset for configuration 
   files.

2.8 An HTML document that is generated at the server on the fly 
    but has not been transmitted to the client yet

B: META tags specified in this document

Note: Generating programs typically specify the charset 
     *TWICE*: once for the encoding of the output 
     stream and once for generating meta tags.

2.9 An HTML document temporarily created at the client by XSLT

B: META tags specified in this document

Note: The encoding parameter of xsl:output can specify the charset.
      Moreover, when the output method is HTML, this parameter 
      also generates an appropriate META tag.

2.10 CSS stylesheets which are stored at the server but have 
     not been transmitted to the client yet

B: @encoding in CSS stylesheets

C: the attribute "charset" of LINK elements of HTML 4.01; 
   the charset attribute of the stylesheet-linking PI.

G: Apache provides the directive AddCharset for configuration 
   files.

2.11 XSLT stylesheets which are stored at the server but have 
     not been transmitted to the client yet

B: the encoding declaration in XSLT stylesheets

C: the charset attribute of the stylesheet-linking PI.

G: Apache provides the directive AddCharset for configuration 
   files.

Note: Use of C is incorrect.

2.12 plain text stored at the server which are stored at the server
     but have not been transmitted to the client yet

G: Apache provides the directive AddCharset for configuration 
   files.

2.13 text typed in <textarea> or <input type="text"> of HTML and 
   transmitted via HTTP

A: Each part of a multipart/form-data should have the charset parameter.

E: As the charset of such text, browsers typically use the charset 
   of the HTML page.

Note: Unfortunately, the charset parameter for parts of multipart/form-data 
      is not widely implemented.

2.14 file uploaded by <input type="file"> of HTML

A: Each part of a multipart/form-data should have the charset parameter.

Note: Unfortunately, the charset parameter for parts of multipart/form-data 
      is not widely implemented.

2.15 Javascript, VBScript, etc. received from the HTTP server 

B: Script elements of HTML 4.01 provide the charset parameter.

D: the charset of the referring resource (typically HTML) 

F: Some browsers sniff the charset.

Note 1: Since there are no media types for such programming languages, 
        the charset parameter is not available.

Note 2: Since scripts in such programming languages contains 
        many ASCII characters and a small number of non-ASCII 
        characters, guessing almost always fails.

Note 3: The referring resource may be an HTML document 
        temporarily created by XSLT at the client side.  
        Even when users create everything in Shift_JIS, 
        creates UTF-16 HTML documents and assumes the referenced
        Javascript as UTF-16.

2.16 E-mail sent via SMTP 

A: the charset parameter of MIME entities,

F: content sniffing

Note: The encoding of E-mail received by and stored at the 
      SMTP client is up to the mail program.

2.17 JSP pages

G: The pageEncoding attribute of the page directive of JSP 1.2.

3. Misc

3.1 Database

Typically, web servers are front ends for database systems.  
Encoding issues will arise especially because legacy data 
are in legacy encodings.

3.2 Content negotiation

 We also have to consider content negotiation issues.  If 
configuration of the charset parameter is difficult, the 
same thing applies to configuration for negotiation.

- charset negotiation, 
- language negotiation,
- media type negotiation,
- CONNEG

4. Concluding remarks

Unfortunately, the encoding issue is complicated, inconsistent, and
incomprehensible.  Furthermore, different patch levels of WWW browsers
behave slightly differently.  As a result, it is extremely difficult
to internationalize Web applications.  Many WWW developers in Japan
suffer.

I agree that we have to change the current situation.  However, I also
think that we can easily impair the situation by shortsighted
"improvements".  I believe that we strongly need a long-term plan.

In my understanding, I18N people at IETF and the I18N WG have always
believed authoritative use of the charset parameter.  I believe that a
long-term solution is to design an XML-based language for WWW server
configuration and to reference to such configuration files from all
WWW technologies, and that we should avoid ad-hoc solutions wherever
possible.  I feel that further promotion of meta tags, @charset,
and encoding declarations merely makes the situation worse.

P.S.  I don't know which mailing list or working group is best 
for this discussion.  Probably, the I18N WG of W3C?

Cheers,

IBM Tokyo Research Lab / International University of Japan, Research Institute

MURATA Makoto (FAMILY Given)
-----------------------------------------------------------------------
[1] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0177.html