Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18590 for ietf-xml-mime-bks; Tue, 30 Nov 1999 17:54:25 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18586 for ; Tue, 30 Nov 1999 17:54:24 -0800 (PST) Received: by mx.fujixerox.co.jp; id KAA26621; Wed, 1 Dec 1999 10:56:46 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma026372; Wed, 1 Dec 99 10:56:08 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id KAA07082; Wed, 1 Dec 1999 10:56:07 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id KAA15297; Wed, 1 Dec 1999 10:56:46 +0900 (JST) Message-Id: <199912010159.AA03439@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 01 Dec 1999 10:59:14 +0900 To: Chris Lilley Cc: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) In-Reply-To: <3843D776.67E325A2@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA07455 for ietf-xml-mime-bks; Tue, 30 Nov 1999 05:54:47 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07451 for ; Tue, 30 Nov 1999 05:54:45 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA08214; Tue, 30 Nov 1999 08:56:07 -0500 Message-ID: <3843D776.67E325A2@w3.org> Date: Tue, 30 Nov 1999 14:56:06 +0100 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) References: <199911301048.AA03433@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA02438 for ietf-xml-mime-bks; Tue, 30 Nov 1999 02:44:30 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02430 for ; Tue, 30 Nov 1999 02:44:28 -0800 (PST) Received: by mx.fujixerox.co.jp; id TAA22272; Tue, 30 Nov 1999 19:46:46 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma021934; Tue, 30 Nov 99 19:46:26 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id TAA17212; Tue, 30 Nov 1999 19:45:30 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id TAA12901; Tue, 30 Nov 1999 19:46:07 +0900 (JST) Message-Id: <199911301048.AA03433@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 30 Nov 1999 19:48:36 +0900 To: Chris Lilley Cc: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) In-Reply-To: <38439C6F.B70ED3AE@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA29454 for ietf-xml-mime-bks; Tue, 30 Nov 1999 01:43:02 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29450 for ; Tue, 30 Nov 1999 01:43:01 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA21006; Tue, 30 Nov 1999 04:44:16 -0500 Message-ID: <38439C6F.B70ED3AE@w3.org> Date: Tue, 30 Nov 1999 10:44:15 +0100 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) References: <199911300131.AA03411@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06855 for ietf-xml-mime-bks; Mon, 29 Nov 1999 17:29:36 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06851 for ; Mon, 29 Nov 1999 17:29:34 -0800 (PST) Received: by mx.fujixerox.co.jp; id KAA01226; Tue, 30 Nov 1999 10:31:53 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma029780; Tue, 30 Nov 99 10:30:56 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id KAA10886; Tue, 30 Nov 1999 10:28:49 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id KAA10570; Tue, 30 Nov 1999 10:29:25 +0900 (JST) Message-Id: <199911300131.AA03411@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 30 Nov 1999 10:31:54 +0900 To: Chris Lilley Cc: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) In-Reply-To: <38427069.862478A8@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id EAA25787 for ietf-xml-mime-bks; Mon, 29 Nov 1999 04:22:03 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25783 for ; Mon, 29 Nov 1999 04:22:01 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA11204; Mon, 29 Nov 1999 07:24:09 -0500 Message-ID: <38427069.862478A8@w3.org> Date: Mon, 29 Nov 1999 13:24:09 +0100 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: Dan Connolly , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: External parsed entities (Re: Inconsistency between IETF and W3C...) References: <199911290535.AA03406@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: > > > 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA19521 for ietf-xml-mime-bks; Sun, 28 Nov 1999 21:39:27 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19517 for ; Sun, 28 Nov 1999 21:39:25 -0800 (PST) Received: by mx.fujixerox.co.jp; id OAA26035; Mon, 29 Nov 1999 14:41:41 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma025782; Mon, 29 Nov 99 14:41:16 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id OAA26028; Mon, 29 Nov 1999 14:41:16 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id OAA07244; Mon, 29 Nov 1999 14:41:50 +0900 (JST) Message-Id: <199911290544.AA03407@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 29 Nov 1999 14:44:21 +0900 To: Dan Connolly Cc: Chris Lilley , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types In-Reply-To: <383CD0B3.D9EC47EA@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id VAA19465 for ietf-xml-mime-bks; Sun, 28 Nov 1999 21:31:19 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19461 for ; Sun, 28 Nov 1999 21:31:16 -0800 (PST) Received: by mx.fujixerox.co.jp; id OAA22412; Mon, 29 Nov 1999 14:33:11 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma022182; Mon, 29 Nov 99 14:32:48 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id OAA24580; Mon, 29 Nov 1999 14:32:48 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id OAA07196; Mon, 29 Nov 1999 14:33:22 +0900 (JST) Message-Id: <199911290535.AA03406@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 29 Nov 1999 14:35:52 +0900 To: Dan Connolly Cc: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: External parsed entities (Re: Inconsistency between IETF and W3C...) In-Reply-To: <383CD8A1.FA750D70@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: This can be used as an external parsed entity from another document as blow: ]> &parsedentity; which is equivalent to . 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: murata.makoto@fujixerox.co.jp Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA01891 for ietf-xml-mime-bks; Wed, 24 Nov 1999 22:33:25 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01885 for ; Wed, 24 Nov 1999 22:33:23 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA21976; Thu, 25 Nov 1999 01:35:14 -0500 Message-ID: <383CD8A1.FA750D70@w3.org> Date: Thu, 25 Nov 1999 07:35:13 +0100 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Connolly CC: MURATA Makoto , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911241431.AA03351@archlute.fujixerox.co.jp> <383C2074.EEFC4B6E@w3.org> <383CC85D.11737D7F@w3.org> <383CD0B3.D9EC47EA@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA00953 for ietf-xml-mime-bks; Wed, 24 Nov 1999 21:59:24 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA00948 for ; Wed, 24 Nov 1999 21:59:23 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA19952; Thu, 25 Nov 1999 01:01:16 -0500 Message-ID: <383CD0B3.D9EC47EA@w3.org> Date: Thu, 25 Nov 1999 00:01:23 -0600 From: Dan Connolly X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Lilley CC: MURATA Makoto , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911241431.AA03351@archlute.fujixerox.co.jp> <383C2074.EEFC4B6E@w3.org> <383CC85D.11737D7F@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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/ Received: by ns.secondary.com (8.9.3/8.9.3) id VAA00589 for ietf-xml-mime-bks; Wed, 24 Nov 1999 21:30:06 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA00585 for ; Wed, 24 Nov 1999 21:30:05 -0800 (PST) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <61037(2)>; Wed, 24 Nov 1999 21:32:02 PST Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <99908>; Wed, 24 Nov 1999 21:31:44 PST From: "Larry Masinter" To: "Chris Lilley" , "Dan Connolly" Cc: "MURATA Makoto" , , , , , Subject: RE: Inconsistency between IETF and W3C: XML fragments and media types Date: Wed, 24 Nov 1999 21:31:27 PST Message-ID: <002001bf3706$52507800$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <383CC85D.11737D7F@w3.org> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA00480 for ietf-xml-mime-bks; Wed, 24 Nov 1999 21:24:04 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA00475 for ; Wed, 24 Nov 1999 21:24:03 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA17817; Thu, 25 Nov 1999 00:25:50 -0500 Message-ID: <383CC85D.11737D7F@w3.org> Date: Thu, 25 Nov 1999 06:25:49 +0100 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Connolly CC: MURATA Makoto , timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911241431.AA03351@archlute.fujixerox.co.jp> <383C2074.EEFC4B6E@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA26226 for ietf-xml-mime-bks; Wed, 24 Nov 1999 20:00:29 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26220 for ; Wed, 24 Nov 1999 20:00:27 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA12371; Wed, 24 Nov 1999 23:02:19 -0500 Message-ID: <383CB4D1.E7EBCBAD@w3.org> Date: Wed, 24 Nov 1999 22:02:25 -0600 From: Dan Connolly X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911250251.AA03360@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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/ Received: by ns.secondary.com (8.9.3/8.9.3) id SAA21803 for ietf-xml-mime-bks; Wed, 24 Nov 1999 18:52:27 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21799 for ; Wed, 24 Nov 1999 18:52:25 -0800 (PST) Received: by mx.fujixerox.co.jp; id LAA03233; Thu, 25 Nov 1999 11:54:20 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma002955; Thu, 25 Nov 99 11:53:33 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA10581; Thu, 25 Nov 1999 11:53:31 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id LAA87622; Thu, 25 Nov 1999 11:53:56 +0900 (JST) Message-Id: <199911250256.AA03362@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 25 Nov 1999 11:56:32 +0900 To: James Clark Cc: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types In-Reply-To: <383C9C3B.34DC7100@jclark.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA21506 for ietf-xml-mime-bks; Wed, 24 Nov 1999 18:47:11 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21501 for ; Wed, 24 Nov 1999 18:47:09 -0800 (PST) Received: by mx.fujixerox.co.jp; id LAA01430; Thu, 25 Nov 1999 11:49:01 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma001220; Thu, 25 Nov 99 11:48:21 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA09749; Thu, 25 Nov 1999 11:48:21 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id LAA87605; Thu, 25 Nov 1999 11:48:47 +0900 (JST) Message-Id: <199911250251.AA03360@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 25 Nov 1999 11:51:22 +0900 To: Dan Connolly Cc: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types In-Reply-To: <383C2074.EEFC4B6E@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id SAA21248 for ietf-xml-mime-bks; Wed, 24 Nov 1999 18:41:22 -0800 (PST) Received: from jclark.com (jclark@jclark.com [192.41.25.183]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21244 for ; Wed, 24 Nov 1999 18:41:20 -0800 (PST) Received: from jclark.com (p33-bkkSP12.C.loxinfo.net.th [203.146.65.153]) by jclark.com (8.8.5) id TAA11495; Wed, 24 Nov 1999 19:42:08 -0700 (MST) X-Authentication-Warning: jclark.com: Host p33-bkkSP12.C.loxinfo.net.th [203.146.65.153] claimed to be jclark.com Message-ID: <383C9C3B.34DC7100@jclark.com> Date: Thu, 25 Nov 1999 09:17:31 +0700 From: James Clark X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911241431.AA03351@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11038 for ietf-xml-mime-bks; Wed, 24 Nov 1999 09:27:49 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11012 for ; Wed, 24 Nov 1999 09:27:46 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA25891; Wed, 24 Nov 1999 12:29:19 -0500 Message-ID: <383C2074.EEFC4B6E@w3.org> Date: Wed, 24 Nov 1999 11:29:24 -0600 From: Dan Connolly X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Re: Inconsistency between IETF and W3C: XML fragments and media types References: <199911241431.AA03351@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Murata Makoto (Family Given) " -- 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 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/ Received: by ns.secondary.com (8.9.3/8.9.3) id GAA08678 for ietf-xml-mime-bks; Wed, 24 Nov 1999 06:27:23 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08674 for ; Wed, 24 Nov 1999 06:27:22 -0800 (PST) Received: by mx.fujixerox.co.jp; id XAA29210; Wed, 24 Nov 1999 23:29:00 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma029124; Wed, 24 Nov 99 23:28:25 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id XAA22237; Wed, 24 Nov 1999 23:28:25 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id XAA85471; Wed, 24 Nov 1999 23:28:49 +0900 (JST) Message-Id: <199911241431.AA03351@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 24 Nov 1999 23:31:26 +0900 To: timbl@w3.org Cc: murata.makoto@fujixerox.co.jp, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com Subject: Inconsistency between IETF and W3C: XML fragments and media types MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29386 for ietf-xml-mime-bks; Thu, 18 Nov 1999 08:00:32 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29381 for ; Thu, 18 Nov 1999 08:00:31 -0800 (PST) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52065(2)>; Thu, 18 Nov 1999 08:01:55 PST Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <97899>; Thu, 18 Nov 1999 08:01:38 PST From: "Larry Masinter" To: "MURATA Makoto" , "Dan Kohn" Cc: Subject: RE: Announcement of draft-murata-xml-01.txt Date: Thu, 18 Nov 1999 08:01:25 PST Message-ID: <001b01bf31de$2a4f3d00$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199911180835.AA03236@archlute.fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA17517 for ietf-xml-mime-bks; Thu, 18 Nov 1999 00:32:26 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17506 for ; Thu, 18 Nov 1999 00:32:21 -0800 (PST) Received: by mx.fujixerox.co.jp; id RAA08001; Thu, 18 Nov 1999 17:33:46 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma007703; Thu, 18 Nov 99 17:32:56 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id RAA11058; Thu, 18 Nov 1999 17:32:55 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id RAA61191; Thu, 18 Nov 1999 17:33:06 +0900 (JST) Message-Id: <199911180835.AA03236@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 18 Nov 1999 17:35:51 +0900 To: Dan Kohn Cc: ietf-xml-mime@imc.org Subject: Re: Announcement of draft-murata-xml-01.txt In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE0411BDD@tdmail2.teledesic.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12946 for ietf-xml-mime-bks; Wed, 17 Nov 1999 13:04:33 -0800 (PST) Received: from mgate-01.teledesic.com ([216.190.22.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12942 for ; Wed, 17 Nov 1999 13:04:31 -0800 (PST) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id ; Wed, 17 Nov 1999 13:05:44 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0411BDD@tdmail2.teledesic.com> From: Dan Kohn To: ietf-xml-mime@imc.org Subject: RE: Announcement of draft-murata-xml-01.txt Date: Wed, 17 Nov 1999 12:58:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 tel:+1-425-519-7968 fax:+1-425-602-6223 http://www.dankohn.com -----Original Message----- From: MURATA Makoto [mailto:murata.makoto@fujixerox.co.jp] Sent: Wednesday, 1999-11-17 03:20 To: ietf-xml-mime@imc.org 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00703 for ietf-xml-mime-bks; Wed, 17 Nov 1999 03:16:32 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00699 for ; Wed, 17 Nov 1999 03:16:30 -0800 (PST) Received: by mx.fujixerox.co.jp; id UAA29833; Wed, 17 Nov 1999 20:17:51 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma029756; Wed, 17 Nov 99 20:17:22 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id UAA10542 for ; Wed, 17 Nov 1999 20:17:22 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-179.greens.fxis.fujixerox.co.jp [131.221.160.179]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id UAA56740 for ; Wed, 17 Nov 1999 20:17:31 +0900 (JST) Message-Id: <199911171120.AA03203@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 17 Nov 1999 20:20:17 +0900 To: ietf-xml-mime@imc.org Subject: Announcement of draft-murata-xml-01.txt MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA10154 for ietf-xml-mime-bks; Mon, 8 Nov 1999 20:36:50 -0800 (PST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10150 for ; Mon, 8 Nov 1999 20:36:48 -0800 (PST) Received: from enoshima ([133.27.195.224]) by sh.w3.mag.keio.ac.jp (8.9.3/3.6W-W3C/Keio) with SMTP id NAA09318; Tue, 9 Nov 1999 13:38:06 +0900 (JST) Message-Id: <199911090438.NAA09318@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Tue, 09 Nov 1999 13:14:30 +0900 To: ietf-types@iana.org, ietf-xml-mime@imc.org From: "Martin J. Duerst" Subject: MIME types for presence In-Reply-To: <199911081841.TAA13365@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a mailing list discussing XML and MIME types: To: ietf-xml-mime@imc.org List-Archive: List-ID: List-Subscribe: I have cross-posted to that list. Regards, Martin. At 19:41 1999/11/08 +0100, owner-ietf-types@dokka.maxware.no wrote: > Date: Fri, 05 Nov 1999 16:18:52 +0100 > From: Christophe Vermeulen > To: ietf-types@iana.org > CC: impp@iastate.edu > Subject: Registration of MIME media type presence/xml > List-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 (" 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 > > > 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:Christophe.Vermeulen@alcatel.be > http://www.rc.bel.alcatel.be/~meulenc (Intranet) > ------------------------------------------------------------------------ > > #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA06132 for ietf-xml-mime-bks; Sun, 7 Nov 1999 02:08:39 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06128 for ; Sun, 7 Nov 1999 02:08:38 -0800 (PST) Received: by mx.fujixerox.co.jp; id TAA18549; Sun, 7 Nov 1999 19:09:09 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma018542; Sun, 7 Nov 99 19:08:44 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id TAA21228 for ; Sun, 7 Nov 1999 19:08:44 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-200.greens.fxis.fujixerox.co.jp [131.221.160.200]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id TAA12200 for ; Sun, 7 Nov 1999 19:08:32 +0900 (JST) Message-Id: <199911071011.AA02995@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Sun, 07 Nov 1999 19:11:30 +0900 To: Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG In-Reply-To: <199911051813.NAA25743@fastrack.Canada.Sun.COM> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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, 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06117 for ietf-xml-mime-bks; Sun, 7 Nov 1999 02:05:13 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06113 for ; Sun, 7 Nov 1999 02:05:07 -0800 (PST) Received: by mx.fujixerox.co.jp; id TAA18365; Sun, 7 Nov 1999 19:05:37 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma018334; Sun, 7 Nov 99 19:05:25 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id TAA21162 for ; Sun, 7 Nov 1999 19:05:25 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-200.greens.fxis.fujixerox.co.jp [131.221.160.200]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id TAA12195 for ; Sun, 7 Nov 1999 19:05:13 +0900 (JST) Message-Id: <199911071008.AA02994@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Sun, 07 Nov 1999 19:08:11 +0900 To: ietf-xml-mime@imc.org Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG In-Reply-To: <199911032331.SAA19553@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29373 for ietf-xml-mime-bks; Fri, 5 Nov 1999 10:13:17 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29369 for ; Fri, 5 Nov 1999 10:13:12 -0800 (PST) Received: from canadamail1.Canada.Sun.COM ([129.155.5.100]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20814; Fri, 5 Nov 1999 10:13:33 -0800 (PST) Received: from fastrack.Canada.Sun.COM (fastrack-1.Canada.Sun.COM [129.155.1.8]) by canadamail1.Canada.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id NAA19956; Fri, 5 Nov 1999 13:13:27 -0500 (EST) Received: from fastrack.Canada.Sun.COM by fastrack.Canada.Sun.COM (SMI-8.6/SMI-SVR4) id NAA25743; Fri, 5 Nov 1999 13:13:11 -0500 From: Mark.A.Baker@Canada.Sun.COM (Mark Baker - Ottawa Consumer and Embedded Div.) Message-Id: <199911051813.NAA25743@fastrack.Canada.Sun.COM> Date: Fri, 5 Nov 1999 10:13:23 -0800 To: "Christopher R. Maden" , Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >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.
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, 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 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12448 for ietf-xml-mime-bks; Fri, 5 Nov 1999 00:23:30 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA12444 for ; Fri, 5 Nov 1999 00:23:29 -0800 (PST) Received: by mx.fujixerox.co.jp; id RAA15387; Fri, 5 Nov 1999 17:23:49 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma014981; Fri, 5 Nov 99 17:23:14 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id RAA06869 for ; Fri, 5 Nov 1999 17:23:13 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-200.greens.fxis.fujixerox.co.jp [131.221.160.200]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id RAA04965 for ; Fri, 5 Nov 1999 17:22:57 +0900 (JST) Message-Id: <199911050825.AA02980@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 05 Nov 1999 17:25:58 +0900 To: ietf-xml-mime@imc.org Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG In-Reply-To: MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Christopher R. Maden wrote: > > But then why all the concern with backwards-compatible syntax like
> 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: murata.makoto@fujixerox.co.jp Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12393 for ietf-xml-mime-bks; Fri, 5 Nov 1999 00:13:43 -0800 (PST) Received: from themis.host4u.net (themis.host4u.net [216.71.64.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA12388 for ; Fri, 5 Nov 1999 00:13:41 -0800 (PST) Received: from [209.157.134.38] (pm3b-38.meer.net [209.157.134.38]) by themis.host4u.net (8.8.5/8.8.5) with SMTP id CAA23544 for ; Fri, 5 Nov 1999 02:13:45 -0600 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Nov 1999 00:13:18 -0800 To: ietf-xml-mime@imc.org From: crism@exemplary.net (Christopher R. Maden) Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [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
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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA07035 for ietf-xml-mime-bks; Thu, 4 Nov 1999 21:55:27 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07031 for ; Thu, 4 Nov 1999 21:55:26 -0800 (PST) Received: by mx.fujixerox.co.jp; id OAA15875; Fri, 5 Nov 1999 14:55:46 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma015753; Fri, 5 Nov 99 14:55:10 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id OAA10878 for ; Fri, 5 Nov 1999 14:55:09 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-200.greens.fxis.fujixerox.co.jp [131.221.160.200]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id OAA03380 for ; Fri, 5 Nov 1999 14:54:53 +0900 (JST) Message-Id: <199911050557.AA02972@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 05 Nov 1999 14:57:53 +0900 To: ietf-xml-mime@imc.org Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG In-Reply-To: MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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.
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: murata.makoto@fujixerox.co.jp Return-Path: Delivered-To: tallen@sonic.net Received: (qmail 9145 invoked from network); 3 Nov 1999 23:33:42 -0000 Received: from ns.secondary.com (208.184.76.39) by buzz.sonic.net with SMTP; 3 Nov 1999 23:33:42 -0000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17085 for ietf-xml-mime-bks; Wed, 3 Nov 1999 15:31:09 -0800 (PST) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17081 for ; Wed, 3 Nov 1999 15:31:07 -0800 (PST) Received: from thinkpad (slip129-37-221-41.ny.us.prserv.net [129.37.221.41]) by hesketh.net (8.9.3/8.9.3) with SMTP id SAA19553 for ; Wed, 3 Nov 1999 18:31:23 -0500 Message-Id: <199911032331.SAA19553@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 03 Nov 1999 18:31:08 -0500 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Fwd: Fw: XHTML 1.0 returned to HTML WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" >To: "xml-dev" >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: owner-xml-dev@ic.ac.uk >Reply-To: "Tim Berners-Lee" >> >> 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18088 for ietf-xml-mime-bks; Wed, 3 Nov 1999 16:22:49 -0800 (PST) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA18084 for ; Wed, 3 Nov 1999 16:22:46 -0800 (PST) Received: (qmail 26116 invoked from network); 4 Nov 1999 00:23:00 -0000 Received: from prop.sonic.net (208.201.224.193) by marine.sonic.net with SMTP; 4 Nov 1999 00:23:00 -0000 Received: from bolt.sonic.net (tallen@bolt [208.201.224.36]) by prop.sonic.net (8.8.8/8.8.5) with ESMTP id QAA25695; Wed, 3 Nov 1999 16:23:21 -0800 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id QAA31829; Wed, 3 Nov 1999 16:22:59 -0800 Date: Wed, 3 Nov 1999 16:22:59 -0800 From: Terry Allen Message-Id: <199911040022.QAA31829@bolt.sonic.net> To: ietf-xml-mime@imc.org, simonstl@simonstl.com Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18051 for ietf-xml-mime-bks; Wed, 3 Nov 1999 16:20:32 -0800 (PST) Received: from themis.host4u.net (themis.host4u.net [216.71.64.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18046 for ; Wed, 3 Nov 1999 16:20:31 -0800 (PST) Received: from [209.157.134.46] (pm3b-46.meer.net [209.157.134.46]) by themis.host4u.net (8.8.5/8.8.5) with SMTP id SAA18779 for ; Wed, 3 Nov 1999 18:20:21 -0600 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Nov 1999 16:19:44 -0800 To: ietf-xml-mime@imc.org From: crism@exemplary.net (Christopher R. Maden) Subject: Re: Fwd: Fw: XHTML 1.0 returned to HTML WG Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Simon St. Laurent] >>From: "Tim Berners-Lee" >>> >>> 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.
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 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17085 for ietf-xml-mime-bks; Wed, 3 Nov 1999 15:31:09 -0800 (PST) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17081 for ; Wed, 3 Nov 1999 15:31:07 -0800 (PST) Received: from thinkpad (slip129-37-221-41.ny.us.prserv.net [129.37.221.41]) by hesketh.net (8.9.3/8.9.3) with SMTP id SAA19553 for ; Wed, 3 Nov 1999 18:31:23 -0500 Message-Id: <199911032331.SAA19553@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 03 Nov 1999 18:31:08 -0500 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Fwd: Fw: XHTML 1.0 returned to HTML WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" >To: "xml-dev" >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: owner-xml-dev@ic.ac.uk >Reply-To: "Tim Berners-Lee" >> >> 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 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA16606 for ietf-xml-mime-bks; Mon, 1 Nov 1999 01:02:05 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA16602 for ; Mon, 1 Nov 1999 01:02:03 -0800 (PST) Received: by mx.fujixerox.co.jp; id SAA26466; Mon, 1 Nov 1999 18:01:50 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma026200; Mon, 1 Nov 99 18:01:05 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id SAA29381; Mon, 1 Nov 1999 18:01:04 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-200.greens.fxis.fujixerox.co.jp [131.221.160.200]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id SAA68609; Mon, 1 Nov 1999 18:01:15 +0900 (JST) Message-Id: <199911010903.AA02884@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 01 Nov 1999 18:03:42 +0900 To: Cc: jjc@jclark.com Subject: Re: Question: URI reference and media type in HTML/XML In-Reply-To: <000b01bf2206$3b05fea0$3d7370c6@eps.inso.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gavin Thomas Nicol wrote: > > > > > > 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: murata.makoto@fujixerox.co.jp