Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27715 for ietf-xml-mime-bks; Sun, 31 Oct 1999 17:07:43 -0800 (PST) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27711 for ; Sun, 31 Oct 1999 17:07:41 -0800 (PST) Received: from meta.inria.fr by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id CAA02700 for ; Mon, 1 Nov 1999 02:07:37 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host bb-pm.inria.fr [138.96.224.140] claimed to be meta.inria.fr Received: by meta.inria.fr (8.8.8/8.6.12) id WAA00558; Sun, 31 Oct 1999 22:04:28 +0100 From: Bert Bos MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 31 Oct 1999 16:04:26 -0500 (EST) To: Subject: RE: Question: URI reference and media type in HTML/XML In-Reply-To: <000b01bf2206$3b05fea0$3d7370c6@eps.inso.com> References: <199910290413.AA02824@archlute.fujixerox.co.jp> <000b01bf2206$3b05fea0$3d7370c6@eps.inso.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14364.36155.370522.205571@meta.inria.fr> Reply-To: bert@w3.org Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [> > = quote from MURATA Makoto] Gavin Thomas Nicol writes: > > > > > > 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. I'm not sure. Makoto poses a very interesting question. Either this example is an exception to the rule, or there is something wrong with (this use of) the xml-stylesheet PI. In this example, there is no sense in putting the type of the document in the PI, because we must have already established the type of the document in order to understand the PI. 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... Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/INRIA bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France Received: by ns.secondary.com (8.9.3/8.9.3) id FAA14372 for ietf-xml-mime-bks; Fri, 29 Oct 1999 05:05:49 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14367 for ; Fri, 29 Oct 1999 05:05:48 -0700 (PDT) Received: from endymion ([198.112.115.61]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id IAA13286 for ; Fri, 29 Oct 1999 08:03:49 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: Subject: RE: Question: URI reference and media type in HTML/XML Date: Fri, 29 Oct 1999 08:07:53 -0400 Message-ID: <000b01bf2206$3b05fea0$3d7370c6@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199910290413.AA02824@archlute.fujixerox.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > 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. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA04231 for ietf-xml-mime-bks; Thu, 28 Oct 1999 21:08:10 -0700 (PDT) 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 VAA04227 for ; Thu, 28 Oct 1999 21:08:09 -0700 (PDT) Received: by mx.fujixerox.co.jp; id NAA00738; Fri, 29 Oct 1999 13:11:24 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma000381; Fri, 29 Oct 99 13:10: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 NAA04349 for ; Fri, 29 Oct 1999 13:10:33 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-177.greens.fxis.fujixerox.co.jp [131.221.160.177]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id NAA01062 for ; Fri, 29 Oct 1999 13:10:37 +0900 (JST) Message-Id: <199910290413.AA02824@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 29 Oct 1999 13:13:10 +0900 To: ietf-xml-mime@imc.org Subject: Question: URI reference and media type in HTML/XML 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: HTML and XML provide language constructs that specify both URI references and media types. For example, an example (see below) in 2.7 "Embedding Stylesheets" of the XSLT PR [1] specifies a fragment identifier and "text/xml". 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? [1] http://www.w3.org/TR/xslt#section-Embedding-Stylesheets 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 VAA04204 for ietf-xml-mime-bks; Thu, 28 Oct 1999 21:05:33 -0700 (PDT) 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 VAA04199 for ; Thu, 28 Oct 1999 21:05:31 -0700 (PDT) Received: by mx.fujixerox.co.jp; id NAA29644; Fri, 29 Oct 1999 13:08:47 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma029277; Fri, 29 Oct 99 13:08:18 +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 NAA03889 for ; Fri, 29 Oct 1999 13:08:18 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-177.greens.fxis.fujixerox.co.jp [131.221.160.177]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id NAA01036 for ; Fri, 29 Oct 1999 13:08:22 +0900 (JST) Message-Id: <199910290410.AA02823@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 29 Oct 1999 13:10:55 +0900 To: ietf-xml-mime@imc.org Subject: Agreement: Fragments do not have 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: Having read recent discussion, I think that we reached an greement. Fragments do not have media types. 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 UAA03084 for ietf-xml-mime-bks; Thu, 28 Oct 1999 20:18:59 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA03077 for ; Thu, 28 Oct 1999 20:18:57 -0700 (PDT) Received: from endymion (modem_e [199.93.212.247]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id XAA06137 for ; Thu, 28 Oct 1999 23:16:56 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: Subject: RE: MIME types and fragment identifiers in HTML and XML Date: Thu, 28 Oct 1999 22:50:41 -0400 Message-ID: <007e01bf21bc$9f506e80$3d7370c6@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <38179A88.78791829@w3.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > That part is certainly true. To process the fragment (client-side > specialiser) one must first retrieve and dispatch the entire document, > according to it's media type as a whole, before then being > able to point to or position oneself at the particular fragment in question. Right. This is fundamentally different to sub-resource addressing. Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18092 for ietf-xml-mime-bks; Wed, 27 Oct 1999 17:33:23 -0700 (PDT) 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 RAA18088 for ; Wed, 27 Oct 1999 17:33:22 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10396; Wed, 27 Oct 1999 20:36:26 -0400 Message-ID: <38179A88.78791829@w3.org> Date: Thu, 28 Oct 1999 02:36:24 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: MURATA Makoto , ietf-xml-mime@imc.org Subject: Re: MIME types and fragment identifiers in HTML and XML References: <001301bf2023$ca3cf540$15d0000d@copper.parc.xerox.com> 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: Larry Masinter wrote: > > > I still have fundamental questions. Do fragments identified by fragment > > identifiers have media types? If so, who specifies the media types? > > We're making up things about fragment identifiers. The only existing > ones are the ones that work with HTML, Actually there are others, including ones that work with SMIL, SVG, and WebCGM. > and *those* certainly don't > identify things with media types. That part is certainly true. To process the fragment (client-side specialiser) one must first retrieve and dispatch the entire document, according to it's media type as a whole, before then being able to point to or position oneself at the particular fragment in question. -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id GAA04997 for ietf-xml-mime-bks; Wed, 27 Oct 1999 06:43:31 -0700 (PDT) Received: from mail.reutershealth.com (mail.reutershealth.com [204.243.9.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04993 for ; Wed, 27 Oct 1999 06:43:29 -0700 (PDT) Received: from reutershealth.com (IDENT:cowan@skunk.reutershealth.com [204.243.9.153]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id JAA15927; Wed, 27 Oct 1999 09:56:39 -0400 (EDT) Message-ID: <38170371.6A4F8578@reutershealth.com> Date: Wed, 27 Oct 1999 09:51:45 -0400 From: John Cowan Organization: Reuters Health Information X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: MIME types and fragment identifiers in HTML and XML References: <199910270226.AA02732@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: > > I still have fundamental questions. Do fragments identified by fragment > identifiers have media types? No. The purpose of a media type (type, subtype, and parameters) is to give just enough information to make a bunch of bytes (whether in a file or on a wire) dispatchable to the appropriate interpreter. To interpret a fragment, one has to have already determined the media type of the context. -- John Cowan http://www.reutershealth.com jcowan@reutershealth.com Schlingt dreifach einen Kreis vom dies / Schliess eurer Aug vor heiliger Schau Den er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00532 for ietf-xml-mime-bks; Wed, 27 Oct 1999 03:52:31 -0700 (PDT) Received: from odin.cromwellmedia.co.uk (odin.cromwellmedia.co.uk [194.164.44.244]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00528 for ; Wed, 27 Oct 1999 03:52:29 -0700 (PDT) Received: by odin.cromwellmedia.co.uk with Internet Mail Service (5.5.2448.0) id <4QN9ZRBW>; Wed, 27 Oct 1999 11:54:22 +0100 Message-ID: From: Miles Sabin To: ietf-xml-mime@imc.org Subject: RE: MIME types and fragment identifiers in HTML and XML Date: Wed, 27 Oct 1999 11:54:16 +0100 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry Masinter wrote, > We're making up things about fragment identifiers. The > only existing ones are the ones that work with HTML, > and *those* certainly don't identify things with media > types. > I don't think fragments can or should have media > types. Content-type media types in MIME are for > identifying the application semantics intended by an > entire message body, and not for denoting anything > about the types of components of that body. I agree that as things stand there are no media types associated with fragments. But, for all that, I think that Makoto's plea for something of this sort is reasonable: where a resource is composite and has a named constituent which could be treated as having a media type distinct from that of it's enclosing resource if taken in isolation, it'd be nice if that media type were available. One option to support this might be to extend media types to allow for composite types (tho' I don't really see how that could be made to work in practice). Another option might be an HTTP extension: either a 'fragment' GET, or more simply, a Fragment: request header. With the latter we might replace, GET /foo.xml#stylesheet HTTP/1.1 Host: foo.bar.com with, GET /foo.xml HTTP/1.1 Host: foo.bar.com Fragment: stylesheet and expect to get back an entity with with a text/xml-xsl (or whatever it is) media type. Hmm ... actully, looking at this, it strikes me that there might be some overlap with the CONNEG stuff? Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England Received: by ns.secondary.com (8.9.3/8.9.3) id TAA14263 for ietf-xml-mime-bks; Tue, 26 Oct 1999 19:31:46 -0700 (PDT) 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 TAA14259 for ; Tue, 26 Oct 1999 19:31:46 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <56509(1)>; Tue, 26 Oct 1999 19:34:44 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <99433>; Tue, 26 Oct 1999 19:34:36 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: MIME types and fragment identifiers in HTML and XML Date: Tue, 26 Oct 1999 19:34:27 PDT Message-ID: <001301bf2023$ca3cf540$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-reply-to: <199910270226.AA02732@archlute.fujixerox.co.jp> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I still have fundamental questions. Do fragments identified by fragment > identifiers have media types? If so, who specifies the media types? We're making up things about fragment identifiers. The only existing ones are the ones that work with HTML, and *those* certainly don't identify things with media types. If you point at an

This is a heading marked 'ab'

, what is the type of the fragment inside the H1? It's not 'text/html'. By extension, I don't think fragments have media types. That's why they're fragments. > You appear to argue that the type info specified by HTML or XML link > constructs may be used to override the media type of an HTML entity. As > for fragments, are you saying that the type info specified by HTML or XML > link constructs *always* provides the media type? I don't think fragments can or should have media types. Content-type media types in MIME are for identifying the application semantics intended by an entire message body, and not for denoting anything about the types of components of that body. Larry -- http://www.parc.xerox.com/masinter Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13918 for ietf-xml-mime-bks; Tue, 26 Oct 1999 19:21:40 -0700 (PDT) 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 TAA13914 for ; Tue, 26 Oct 1999 19:21:39 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA16562; Wed, 27 Oct 1999 11:24:44 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma016357; Wed, 27 Oct 99 11:24:15 +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 LAA27137 for ; Wed, 27 Oct 1999 11:24:15 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-177.greens.fxis.fujixerox.co.jp [131.221.160.177]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id LAA63191 for ; Wed, 27 Oct 1999 11:24:15 +0900 (JST) Message-Id: <199910270226.AA02732@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 27 Oct 1999 11:26:50 +0900 To: Subject: Re: MIME types and fragment identifiers in HTML and XML In-Reply-To: <000101bf1e4e$a0f42360$15d0000d@copper.parc.xerox.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: Larry, Thank you for your detailed comments and corrections. I still have fundamental questions. Do fragments identified by fragment identifiers have media types? If so, who specifies the media types? You appear to argue that the type info specified by HTML or XML link constructs may be used to override the media type of an HTML entity. As for fragments, are you saying that the type info specified by HTML or XML link constructs *always* provides the media type? 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 LAA08308 for ietf-xml-mime-bks; Sun, 24 Oct 1999 11:33:44 -0700 (PDT) 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 LAA08304 for ; Sun, 24 Oct 1999 11:33:43 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52290(3)>; Sun, 24 Oct 1999 11:36:33 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <97855>; Sun, 24 Oct 1999 11:36:23 PDT From: "Larry Masinter" To: "MURATA Makoto" Cc: Subject: RE: MIME types and fragment identifiers in HTML and XML Date: Sun, 24 Oct 1999 11:36:04 PDT Message-ID: <000101bf1e4e$a0f42360$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: <199910210739.AA02571@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: One more reference to include: the XPointer draft claims to define what fragment identifiers for XML content-type are supposed to be, but isn't referenced in your analysis http://www.w3.org/1999/07/WD-xptr-19990709 says: XPointer defines the meaning of the "selector" or "fragment identifier" portion of URIs that locate resources of MIME media types "text/xml" and "application/xml". > 1. URI and URI reference > > A URI does not have a fragment identifier, but a URI reference (as defined by > RFC 2396) may have a fragment identifier. (Note: HTML and XML very often > say "URI" when it should actually say "URI reference".). To be fair, the terminology has changed over time; the term "URI" is used ambiguously in various documents. > 1) URI > > An entity is returned by some protocol (here, the word "entity" is used as > in RFC 2616). The protocol should provide some mechanism for transmitting or > inferring media type. In HTTP and email, this is done explicitly with the > 'content-type' header. Not all resources identified by a URI have a way of obtaining an 'entity'. HTTP does, and so "http:" URLs can talk about entities being returned, but "mailto:" has no corresponding entity. It isn't necessary for there to be a 'protocol' that 'returns' entities, either; for example, the "cid" URL scheme makes reference to content of MIME messages without a specified protocol, but it would be possible to use a fragment identifier with a "cid" URL. Those URIs which don't have a way of obtaining entities also don't allow fragment identifiers. Your use of 'email' here is somewhat confusing, because there is often no appropriate URI to use for an email message. However, other protocols use MIME content-type for content identification, including IMAP and IPP. > 2) URI reference > > A URI is first constructed. I'm not sure "constructed" is the right word here, but I'm not sure what you meant. > An entity is returned or accessed interactively > by some protocol. The protocol should indicate the media type of the > entity. > Then, the user agent for this media type may extract or locate some fragment > of this entity by using the fragment identifier. I don't think "user agent" is the right term here; it is the "interpreter for this media type"; in some cases, the interpreter is part of a user agent, and in others, it's part of some other function. > The protocol does not indicate the media type for that fragment. You're saying that fragments don't have media types themselves, I think. > Thus, it > does not have content types, unless the fragment contains some other way of > specifying media types. (For example, RFC 2397, "data" URL scheme, provides > a way of including MIME content-type along with encoded data.) I think you're trying to argue that fragments don't, in general, have media types, even when there are some cases where compound objects have embedded data which *does* have a media type. The data URL scheme is certainly one kind of counterexample, but I'm not sure I would recommend it. > 2. Media types specified by HTML or XML language constructs > > HTML and XML provides many constructs which specifies both an URI reference > and a media type. The HTML and XML specifications are rather silent about > the intended semantics. > 1) URI > > One could argue that the specified media type is used when the protocol does > not indicate the content type of the entity. One could even argue that > the specified media type always override the content type indicated by the > protocol. (Note: Many implementations fail to indicate media types > correctly.) > > One could also argue that the specified media type is used to predict or > restrict the content type of the desired entity. That is, if an A > link contains a 'type' attribute and the resulting URI returns an > entity with a different content-type, then an error has occurred. > This isn't so different as getting a '404 not found'. Something > happened which wasn't expected. There are various ways of recovering, > but any attempt to override one piece of MIME data with something > that's "fresher" and more authoritative seems wrong. I think I sent something like this earlier, but it came out wrong. The problem when you have conflicting sources of information ("what is the MIME type of this data") that you *do* want to select the one that is fresher and more authoritative, but that there are cases where the data associated with the URI itself is likely to be more authoritative (e.g., with some FTP sources) and other cases where the data associated with the entity is more authoritative (e.g., with a recently maintained HTTP server.) This is a design issue with HTML and (I suppose) XLink. Perhaps there needs to be more than one way of associating a content-type with a URI, one of which says "override content-type" and another of which says "default content-type". Note that even MIME-compliant protocols that normally associate content-type with data can disclaim responsibility for it by, say, using content-type: application/octet-stream. We might have some theory of overriding, where text/xml would override application/octet-stream and text/html would override text/xml (specific overrides generic). > 2) URI reference > > If a construct in HTML or XML specifies a URI reference containing a fragment > identifier, the construct also specifies a media type, and the protocol > indicates the content type of the entity, what will happen? > > One could argue that the specified media type is used for the desired > fragment, unless the fragment contains some other way of specifying media types. I don't understand this case ('the fragment contains some other way...') > One could also argue that the fragment must indicate the media type and that > it must coincide with the media type specified by the HTML or XML > construct (fragment). This is unreasonable, since it isn't compatible with normal usage where fragments are used without explicit media type. > If the fragment does not explicitly specify the same media type, an error has > occurred. Perhaps you mean "if the fragment explicity specifies a media type but it isn't the same", since not specifying a media type shouldn't be an error. I believe that there is a generic form of a "fragment" which is "an uninterpreted name", and that we should expect that most media types that allow fragments have a way of looking up named components. This would correspond to names in HTML and IDs in XML. We should expect that other media types that have fragments will also define named components, too. I'd like this definition of fragment identifiers to be more specific about encoding, though; currently it is common practice to use spaces in fragment identifiers, for example, rather than %20 encoding them. > [1] HTML 4.0 > > (http://www.w3.org/TR/html40/types.html#h-6.7) > > > 6.7 Content types (MIME types) > > > > Note. A "media type" (defined in [RFC2045] and [RFC2046]) specifies > > the nature of a linked resource. This specification employs the term > > "content type" rather than "media type" in accordance with current > > usage. Furthermore, in this specification, "media type" may refer to > > the media where a user agent renders a document. > > > > This type is represented in the DTD by %ContentType;. > > > > Content types are case-insensitive. > > > > Examples of content types include "text/html", "image/png", > > "image/gif", "video/mpeg", "audio/basic", "text/tcl", > > "text/javascript", and "text/vbscript". For the current list of > > registered MIME types, please consult [MIMETYPES]. > > Note. The content type "text/css", while not currently registered with > > IANA, should be used when the linked resource is a [CSS1] style sheet. > http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.3 I've been trying to deal with issues around this paragraph in the HTML working group; certainly, since "text/css" has been registered, this paragraph should change. Received: by mail.imc.org (8.9.3/8.9.3) id DAA12110 for ietf-xml-mime-bks; Fri, 22 Oct 1999 03:01:51 -0700 (PDT) Received: from matrix3 (zoovan-nas2-18.zoolink.com [216.94.40.146]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA12090 for ; Fri, 22 Oct 1999 03:01:48 -0700 (PDT) From: jmaxwell8@hotmail.com Received: from mail pickup service by matrix3 with Microsoft SMTPSVC; Fri, 22 Oct 1999 02:55:08 -0700 To: Subject: Keep in touch. Date: Fri, 22 Oct 1999 02:55:08 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <07aec08550916a9MATRIX3@matrix3> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Want to keep in touch with old friends from school? The Gradfinder website is the perfect place to do just that. On Gradfinder you can search for friends, add your current contact info, a current photo, and details about what you are up to these days. You can update your info at any time after that. All changes happen immediately. There are also message boards you can use to help organize reunions. You can use our photo album wizard to create online albums to share with friends and family. There are currently over 100,000 schools listed from grade 1 to university from 60 countries around the world. This service is free so check it out! This site can be found at: http://www.gradfinder.com Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id AAA19775 for ietf-xml-mime-bks; Thu, 21 Oct 1999 00:35:00 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA19768 for ; Thu, 21 Oct 1999 00:34:58 -0700 (PDT) Received: by mx.fujixerox.co.jp; id QAA00717; Thu, 21 Oct 1999 16:37:35 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma000601; Thu, 21 Oct 99 16:37:01 +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 QAA11348 for ; Thu, 21 Oct 1999 16:37:00 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-177.greens.fxis.fujixerox.co.jp [131.221.160.177]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id QAA19413 for ; Thu, 21 Oct 1999 16:36:49 +0900 (JST) Message-Id: <199910210739.AA02571@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 21 Oct 1999 16:39:31 +0900 To: Subject: MIME types and fragment identifiers in HTML and XML 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: Here is my understanding of MIME types and fragment identifiers. I think that the semantics of "type" attribute in HTML 4.0 [1] and "Associating Style Sheets with XML documents " [2] are unclear. 1. URI and URI reference A URI does not have a fragment identifier, but a URI reference (as defined by RFC 2396) may have a fragment identifier. (Note: HTML and XML very often say "URI" when it should actually say "URI reference".). 1) URI An entity is returned by some protocol (here, the word "entity" is used as in RFC 2616). The protocol should provide some mechanism for transmitting or inferring media type. In HTTP and email, this is done explicitly with the 'content-type' header. 2) URI reference A URI is first constructed. An entity is returned or accessed interactively by some protocol. The protocol should indicate the media type of the entity. Then, the user agent for this media type may extract or locate some fragment of this entity by using the fragment identifier. The protocol does not indicate the media type for that fragment. Thus, it does not have content types, unless the fragment contains some other way of specifying media types. (For example, RFC 2397, "data" URL scheme, provides a way of including MIME content-type along with encoded data.) 2. Media types specified by HTML or XML language constructs HTML and XML provides many constructs which specifies both an URI reference and a media type. The HTML and XML specifications are rather silent about the intended semantics. 1) URI One could argue that the specified media type is used when the protocol does not indicate the content type of the entity. One could even argue that the specified media type always override the content type indicated by the protocol. (Note: Many implementations fail to indicate media types correctly.) One could also argue that the specified media type is used to predict or restrict the content type of the desired entity. That is, if an A link contains a 'type' attribute and the resulting URI returns an entity with a different content-type, then an error has occurred. This isn't so different as getting a '404 not found'. Something happened which wasn't expected. There are various ways of recovering, but any attempt to override one piece of MIME data with something that's "fresher" and more authoritative seems wrong. 2) URI reference If a construct in HTML or XML specifies a URI reference containing a fragment identifier, the construct also specifies a media type, and the protocol indicates the content type of the entity, what will happen? One could argue that the specified media type is used for the desired fragment, unless the fragment contains some other way of specifying media types. One could also argue that the fragment must indicate the media type and that it must coincide with the media type specified by the HTML or XML construct (fragment). If the fragment does not explicitly specify the same media type, an error has occurred. [1] HTML 4.0 (http://www.w3.org/TR/html40/types.html#h-6.7) > 6.7 Content types (MIME types) > > Note. A "media type" (defined in [RFC2045] and [RFC2046]) specifies > the nature of a linked resource. This specification employs the term > "content type" rather than "media type" in accordance with current > usage. Furthermore, in this specification, "media type" may refer to > the media where a user agent renders a document. > > This type is represented in the DTD by %ContentType;. > > Content types are case-insensitive. > > Examples of content types include "text/html", "image/png", > "image/gif", "video/mpeg", "audio/basic", "text/tcl", > "text/javascript", and "text/vbscript". For the current list of > registered MIME types, please consult [MIMETYPES]. > > Note. The content type "text/css", while not currently registered with > IANA, should be used when the linked resource is a [CSS1] style sheet. http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.3 > 14.2.3 Header style information: the STYLE element > > > %i18n; -- lang, dir, for use with title -- > type %ContentType; #REQUIRED -- content type of style language -- > media %MediaDesc; #IMPLIED -- designed for use with these media -- > title %Text; #IMPLIED -- advisory title -- > > > > > Start tag: required, End tag: required > > Attribute definitions > > type = content-type [CI] > > This attribute specifies the style sheet language of the element's > contents and overrides the default style sheet language. The style > sheet language is specified as a content type (e.g., > "text/css"). Authors must supply a value for this attribute; there is > no default value for this attribute. > [2] Associating Style Sheets with XML documents http://www.w3.org/TR/xml-stylesheet/ >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, with the exception of the alternate >pseudo-attribute. If alternate="yes" is specified, then the processing >instruction has the semantics of >instead of . Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id VAA17244 for ietf-xml-mime-bks; Sun, 17 Oct 1999 21:20:22 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA17234 for ; Sun, 17 Oct 1999 21:20:11 -0700 (PDT) Received: from endymion (modem_e [199.93.212.247]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id AAA18621; Mon, 18 Oct 1999 00:16:50 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'Chris Lilley'" , "'Larry Masinter'" Cc: "'Bert Bos'" , Subject: RE: Media types for XSL stylesheets Date: Sun, 17 Oct 1999 10:37:52 -0400 Message-ID: <000301bf191f$a030b350$9f17ae92@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <380381D1.E9D277B0@w3.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Who is the "vendor" of TCL? Scriptics. Received: by mail.imc.org (8.9.3/8.9.3) id VAA17243 for ietf-xml-mime-bks; Sun, 17 Oct 1999 21:20:13 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA17236 for ; Sun, 17 Oct 1999 21:20:11 -0700 (PDT) Received: from endymion (modem_e [199.93.212.247]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id AAA18597; Mon, 18 Oct 1999 00:16:31 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'MURATA Makoto'" , "'James Clark'" Cc: Subject: RE: Media types for XSL stylesheets Date: Sun, 17 Oct 1999 10:35:54 -0400 Message-ID: <000201bf191f$946e7250$9f17ae92@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <199910120705.AA02431@archlute.fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think that text/xml is not appropriate for XSLT since an > XSLT stylesheet > is not readable by casual users. > > [1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html Agreed. In addition, it is truly application-specific. Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id LAA08018 for ietf-xml-mime-bks; Tue, 12 Oct 1999 11:43:53 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA08014 for ; Tue, 12 Oct 1999 11:43:51 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29102; Tue, 12 Oct 1999 14:45:40 -0400 Message-ID: <380381D1.E9D277B0@w3.org> Date: Tue, 12 Oct 1999 20:45:37 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: Bert Bos , ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets References: <004001bf14d6$00150e40$c3d2000d@copper.parc.xerox.com> 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: Larry Masinter wrote: > My guess is that the registration would push back and suggest > registering them as "application" and possibly as faceted > "application/vnd.ms-vbscript", "application/vnd.tcl". Who is the "vendor" of TCL? > > > That leads to another issue: MIME type are not only used to get the > > interpretation started, but also to negotiate capabilities between a > > client and a server, e.g., in HTTP. In that context, sending a > > document with embedded XSL to a client that has indicated not being > > able to handle XSL is not very smart. True, although if it couldn't, the server would need to be smart to strip out the XSL (or indeed, to pre-process it on the server). This is where a reference rather than explicit content can be helpful - the script is requested in a separate request, and can be content negotiated. > MIME types aren't used effectively for HTTP negotiation; the use > of "Accept" headers has proven unwieldy. Yes, the early browsers didn't "get it" and sent the same string regardless of the request; the adoption of plug-in architectures did not produce any change in the Accept header, and more imporantly, the bulk of content authors are no longer in control of the servers they use, and so cannot add new MIME types or configuration options such as qs factors. Which, of course, not only calls into question coneg but also the use of MIME types itself. However, conneg based on Accept can still be useful today - it is more robust and scalable than recognising user agent identification strings, for example - and is used on the W3C site to send a PNG (if the client can accept it) or a GIF (if not). > We're still looking for > some other kind of capability/profile mechanism that would be suitable. > The CONNEG work and the continuing CCPP work in W3C will hopefully > yield a workable mechanism. Yes. One thing that would help would be a standard resource description which could be uploaded (users can still upload files) along with the actual content, and would affect only the listed resources. That might allow more flexible content negotiation without server reconfiguration, cgi scripts, or servlets. > > In other words, that document with its embedded XSL needs not just a > > MIME type for its first byte, but also a description (a "profile") of > > the other capabilities a client needs. That would be something like a > > CC/PP( http://www.w3.org/Mobile/CCPP/ ) profile, I assume, and inside > > that there *would* be an entry that says "application/xsl" (or whatever > > the MIME type will be). > > It isn't necessary to have a MIME type to talk about a capability. > That is, you could have a feature which is "able to interpret XSL style" > without registering "application/xsl". True. There are other alternatives to MIME types. > The recognition that MIME labelling is insufficient for fine-grained > description of recipient capabilities or document profiles was the > foundation of the CONNEG work; it seems likely that CCPP can use the > CONNEG registry and a superset of the semantics of CONNEG feature > sets, although likely with an XML (RDF?) based syntax for feature sets. > > See http://www.imc.org/ietf-medfree Thanks for the reference. Interesting work. -- Chris Received: by mail.imc.org (8.9.3/8.9.3) id KAA06350 for ietf-xml-mime-bks; Tue, 12 Oct 1999 10:18:03 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.imc.org (8.9.3/8.9.3) with SMTP id KAA06345 for ; Tue, 12 Oct 1999 10:18:02 -0700 (PDT) Received: from copper.parc.xerox.com ([13.0.210.195]) by alpha.xerox.com with SMTP id <54597(3)>; Tue, 12 Oct 1999 10:19:45 PDT From: "Larry Masinter" To: "Bert Bos" , Subject: RE: Media types for XSL stylesheets Date: Tue, 12 Oct 1999 10:19:54 PDT Message-ID: <004001bf14d6$00150e40$c3d2000d@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 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <14339.17928.694777.888333@www43.inria.fr> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On the other hand, if you have a format that allows a wide, maybe even > open-ended range of things to be embedded in it, such as a multipart > MIME message, or the SCRIPT element of HTML, then you need a more > flexible way to label the embedding. MIME types seem to do that very > well, so both these formats have adopted them as the labeling > mechanism. Actually, there's an issue with HTML use of MIME to label SCRIPT elements: no one has registered any MIME types for embedded script languages. Although the HTML 4.0 document mentions "text/javascript", "text/vbscript", "text/tcl" in examples, they're not registered. My guess is that the registration would push back and suggest registering them as "application" and possibly as faceted "application/vnd.ms-vbscript", "application/vnd.tcl". > That leads to another issue: MIME type are not only used to get the > interpretation started, but also to negotiate capabilities between a > client and a server, e.g., in HTTP. In that context, sending a > document with embedded XSL to a client that has indicated not being > able to handle XSL is not very smart. MIME types aren't used effectively for HTTP negotiation; the use of "Accept" headers has proven unwieldy. We're still looking for some other kind of capability/profile mechanism that would be suitable. The CONNEG work and the continuing CCPP work in W3C will hopefully yield a workable mechanism. > In other words, that document with its embedded XSL needs not just a > MIME type for its first byte, but also a description (a "profile") of > the other capabilities a client needs. That would be something like a > CC/PP( http://www.w3.org/Mobile/CCPP/ ) profile, I assume, and inside > that there *would* be an entry that says "application/xsl" (or whatever > the MIME type will be). It isn't necessary to have a MIME type to talk about a capability. That is, you could have a feature which is "able to interpret XSL style" without registering "application/xsl". The recognition that MIME labelling is insufficient for fine-grained description of recipient capabilities or document profiles was the foundation of the CONNEG work; it seems likely that CCPP can use the CONNEG registry and a superset of the semantics of CONNEG feature sets, although likely with an XML (RDF?) based syntax for feature sets. See http://www.imc.org/ietf-medfree > > > Bert > -- > Bert Bos ( W 3 C ) http://www.w3.org/ > http://www.w3.org/people/bos/ W3C/INRIA > bert@w3.org 2004 Rt des Lucioles / BP 93 > +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France > > Received: by mail.imc.org (8.9.3/8.9.3) id JAA06057 for ietf-xml-mime-bks; Tue, 12 Oct 1999 09:59:35 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA06053 for ; Tue, 12 Oct 1999 09:59:34 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA21354; Tue, 12 Oct 1999 13:01:16 -0400 Message-ID: <3803695A.523C2645@w3.org> Date: Tue, 12 Oct 1999 19:01:14 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org, jjc@jclark.com Subject: Re: Media types for XSL stylesheets References: <199910120128.AA02410@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: > 3) An XSL stylesheet may be embedded as a part of XML document itself and > is referenced by a fragment identifier from this XML document. The above > example demonstrates such an embedded XSL stylesheet. Yes > 5) The example quoted above is controvertial. If this document is delivered > as "text/xml", what will be the media type for the referenced (embedded) > XSL stylesheet? text/xml or text/xsl? It is not a separate resource and thus, the stylesheet portion does not have or need a separate media type, would be my explanation. There is no message body or separate bodypart to label. The media type for the document as a whole would be that of the root element; either a specialised type, if it has one, or a more generic application/xml, as appropriate. -- Chris Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id HAA04527 for ietf-xml-mime-bks; Tue, 12 Oct 1999 07:57:52 -0700 (PDT) Received: from www43.inria.fr (bbos@www43.inria.fr [138.96.10.4]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA04522 for ; Tue, 12 Oct 1999 07:57:50 -0700 (PDT) Received: by www43.inria.fr (8.8.8/8.8.5) id QAA02169; Tue, 12 Oct 1999 16:59:40 +0200 (MET DST) From: Bert Bos MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Oct 1999 16:59:38 +0200 (MET DST) To: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets In-Reply-To: <199910121447.KAA17558@locke.ccil.org> References: <199910121342.AA02453@archlute.fujixerox.co.jp> <199910121447.KAA17558@locke.ccil.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14339.17928.694777.888333@www43.inria.fr> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Cowan writes: > MURATA Makoto scripsit: > > > I think that such an embedded portion INHERITS the media type of the > > document. Even if a stylesheet linking PI specifies a different media type, > > it is merely ignored. > > Not necessarily. A portion of image/gif is by no means an image/gif. > Media types exist so that uninterpreted bytes get an interpretation, > but internal resources have already been interpreted. The GIF format indeed defines a set of chunk codes, so embeddings in GIF are implicitly typed by the GIF spec and do not need MIME. On the other hand, if you have a format that allows a wide, maybe even open-ended range of things to be embedded in it, such as a multipart MIME message, or the SCRIPT element of HTML, then you need a more flexible way to label the embedding. MIME types seem to do that very well, so both these formats have adopted them as the labeling mechanism. That leads to another issue: MIME type are not only used to get the interpretation started, but also to negotiate capabilities between a client and a server, e.g., in HTTP. In that context, sending a document with embedded XSL to a client that has indicated not being able to handle XSL is not very smart. In other words, that document with its embedded XSL needs not just a MIME type for its first byte, but also a description (a "profile") of the other capabilities a client needs. That would be something like a CC/PP[1] profile, I assume, and inside that there *would* be an entry that says "application/xsl" (or whatever the MIME type will be). [1] http://www.w3.org/Mobile/CCPP/ Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/INRIA bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France Received: by mail.imc.org (8.9.3/8.9.3) id HAA04230 for ietf-xml-mime-bks; Tue, 12 Oct 1999 07:35:49 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA04226 for ; Tue, 12 Oct 1999 07:35:48 -0700 (PDT) Received: from thinkpad (slip129-37-221-103.ny.us.prserv.net [129.37.221.103]) by hesketh.net (8.9.3/8.9.3) with SMTP id KAA16510 for ; Tue, 12 Oct 1999 10:37:42 -0400 Message-Id: <199910121437.KAA16510@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: Tue, 12 Oct 1999 10:41:32 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Media types for XSL stylesheets In-Reply-To: <199910121447.KAA17558@locke.ccil.org> References: <199910121342.AA02453@archlute.fujixerox.co.jp> 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: At 10:47 AM 10/12/99 -0400, John Cowan wrote: >MURATA Makoto scripsit: > >> I think that such an embedded portion INHERITS the media type of the >> document. Even if a stylesheet linking PI specifies a different media type, >> it is merely ignored. > >Not necessarily. A portion of image/gif is by no means an image/gif. >Media types exist so that uninterpreted bytes get an interpretation, >but internal resources have already been interpreted. I guess I'd like to ask at this point whether XML-based media types are sufficiently different from other media types that this interpretation is no longer necessarily _mandatory_. In large part, the interests I have in XML revolve around the fact that any well-formed portion of an XML document is itself an XML document, and that distinction between 'internal' and 'external' resources no longer matters nearly as strongly. 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 mail.imc.org (8.9.3/8.9.3) id HAA03876 for ietf-xml-mime-bks; Tue, 12 Oct 1999 07:01:47 -0700 (PDT) Received: from locke.ccil.org (cowan@[192.190.237.102]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA03872 for ; Tue, 12 Oct 1999 07:01:46 -0700 (PDT) Received: (from cowan@localhost) by locke.ccil.org (8.8.5/8.8.5) id KAA17558; Tue, 12 Oct 1999 10:47:01 -0400 (EDT) From: John Cowan Message-Id: <199910121447.KAA17558@locke.ccil.org> Subject: Re: Media types for XSL stylesheets To: murata.makoto@fujixerox.co.jp (MURATA Makoto) Date: Tue, 12 Oct 1999 10:47:01 -0400 (EDT) Cc: ietf-xml-mime@imc.org, jjc@jclark.com In-Reply-To: <199910121342.AA02453@archlute.fujixerox.co.jp> from "MURATA Makoto" at Oct 12, 99 10:42:48 pm X-Mailer: ELM [version 2.4 PL25] 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: MURATA Makoto scripsit: > I think that such an embedded portion INHERITS the media type of the > document. Even if a stylesheet linking PI specifies a different media type, > it is merely ignored. Not necessarily. A portion of image/gif is by no means an image/gif. Media types exist so that uninterpreted bytes get an interpretation, but internal resources have already been interpreted. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin Received: by mail.imc.org (8.9.3/8.9.3) id GAA03600 for ietf-xml-mime-bks; Tue, 12 Oct 1999 06:39:03 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA03594 for ; Tue, 12 Oct 1999 06:39:01 -0700 (PDT) Received: by mx.fujixerox.co.jp; id WAA04490; Tue, 12 Oct 1999 22:40:39 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma004425; Tue, 12 Oct 99 22:40: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 WAA22262; Tue, 12 Oct 1999 22:40:25 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id WAA98050; Tue, 12 Oct 1999 22:40:11 +0900 (JST) Message-Id: <199910121342.AA02453@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 22:42:48 +0900 To: John Cowan Cc: ietf-xml-mime@imc.org, jjc@jclark.com Subject: Re: Media types for XSL stylesheets In-Reply-To: <199910121401.KAA15954@locke.ccil.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: John Cowan wrote: > There is no reason why an embedded portion of a document should have a > media type. The document's overall media type might be text/xml, > application/xml, or anything else; the fact that it contains an > embedded XSL instance is irrelevant. I think that such an embedded portion INHERITS the media type of the document. Even if a stylesheet linking PI specifies a different media type, it is merely ignored. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id GAA03353 for ietf-xml-mime-bks; Tue, 12 Oct 1999 06:16:33 -0700 (PDT) Received: from locke.ccil.org (cowan@[192.190.237.102]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA03349 for ; Tue, 12 Oct 1999 06:16:31 -0700 (PDT) Received: (from cowan@localhost) by locke.ccil.org (8.8.5/8.8.5) id KAA15954; Tue, 12 Oct 1999 10:01:45 -0400 (EDT) From: John Cowan Message-Id: <199910121401.KAA15954@locke.ccil.org> Subject: Re: Media types for XSL stylesheets To: murata.makoto@fujixerox.co.jp (MURATA Makoto) Date: Tue, 12 Oct 1999 10:01:45 -0400 (EDT) Cc: ietf-xml-mime@imc.org, jjc@jclark.com In-Reply-To: <199910120128.AA02410@archlute.fujixerox.co.jp> from "MURATA Makoto" at Oct 12, 99 10:28:53 am X-Mailer: ELM [version 2.4 PL25] 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: MURATA Makoto scripsit: > 5) The example quoted above is controvertial. If this document is delivered > as "text/xml", what will be the media type for the referenced (embedded) > XSL stylesheet? text/xml or text/xsl? There is no reason why an embedded portion of a document should have a media type. The document's overall media type might be text/xml, application/xml, or anything else; the fact that it contains an embedded XSL instance is irrelevant. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin Received: by mail.imc.org (8.9.3/8.9.3) id BAA23483 for ietf-xml-mime-bks; Tue, 12 Oct 1999 01:58:11 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA23478 for ; Tue, 12 Oct 1999 01:58:09 -0700 (PDT) Received: by mx.fujixerox.co.jp; id RAA11962; Tue, 12 Oct 1999 17:59:56 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma011752; Tue, 12 Oct 99 17:59: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 RAA23574; Tue, 12 Oct 1999 17:59:25 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id RAA90750; Tue, 12 Oct 1999 17:59:11 +0900 (JST) Message-Id: <199910120901.AA02442@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 18:01:48 +0900 To: James Clark Cc: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets In-Reply-To: <3802F1CE.B6C17BEF@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: > MURATA Makoto wrote: > > > I would suggest application/xsl-xml (other than application/xml). > > Why application/xsl-xml rather than application/xslt-xml? Wouldn't > application/xsl-xml would suggest it was limited to XSL stylesheets > (i.e. XSLT stylesheets that generate XSL FOs)? What's needed is > something that works for any XSLT stylesheet. I agree that xslt-xml is better. > > It might be a > > good idea to follow the "*/*-xml" contention, > > What exactly is the current status of this convention? Has this > convention become the official policy of the media types registry? If > not, when is it expected to become the official policy? Since the current draft is merely an I-D, there is no "official policy". However, there appear to be no strong opposition in this mailing list. By reading the discussion in the past, I have a feeling that some people love the convention and others can live with it. (If somebody cannot live with it, speak up now!) There have been some other proposals such as the top-level media type "xml", hierarchical media types, another convention "*/xml-*", and an added parameter for text/xml and application/xml. Some people have strongly disagreed with these proposals. (More about this, see the archive of this mailing list at http://www.imc.org/ietf-xml-mime/mail-archive) Since we do not lose anything by chosing application/xslt-xml rather than application/xslt, I think that we should try application/xslt-xml. 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 mail.imc.org (8.9.3/8.9.3) id BAA22833 for ietf-xml-mime-bks; Tue, 12 Oct 1999 01:33:59 -0700 (PDT) Received: from jclark.com (jclark@jclark.com [192.41.25.183]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA22829 for ; Tue, 12 Oct 1999 01:33:58 -0700 (PDT) Received: from jclark.com (p5-bkkSP1.C.loxinfo.net.th [203.146.28.5]) by jclark.com (8.8.5) id CAA03887; Tue, 12 Oct 1999 02:33:53 -0600 (MDT) X-Authentication-Warning: jclark.com: Host p5-bkkSP1.C.loxinfo.net.th [203.146.28.5] claimed to be jclark.com Message-ID: <3802F1CE.B6C17BEF@jclark.com> Date: Tue, 12 Oct 1999 15:31:10 +0700 From: James Clark X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets References: <199910120705.AA02431@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: > I would suggest application/xsl-xml (other than application/xml). Why application/xsl-xml rather than application/xslt-xml? Wouldn't application/xsl-xml would suggest it was limited to XSL stylesheets (i.e. XSLT stylesheets that generate XSL FOs)? What's needed is something that works for any XSLT stylesheet. > Since XSL stylesheets are not readable for casual readers, text/* is not > appropriate (see the criteria explained by Ned Freed [1]). I'm not sure I would agree that all XSLT stylesheets are not readable by casual readers. However, there are certainly plenty of XSLT stylesheets that aren't suitable for casual readers, and I think having both a text/* and an application/* registration is an unnecessary complication, so I would be happy with application/*. > It might be a > good idea to follow the "*/*-xml" contention, What exactly is the current status of this convention? Has this convention become the official policy of the media types registry? If not, when is it expected to become the official policy? James Received: by mail.imc.org (8.9.3/8.9.3) id AAA20449 for ietf-xml-mime-bks; Tue, 12 Oct 1999 00:02:02 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA20440 for ; Tue, 12 Oct 1999 00:02:00 -0700 (PDT) Received: by mx.fujixerox.co.jp; id QAA24500; Tue, 12 Oct 1999 16:05:31 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma024128; Tue, 12 Oct 99 16:04:54 +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 QAA29150; Tue, 12 Oct 1999 16:03:13 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id QAA87268; Tue, 12 Oct 1999 16:02:59 +0900 (JST) Message-Id: <199910120705.AA02431@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 16:05:37 +0900 To: James Clark Cc: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets In-Reply-To: <3802C9C0.F1601635@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: > > > Do you intend to introduce XSLT-specific fragment identifiers in the > > future? > > I don't know of any plans to do this. > > > Or, do you intend to use XPointer for referencing into XSLT? > > That's what I would expect. Then, I would suggest application/xsl-xml (other than application/xml). Since XSL stylesheets are not readable for casual readers, text/* is not appropriate (see the criteria explained by Ned Freed [1]). It might be a good idea to follow the "*/*-xml" contention, since you do not want to lose the support of generic XML processing such as XPointer. I think that text/xml is not appropriate for XSLT since an XSLT stylesheet is not readable by casual users. [1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id WAA18688 for ietf-xml-mime-bks; Mon, 11 Oct 1999 22:38:54 -0700 (PDT) Received: from jclark.com (jclark@jclark.com [192.41.25.183]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA18684 for ; Mon, 11 Oct 1999 22:38:53 -0700 (PDT) Received: from jclark.com (p10-bkkSP11.C.loxinfo.net.th [203.146.13.10]) by jclark.com (8.8.5) id XAA04329; Mon, 11 Oct 1999 23:40:28 -0600 (MDT) X-Authentication-Warning: jclark.com: Host p10-bkkSP11.C.loxinfo.net.th [203.146.13.10] claimed to be jclark.com Message-ID: <3802C9C0.F1601635@jclark.com> Date: Tue, 12 Oct 1999 12:40:16 +0700 From: James Clark X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets References: <199910120526.AA02425@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: > > James Clark wrote: > > I suspect a specialized media type for XSLT is needed, since > > Let me ask a question about fragment identifiers > > Do you intend to introduce XSLT-specific fragment identifiers in the > future? I don't know of any plans to do this. > For example, "return the first template rule which has the pattern text()"? > Or, do you intend to use XPointer for referencing into XSLT? That's what I would expect. James Received: by mail.imc.org (8.9.3/8.9.3) id WAA18523 for ietf-xml-mime-bks; Mon, 11 Oct 1999 22:22:54 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA18518 for ; Mon, 11 Oct 1999 22:22:52 -0700 (PDT) Received: by mx.fujixerox.co.jp; id OAA16905; Tue, 12 Oct 1999 14:26:22 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma016769; Tue, 12 Oct 99 14:26: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 OAA12400; Tue, 12 Oct 1999 14:24:31 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id OAA84311; Tue, 12 Oct 1999 14:24:17 +0900 (JST) Message-Id: <199910120526.AA02425@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 14:26:54 +0900 To: James Clark Cc: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets In-Reply-To: <3802A481.DCA57A7B@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 suspect a specialized media type for XSLT is needed, since Let me ask a question about fragment identifiers Do you intend to introduce XSLT-specific fragment identifiers in the future? For example, "return the first template rule which has the pattern text()"? Or, do you intend to use XPointer for referencing into XSLT? Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id UAA14455 for ietf-xml-mime-bks; Mon, 11 Oct 1999 20:06:04 -0700 (PDT) Received: from jclark.com (jclark@jclark.com [192.41.25.183]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA14451 for ; Mon, 11 Oct 1999 20:06:03 -0700 (PDT) Received: from jclark.com (p14-bkkSP1.C.loxinfo.net.th [203.146.28.14]) by jclark.com (8.8.5) id VAA01778; Mon, 11 Oct 1999 21:07:39 -0600 (MDT) X-Authentication-Warning: jclark.com: Host p14-bkkSP1.C.loxinfo.net.th [203.146.28.14] claimed to be jclark.com Message-ID: <3802A481.DCA57A7B@jclark.com> Date: Tue, 12 Oct 1999 10:01:21 +0700 From: James Clark X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets References: <199910120214.AA02418@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: > I read your mail and the XSL PR. I think that the PR has done a very good > job, since it uses text/xml and application/xml and still keeps the door > open for XSL-specialized media types. I think eventually it would be desirable to have an XSL-specialized media type and now seems like a good time to start a discussion of this. First, a bit more background to supplement what you have already given. 1. There are two specs involved here, XSLT and XSL. XSLT, which has just become a PR, is a language expressed in XML for transforming XML documents. XSL, which is currently a WD, defines an XML language for specifying formatting (at a semantic level similar to RTF rather than PDF); this language is usually called XSL FO (Formatting Objects). An XSL stylesheet is an XSLT stylesheet that transforms into XSL FOs. XSL is thus the combination of XSLT and XSL FO. XSL FO is not a separate spec. 2. XSLT is not restricted to transform into XML. Although it always conceptually produces an XML tree, than XML tree need not be serialized as XML. It can be serialized as HTML or as plain text. XSLT allows stylesheets to declare the media type of the result. You can have XSLT stylesheets that transform into VRML or SVG. A browser could launch the appropriate viewer based on the declared result media type. 3. XSL FOs can potentially be mixed with other XML vocabularies such as SVG. I suspect a specialized media type for XSLT is needed, since - it's not always possible to tell that an XML document is an XSLT stylesheet; for example, is a legal XSLT stylesheet (whose semantics are to transform any XSLT document to an XML document containing just a single empty "doc" element); thus even if there was a way with application/xml to indicate the namespace URIs used, this would not be enough for content negotiation to work - it would be useful for the media type for XSLT to have a parameter that declared the media type of the result of a transformation; in order for a browser to be able to use an XSLT stylesheet to display a document, it needs not just to be able to handle XSLT but also to be able to handle the result of the XSLT process; this seems specific to XSLT I don't think there needs to be a specific media type for XSL. XSL should be handled as an instance of the XSLT media type. I'm not sure about XSL FOs. One way to deal with them would be as an instance of application/xml with a parameter indicating the namespace URIs used, but that would make the media type of an XSL stylesheet something like application/xslt; result="application/xml; namespace-uris=\"http://www.w3.org/1999/XSL/Format\"" which is a bit unwieldy. James Received: by mail.imc.org (8.9.3/8.9.3) id TAA13499 for ietf-xml-mime-bks; Mon, 11 Oct 1999 19:11:11 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA13493 for ; Mon, 11 Oct 1999 19:11:10 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA01417; Tue, 12 Oct 1999 11:14:38 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma000861; Tue, 12 Oct 99 11:13:29 +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 LAA03054; Tue, 12 Oct 1999 11:11:50 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id LAA78737; Tue, 12 Oct 1999 11:11:36 +0900 (JST) Message-Id: <199910120214.AA02418@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 11:14:13 +0900 To: James Clark Cc: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets In-Reply-To: <380295E9.E2AFEAE5@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: > You must be looking at an old WD. I am afraid that I made a mistake. I tried the http://www.w3.org/TR/xslt, but the server returned an old file in the cash. My apologies. I read your mail and the XSL PR. I think that the PR has done a very good job, since it uses text/xml and application/xml and still keeps the door open for XSL-specialized media types. 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 mail.imc.org (8.9.3/8.9.3) id SAA13332 for ietf-xml-mime-bks; Mon, 11 Oct 1999 18:57:39 -0700 (PDT) Received: from jclark.com (jclark@jclark.com [192.41.25.183]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA13328 for ; Mon, 11 Oct 1999 18:57:38 -0700 (PDT) Received: from jclark.com (p40-bkkSP11.C.loxinfo.net.th [203.146.13.40]) by jclark.com (8.8.5) id TAA18525; Mon, 11 Oct 1999 19:59:09 -0600 (MDT) X-Authentication-Warning: jclark.com: Host p40-bkkSP11.C.loxinfo.net.th [203.146.13.40] claimed to be jclark.com Message-ID: <380295E9.E2AFEAE5@jclark.com> Date: Tue, 12 Oct 1999 08:59:05 +0700 From: James Clark X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: Media types for XSL stylesheets References: <199910120128.AA02410@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: You must be looking at an old WD. The PR says: "The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT stylesheets. It is possible that a media type will be registered specifically for XSLT stylesheets; if and when it is, that media type may also be used." The example in 2.7 uses text/xml. 2.3 also warns that: "In some situations, the only way that a system can recognize that an XML document needs to be processed by an XSLT processor as an XSLT stylesheet is by examining the XML document itself. Using the simplified syntax makes this harder, and can even make it impossible if the xsl:version attribute is omitted from the document element. Therefore, the simplified syntax should not be used for XSLT stylesheets that may be used in such a situation. This situation can, for example, arise when an XSLT stylesheet is transmitted as a message with a MIME media type of text/xml or application/xml to a recipient that will use the MIME media type to determine how the message is processed." MURATA Makoto wrote: > > XSL Transformations (XSLT) has become a proposed recommendation of W3C. > The URL is: > http://www.w3.org/TR/xslt > > An example in 2.7 "Embedding Stylesheets" uses "text/xsl". > > > > > > xmlns:xsl="http://www.w3.org/XSL/Transform/1.0" > xmlns:fo="http://www.w3.org/XSL/Format/1.0"> > > > > > > > > > > > > ... > > > > > However, there is a note as below: > > NOTE: The text/xsl media type has not been registered. No decision > has been made on whether a media type other than text/xml or > application/xml will be used for XSLT and XSL. > > Here is some background information about this issue. > > 1) At present, AFAIK, XSL is the only stylesheet in the XML syntax. But this > may change at any time. > > 2) An XSL stylesheet does not always begin with the XSL namespace. If it > is written in the simplified syntax shown in "2.3 Literal Result Element as > Stylesheet" of XSLT, it can begin with any namespace. > > 3) An XSL stylesheet may be embedded as a part of XML document itself and > is referenced by a fragment identifier from this XML document. The above > example demonstrates such an embedded XSL stylesheet. > > 4) The combination of 3) and 4) means that an embedded stylesheet may > be in the simplified syntax, and can begin with any namespace. > > 5) The example quoted above is controvertial. If this document is delivered > as "text/xml", what will be the media type for the referenced (embedded) > XSL stylesheet? text/xml or text/xsl? > > Makoto > > Fuji Xerox Information Systems > > Tel: +81-44-812-7230 Fax: +81-44-812-7231 > E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id SAA12884 for ietf-xml-mime-bks; Mon, 11 Oct 1999 18:25:41 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA12880 for ; Mon, 11 Oct 1999 18:25:39 -0700 (PDT) Received: by mx.fujixerox.co.jp; id KAA11059; Tue, 12 Oct 1999 10:29:00 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma010732; Tue, 12 Oct 99 10:28:12 +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 KAA23236; Tue, 12 Oct 1999 10:26:31 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id KAA77504; Tue, 12 Oct 1999 10:26:16 +0900 (JST) Message-Id: <199910120128.AA02410@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 12 Oct 1999 10:28:53 +0900 To: ietf-xml-mime@imc.org Cc: jjc@jclark.com Subject: Media types for XSL stylesheets 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: XSL Transformations (XSLT) has become a proposed recommendation of W3C. The URL is: http://www.w3.org/TR/xslt An example in 2.7 "Embedding Stylesheets" uses "text/xsl". ... However, there is a note as below: NOTE: The text/xsl media type has not been registered. No decision has been made on whether a media type other than text/xml or application/xml will be used for XSLT and XSL. Here is some background information about this issue. 1) At present, AFAIK, XSL is the only stylesheet in the XML syntax. But this may change at any time. 2) An XSL stylesheet does not always begin with the XSL namespace. If it is written in the simplified syntax shown in "2.3 Literal Result Element as Stylesheet" of XSLT, it can begin with any namespace. 3) An XSL stylesheet may be embedded as a part of XML document itself and is referenced by a fragment identifier from this XML document. The above example demonstrates such an embedded XSL stylesheet. 4) The combination of 3) and 4) means that an embedded stylesheet may be in the simplified syntax, and can begin with any namespace. 5) The example quoted above is controvertial. If this document is delivered as "text/xml", what will be the media type for the referenced (embedded) XSL stylesheet? text/xml or text/xsl? Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id MAA06008 for ietf-xml-mime-bks; Sun, 10 Oct 1999 12:36:25 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA06004 for ; Sun, 10 Oct 1999 12:36:24 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28058; Sun, 10 Oct 1999 15:37:57 -0400 Message-ID: <3800EB08.B2089EC@w3.org> Date: Sun, 10 Oct 1999 21:37:44 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gtn@ebt.com CC: "'Simon St.Laurent'" , ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D References: <000a01bf0d77$f098fa90$0100007f@eps.inso.com> 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: Gavin Thomas Nicol wrote: > > > So you expect software written for both SVG-specific and > > XML-generic to understand both SVG and XML fragment identifier rules? No ;-) > > It seems more > > likely that SVG applications would only understand SVG FI > > rules and XML applications would understand XPointer - fortunately, a > > superset of SVG. Yes. > I think the question here is one of intent. If people believe that > generic XML processors are going to be manipulating SVG as part of > common practise, then it makes little sense to have a media-types > specific fragment identifier. If SVG is *not* commonly going to be > manipulated by generic XML processors, then a media-specific fragment > id makes perfect sense. It's event better if they line up. They do indeed line up, and sometimes SVG will be manipulated by generic XML processors, and sometimes (often) it will be displayed by SVG-specific processors. -- Chris Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id MAA05746 for ietf-xml-mime-bks; Sun, 10 Oct 1999 12:21:07 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA05741 for ; Sun, 10 Oct 1999 12:21:02 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA27017; Sun, 10 Oct 1999 15:22:34 -0400 Message-ID: <3800E76B.EFEA43E4@w3.org> Date: Sun, 10 Oct 1999 21:22:19 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Simon St.Laurent" CC: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D References: <199909270230.AA02229@archlute.fujixerox.co.jp> <199909291221.IAA29207@hesketh.net> <199910011640.MAA30224@hesketh.net> 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: "Simon St.Laurent" wrote: > > At 06:40 PM 9/29/99 +0200, Chris Lilley wrote: > >"Simon St.Laurent" wrote: > >> All suggestions regarding the fragment identifier issue are welcome. My > >> personal take is that non-SVG XML could (and in fact would probably have > >> to) use conventional XPointers to reference _into_ SVG documents, making > >> the -xml suffix important for identification. This would not, however, > >> constrain SVG documents from using their own fragment identifiers to > >> reference other SVG documents. > > > >Hmm. I think you have that backwards. It is not where the reference > >comes *from* that is important, but what it points *into*. Because the > >fragment goes onto the end of a url. > > I think we've got a fundamental disconnect here. Yes. > Generic XML software (say > a directory system or something making a reference) isn't going to care > whether a given XML document is SVG or CGM or whatever. All it necessarily > knows is that the target document is XML. Why should it know anything > about SVG or CGM's fragment identifiers? Because CGM is not written in XML, for starters. So an XPath/XPointer is going to get you nowhere. CGM does have its own fragment identifier syntax, and so that is what you use if you are pointing intoa CGM. Similarly, if some video format had a fragment syntax thatlet you point to a particular SMPTE timecode inside the movie, you would use that media type's fragment syntax when pointing into that movie. > The 'end of the URL' may not be processed by an application that > understands SVG at all. Is there some reason that it should? Lets clarify here. By "end of the url" I meant the client side specialiser, the part after the #. So, in the case of a URL which points at an SVG file, then yes, it will be an SVG application that processes it. The entire resource is returned to the requesting application. Similarly, a URL pointing to HTML which has a fragment identifier, will be processed by something that knows how to deal with HTML fragment identifiers. And a URL pointingto a video will have the fragment identifier processed by that video client. These URLs could have been embeeded in an XML file, a CGM, a PDF, a hotlist, or written on a napkin or typed on a command line. It doesn't matter where they came from; its where they point to. > > >Consider for example an xml file which contained a link to the third > >picture in a CGM file. The URL would be that of the CGM, and the > >fragment syntax used would be the WebCGM fragment syntax, not Xpointer. > >Conversely, A WebCGM which contained a link into the third paragraph of > >an XML file would use XPointer as the fragment identifier on the end of > >the URL that pointed to the XML document. > > So you expect software written for both SVG-specific and XML-generic to > understand both SVG and XML fragment identifier rules? No. (And its a pity you moved the example, because my example was clearer, since CGM is not writen in XML). It sounds as if you are confusing the roles of link recognition (which is dealt with by the place where the link starts from) and fragment resolution, which happens when the requested resource has been retrieved and dispatched to the appropriate handler. > It seems more > likely that SVG applications would only understand SVG FI rules and XML > applications would understand XPointer Yes! Which is what I said, and thus, the thing that knows how to interpret the fragment identifier is in charge of dealing with it once the resource has been fetched. - fortunately, a superset of SVG. Yes, which is why SVG does not make a very clear example in these discussions, which is why I picked something (WebCGM) which is not written in XML and which already has its own defined fragment syntax. > If you want to operate this way, why have different fragment identifier > rules at all? It seems like you've just created extra work for all kinds > of applications. No, not at all. I think, as you yourself said when you started this message, that you have misunderstood me. I don't think we disagree at all, in fact. -- Chris Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id FAA10025 for ietf-xml-mime-bks; Fri, 8 Oct 1999 05:12:56 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA10021 for ; Fri, 8 Oct 1999 05:12:54 -0700 (PDT) Received: by mx.fujixerox.co.jp; id VAA27204; Fri, 8 Oct 1999 21:15:40 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma027162; Fri, 8 Oct 99 21:15: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 VAA12310 for ; Fri, 8 Oct 1999 21:13:56 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id VAA31569 for ; Fri, 8 Oct 1999 21:13:34 +0900 (JST) Message-Id: <199910081216.AA02409@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 08 Oct 1999 21:16:15 +0900 To: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D In-Reply-To: <37F3855A.2E88B13E@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: > > Q1. If you introduce a media type "image/svg", you can certainly introduce > > SVG-specific fragment > > identifiers. > > There are two issues here. > > Firstly, since it is defining a media type, it needs to define what the > fragment identifier syntax is. We use XPointer, but in this release > restict it to pointing to IDs. This is because we want a spec that is > fully implemented very rapidly. > > Later versions will probably remove this restriction, once XLink and > XPointer are more established. 16.2.2 "SVG fragment identifiers" of the latest draft of SVG [1] introduces SVG view specifications such as "MyDrawing.svg#svgView(viewBox(0,200,1000,1000)))". >16.2.2. SVG fragment identifiers > > Shorthand bare name form of addressing (e.g., > MyDrawing.svg#MyView). This form of addressing, which > allows addressing an SVG element by its ID, is compatible > with the fragment addressing mechanism for older versions of > HTML and the shorthand bare name formulation in "XML Pointer > Language (XPointer)" [XPTR]. (The bare name form of addressing > #MyElement is equivalent to the XPointer formulation > #xptr(id('MyView')).) > > XPointer-compatible ID reference (e.g., > MyDrawing.svg#xptr(id('MyView'))). This form of addressing, > which also allows addressing an SVG element by its ID, is > compatible with the syntax for referencing IDs in "XML Pointer > Language (XPointer)" [XPTR]. > > SVG view specification (e.g., > MyDrawing.svg#svgView(viewBox(0,200,1000,1000))). This form of > addressing specifies the desired view of the document (e.g., > the region of the document to view, the initial zoom level) > completely within the SVG fragment specification. The contents > of the SVG view specification are the five parameter specifications, > viewBox(...), preserveAspectRatio(...), transform(...), > allowZoomAndPan(...) and viewTarget(...), whose parameters have > the same meaning as the corresponding attributes on a element. > Chris Lilley wrote: > > I would like to understand what you mean by "SVG fragment identifier" > before being able to answer how I feel. I need to understand your > question better first. Let me reformulate my question. Suppose that I have an XHTML document. The first subsection of the second section has an embedded SVG. I would like to use an XPointer to specify "the SVG in the first subsection of the second section". Then, I would like to obtain a region of this SVG by using an SVG view specficiation such as svgView(viewBox(0,200,1000,1000))). I would like to combine the XPointer and the SVG view specfication to form a fragment identifier. I think I cannot do this, since SVG view speficiations require image/svg and XPointer requires text/xml or application/xml (or */*-xml). Am I right? #Probably, I am repeating the debate Gavin did long time ago. [1] http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp Received: by mail.imc.org (8.9.3/8.9.3) id EAA09817 for ietf-xml-mime-bks; Fri, 8 Oct 1999 04:59:53 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA09812 for ; Fri, 8 Oct 1999 04:59:52 -0700 (PDT) Received: by mx.fujixerox.co.jp; id VAA24357; Fri, 8 Oct 1999 21:02:37 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma024276; Fri, 8 Oct 99 21:02:13 +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 VAA11709 for ; Fri, 8 Oct 1999 21:00:59 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-176.greens.fxis.fujixerox.co.jp [131.221.160.176]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id VAA31300 for ; Fri, 8 Oct 1999 21:00:37 +0900 (JST) Message-Id: <199910081203.AA02408@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 08 Oct 1999 21:03:18 +0900 To: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D In-Reply-To: <37F24112.7CC34039@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: > > "Simon St.Laurent" wrote: > > I don't think xml- is introduced as a general convention for anything. > > xml-dtd can be the form for XML DTD information in large part because DTD > > files are not themselves well-formed XML documents. > > Agreed. Could the same type be used for other "parts of xml" which are > not by themselves well-formed xml documents? I am thinking of external > parsed entities. Which media type should we use for external parsed entities? This is an interesting exercise. There are two cases. Case 1: an external parsed entity is also a standalone XML document. For example, is a standalone XML document, but can be referenced as an external parsed entity. For example, ]> &ent; For such external parsed entities, text/xml or application/xml works perfectly well. Case 2: An external parsed entity is not a standalone XML document. There are two subcases. The first subcase is that the client side is expecting an external parsed entity. The second subcase is that the client side has no information in advance. Subcase 1: The client needs the charset parameter only. The media type is not useful, since the client already knows that the MIME entity is an XML parsed entity. Thus, text/xml or application/xml works. Subcase 2: If the media type is text/xml or application/xml, the MIME client would probably invoke an XML processor, and get a fatal error. Is this a problem? I think that it is OK. After all, the client cannot do anything useful, since the external parsed entity does not parse as an XML document. 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 mail.imc.org (8.9.3/8.9.3) id BAA29179 for ietf-xml-mime-bks; Sun, 3 Oct 1999 01:20:08 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA29175 for ; Sun, 3 Oct 1999 01:20:03 -0700 (PDT) Received: from endymion (modem_e [199.93.212.247]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id EAA23456; Sun, 3 Oct 1999 04:14:53 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'Simon St.Laurent'" , "'Chris Lilley'" Cc: Subject: RE: Announcement of an I-D Date: Sun, 3 Oct 1999 04:18:56 -0400 Message-ID: <000a01bf0d77$f098fa90$0100007f@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199910011640.MAA30224@hesketh.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > So you expect software written for both SVG-specific and > XML-generic to understand both SVG and XML fragment identifier rules? It seems more > likely that SVG applications would only understand SVG FI > rules and XML applications would understand XPointer - fortunately, a > superset of SVG. I think the question here is one of intent. If people believe that generic XML processors are going to be manipulating SVG as part of common practise, then it makes little sense to have a media-types specific fragment identifier. If SVG is *not* commonly going to be manipulated by generic XML processors, then a media-specific fragment id makes perfect sense. It's event better if they line up. I remember getting into this debate years ago when I proposed having a generic tree-structured fragment identifier for *all* media types (non-herarchical data could be handled with just single-level qualification). You can see where the debate ended up... Received: by mail.imc.org (8.9.3/8.9.3) id JAA18151 for ietf-xml-mime-bks; Fri, 1 Oct 1999 09:39:49 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA18147 for ; Fri, 1 Oct 1999 09:39:45 -0700 (PDT) Received: from thinkpad (slip129-37-221-195.ny.us.prserv.net [129.37.221.195]) by hesketh.net (8.9.3/8.9.3) with SMTP id MAA30224; Fri, 1 Oct 1999 12:40:41 -0400 Message-Id: <199910011640.MAA30224@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 01 Oct 1999 12:43:40 -0400 To: Chris Lilley From: "Simon St.Laurent" Subject: Re: Announcement of an I-D Cc: ietf-xml-mime@imc.org In-Reply-To: <37F24112.7CC34039@w3.org> References: <199909270230.AA02229@archlute.fujixerox.co.jp> <199909291221.IAA29207@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 06:40 PM 9/29/99 +0200, Chris Lilley wrote: >"Simon St.Laurent" wrote: >> All suggestions regarding the fragment identifier issue are welcome. My >> personal take is that non-SVG XML could (and in fact would probably have >> to) use conventional XPointers to reference _into_ SVG documents, making >> the -xml suffix important for identification. This would not, however, >> constrain SVG documents from using their own fragment identifiers to >> reference other SVG documents. > >Hmm. I think you have that backwards. It is not where the reference >comes *from* that is important, but what it points *into*. Because the >fragment goes onto the end of a url. I think we've got a fundamental disconnect here. Generic XML software (say a directory system or something making a reference) isn't going to care whether a given XML document is SVG or CGM or whatever. All it necessarily knows is that the target document is XML. Why should it know anything about SVG or CGM's fragment identifiers? The 'end of the URL' may not be processed by an application that understands SVG at all. Is there some reason that it should? >Consider for example an xml file which contained a link to the third >picture in a CGM file. The URL would be that of the CGM, and the >fragment syntax used would be the WebCGM fragment syntax, not Xpointer. >Conversely, A WebCGM which contained a link into the third paragraph of >an XML file would use XPointer as the fragment identifier on the end of >the URL that pointed to the XML document. So you expect software written for both SVG-specific and XML-generic to understand both SVG and XML fragment identifier rules? It seems more likely that SVG applications would only understand SVG FI rules and XML applications would understand XPointer - fortunately, a superset of SVG. If you want to operate this way, why have different fragment identifier rules at all? It seems like you've just created extra work for all kinds of applications. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com