Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
From: MURATA Makoto <[email-masked]>
To: Chris Lilley <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 01 Dec 1999 10:59:14 +0900
List-Id: <ietf-xml-mime.imc.org>

Chris Lilley wrote:
> a) application/xml for xml files. All are required tobe well formed,as
> per the XML specification, otherwise it is a fatal error.
> b) application/xml-epe for external parsed entities which are not
> themselves well-formed instances

Point of clarification.   I have an external parsed entity.  I use 
it only as an external parsed entity.  Incidentally, it also parses 
as an XML document, but this was never intended.  Which one should 
I use?

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Tue, 30 Nov 1999 14:56:06 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: MURATA Makoto <[email-masked]>
CC: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

MURATA Makoto wrote:
> 
> Chris Lilley wrote:
> 
> > Yes, agreed.
> >
> > > We have two choices.  One is to use text/xml or application/xml even for
> > > external parsed entities.  The other is to use application/xml-epe
> > > only for those external parsed entities which are not XML documents.  I think
> > > that the latter is a complicated rule.
> >
> > The former also has complications, sinc eit means that application/xml
> > is "sometimes but nnot allways, well-formed xml". Since the terms valid
> > xml and well-formed xml are defined, but there is no defined term for
> > "stuf that is not wellformed", this is a problem. I think that this is
> > significant complication.
> 
> Well, I do not think this is complicated.  text/xml or application/xml
> means either external parsed entities or document entities.  This is simple.

And you may or may not be able to send the result to an XML parser. This
is not simple.
> 
> > Wheras for the latter option, it is simple. Is the epe itself a
> > well-formed document (this is easy to check mechanically). if yes, label
> > it as applicatio/xml. If no,label it as application/xml-epe (or whatever
> > term is chosen). This seems a simple, readily understod, and
> > machine-processable rule.
> 
> Suppose that you make an XML document which references to an external
> parsed entity.  You are very likely to inform the URI of that document
> to recipients but not that of the external parsed entity.  The external
> parsed entity will thus be fetched only from XML processors during
> parsing.  The fact that it is labelled as text/xml or application/xml
> does not cause any problems.

Provided that it is not also referenced directly from anywhare - which,
if it is also a well-formed document in its won right, it might be.

I think "security through obscurity" is a poor plan when it would be
better justto have unambiguous labelling in the first place.

> But the URI of the external parsed entity may become disclosed and some
> program (e.g., WWW robots) may fetch it as a MIME entity.  This program
> does not know if this MIME entity is an XML document or external parsed entity.
> If it parses as XML, it is an XML document. 

If it does not, then it is a fatal error. Hwever, according to your
proposal, it might still have been correctly labelled. According to
mine, it would have ben incorrectly labelled.

Its the principle of least surprise, really.

>  Even if it does not, it may or may
> not be an external parsed entity.  Is this a problem? 

Yes, clearly. You describe a process whereby the MIME type told you no
useful information abnout the requested resource. That sounds like a
problem to me.

> > > However, I have assumed that this issue is not very important since
> > > we should anyway avoid external parsed entities at all in the Internet.
> >
> > (Out of curioisity - why? In the context of HTTp/1.1 keep alive - its
> > not very expensive to fetch an epe once. If the epe is shared between
> > two or more documents, ther eis a net win even with HTTP/1.0)
> 
> Because different processors emit different outputs.  I personally think that
> in the Internet, we should never use (1) default values declared in external
> DTD subsets and external pararmeter entities, and (2) external parsed entities.

That is your choice if you don't want to use these features. But the
features are a legal part of the XML 1.0 spec and thus, any solution for
a MIME type or types from XML has to address all legal cases, not just
the ones you plan to use. I would have thought that was straightforward.
Or did you mean that, you do not plan to use themand you believe that
no-one else either uses or will use them? If that is the case, i can
readilly provide counter-examples.

> > Well, there is a move to define a category of "full infoset" parsers -
> > non validating, but which fetch epe's and external DTD subsets - which
> > deals with this problem.
> 
> I am not aware of such a move, and I have been a member of the XML Syntax WG.

Ask Tim Bray about it. He proposed the term, i believe.

> I am aware of a move for so-called "trivial subset".  But I do not know
> what will happen.

No, this is a move in the opposite direction. It recognises that the XML
spec defines a high ground (full validation) and a low ground (no
external DTD or entities fetched) but that in practice, there is a
valuable middle ground (no validation, but all external DTDs, external
parameter entities they refer to, and external parsed entities
referenced from the instance are fetched and used for such purposes as
attribute defaulting, declaration of ID, and suchlike. In practice, it
is this middle ground which is frequently that implemented by parsers
and which itwould be good to rely on for XML applications, yet there is
no defined name for this thing and thus no way to claim conformance to
it.

But this is not the forum for sucha topic, I apologise for the
digression.
> 
> > Regardless, it is legal now to use epes, and thus, a rule needs tobe
> > established for labellingthem; and the rule needs to cover all legal
> > cases, not just some frequently occurring ones.
> 
> I think that the current rule satisfies there criteria.  The only
> caveat is that (1) to know if an XML MIME entity is an XML document,
> you have to parse it, and (2) even if an  XML MIME entity does not
> parse as an XML document, you are not sure if it is an external
> parsed entity or not.

I have difficulty accepting these caveats, when there are better options
available. The sniffing procedure you describe, for one thing, seems to
mandate recovery from a fatal error.

> I do not think they are problems.  As for (1), you have to parse it anyway,
> since the MIME header may be wrong. 

That argument could be used, in the limit, to show that ther eis no need
for any MIME labelling at all. Its not a good direction to take.

> As for (2), are they any requirements to
> distinguish those text which may become external parsed entities, and those which
> cannot?  To me, what does not parse as an XML document is useless.

But to others, perhaps not - if it parses as an epe and is being used as
such.

So, to be clear, I am suggesting

a) application/xml for xml files. All are required tobe well formed,as
per the XML specification, otherwise it is a fatal error.
b) application/xml-epe for external parsed entities which are not
themselves well-formed instances

> By the way, if there is a strong reason for introducing a specialized
> media type for external parsed entities, we also need another media
> type for external *parameter* entities.

Yes. Which would then mean that -epe would be a bad choice of name ;-)
and another one should be sought. Perhaps -pars and -pram

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Tue, 30 Nov 1999 19:48:36 +0900
To: Chris Lilley <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

Chris Lilley wrote:

> Yes, agreed.
> 
> > We have two choices.  One is to use text/xml or application/xml even for
> > external parsed entities.  The other is to use application/xml-epe
> > only for those external parsed entities which are not XML documents.  I think
> > that the latter is a complicated rule. 
> 
> The former also has complications, sinc eit means that application/xml
> is "sometimes but nnot allways, well-formed xml". Since the terms valid
> xml and well-formed xml are defined, but there is no defined term for
> "stuf that is not wellformed", this is a problem. I think that this is
> significant complication.

Well, I do not think this is complicated.  text/xml or application/xml 
means either external parsed entities or document entities.  This is simple. 

> Wheras for the latter option, it is simple. Is the epe itself a
> well-formed document (this is easy to check mechanically). if yes, label
> it as applicatio/xml. If no,label it as application/xml-epe (or whatever
> term is chosen). This seems a simple, readily understod, and
> machine-processable rule.

Suppose that you make an XML document which references to an external 
parsed entity.  You are very likely to inform the URI of that document 
to recipients but not that of the external parsed entity.  The external 
parsed entity will thus be fetched only from XML processors during 
parsing.  The fact that it is labelled as text/xml or application/xml 
does not cause any problems.

But the URI of the external parsed entity may become disclosed and some 
program (e.g., WWW robots) may fetch it as a MIME entity.  This program 
does not know if this MIME entity is an XML document or external parsed entity.  
If it parses as XML, it is an XML document.  Even if it does not, it may or may 
not be an external parsed entity.  Is this a problem?  I do not see any 
problems.

> > However, I have assumed that this issue is not very important since
> > we should anyway avoid external parsed entities at all in the Internet.
> 
> (Out of curioisity - why? In the context of HTTp/1.1 keep alive - its
> not very expensive to fetch an epe once. If the epe is shared between
> two or more documents, ther eis a net win even with HTTP/1.0)

Because different processors emit different outputs.  I personally think that 
in the Internet, we should never use (1) default values declared in external 
DTD subsets and external pararmeter entities, and (2) external parsed entities.

> > If external parsed entities are used, different parses emit different
> > results.  (See "5. Conformance" of the XML recommendation
> > http://www.w3.org/TR/REC-xml#sec-conformance)
> > 
> > >For maximum reliability in interoperating between different XML processors,
> > >applications which use non-validating processors should not rely on any
> > >behaviors not required of such processors.
> 
> Well, there is a move to define a category of "full infoset" parsers -
> non validating, but which fetch epe's and external DTD subsets - which
> deals with this problem.

I am not aware of such a move, and I have been a member of the XML Syntax WG.  
I am aware of a move for so-called "trivial subset".  But I do not know 
what will happen.  

> Regardless, it is legal now to use epes, and thus, a rule needs tobe
> established for labellingthem; and the rule needs to cover all legal
> cases, not just some frequently occurring ones.

I think that the current rule satisfies there criteria.  The only 
caveat is that (1) to know if an XML MIME entity is an XML document, 
you have to parse it, and (2) even if an  XML MIME entity does not 
parse as an XML document, you are not sure if it is an external 
parsed entity or not.

I do not think they are problems.  As for (1), you have to parse it anyway, 
since the MIME header may be wrong.  As for (2), are they any requirements to 
distinguish those text which may become external parsed entities, and those which 
cannot?  To me, what does not parse as an XML document is useless.  

By the way, if there is a strong reason for introducing a specialized 
media type for external parsed entities, we also need another media 
type for external *parameter* entities.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Tue, 30 Nov 1999 10:44:15 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: MURATA Makoto <[email-masked]>
CC: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

MURATA Makoto wrote:
> 
> Chris Lilley wrote:
> >
> >
> > MURATA Makoto wrote:
> 
> > > In order to allow such an XML document, we have to use text/xml or application/xml
> > > for external parsed entities.
> >
> > No, that doesn't follow. You are driving a non-commutative relationship
> > backwards. Just because a well formed XML document can be used as an
> > external parsed entity (and can be labelled as text/xml or
> > application/xml), it does not follow that a non-well-formed thing can
> > also be so labelled. It should be labelled something else, like
> > application/xml-epe or whatever.
> 
> True.  The fact that some XML documents are also external parsed entities
> only implies that we cannot always use application/xml-epe for external
> parsed entities.

Yes, agreed.

> We have two choices.  One is to use text/xml or application/xml even for
> external parsed entities.  The other is to use application/xml-epe
> only for those external parsed entities which are not XML documents.  I think
> that the latter is a complicated rule. 

The former also has complications, sinc eit means that application/xml
is "sometimes but nnot allways, well-formed xml". Since the terms valid
xml and well-formed xml are defined, but there is no defined term for
"stuf that is not wellformed", this is a problem. I think that this is
significant complication.

Wheras for the latter option, it is simple. Is the epe itself a
well-formed document (this is easy to check mechanically). if yes, label
it as applicatio/xml. If no,label it as application/xml-epe (or whatever
term is chosen). This seems a simple, readily understod, and
machine-processable rule.

>  However, since few external parsed
> entities are also XML documents, one could argue that the latter is more
> realistic.

"few" is not sufficient for a algorithm.

> However, I have assumed that this issue is not very important since
> we should anyway avoid external parsed entities at all in the Internet.

(Out of curioisity - why? In the context of HTTp/1.1 keep alive - its
not very expensive to fetch an epe once. If the epe is shared between
two or more documents, ther eis a net win even with HTTP/1.0)

> If external parsed entities are used, different parses emit different
> results.  (See "5. Conformance" of the XML recommendation
> http://www.w3.org/TR/REC-xml#sec-conformance)
> 
> >For maximum reliability in interoperating between different XML processors,
> >applications which use non-validating processors should not rely on any
> >behaviors not required of such processors.

Well, there is a move to define a category of "full infoset" parsers -
non validating, but which fetch epe's and external DTD subsets - which
deals with this problem.

Regardless, it is legal now to use epes, and thus, a rule needs tobe
established for labellingthem; and the rule needs to cover all legal
cases, not just some frequently occurring ones.

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Tue, 30 Nov 1999 10:31:54 +0900
To: Chris Lilley <[email-masked]>
Cc: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

Chris Lilley wrote:
> 
> 
> MURATA Makoto wrote:

> > In order to allow such an XML document, we have to use text/xml or application/xml
> > for external parsed entities.
> 
> No, that doesn't follow. You are driving a non-commutative relationship
> backwards. Just because a well formed XML document can be used as an
> external parsed entity (and can be labelled as text/xml or
> application/xml), it does not follow that a non-well-formed thing can
> also be so labelled. It should be labelled something else, like
> application/xml-epe or whatever.

True.  The fact that some XML documents are also external parsed entities 
only implies that we cannot always use application/xml-epe for external 
parsed entities.

We have two choices.  One is to use text/xml or application/xml even for 
external parsed entities.  The other is to use application/xml-epe 
only for those external parsed entities which are not XML documents.  I think 
that the latter is a complicated rule.  However, since few external parsed 
entities are also XML documents, one could argue that the latter is more 
realistic.

However, I have assumed that this issue is not very important since 
we should anyway avoid external parsed entities at all in the Internet.  
If external parsed entities are used, different parses emit different 
results.  (See "5. Conformance" of the XML recommendation 
http://www.w3.org/TR/REC-xml#sec-conformance)

>For maximum reliability in interoperating between different XML processors, 
>applications which use non-validating processors should not rely on any 
>behaviors not required of such processors.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Mon, 29 Nov 1999 13:24:09 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: MURATA Makoto <[email-masked]>
CC: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

MURATA Makoto wrote:
> 
> Chris Lilley wrote:
> > [someone] wrote:
> > > The text/xml MIME type isn't limited to well-formed documents, but
> > > rather
> > > to XML entities (c.f. 2nd para under 3. XML Media Types of
> > > http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt); so the
> > > following:
> > >
> > >         Four score and seven years ago
> > >
> > > is a valid text/xml body, but an XML processor will burp cuz there's
> > > no root element.
> >
> > This is a good point, which had escaped my notice before. Certainly, it
> > should be a requirement that text/xml (or the preferred application/xml,
> > which avoids silly crufty rules about charsets) is always a well formed
> > XML instance, and things thatare now well formed XML use a different
> > type.
> 
> In XML 1.0, an XML document can also become an external parsed entity.

Of course - that is not the problem. Rather the converse - an external
parsed entity is not necessarily a well formed document.

> For example, consider an XML document as below:
> 
> <?xml version="1.0"?>
> <test/>

Thats fine, I have no issue with that instance being labelled as
text/xml or application/xml. But I do have a problem with this being so
labelled:

hello world

> In order to allow such an XML document, we have to use text/xml or application/xml
> for external parsed entities.

No, that doesn't follow. You are driving a non-commutative relationship
backwards. Just because a well formed XML document can be used as an
external parsed entity (and can be labelled as text/xml or
application/xml), it does not follow that a non-well-formed thing can
also be so labelled. It should be labelled something else, like
application/xml-epe or whatever.

Which would then mean that valid MIME types for an epe would be
application/xml-epe or application/xml depending on whether the epe was
a well-formed document init own right, or not.

> Dan Connolly wrote:
> >       Four score and seven years ago
> >
> > is a valid text/xml body, but an XML processor will burp cuz there's
> > no root element.
> 
> Yes.  It must report a fatal error.  Even if we disallowed the use of text/xml
> or application/xml for parsed entities, the world would not be free from incorrect
> documents and fatal errors.

It is one thing for such errors to occur through mistakes. It is another
to encourage or mandate such errors, through labelling things
inappropriately.

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Mon, 29 Nov 1999 14:44:21 +0900
To: Dan Connolly <[email-masked]>
Cc: Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

Dan Connolly wrote:
> 
> I read the archive now and then. I see lots of questions and
> few well-tested answers.
> 
> The whole problem of MIME types for XML with namespaces looks, to me, as
> hard as the whole software installation dependency problem; what's
> supposed
> to happen when I click on foo.xml on a wintel box? Given some list of
> installed
> linux RPM packages, how many do I have to install (and which ones)
> before my machine groks some new XML namespace?

Right.

Unfortunately, we still do not understand the interaction of namespaces, 
media types, fragment identifiers, XML-based sublanguages, dispatching, 
content negotiation, and CONNEG.  We need some solution, but nobody appears 
to have one.  The current I-D is merely a very small step.  

Dan Connolly wrote:
> Yes... but I hope folks aren't taking my silence as agreement to
> everything
> that is proposed in this forum.

Your silence means that you are not involved.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Mon, 29 Nov 1999 14:35:52 +0900
To: Dan Connolly <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: External parsed entities (Re: Inconsistency between IETF and W3C...)
Sender: [email-masked]

Chris Lilley wrote:
> > The text/xml MIME type isn't limited to well-formed documents, but
> > rather
> > to XML entities (c.f. 2nd para under 3. XML Media Types of
> > http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt); so the
> > following:
> > 
> >         Four score and seven years ago
> > 
> > is a valid text/xml body, but an XML processor will burp cuz there's
> > no root element.
> 
> This is s agood point, which had escaped my notice before. Certainly, it
> should be a requirement that text/xml (or the preferred application/xml,
> which avoids silly crufty rules about charsets) is always a well formed
> XML instance, and things thatare now well formed XML use a different
> type.

In XML 1.0, an XML document can also become an external parsed entity.  
For example, consider an XML document as below:

<?xml version="1.0"?>
<test/>

This can be used as an external parsed entity from another 
document as blow:

<?xml version="1.0"?>
<!DOCTYPE doc [
<!ENTITY parsedentity SYSTEM "http://hoge">
]>
<doc>&parsedentity;</doc>

which is equivalent to <doc><test/></doc>.

In order to allow such an XML document, we have to use text/xml or application/xml
for external parsed entities.

Dan Connolly wrote:
> 	Four score and seven years ago
> 
> is a valid text/xml body, but an XML processor will burp cuz there's
> no root element.

Yes.  It must report a fatal error.  Even if we disallowed the use of text/xml 
or application/xml for parsed entities, the world would not be free from incorrect 
documents and fatal errors.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Thu, 25 Nov 1999 07:35:13 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Dan Connolly <[email-masked]>
CC: MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

Dan Connolly wrote:
> 
> Chris Lilley wrote:
> >
> > Dan Connolly wrote:
> > > I don't care for that idea.
> >
> > Because ....
> 
> Sorry... because it encourages folks to extract structure from
> the subtype name, which is specified in the MIME spec as an atomic unit.
> It smells like a kludge.

Yes.

Its the sort of kludge that hapens when some folks would like a
multi-tier rather than two-tier name, or would like a new top level
type, or to use parameters; and when other folks have been dead set
against suchthings for years, and think that the existing two-tier
system is already too much.

A compromise, in other words.

Yes, it would formalise a particular meaning for the string "-xml" when
appearing at the end of a subtype.

> 
> While it suggests that
>         if a MIME type consists of XML documents, then it should be named
> */*-xml
> I wonder if it guarantees that
>         if a MIME type matches */*-xml then it consists of XML documents

I suspec that in this case,registration would not be allowed.
> 
> But reviewing it more closely, the kludge seems thorough:
> 
>         The registrar for the IETF tree will enforce this rule
>         for all XML-based media types created in the IETF tree.
> 
> Hmm... maybe not; this seems problematic:
> 
>         This convention will
>         allow applications that can process XML generically to detect that
>         the MIME entity is supposed to be an XML document, verify this
>         assumption by invoking some XML processor, and then process the XML
>         document accordingly.

Why is that problematic? Its says that applications which have xml
parsers can request any MIME type tha uses XML, and process the result
any way it wants to.

> The text/xml MIME type isn't limited to well-formed documents, but
> rather
> to XML entities (c.f. 2nd para under 3. XML Media Types of
> http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt); so the
> following:
> 
>         Four score and seven years ago
> 
> is a valid text/xml body, but an XML processor will burp cuz there's
> no root element.

Thi si s agood point, which had escaped my notice before. Certainly, it
should be a requirement that text/xml (or the preferred application/xml,
which avoids silly crufty rules about charsets) is always a well formed
XML instance, and things thatare now well formed XML use a different
type.
> 
> > Have you been following the IETF/W3C/IMC joint mailing list about MIME
> > types for XML?
> 
> I read the archive now and then. I see lots of questions and
> few well-tested answers.

;-)

> > That is where this -xml stuff originated from.
> 
> Yes... but I hope folks aren't taking my silence as agreement to
> everything
> that is proposed in this forum.
> 
> > I *do* like image/svg-xml, actually. It certainly better than either
> > image/svg or application/xml in terms of saying what the SVG file
> > contains.
> 
> I don't have any particular objection to image/svg-xml; it works
> as well as any other arbitrarily named subtype of image or
> application, as far as I'm concerned.

OK.

--
Chris

Date: Thu, 25 Nov 1999 00:01:23 -0600
From: Dan Connolly <[email-masked]>
To: Chris Lilley <[email-masked]>
CC: MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

Chris Lilley wrote:
> 
> Dan Connolly wrote:
[...]
> > I wonder why it's mandatory.
> 
> Because typically, CSS processors cannot deal with XSL stylesheets and
> XSL processors cannot deal with CSS stylesheets, and avioding
> downloading the thing if it is not a type you can process is highly
> desirable.

Yes, well... "typically" and "highly desirable" add up to SHOULD
or even STRONGLY RECOMMENDED; but not MUST.

MUST complete precludes content negotiation, where the client advertises
its capabilities when fetching the stylesheet, and the server
dynamically
chooses the best representation.

> > Anyway... the type="text/xml" in the XSLT spec example is saying:
> > "the stylesheet I'm pointing to is written in XML;
> 
> It would be more useful to say it is written in XS:L

yes, as discussed below...

> (is thatwhat you
> meant?)

no. I meant what I wrote.

> > This is a case where it might be useful to have a specific MIME
> > type for XSL(T),
> 
> There was one, last I looked.

I suggest you look again; I'm pretty certain there isn't one.

> > so that you could say:
> >
> >         "the stylesheet I'm pointing to is written in XSL; if you don't
> >         grok XSL, don't bother fetching it."
> 
> Exactly.
> 
> > "   draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
> >    and examples (application/mathml-xml, application/xsl-xml,
> >    application/rdf-xml, and image/svg-xml) are added."
> >
> > I don't care for that idea.
> 
> Because ....

Sorry... because it encourages folks to extract structure from
the subtype name, which is specified in the MIME spec as an atomic unit.
It smells like a kludge.

While it suggests that
	if a MIME type consists of XML documents, then it should be named
*/*-xml
I wonder if it guarantees that
	if a MIME type matches */*-xml then it consists of XML documents

But reviewing it more closely, the kludge seems thorough:

	The registrar for the IETF tree will enforce this rule
	for all XML-based media types created in the IETF tree.

Hmm... maybe not; this seems problematic:

	This convention will
	allow applications that can process XML generically to detect that
	the MIME entity is supposed to be an XML document, verify this
	assumption by invoking some XML processor, and then process the XML
	document accordingly.

The text/xml MIME type isn't limited to well-formed documents, but
rather
to XML entities (c.f. 2nd para under 3. XML Media Types of
http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt); so the
following:

	Four score and seven years ago

is a valid text/xml body, but an XML processor will burp cuz there's
no root element.

> Have you been following the IETF/W3C/IMC joint mailing list about MIME
> types for XML?

I read the archive now and then. I see lots of questions and
few well-tested answers.

The whole problem of MIME types for XML with namespaces looks, to me, as
hard as the whole software installation dependency problem; what's
supposed
to happen when I click on foo.xml on a wintel box? Given some list of
installed
linux RPM packages, how many do I have to install (and which ones)
before my machine groks some new XML namespace?

It seems worthwhile to brainstorm about designes and/or conventions and
try
them out; but it seems premature, to me, to standardize the ideas I've
seen.

> That is where this -xml stuff originated from.

Yes... but I hope folks aren't taking my silence as agreement to
everything
that is proposed in this forum.

> I *do* like image/svg-xml, actually. It certainly better than either
> image/svg or application/xml in terms of saying what the SVG file
> contains.

I don't have any particular objection to image/svg-xml; it works
as well as any other arbitrarily named subtype of image or
application, as far as I'm concerned.

-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/

From: "Larry Masinter" <[email-masked]>
To: "Chris Lilley" <[email-masked]>, "Dan Connolly" <[email-masked]>
Cc: "MURATA Makoto" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Inconsistency between IETF and W3C: XML fragments and media types
Date: Wed, 24 Nov 1999 21:31:27 PST
Importance: Normal
Sender: [email-masked]

> > My recollection is that type="..." is advisory: it helps user agents
> > optimize for the case that they don't know the relevant media type,
> > so they can skip fetching the thing. So it would be odd for it
> > to be mandatory. But sure enough! it is:
>
> > I wonder why it's mandatory.
> 
> Because typically, CSS processors cannot deal with XSL stylesheets and
> XSL processors cannot deal with CSS stylesheets, and avioding
> downloading the thing if it is not a type you can process is highly
> desirable.

This reasoning doesn't apply when the stylesheet is embedded, which
is the case we're complaining about. It's fine to supply a type
for an external stylesheet, it isn't fine to supply (or require
supplying) a type for embedded stylesheets that are referenced
via a fragment identifier.

Larry

Date: Thu, 25 Nov 1999 06:25:49 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Dan Connolly <[email-masked]>
CC: MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

Dan Connolly wrote:

> My recollection is that type="..." is advisory: it helps user agents
> optimize for the case that they don't know the relevant media type,
> so they can skip fetching the thing. So it would be odd for it
> to be mandatory. But sure enough! it is:
> 
> =======
> The following pseudo attributes are defined
> 
> href CDATA #REQUIRED
> type CDATA #REQUIRED
> title CDATA #IMPLIED
> media CDATA #IMPLIED
> charset CDATA #IMPLIED
> alternate (yes|no) "no"
> 
> The semantics of the pseudo-attributes are exactly as with <LINK
> REL="stylesheet"> in HTML 4.0
> =======
> 
> I wonder why it's mandatory.

Because typically, CSS processors cannot deal with XSL stylesheets and
XSL processors cannot deal with CSS stylesheets, and avioding
downloading the thing if it is not a type you can process is highly
desirable.

> Anyway.. regarding the semantics... the advisory stuff seems to have
> been
> lost somewhere:
> 
> ========
> http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#adef-type-A
> 
> type = content-type [CI]
>     When present, this attribute specifies the content type of a piece
> of
>     content, for example, the result of dereferencing a URI. Content
> types
>     are defined in [MIMETYPES].
> ========
> 
> The same text occurs at
> http://www.w3.org/TR/1999/PR-html40-19990824/struct/links.html#adef-type-A
> 
> Hmm... perhaps I can get this cleared up before HTML 4.01 becomes a
> recommendation.
> 
> Anyway... the type="text/xml" in the XSLT spec example is saying:
> "the stylesheet I'm pointing to is written in XML; 

It would be more useful to say it is written in XS:L (is thatwhat you
meant?)

> This is a case where it might be useful to have a specific MIME
> type for XSL(T), 

There was one, last I looked.

> so that you could say:
> 
>         "the stylesheet I'm pointing to is written in XSL; if you don't
>         grok XSL, don't bother fetching it."

Exactly.

> "   draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
>    and examples (application/mathml-xml, application/xsl-xml,
>    application/rdf-xml, and image/svg-xml) are added."
> 
> I don't care for that idea.

Because ....

Have you been following the IETF/W3C/IMC joint mailing list about MIME
types for XML? That is where this -xml stuff originated from.

I *do* like image/svg-xml, actually. It certainly better than either
image/svg or application/xml in terms of saying what the SVG file
contains.

--
Chris

Date: Wed, 24 Nov 1999 22:02:25 -0600
From: Dan Connolly <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

just responding to one point, for now...

MURATA Makoto wrote:
[...]
> > Anyway... the type="text/xml" in the XSLT spec example is saying:
> > "the stylesheet I'm pointing to is written in XML; if you don't
> > grok XML, don't bother fetching it." Given that interpretation,
> > I don't think it really matters that the pointer includes a fragid,
> > regardless of the sort of "type mismatch error" in givin a MIME
> > type for an XPointer node.
> 
> We have to agree on some interpretation.  In your interpreation, if
> a CSS stylesheet having the text/css media type is referenced by a
> PI with type="text/xsl", those user agents which do not know XSL
> don't fetch the CSS stylesheet.  Is this OK?

Yes. This is a risk that the author of the document who
writes type="text/xsl" must be prepared to accept.

This is why I find it odd that the type= attribute is mandatory;
the safe thing, in general, is to leave it out and force the
client to discover the media type of the stylesheet by fetching it.

-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/

From: MURATA Makoto <[email-masked]>
Date: Thu, 25 Nov 1999 11:56:32 +0900
To: James Clark <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

James Clark wrote:
> I'm not convinced there is an inconsistency here.  The style element in
> HTML has a required type attribute. Does that imply elements have MIME
> types? I don't think so. It's just (ab)using MIME types as identifiers
> for stylesheet languages.  

I personally think that this is an abuse and should be stopped.

> An alternative view is that the type
> pseudo-attribute on the PI is giving the MIME type of the complete
> resource, as an optimization to allow the resource not to be fetched if
> the MIME type cannot be handled.  On either view I don't see an
> inconsistency.

This is one interpretation of the type (pseudo) attribute.  We need 
some clarification.  I would like to hear opinions of the editors of HTML.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Thu, 25 Nov 1999 11:51:22 +0900
To: Dan Connolly <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

Dan,

Thank you for your prompt action.  I am hoping that all relevant 
specs will be clear about the relationship between fragment identifiers 
and media types.

> www-html-editor: I suggest that the definition of the "type"
> attribute on the HTML "link" element needs clarification.

Yes, indeed.

> MURATA Makoto wrote:
> > 
> > We are writing this mail as co-authors of Internet Draft which is
> > intended to replace RFC 2376.
> 
> Hmm... perhaps I've neglected some stuff that I should have read, but

There was an announcement of the IETF-XML-MIME ML in the XML CG on 
March 30.

	http://lists.w3.org/Archives/Member/w3c-xml-cg/1999Mar/0048.html

This announcement is linked from the XML Coordination Group 
(http://www.w3.org/XML/Group/) as the second item in the "Attention CG members:" 
section (at the very beginning).  Fortunately, Chris, Martin, and Bert 
have been involved in the discussion.  I have thought you are counting 
on them :-)

> My recollection is that type="..." is advisory: it helps user agents
> optimize for the case that they don't know the relevant media type,
> so they can skip fetching the thing. 

The semantics of the type attribute in HTML and the 
stylesheet-linking PI has to be clarified.
 
> Anyway... the type="text/xml" in the XSLT spec example is saying:
> "the stylesheet I'm pointing to is written in XML; if you don't
> grok XML, don't bother fetching it." Given that interpretation,
> I don't think it really matters that the pointer includes a fragid,
> regardless of the sort of "type mismatch error" in givin a MIME
> type for an XPointer node.

We have to agree on some interpretation.  In your interpreation, if 
a CSS stylesheet having the text/css media type is referenced by a 
PI with type="text/xsl", those user agents which do not know XSL 
don't fetch the CSS stylesheet.  Is this OK?

> This is a case where it might be useful to have a specific MIME
> type for XSL(T), so that you could say:
> 
> 	"the stylesheet I'm pointing to is written in XSL; if you don't
> 	grok XSL, don't bother fetching it."

When do we need specialized media types and when can we live with 
text/xml and application/xml?  There have been a lot of discussion 
in the IETF-XML-MIME ML.

Specialized media types often look convenient, but do you give 
up general-purpose XML processing such as XPointer and tree views 
(e.g., IE 5.0)?

Which media type should be used if an XML document contain XHTML and SVG, 
for example?  How do we interpret fragment identifiers for such documents? 
(People would like to reference to an SVG element by an XPointer and 
then address an SVG element via a SVG view specification [1].)

[1] http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG

We have agreed that specialized media types on XML will appear anyway.  
xml/*, */xml/*, */xml-*, */*;xml=1.0 have been proposed, but have 
not been agreed.

I see no consensus about interpretation of fragment identifiers. ;-(

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Thu, 25 Nov 1999 09:17:31 +0700
From: James Clark <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

MURATA Makoto wrote:
 
> There is an inconsistency between the IETF-XML-MIME ML and
> recently-published XSLT.
> 
> People at the IETF-XML-MIME ML believe that XML fragments (which
> are referenced by fragment identifiers) do not have media types.
> 
> However, the XSLT recommendation has an example stylesheet-linking PI,
> which specifies "text/xml" for an XML fragment.

I'm not convinced there is an inconsistency here.  The style element in
HTML has a required type attribute. Does that imply elements have MIME
types? I don't think so. It's just (ab)using MIME types as identifiers
for stylesheet languages.  An alternative view is that the type
pseudo-attribute on the PI is giving the MIME type of the complete
resource, as an optimization to allow the resource not to be fetched if
the MIME type cannot be handled.  On either view I don't see an
inconsistency.

James

Date: Wed, 24 Nov 1999 11:29:24 -0600
From: Dan Connolly <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

www-html-editor: I suggest that the definition of the "type"
attribute on the HTML "link" element needs clarification.

MURATA Makoto wrote:
> 
> We are writing this mail as co-authors of Internet Draft which is
> intended to replace RFC 2376.

Hmm... perhaps I've neglected some stuff that I should have read, but
I don't intend for any draft to replace RFC2376, and I'm
one of the contacts:

   "Person & email address for further information:

      Dan Connolly <[email-masked]>
      Murata Makoto (Family Given) <[email-masked]>"
	-- http://www.ietf.org/rfc/rfc2376.txt

>  One of us (Murata) is also a co-author of
> RFC 2376 (XML Media Types).  We both participate in the IETF-XML-MIME
> mailing list hosted by IMC.
> 
> There is an inconsistency between the IETF-XML-MIME ML and
> recently-published XSLT.

I don't believe so.

> People at the IETF-XML-MIME ML believe that XML fragments (which
> are referenced by fragment identifiers) do not have media types.

True.

Unfortunately, there are two things that might be meant by 'XML
fragments'. One(1) is the subject of:

	XML Fragment Interchange 
	http://www.w3.org/1999/06/WD-xml-fragment-19990630.html

This sort of XML Fragment is consistent with the existing
(RFC 2376) definiton of the text/xml MIME type: it's a
kind of XML entity, which is a sequence of characters that
has a standardized encoding as a sequence of bytes.

The other thing(2) that might be meant by 'XML fragments' is
for example, what http://example.net/foo.xml#fragID points
to. What that thing points to does *not* have a standardized
representation as a sequence of characters nor bytes, so
it can't have a MIME type.
It's a "node". c.f.

	XML Pointer Language (XPointer)
	http://www.w3.org/1999/07/WD-xptr-19990709

> However, the XSLT recommendation has an example stylesheet-linking PI,
> which specifies "text/xml" for an XML fragment.

I assume you're referring to
http://www.w3.org/TR/1999/REC-xslt-19991116#section-Embedding-Stylesheets

> However, the XSLT recommendation has an example stylesheet-linking PI,
> which specifies "text/xml" for an XML fragment.  Although James Clark
> agrees that fragments do not have media types, he was not able to
> remove "text/xml" from this example, since the "type" pseduo attribute
> is required by another recommendation "Associating Style Sheets with
> XML documents".

i.e. http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/

My recollection is that type="..." is advisory: it helps user agents
optimize for the case that they don't know the relevant media type,
so they can skip fetching the thing. So it would be odd for it
to be mandatory. But sure enough! it is:

=======
The following pseudo attributes are defined

href CDATA #REQUIRED
type CDATA #REQUIRED
title CDATA #IMPLIED
media CDATA #IMPLIED
charset CDATA #IMPLIED
alternate (yes|no) "no"

The semantics of the pseudo-attributes are exactly as with <LINK
REL="stylesheet"> in HTML 4.0
=======

I wonder why it's mandatory.

Anyway.. regarding the semantics... the advisory stuff seems to have
been
lost somewhere:

========
http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#adef-type-A

type = content-type [CI] 
    When present, this attribute specifies the content type of a piece
of
    content, for example, the result of dereferencing a URI. Content
types
    are defined in [MIMETYPES]. 
========

The same text occurs at
http://www.w3.org/TR/1999/PR-html40-19990824/struct/links.html#adef-type-A

Hmm... perhaps I can get this cleared up before HTML 4.01 becomes a
recommendation.

Anyway... the type="text/xml" in the XSLT spec example is saying:
"the stylesheet I'm pointing to is written in XML; if you don't
grok XML, don't bother fetching it." Given that interpretation,
I don't think it really matters that the pointer includes a fragid,
regardless of the sort of "type mismatch error" in givin a MIME
type for an XPointer node.

This is a case where it might be useful to have a specific MIME
type for XSL(T), so that you could say:

	"the stylesheet I'm pointing to is written in XSL; if you don't
	grok XSL, don't bother fetching it."

A namespace parameter on the text/xml media type would be another
way to convey that meaning.

>         (http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt)

What's the difference between this an RFC 2376 anyway? Ah:

"   draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
   and examples (application/mathml-xml, application/xsl-xml,
   application/rdf-xml, and image/svg-xml) are added."

I don't care for that idea.

-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/

From: MURATA Makoto <[email-masked]>
Date: Wed, 24 Nov 1999 23:31:26 +0900
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Inconsistency between IETF and W3C: XML fragments and media types
Sender: [email-masked]

We are writing this mail as co-authors of Internet Draft which is 
intended to replace RFC 2376.  One of us (Murata) is also a co-author of 
RFC 2376 (XML Media Types).  We both participate in the IETF-XML-MIME 
mailing list hosted by IMC.

There is an inconsistency between the IETF-XML-MIME ML and 
recently-published XSLT.

People at the IETF-XML-MIME ML believe that XML fragments (which 
are referenced by fragment identifiers) do not have media types.  

However, the XSLT recommendation has an example stylesheet-linking PI, 
which specifies "text/xml" for an XML fragment.  Although James Clark 
agrees that fragments do not have media types, he was not able to 
remove "text/xml" from this example, since the "type" pseduo attribute 
is required by another recommendation "Associating Style Sheets with 
XML documents".

If the XML syntax WG were active, we would ask them to publish an errata 
of the "Associating Style Sheets with XML documents" and then ask the 
XSL WG to publish an errata.  However, the XML Syntax WG does not exist 
any more and the XML Core WG is not active yet.

Since this issue is about cordination between IETF and W3C, we believe 
that we should request your attention.  We would appreciate it very much 
if you consider this issue and take some action which you think is appropriate.

Sincerely yours,

MURATA Makoto and Simon St.Laurent
Co-author of draft-murata-xml-01 
	(http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt)

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, "Dan Kohn" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Announcement of draft-murata-xml-01.txt
Date: Thu, 18 Nov 1999 08:01:25 PST
Importance: Normal
Sender: [email-masked]

> > Could you please explain why the MIME charset declaration must take
> > precedence over an explicit encoding declaration. 

In addition, there are (or at least have been) MIME processing
engines that do transcoding of text/* MIME bodies without reference
to any of the internal content. You might wish that it were disallowed,
but it isn't. Since it is possible that some agent might change a 
text/xml;charset=iso2022-jp to text/xml;charset=UTF8 without modifying
anything inside the body, being explicit about this possibility
seems like a good idea.

Larry

From: MURATA Makoto <[email-masked]>
Date: Thu, 18 Nov 1999 17:35:51 +0900
To: Dan Kohn <[email-masked]>
Cc: [email-masked]
Subject: Re: Announcement of draft-murata-xml-01.txt
Sender: [email-masked]

Dan,

> Looks good.  A few comments.

Thank you for your attention and comments.

> 
>    Omitting the charset parameter is NOT RECOMMENDED for text/xml. For
>    example, even if the contents of the XML MIME entity are UTF-16 or
>    UTF-8, or the XML MIME entity has an explicit encoding declaration,
>    XML and MIME processors must assume the charset is "us-ascii".
> 
> Could you please explain why the MIME charset declaration must take
> precedence over an explicit encoding declaration. 

RFC 2616 (Hypertext Transfer Protocol) is a draft standard of IETF.  It clearly 
says that the charset parameter is authoritative.  Probably, this I-D should 
explicitly reference to RFC 2616.  

> 3.4.1 Missing Charset
> 
>    Some HTTP/1.0 software has interpreted a Content-Type header without
>    charset parameter incorrectly to mean "recipient should guess."
>    Senders wishing to defeat this behavior MAY include a charset
>    parameter even when the charset is ISO-8859-1 and SHOULD do so when
>    it is known that it will not confuse the recipient.
> 
>    Unfortunately, some older HTTP/1.0 clients did not deal properly with
>    an explicit charset parameter. HTTP/1.1 recipients MUST respect the
>    charset label provided by the sender; and those user agents that have
>    a provision to "guess" a charset MUST use the charset from the
>    content-type field if they support that charset, rather than the
>    recipient's preference, when initially displaying a document. See
>    section 3.7.1.

You wrote:
> Also, since you use must, you might consider referencing RFC 2119.  

I believe that it is already referenced.

> Ordinal
> numbering of footnotes provides no additional useful information, while
> using [RDF] instead of [14] makes it clear (especially at second glance)
> what is being referenced.

This I-D is originally written in XML, and the DTD is specified by 
RFC 2629.  The footnote numbers are generated by the conversion software.

> You might consider internally referencing the text (e.g., the Encoding
> Considerations) from text/xml into application/xml rather than repeating it.
> That way, it would be completely clear what the divergence was rather than
> having to compare the text blocks.

This part of the specification is borrowed from RFC 2376 as is.  Probably, 
RFC 2376 should have been written in the manner you suggested.  But I do 
not think I should try to rewrite it now.  Such rewritting may cause 
inconsistencies.

> Would it make sense to add a note to application/xml-dtd explaining that
> DTDs are not valid XML documents?

Yes, it certainly does.  I will add such a note in the next version.

> 
> ESMTP does not equal 8-bit clean.  Every time you say "(e.g., ESMTP,
> 8BITMIME, or NNTP)" I think you mean to say (e.g., 8BITMIME ESMTP or NNTP).

Yes, you are very right.  RFC 2376 has the same problem. ;-)  I will 
fix this in the next version.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: Dan Kohn <[email-masked]>
To: [email-masked]
Subject: RE: Announcement of draft-murata-xml-01.txt
Date: Wed, 17 Nov 1999 12:58:53 -0800
Sender: [email-masked]

Looks good.  A few comments.

   Omitting the charset parameter is NOT RECOMMENDED for text/xml. For
   example, even if the contents of the XML MIME entity are UTF-16 or
   UTF-8, or the XML MIME entity has an explicit encoding declaration,
   XML and MIME processors must assume the charset is "us-ascii".

Could you please explain why the MIME charset declaration must take
precedence over an explicit encoding declaration.  Specifically, I'm
concerned about cases where users author XML documents which internally
specify UTF-8, but then upload them to HTTP servers that automatically (and
incorrectly) tag them as US-ASCII or as nothing (which has the same effect).
Why would the MIME charset declaration ever be more canonical or more
correct than the internal one?  I would suggest perhaps adding some language
to explain this decision.

Also, since you use must, you might consider referencing RFC 2119.  Ordinal
numbering of footnotes provides no additional useful information, while
using [RDF] instead of [14] makes it clear (especially at second glance)
what is being referenced.

You might consider internally referencing the text (e.g., the Encoding
Considerations) from text/xml into application/xml rather than repeating it.
That way, it would be completely clear what the divergence was rather than
having to compare the text blocks.

Would it make sense to add a note to application/xml-dtd explaining that
DTDs are not valid XML documents?

ESMTP does not equal 8-bit clean.  Every time you say "(e.g., ESMTP,
8BITMIME, or NNTP)" I think you mean to say (e.g., 8BITMIME ESMTP or NNTP).

		- dan
--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-519-7968  fax:+1-425-602-6223
http://www.dankohn.com

-----Original Message-----
From: MURATA Makoto [mailto:[email-masked]]
Sent: Wednesday, 1999-11-17 03:20
To: [email-masked]
Subject: Announcement of draft-murata-xml-01.txt

Simon St. Laurent and I co-authored an I-D for XML media types.  It 
is available at:

	http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt

On the basis of discussion in this ML (most notably Ned's comments),
this version shows when text/xml is more appropriate than application/xml 
and vice versa.  Non-XPointer fragment identifiers for XML vocabularies 
like SVG and SMIL requires further discussion.

Incidentally, the XSLT recommendation is published from W3C today.  It is 
available at:

	http://www.w3.org/TR/xslt

Although we have agreed that fragments do not have media types, "2.7
Embedding 
Stylesheets" of this recommendation uses "text/xml" for fragments.  Since
another 
recommendation of W3C, namely "Associating stylesheets with XML documents", 
already mandates the pseudo attribute "type" for stylesheet-linking PIs, 
XSLT had to specify something.  Comments?

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Wed, 17 Nov 1999 20:20:17 +0900
To: [email-masked]
Subject: Announcement of draft-murata-xml-01.txt
Sender: [email-masked]

Simon St. Laurent and I co-authored an I-D for XML media types.  It 
is available at:

	http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt

On the basis of discussion in this ML (most notably Ned's comments),
this version shows when text/xml is more appropriate than application/xml 
and vice versa.  Non-XPointer fragment identifiers for XML vocabularies 
like SVG and SMIL requires further discussion.

Incidentally, the XSLT recommendation is published from W3C today.  It is 
available at:

	http://www.w3.org/TR/xslt

Although we have agreed that fragments do not have media types, "2.7 Embedding 
Stylesheets" of this recommendation uses "text/xml" for fragments.  Since another 
recommendation of W3C, namely "Associating stylesheets with XML documents", 
already mandates the pseudo attribute "type" for stylesheet-linking PIs, 
XSLT had to specify something.  Comments?

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Tue, 09 Nov 1999 13:14:30 +0900
To: [email-masked], [email-masked]
From: "Martin J. Duerst" <[email-masked]>
Subject: MIME types for presence
Sender: [email-masked]

There is a mailing list discussing XML and MIME types:

To: [email-masked]
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Subscribe: <mailto:[email-masked]?body=subscribe>

I have cross-posted to that list.

Regards,   Martin.

At 19:41 1999/11/08 +0100, [email-masked] wrote:

> Date: Fri, 05 Nov 1999 16:18:52 +0100
> From: Christophe Vermeulen <[email-masked]>

> To: [email-masked]
> CC: [email-masked]
> Subject: Registration of MIME media type presence/xml
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> Dear sirs,
> 
> Recent discussions inside the Instant Messaging and Presence
> Protocol (IMPP) WG did show that the presence information
> may need the registration of a new MIME type. However, it
> is not clear to the group which MIME type should be pursued,
> in order to avoid future inter-operability problems.
> 
> In particular, while the WG wants to focus on only one format
> for presence, the prior existence of several Instant Messaging
> systems and protocols, that may use various mix of technologies
> and formattings such as attribute:value, vCard, ASN.1 or XML,
> brought some of us to think that asking for the registration of
> one subtype such as application/presence may be very shortsighted.
> 
> Could you tell me what your first impression is on such a
> draft request, as include below, so that the Workgroup may
> get a clearer idea on how to proceed further ?
> You may recognize that some parts of this draft are literally
> copied from the XML Media Types RFC, as XML is also proposed
> as the subtype in this draft proposal.
> 
> Please note that this mail and the following draft registration
> form are neither endorsed by the WorkGroup, nor a formal request
> to register the proposed MIME type, but only a personal request
> that may serve as basis for discussion.
> 
> Thanks in advance.
> 
> -- Begin Draft
> 
> 
> MIME media type name: presence
> 
> MIME subtype name: xml
> 
> Required parameters: none
> 
> Optional parameters: charset
> 
>        "UTF-8" [RFC-2279] is the recommended value, representing
>        the UTF-8 charset. If absent, US-ASCII has to be assumed as
>        of [RFC-2046].
> 
> Encoding considerations:
> 
>        This media type MAY be encoded as appropriate for the charset and
>        the capabilities of the underlying MIME transport. For 7-bit
>        transports, data in both UTF-8 and UTF-16 is encoded in quoted-
>        printable or base64.  For 8-bit clean transport (e.g., ESMTP,
>        8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
>        encoded.  For binary clean transports (e.g., HTTP or the upcoming
>        IMPP), no content-transfer-encoding is necessary.
> 
> Security considerations:
> 
>        To be provided.
> 
> Interoperability considerations:
> 
>        The major reason to request this registration as presence/xml,
>        instead of say, application/presence, is that many different
>        encodings may be used for presence information, e.g. based on
>        vCard or ASN.1. While the workgroup does neither intend to
> registrate
>        nor to design those alternatives for the moment being, their
> likelihood
>        in the future would create interoperability problems if this
>        registration was using a subtype of text or application instead.
> 
> Published specification: Not available yet.
> 
> Applications which use this media type:
> 
>        This media type is primarily intended to be transported on top
>        of the Instant Messaging and Presence Protocol, currently
>        being defined by the IETF IMPP WG. However, the adoption of
>        MIME as the encapsulation mechanism for presence information
>        was partly dictated by the wish to have a transport-independent
>        presence information specification, so that HTTP, SMTP or other
>        protocols may be used.
> 
> Additional information:
> 
>        Although no byte sequences can be counted on to always be present,
>        XML entities in ASCII-compatible charsets (including UTF-8) often
>        begin with hexadecimal 3C 3F 78 6D 6C ("<?xml").  For more
>        information, see Appendix F of [REC-XML].
> 
>        File extension(s): .xml
>        Macintosh File Type Code(s): "TEXT"
> 
> Person & email address to contact for further information:
> 
>        Christophe Vermeulen <[email-masked]>
> 
> 
> Intended usage: COMMON
> 
> Author/Change controller:
> 
>        To be provided
> 
> --  End Draft
> 
> Christophe.
> ------------------------------------------------------------------------
> Statutory Disclaimer: The above is not necessarily an Alcatel position.
> ------------------------------------------------------------------------
>            _             Christophe Vermeulen
>            V             Security Specialist, Service Deployment Project
>   .-----------------.    Alcatel Bell, Research Division DS9 F/C0
>   |  A L C A T E L  |    Fr. Wellesplein 1 - B-2018 Antwerp - Belgium
>   '-----------------'    Phone: +32 3 240 8942 - Fax: +32 3 240 8485
>                          mailto:[email-masked]
>                          http://www.rc.bel.alcatel.be/~meulenc (Intranet)
> ------------------------------------------------------------------------ 
> 
> 

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

From: MURATA Makoto <[email-masked]>
Date: Sun, 07 Nov 1999 19:11:30 +0900
To: <[email-masked]>
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

Mark Baker - Ottawa Consumer and Embedded Div. wrote:
> 
> No, but it's a lot worse (potentially) than just "won't work".
> If XHTML 1.0 is commonly delivered as */xml now, then future
> processors might very well be expected to understand, for
> example, <img src=""> even though that syntax would be
> deprecated in a future version of XML that included XLink.

I agree that this is very harmful.

> Not that this problem is insurmountable, but it probably is
> likely premature to allow it now before we consider the
> possible consequences.

In my understanding, XHTML 1.0 will be commonly delivered as text/html.  
The vote from Xerox asked omission of text/xml from XHTML.

Future versions of HTML will be delivered as something else, but it likely 
to be text/xml or application/xml.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Sun, 07 Nov 1999 19:08:11 +0900
To: [email-masked]
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

Simon St.Laurent wrote:
> I'd appreciate hearing opinions on this.  Apart from a preference for
> application/xml over text/xml, the more important issue for me is whether
> we should discuss 
> 
> 1) transmitting entities of text/html-xml identified as text/xml
> 2) transmitting entities of application/html-xml identified as application/xml

I do not think that we need more specialized media types for HTML.  text/html, 
text/xml, application/xml are good eonugh.

text/xhtml was discussed in this ML, and it was discussed heavily in the 
HTML WG.  In my understanding, there is a consensus that a new specilized 
media type for HTML does not solve any problems.  If we need something that works on 
existing browsers, we only have to use text/html.  If we need something that 
allows addition of other vocabularies (e.g., MathML and RDF), we already have 
text/xml and application/xml.

Murray Altheim wrote:
> In thinking about this more, I can see the value in defining a new
> media type 'text/xhtml' for the family iff we see that all applications
> within that space using the same infrastructure and mechanisms for 
> extensibility, so that any application within that space can predict
> how to read what has been extended and the implications of the
> extension. We *may* be able to solve that with document profiles.
> 
> But if it's still open season within 'text/xhtml' then we've only put 
> off the problem until later, and also compounded it by meaninglessly 
> fragmented the 'text/xml' space. If there is a solution for XML it 
> should be the same as for XHTML, and so my sense is that either the
> HTML WG's concept of document profiles is more usable generally in
> XML or we're duplicating what must also be done for XML.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: [email-masked] (Mark Baker - Ottawa Consumer and Embedded Div.)
Date: Fri, 5 Nov 1999 10:13:23 -0800
To: "Christopher R. Maden" <[email-masked]>, <[email-masked]>
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

>I don't understand why they were using text/xml in the first place.  First
>of all, XHTML is still HTML, and there is a well-defined media type for it:
>text/html.  But more importantly, XHTML is largely an exercise in
>pragmatism; it's intended to work in older browsers (cf. <br /> syntax) -
>text/html will work in older browsers, while text/xml won't.  Is this a
>hard decision?

No, but it's a lot worse (potentially) than just "won't work".
If XHTML 1.0 is commonly delivered as */xml now, then future
processors might very well be expected to understand, for
example, <img src=""> even though that syntax would be
deprecated in a future version of XML that included XLink.

Not that this problem is insurmountable, but it probably is
likely premature to allow it now before we consider the
possible consequences.

MB
--
Mark Baker                     Personal Apps Lead, Sun Microsystems
Ottawa, Ontario, CANADA   http://java.sun.com/products/personalapps

From: MURATA Makoto <[email-masked]>
Date: Fri, 05 Nov 1999 17:25:58 +0900
To: [email-masked]
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

Christopher R. Maden wrote:
> 
> But then why all the concern with backwards-compatible syntax like <br />
> and avoiding the XML declaration?  

Because the very first version of XHTML is designed to work on old browsers.  
Future versions are different.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Fri, 5 Nov 1999 00:13:18 -0800
To: [email-masked]
From: [email-masked] (Christopher R. Maden)
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

[MURATA Makoto]
>In my understanding, future XHTML will NOT work on old browsers and it
>will contain vocabularies other than XHTML (e.g., MathML, RDF, SMIL,
>something I would invent tomorrow).

But then why all the concern with backwards-compatible syntax like <br />
and avoiding the XML declaration?  Labeling it text/xml won't be
backwards-compatible, so there's no point in contorting the syntax.  It
just seems to me that if you pick a design restriction (backwards
compatible or not), then the decision about the media type follows
naturally, with little room for debate.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111

From: MURATA Makoto <[email-masked]>
Date: Fri, 05 Nov 1999 14:57:53 +0900
To: [email-masked]
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

Christopher R. Maden wrote:
> I don't understand why they were using text/xml in the first place.  First
> of all, XHTML is still HTML, and there is a well-defined media type for it:
> text/html.  But more importantly, XHTML is largely an exercise in
> pragmatism; it's intended to work in older browsers (cf. <br /> syntax) -
> text/html will work in older browsers, while text/xml won't.  Is this a
> hard decision?

In my understanding, future XHTML will NOT work on old browsers and it 
will contain vocabularies other than XHTML (e.g., MathML, RDF, SMIL, 
something I would invent tomorrow).  

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Wed, 03 Nov 1999 18:31:08 -0500
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]
Status: R

This came off XML-dev; I'm sure a lot of you have heard about it. I've cut
it down to the paragraph that's most directly relevant to MIME content
types, as it raises some important issues.

>From: "Tim Berners-Lee" <[email-masked]>
>To: "xml-dev" <[email-masked]>
>Subject: Fw: XHTML 1.0 returned to HTML WG
>Date: Wed, 3 Nov 1999 16:33:41 -0500
>X-Mailer: Microsoft Outlook Express 4.72.2106.4
>Sender: [email-masked]
>Reply-To: "Tim Berners-Lee" <[email-masked]>
>>
>> XHTML 1.0 is hereby sent back to the HTML working group for further work.
>>
>>A few respondents were also concerned about the use of the text/xml
>>media type for delivering xHTML, considering this to be "premature".
>>If a document conforming to XML 1.0 and XML Namespaces is not to be
>>considered "text/xml", this raises an important issue as to what is.

I'd appreciate hearing opinions on this.  Apart from a preference for
application/xml over text/xml, the more important issue for me is whether
we should discuss 

1) transmitting entities of text/html-xml identified as text/xml
2) transmitting entities of application/html-xml identified as application/xml

Does the -xml suffix described in the I-D permit such 'fallback'?  This is
where I wish things were more hierarchically structured.  It seems clear to
me that permitting transmission of text/html as text/xml is perverse, but
the use of the suffix seems like it might justify such usage.

The namespaces issues may carry more emotional/intellectual baggage, but I
think these content-type issues need to be addressed, here as well as in
the W3C.

Simon St.Laurent
XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Wed, 3 Nov 1999 16:22:59 -0800
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

What is the problem here?  The quoted response is inconclusive (sentence 1)
and a non sequitur (sentence 2).  Are you asking what MIME type XHTML
should use today?  after it is emitted as a Recommendation?  If so,
why not */xml?

regards, Terry Allen

Terry Allen                             
Advanced Technology Group               
Commerce One, Inc.
Walnut Creek, Calif.
tallen[at]sonic.net

Date: Wed, 3 Nov 1999 16:19:44 -0800
To: [email-masked]
From: [email-masked] (Christopher R. Maden)
Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

[Simon St. Laurent]
>>From: "Tim Berners-Lee" <[email-masked]>
>>>
>>> XHTML 1.0 is hereby sent back to the HTML working group for further work.
>>>
>>>A few respondents were also concerned about the use of the text/xml
>>>media type for delivering xHTML, considering this to be "premature".
>>>If a document conforming to XML 1.0 and XML Namespaces is not to be
>>>considered "text/xml", this raises an important issue as to what is.

[For text/* below, read 'text/* or application/*'.]

I don't understand why they were using text/xml in the first place.  First
of all, XHTML is still HTML, and there is a well-defined media type for it:
text/html.  But more importantly, XHTML is largely an exercise in
pragmatism; it's intended to work in older browsers (cf. <br /> syntax) -
text/html will work in older browsers, while text/xml won't.  Is this a
hard decision?

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111

Date: Wed, 03 Nov 1999 18:31:08 -0500
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Fwd: Fw: XHTML 1.0 returned to HTML WG
Sender: [email-masked]

This came off XML-dev; I'm sure a lot of you have heard about it. I've cut
it down to the paragraph that's most directly relevant to MIME content
types, as it raises some important issues.

>From: "Tim Berners-Lee" <[email-masked]>
>To: "xml-dev" <[email-masked]>
>Subject: Fw: XHTML 1.0 returned to HTML WG
>Date: Wed, 3 Nov 1999 16:33:41 -0500
>X-Mailer: Microsoft Outlook Express 4.72.2106.4
>Sender: [email-masked]
>Reply-To: "Tim Berners-Lee" <[email-masked]>
>>
>> XHTML 1.0 is hereby sent back to the HTML working group for further work.
>>
>>A few respondents were also concerned about the use of the text/xml
>>media type for delivering xHTML, considering this to be "premature".
>>If a document conforming to XML 1.0 and XML Namespaces is not to be
>>considered "text/xml", this raises an important issue as to what is.

I'd appreciate hearing opinions on this.  Apart from a preference for
application/xml over text/xml, the more important issue for me is whether
we should discuss 

1) transmitting entities of text/html-xml identified as text/xml
2) transmitting entities of application/html-xml identified as application/xml

Does the -xml suffix described in the I-D permit such 'fallback'?  This is
where I wish things were more hierarchically structured.  It seems clear to
me that permitting transmission of text/html as text/xml is perverse, but
the use of the suffix seems like it might justify such usage.

The namespaces issues may carry more emotional/intellectual baggage, but I
think these content-type issues need to be addressed, here as well as in
the W3C.

Simon St.Laurent
XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: MURATA Makoto <[email-masked]>
Date: Mon, 01 Nov 1999 18:03:42 +0900
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: Question: URI reference and media type in HTML/XML
Sender: [email-masked]

Gavin Thomas Nicol wrote:
> > 	<?xml-stylesheet type="text/xml" href="#style1"?>
> > 
> > We have agreed that fragments do not have media types.  What will  
> > happen to such media types combined with fragment identifiers?
> > Should they be simply ignored?
> 
> This is another case where the fragment inherits the media type.
> Again, the entire document must be fetched (as text/xml), and then
> the fragment identifier resplved in terms of that. With the example
> above, the fragment shoould be resolved in the resource containing the
> reference.

You are talking about how to locate a fragment by using frgament identifiers.  
Yes, we need to know the media type of the entire document.

I was actually talking about how can we tell if a located frament is XSLT 
or not.  We might have some other stylesheet languges which are expressed 
in the XML syntax.

Bert Bos wrote:
> What we don't know yet, is what type the style sheet is. If it is
> embedded, it is probably CSS or XSL, but how do we find out which?
> Heuristics will work in this case, of course, but that is not a
> scalable solution. It seems to me that we have no other place to put
> the type of the fragment than on the PI...

Yes, this is my point.  

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]