Received: by mail.proper.com (8.9.3/8.9.3) id OAA18781 for ietf-xml-mime-bks; Sat, 31 Jul 1999 14:32:00 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA18777 for ; Sat, 31 Jul 1999 14:31:58 -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 RAA27445; Sat, 31 Jul 1999 17:34:33 -0400 Message-ID: <37A36BF3.DEA0FD49@w3.org> Date: Sat, 31 Jul 1999 23:34:43 +0200 From: Chris Lilley X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Cowan CC: ietf-xml-mime@imc.org Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT References: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> <001f01beccf9$d37473e0$dd066d8c@sinica.edu.tw> <378B3B34.C153791F@locke.ccil.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: John Cowan wrote: > > Rick Jelliffe wrote: > > I am confused about a related question: I have heard somewhere that > > the XPointer group was going to make XPointers only valid for pointing > > into XML documents. So, for example, it would not be legitimate for > > an XPointer to point into a WebCGM document or other structured data. Is this true? > > Since XPointers refer explicitly to element trees with attributes, > an XPointer into CGM (which is a binary format) wouldn't make > much sense. Right. And WebCGM defines its own fragment syntax (which was heavily inspired by XLink, as it happens). > The real issue is whether XPointers can point into > things like SMIL documents, which "just happen" to be encoded > in XML. When a new media type is registered, that registration gets to define what sa fragment identifier means. So, the language in the XPointer draft is clearly saying, for text/xml and application/xml, this is the syntax. It doesn't say anything about other media types, presumably because it can't speak for them. Other media types can define their own fragment identifiers, which may have very different requirements to Xlink or may have exactly the same ones. So they might well say that they use XLink, too. Or they might say something like "we will allow only links to a given ID but we will use the exact same syntax XPointer uses for that, for compatibility". In other words, all valid fragment identifiers for thast type would use XLink, but not all possible uses of XLink would be valid for that media type. -- Chris Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19340 for ietf-xml-mime-bks; Fri, 23 Jul 1999 23:11:17 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA18739 for ; Fri, 23 Jul 1999 23:11:09 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <55014(2)>; Fri, 23 Jul 1999 23:13:10 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <100856>; Fri, 23 Jul 1999 23:13:03 PDT From: "Larry Masinter" To: "Simon St.Laurent" , Subject: RE: Proposed Suffix for XML-based media types Date: Fri, 23 Jul 1999 23:13:04 PDT Message-ID: <002301bed59b$973172c0$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: <199907191657.MAA08624@hesketh.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > MIME Media Type Suffixes for XML-based Document Types Even if this doesn't do *much* good, I see little harm in it. The document would need to explain the choice of a suffix rather than a prefix (text/xml.blah vs. text/blah-xml), give a list of generic XML processing that might apply (use of XPointer and XLink?), address the charset issue (XML types either need to be UTF8 or else allow an explicit charset parameter). This would then be issued as a BCP, updating the registration procedure BCP. Larry Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29526 for ietf-xml-mime-bks; Fri, 23 Jul 1999 11:25:12 -0700 (PDT) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA29522 for ; Fri, 23 Jul 1999 11:25:11 -0700 (PDT) Received: (qmail 12628 invoked from network); 23 Jul 1999 18:27:14 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 23 Jul 1999 18:27:14 -0000 Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id LAA24805; Fri, 23 Jul 1999 11:27:13 -0700 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA01037; Fri, 23 Jul 1999 11:27:13 -0700 Date: Fri, 23 Jul 1999 11:27:13 -0700 From: Terry Allen Message-Id: <199907231827.LAA01037@bolt.sonic.net> To: chris@w3.org, tbray@textuality.com Subject: Re: Introduction of media types for XML DTDs Cc: ietf-xml-mime@imc.org Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Chris Lilley wrote: | I would argue against text/xml-dtd only on the grounds of the general | charset tangles with text/*, not on the basis of readability or | otherwise. If I send a DTD to someone in email, its probably because I | expect them to read it. If XML software fetches a DTD, its likely for | machine processing and probably no-one reads it. Except that browsers will be "XML software". I'm convinced by Ned's arguments against multiple types, but the solution to the problem of display remains to be found. In default of anything better, I figure that if I intend the DTD for display, I'll just serve it as text/plain. Note that the issue will get worse with XML schemas, which are instances and can be displayed as documents *after XML processing*. regards, Terry Terry Allen Advanced Technology Group Commerce One, Inc. Walnut Creek, Calif. tallen[at]sonic.net Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29039 for ietf-xml-mime-bks; Fri, 23 Jul 1999 10:53:08 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29027 for ; Fri, 23 Jul 1999 10:53: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 NAA16033; Fri, 23 Jul 1999 13:52:41 -0400 Message-ID: <3798ABFA.F8675A71@w3.org> Date: Fri, 23 Jul 1999 19:52:58 +0200 From: Chris Lilley X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Bray CC: ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs References: <3.0.32.19990717112831.012072c0@pop.intergate.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tim Bray wrote: > > At 08:25 AM 7/17/99 PDT, Larry Masinter wrote: > >I think there is no justification for "text/xml-dtd" in addition > >to "application/xml-dtd", because there is no utility at all > >for an unaware recipient to attempt to display a dtd to a > >user as if it were text > > Sounds plausible, but empirical evidence is against this position. > Lots of people read DTDs all the time, and in fact since they are > usually composed in monotype with all sorts of indentation and > other pretty-printing apparatus, there is clearly an expectation > that they be displayed. -Tim Yes, each to their own; for example Tim (and I) would be happy reading a DTD in plain text; Ned Freed would be happy reading RFC822 headers in plain text, and so on and so forth. And again, in practice, software does not use this "fallback" of displaying text/unknown as text/plain so software would either know what to do with a DTD or else it would offer to save it to disk or somesuch. I would argue against text/xml-dtd only on the grounds of the general charset tangles with text/*, not on the basis of readability or otherwise. If I send a DTD to someone in email, its probably because I expect them to read it. If XML software fetches a DTD, its likely for machine processing and probably no-one reads it. -- Chris Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA23160 for ietf-xml-mime-bks; Thu, 22 Jul 1999 00:41:18 -0700 (PDT) Received: from THOR.INNOSOFT.COM (NED@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA23156 for ; Thu, 22 Jul 1999 00:41:16 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDOFRGKL74984JDK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Thu, 22 Jul 1999 00:20:48 PST Date: Thu, 22 Jul 1999 00:17:23 -0800 (PST) From: Ned Freed Subject: Re: Introduction of media types for XML DTDs In-reply-to: "Your message dated Wed, 21 Jul 1999 10:41:34 -0400" <3795DC1E.D302DB59@locke.ccil.org> To: John Cowan Cc: "ietf-xml-mime@imc.org" Message-id: <01JDUG4JFZB0984JDK@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01JDR4CFZNNO984L7H@INNOSOFT.COM> <01JDTH0G64SO984JDK@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Ned Freed wrote: > > [E]xperts don't want to send DTDs and similar > > things to a dumb text viewer anyhow. They want their favorite programmable > > editor, most likely one that is format-savvy for such things. This is certainly > > how I have all the browsers I use configured. > I guess I don't count as an expert, then. My editor is 'ex'; > has been for many years, hopefully will be for many years to come. > But why would I want to edit something I'm displaying through a > browser? Who said anything about editing? Editor != editing. The point (which I thought was obvious) is that browser text displays are fairly incompentent when it comes to displaying structured material. It just isn't what they are designed for. An editor, especially one designed for programming, typically does much better. Although I'll concede that in the case of ex, that may not be the case... Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA28984 for ietf-xml-mime-bks; Wed, 21 Jul 1999 15:44:01 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28978 for ; Wed, 21 Jul 1999 15:43:58 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDOFRGKL74984JDK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 21 Jul 1999 15:44:50 PST Date: Wed, 21 Jul 1999 15:43:34 -0800 (PST) From: Ned Freed Subject: Re: Introduction of media types for XML DTDs In-reply-to: "Your message dated Wed, 21 Jul 1999 13:50:38 -0400" <199907211750.NAA06650@astro.cs.utk.edu> To: Keith Moore Cc: Ned Freed , MURATA Makoto , ietf-xml-mime@imc.org Message-id: <01JDTY3TJEKQ984JDK@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <01JDTH0G64SO984JDK@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > I completely agree -- and this is why I think the ability to fall back to text > > for things like DTDs offers no real advantages for any significant group. > I agree with this. however, another potential advantage comes to mind. > If a body part is labelled "text/something" the MUA can convert the text > to the local format when saving the file - e.g. newline delimited > for UNIX, CR-delimited for Mac, fixed length 80 character ebcdic records > for ancient IBM systems :). The MUA can do this without having specific > knowledge of the content-type. > if the type is labelled "application/something" such a conversion > would not be appropriate unless the MUA had specific knowledge > of the content-type. Actually, for some of these sorts of types, not converting can be a feature. In some cases converting causes bad things to happen -- there can be format and application dependencies on specific line terminators, unfortunately. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20613 for ietf-xml-mime-bks; Wed, 21 Jul 1999 11:21:11 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20609 for ; Wed, 21 Jul 1999 11:21:08 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id NAA06650; Wed, 21 Jul 1999 13:50:39 -0400 (EDT) Message-Id: <199907211750.NAA06650@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: MURATA Makoto , ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs In-reply-to: Your message of "Wed, 21 Jul 1999 07:30:44 -0800." <01JDTH0G64SO984JDK@INNOSOFT.COM> Date: Wed, 21 Jul 1999 13:50:38 -0400 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I completely agree -- and this is why I think the ability to fall back to text > for things like DTDs offers no real advantages for any significant group. I agree with this. however, another potential advantage comes to mind. If a body part is labelled "text/something" the MUA can convert the text to the local format when saving the file - e.g. newline delimited for UNIX, CR-delimited for Mac, fixed length 80 character ebcdic records for ancient IBM systems :). The MUA can do this without having specific knowledge of the content-type. if the type is labelled "application/something" such a conversion would not be appropriate unless the MUA had specific knowledge of the content-type. Keith Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13583 for ietf-xml-mime-bks; Wed, 21 Jul 1999 07:39:57 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13579 for ; Wed, 21 Jul 1999 07:39:56 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id LAA15793 for ; Wed, 21 Jul 1999 11:13:13 -0400 (EDT) Message-ID: <3795DC1E.D302DB59@locke.ccil.org> Date: Wed, 21 Jul 1999 10:41:34 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: "ietf-xml-mime@imc.org" Subject: Re: Introduction of media types for XML DTDs References: <01JDR4CFZNNO984L7H@INNOSOFT.COM> <01JDTH0G64SO984JDK@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed wrote: > [E]xperts don't want to send DTDs and similar > things to a dumb text viewer anyhow. They want their favorite programmable > editor, most likely one that is format-savvy for such things. This is certainly > how I have all the browsers I use configured. I guess I don't count as an expert, then. My editor is 'ex'; has been for many years, hopefully will be for many years to come. But why would I want to edit something I'm displaying through a browser? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13308 for ietf-xml-mime-bks; Wed, 21 Jul 1999 07:34:59 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13304 for ; Wed, 21 Jul 1999 07:34:57 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDOFRGKL74984JDK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 21 Jul 1999 07:35:44 PST Date: Wed, 21 Jul 1999 07:30:44 -0800 (PST) From: Ned Freed Subject: Re: Introduction of media types for XML DTDs In-reply-to: "Your message dated Wed, 21 Jul 1999 13:40:27 +0900" <199907210440.AA01163@archlute.apsdc.ksp.fujixerox.co.jp> To: MURATA Makoto Cc: ietf-xml-mime@imc.org Message-id: <01JDTH0G64SO984JDK@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01JDR4CFZNNO984L7H@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > On the contrary; it is a weakness of current browsers that there > > is no way to tell them "Display such-and-such a media type as > > text/plain in the main window." > At best, this is a criticizm on current browsers. Moreover, even > current browsers make me happy, since I can tell them "Display > such-and-such a media type as with my faviroite text viewer > (which is not IE 5.0)" I completely agree -- and this is why I think the ability to fall back to text for things like DTDs offers no real advantages for any significant group. Normal users will be confused (and we have ample evidence of this in terms of complaints to support lines), and experts don't want to send DTDs and similar things to a dumb text viewer anyhow. They want their favorite programmable editor, most likely one that is format-savvy for such things. This is certainly how I have all the browsers I use configured. Also keep in mind that in some contexts override of plain text viewing with your own application can't be done. (Again, this is a limitation of current applications and hence not directly relevant, but it is a much more real issue than the similar one raised above.) Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA17373 for ietf-xml-mime-bks; Tue, 20 Jul 1999 21:38:58 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA17369 for ; Tue, 20 Jul 1999 21:38:56 -0700 (PDT) Received: by mx.fujixerox.co.jp; id NAA00301; Wed, 21 Jul 1999 13:40:40 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma029580; Wed, 21 Jul 99 13:39:13 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id NAA15585 for ; Wed, 21 Jul 1999 13:37:35 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id NAA10639 for ; Wed, 21 Jul 1999 13:39:12 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id NAA14897 for ; Wed, 21 Jul 1999 13:36:37 +0900 Message-Id: <199907210440.AA01163@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 21 Jul 1999 13:40:27 +0900 To: ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs In-Reply-To: <01JDR4CFZNNO984L7H@INNOSOFT.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-Unsubscribe: Thank you very much, Ned. I have come to believe that we only need application/xml-dtd. Terry Allen wrote: > For the case when it is desired to display the DTD, Ned stated that > text/xml was the wrong way to go, and suggested that something else, > such as content-disposition, could be used to cue the user agent to > display as text. Does any such method work today? Yes, you can tell browsers to invoke Notepad. John Cowan wrote: > > On the contrary; it is a weakness of current browsers that there > is no way to tell them "Display such-and-such a media type as > text/plain in the main window." At best, this is a criticizm on current browsers. Moreover, even current browsers make me happy, since I can tell them "Display such-and-such a media type as with my faviroite text viewer (which is not IE 5.0)" Miles Sabin wrote: > Most users won't ever do that, > but that seems fairly slender grounds for throwing away > at MIME level the knowledge that DTD text is text. Browsers only have to invoke text editors when they encounter application/xml-dtd. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10659 for ietf-xml-mime-bks; Tue, 20 Jul 1999 11:38:34 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA10655 for ; Tue, 20 Jul 1999 11:38:33 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <54286(4)>; Tue, 20 Jul 1999 11:40:09 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <102337>; Tue, 20 Jul 1999 11:39:59 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: Defining 'fragment identifier' behavior because of XML-based MIME type Date: Tue, 20 Jul 1999 11:40:04 PDT Message-ID: <002001bed2df$483315c0$aa66010d@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: <199907121024.AA01071@archlute.apsdc.ksp.fujixerox.co.jp> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I have a question. Why do we have to use media types here? If an XML > document contains a link which takes advantage of XPointer, we just know > that the URI references to an XML document and thus do not have to be > notified by XML media types. This is dangerous; you would be limiting the applicability of XPointer to only work with XML. What if someone were to invent, oh, a "binary XML". (There are several efforts to do so.) XPointer references might just as well apply to binary XML. Would it be possible to extend XPointer to work with Zip files which contained XML files, so that you could point into an XML document that was stored inside a ZIP file? Then you wouldn't know that "the URI references to an XML document". Restricting XPointer only to work with XML would be limiting it unnecessarily. The ability to do generic XML linking into internal body parts of XML-encoded data might be a reason for calling out XML-specific media types, especially if XML documents are "compound" and the media type used just indicates the "top level". So far, this is the first example that resonates with me, although it might be that "application/xml" is good enough for all of these examples, with a separate content-disposition or content-features for calling out either the intention for how the sender might want the information processed by the recipient, or some indication as to the namespaces or other content features of the XML body. Larry Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09113 for ietf-xml-mime-bks; Tue, 20 Jul 1999 10:25:26 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09109 for ; Tue, 20 Jul 1999 10:25:25 -0700 (PDT) Message-Id: <3.0.32.19990720131338.00714564@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 Jul 1999 13:27:05 -0400 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: Soundbite: Proposed Suffix for XML-based media types 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 00:49 1999 07 21 +0900, Murata Makoto wrote: >There is certainly some value, since specialized media types can enjoy >XML-generic support. IE 5.0 does "generic processing of XML" by displaying >the element hierarchy. If we interpret fragment identifiers of XML-based >media types as XPointer, that will be another example of "generic processing >of XML". (Does the same thing apply to XML fragment interchange? > PaulG) I believe so in the sense that XML Fragment interchange can be used with any XML resource with no knowledge about the resource beyond generic XML information. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07861 for ietf-xml-mime-bks; Tue, 20 Jul 1999 09:50:48 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07857 for ; Tue, 20 Jul 1999 09:50:47 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id JAA23040 for ; Tue, 20 Jul 1999 09:52:28 -0700 Message-Id: <3.0.32.19990720095214.011fdc80@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 Jul 1999 09:52:23 -0700 To: ietf-xml-mime@imc.org From: Tim Bray Subject: Re: Soundbite: Proposed Suffix for XML-based media types 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:54 AM 7/20/99 -0400, Keith Moore wrote: >I think it's a silly idea. There's very little value in generic processing >of XML; there's even less value in having an extra level of delegation. How can this assertion be anything but vacuous? XML is a new thing in the world and we're just learning how to deal with it. At this moment, basically *all* the tools available to deal with XML resources are totally generic. I do *not* extrapolate from this to assert that generic-XML processing is the right way to go in general; that would be silly. It is equally silly to assert that generic processing has no value. Since we manifestly, obviously, inarguably, JUST DON'T KNOW right now, it seems to me that whatever we do with media-types, we should be very very careful to avoid closing off maybe-interesting paths. -Tim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02764 for ietf-xml-mime-bks; Tue, 20 Jul 1999 08:42:58 -0700 (PDT) Received: from tpost1.netspace.or.jp (tpost1.netspace.or.jp [202.246.248.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02760 for ; Tue, 20 Jul 1999 08:42:56 -0700 (PDT) Received: from makoto.mars.netspace.or.jp (kwspt10.netspace.or.jp [202.210.80.232]) by tpost1.netspace.or.jp (8.9.3+3.2W/3.7W-tpost1) with SMTP id AAA00556 for ; Wed, 21 Jul 1999 00:44:41 +0900 (JST) Message-Id: <199907201549.AA00492@makoto.mars.netspace.or.jp> From: Murata Makoto Date: Wed, 21 Jul 1999 00:49:19 +0900 To: ietf-xml-mime@imc.org Subject: Re: Soundbite: Proposed Suffix for XML-based media types In-Reply-To: <199907201054.GAA12675@astro.cs.utk.edu> References: <199907201054.GAA12675@astro.cs.utk.edu> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In message "Re: Soundbite: Proposed Suffix for XML-based media types", Keith Moore wrote... >> All MIME media types for XML-based documents will get the suffix '-xml'. > >I think it's a silly idea. There's very little value in generic processing >of XML; there's even less value in having an extra level of delegation. There is certainly some value, since specialized media types can enjoy XML-generic support. IE 5.0 does "generic processing of XML" by displaying the element hierarchy. If we interpret fragment identifiers of XML-based media types as XPointer, that will be another example of "generic processing of XML". (Does the same thing apply to XML fragment interchange? > PaulG) After all, interpretation of fragment identifiers has not been well addressed by MIME yet. In message "Re: Proposed Suffix for XML-based media types", Keith Moore wrote... >nobody has demonstrated a need for an extra level of type classification. >nobody has demonstrated a need for an extra level of fallback behavior. >if anything, experience with the existing two-level type system >indicates that fallback behaviors are of dubious value. There is no consensus, as I see it. Some people believe that the existing two-level type system is fine, while others are convinced that it is not enough. Each camp has failed to persuade the other. Simon's proposal is intended as a compropmise. If people live with it, I think that it is a reasonable solution. Cheers, Makoto Internet: makoto@mars.netspace.or.jp Nifty: VEQ00625 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02174 for ietf-xml-mime-bks; Tue, 20 Jul 1999 08:28:48 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02169 for ; Tue, 20 Jul 1999 08:28:45 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id LAA13766; Tue, 20 Jul 1999 11:29:03 -0400 (EDT) Message-Id: <199907201529.LAA13766@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steven Pemberton cc: Keith Moore , "Simon St.Laurent" , ietf-xml-mime@imc.org Subject: Re: Proposed Suffix for XML-based media types In-reply-to: Your message of "Tue, 20 Jul 1999 16:47:27 +0200." <14228.35767.727159.183158@schoener.cwi.nl> Date: Tue, 20 Jul 1999 11:29:03 -0400 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I thought this whole discussion was based on a perceived need for > extra levels of type classification and fallback. perceived != demonstrated. I certainly haven't seen a convincing argument. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28132 for ietf-xml-mime-bks; Tue, 20 Jul 1999 07:46:21 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28128 for ; Tue, 20 Jul 1999 07:46:19 -0700 (PDT) Received: from schoener.cwi.nl (schoener.cwi.nl [192.16.201.231]) by hera.cwi.nl with ESMTP id QAA24215 for ; Tue, 20 Jul 1999 16:47:28 +0200 (MET DST) Received: by schoener.cwi.nl id QAA23666; Tue, 20 Jul 1999 16:47:27 +0200 (MET DST) From: Steven Pemberton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 1999 16:47:27 +0200 (MET DST) To: Keith Moore Cc: "Simon St.Laurent" , ietf-xml-mime@imc.org Subject: Re: Proposed Suffix for XML-based media types In-Reply-To: <199907201328.JAA13156@astro.cs.utk.edu> References: <14228.24184.600240.137078@schoener.cwi.nl> <199907201328.JAA13156@astro.cs.utk.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14228.35767.727159.183158@schoener.cwi.nl> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > a two-level type system was an explicit design decision > of the 822ext working group. this decision was made for good and valid > reasons, and nothing which has happened since has demonstrated that > such a decision was shortsighted. in particular: > > nobody has demonstrated a need for an extra level of type classification. > nobody has demonstrated a need for an extra level of fallback behavior. I thought this whole discussion was based on a perceived need for extra levels of type classification and fallback. Steven Pemberton Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27496 for ietf-xml-mime-bks; Tue, 20 Jul 1999 07:24:48 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27489 for ; Tue, 20 Jul 1999 07:24:47 -0700 (PDT) Received: from thinkpad (slip129-37-221-117.ny.us.ibm.net [129.37.221.117]) by hesketh.net (8.9.3/8.9.3) with SMTP id KAA09794 for ; Tue, 20 Jul 1999 10:26:33 -0400 Message-Id: <199907201426.KAA09794@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 20 Jul 1999 10:30:21 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Proposed Suffix for XML-based media types In-Reply-To: <199907201328.JAA13156@astro.cs.utk.edu> References: 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 09:28 AM 7/20/99 -0400, Keith Moore wrote: >[Steven Pemberton wrote:] >> Now when we need an extra layer of fallback, it is obvious how to do >> it: >> >> text/xml/xhtml > >sorry, it's not going to happen. the MIME content-type syntax is >well-established; changing it would break a huge amount of deployed software. On this count, I've surrendered long ago and agree with Keith, though fortunately that's not what I'm proposing here. >furthermore a two-level type system was an explicit design decision >of the 822ext working group. this decision was made for good and valid >reasons, and nothing which has happened since has demonstrated that >such a decision was shortsighted. in particular: In this case, I think XML - and other continuing developments around the concept of generic formats - have made a significant case for the creation of formats that can be used with multiple vocabularies. At this point, especially with the rapid growth of XML and supporting generic XML standards (XPointer, XLink, XSL, CSS, and others), I have no qualms about saying that generic XML processing is both useful and important to meaningful information exchange. >nobody has demonstrated a need for an extra level of type classification. >nobody has demonstrated a need for an extra level of fallback behavior. >if anything, experience with the existing two-level type system >indicates that fallback behaviors are of dubious value. I would hope you explore sections 2 and 4 of the full proposal. XML was designed explicitly to be a solid foundation for many document types, in effect a 'fallback' of very sound value. At the time RFC 822 was written, I think they pretty much did the right thing, and I'm willing to live as close to their rules as possible (which is why the proposal uses a suffix, not an extra level with /). However, I think we should seriously consider the fact that XML has changed the rules significantly, in a way which appears to be gathering widespread support and generating new media types at a feverish pace. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21858 for ietf-xml-mime-bks; Tue, 20 Jul 1999 06:27:51 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21852 for ; Tue, 20 Jul 1999 06:27:50 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id JAA13156; Tue, 20 Jul 1999 09:28:13 -0400 (EDT) Message-Id: <199907201328.JAA13156@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steven Pemberton cc: "Simon St.Laurent" , ietf-xml-mime@imc.org Subject: Re: Proposed Suffix for XML-based media types In-reply-to: Your message of "Tue, 20 Jul 1999 13:55:32 +0200." <14228.24184.600240.137078@schoener.cwi.nl> Date: Tue, 20 Jul 1999 09:28:12 -0400 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I very much like Dan Connolly's suggestion of a time back: > > Regard a media type as relative URL rooted at some agreed > place, probably iana.org so that the media type text/xml then > represents the URL > > http://iana.org/text/xml > > (or similar). > > Now when we need an extra layer of fallback, it is obvious how to do > it: > > text/xml/xhtml sorry, it's not going to happen. the MIME content-type syntax is well-established; changing it would break a huge amount of deployed software. furthermore a two-level type system was an explicit design decision of the 822ext working group. this decision was made for good and valid reasons, and nothing which has happened since has demonstrated that such a decision was shortsighted. in particular: nobody has demonstrated a need for an extra level of type classification. nobody has demonstrated a need for an extra level of fallback behavior. if anything, experience with the existing two-level type system indicates that fallback behaviors are of dubious value. Keith Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA17149 for ietf-xml-mime-bks; Tue, 20 Jul 1999 04:54:25 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA17145 for ; Tue, 20 Jul 1999 04:54:23 -0700 (PDT) Received: from schoener.cwi.nl (schoener.cwi.nl [192.16.201.231]) by hera.cwi.nl with ESMTP id NAA13167 for ; Tue, 20 Jul 1999 13:55:35 +0200 (MET DST) Received: by schoener.cwi.nl id NAA23557; Tue, 20 Jul 1999 13:55:34 +0200 (MET DST) From: Steven Pemberton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 1999 13:55:32 +0200 (MET DST) To: "Simon St.Laurent" Cc: ietf-xml-mime@imc.org Subject: Re: Proposed Suffix for XML-based media types In-Reply-To: <199907191657.MAA08624@hesketh.net> References: <199907191657.MAA08624@hesketh.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14228.24184.600240.137078@schoener.cwi.nl> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent writes: > [This is a more formal expansion of my earlier 'modest proposal' > (http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html), which seemed > to generate some interest. This is an extremely rough draft and has no > official status of any kind. All comments, revisions, improved > descriptions, better examples, outrage, etc. are welcome.] My basic problem with this proposal is that it says * We need more than one level of fall back * To fix this we are going to start interpreting the string after the slash to add another layer of structure i.e. media types are no longer supporting our needs fully. In that case I would say: fix the problem, don't try to bandage it over. I very much like Dan Connolly's suggestion of a time back: Regard a media type as relative URL rooted at some agreed place, probably iana.org so that the media type text/xml then represents the URL http://iana.org/text/xml (or similar). Now when we need an extra layer of fallback, it is obvious how to do it: text/xml/xhtml for instance. Best wishes, Steven Pemberton CWI, Amsterdam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA15656 for ietf-xml-mime-bks; Tue, 20 Jul 1999 03:54:09 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA15652 for ; Tue, 20 Jul 1999 03:54:08 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id GAA12675; Tue, 20 Jul 1999 06:54:27 -0400 (EDT) Message-Id: <199907201054.GAA12675@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: ietf-xml-mime@imc.org Subject: Re: Soundbite: Proposed Suffix for XML-based media types In-reply-to: Your message of "Mon, 19 Jul 1999 18:14:00 EDT." <199907192210.SAA20010@hesketh.net> Date: Tue, 20 Jul 1999 06:54:27 -0400 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > All MIME media types for XML-based documents will get the suffix '-xml'. I think it's a silly idea. There's very little value in generic processing of XML; there's even less value in having an extra level of delegation. Keith Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA12872 for ietf-xml-mime-bks; Mon, 19 Jul 1999 15:10:35 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA12868 for ; Mon, 19 Jul 1999 15:10:34 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDR1OUWGXC984L7H@INNOSOFT.COM> for ietf-xml-mime@imc.org; Mon, 19 Jul 1999 15:11:12 PST Date: Mon, 19 Jul 1999 14:52:37 -0800 (PST) From: Ned Freed Subject: Re: Introduction of media types for XML DTDs In-reply-to: "Your message dated Mon, 19 Jul 1999 11:33:38 +0900" <199907190233.AA01144@archlute.apsdc.ksp.fujixerox.co.jp> To: MURATA Makoto Cc: ietf-xml-mime@imc.org Message-id: <01JDR4CFZNNO984L7H@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01JDO8N7YAYM984JDK@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Ned, since you co-authored MIME RFCs, could you please give us an explicit > criteria of text subtypes? The problem is that the criteria have changed over time as our understanding of actual use of markup formats has changed. When MIME was designed we were told that various formats, notably text/richtext, then text/enriched, and even text/html, would be capable of being used in such a way that the output would be readable as-is -- far from beautiful, to be sure, but readable, and that applications were prepared to do this. Under this theory any material that in theory could be read a plain text should be registered under text. But this hasn't happened. In practice the text/richtext, text/enriched, and text/html applications actually produce is typically an unreadable mess -- in some cases even by someone fully familiar with the format. (Note that there are some well behaved applications out there that do generate legible text/enriched, but they are dwarfed in number by the poorly behaved ones.) And given these registrations, the practice of putting things under two trees has carried over to many other types because a feeling has arisen that a "correctly" registered SGML-derived type needs both a text and application registration. So we have a bunch of registrations I for one regard as anywhere from useless to dangerous. (I try to push back on these as media types reviewer, especially the practice of putting the text-encoding variant under text and the WAP WBXML binary variant under application, but I'm only successful in some cases, not all.) > You appear to claim that text subtypes > have to be readable by casual users. This was always the underlying intent. But what has happened is that many things have been registered given the promise of readability, and this has then cascaded into ever sillier registrations. > However, text/css, text/rfc822-headers, > text/vnd.in3d.3dml, text/rtf are already registered. With the sole exception of text/rfc822-headers, I view all of these as mistakes. > I do not think > that they are quite readable by casual users. On the other hand, Postscript > programs are application/postscript rather than text/postscript. Is text/css > a mistake? Text/css is one of the more egregious ones, I think. In the case of PostScript some people actually argued that readable PostScript was a possibility. But nobody seriously thought PostScript output drivers would ever spit out such a thing, so it never got registered under text. > Should XSL become application/xsl-xml rather than text/xsl-xml? I certainly think it should. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA12795 for ietf-xml-mime-bks; Mon, 19 Jul 1999 15:08:32 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA12790 for ; Mon, 19 Jul 1999 15:08:31 -0700 (PDT) Received: from thinkpad (slip129-37-221-201.ny.us.ibm.net [129.37.221.201]) by hesketh.net (8.9.3/8.9.3) with SMTP id SAA20010 for ; Mon, 19 Jul 1999 18:10:14 -0400 Message-Id: <199907192210.SAA20010@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 19 Jul 1999 18:14:00 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Soundbite: Proposed Suffix for XML-based media types In-Reply-To: <199907191657.MAA08624@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: I've been told my last posting was too long, so here's the short version. All MIME media types for XML-based documents will get the suffix '-xml'. The registration process will follow normal IETF procedures per RFC 2048. Advantages: Applications that can process XML generically will be able to request content types of */*xml and get useful results for further processing. Tools designed to work with XML in general (XPointer, XLink, style sheets) will be easy to use with any registered MIME type that uses XML. Disadvantages: Er... four extra bytes in the content-type header? Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07810 for ietf-xml-mime-bks; Mon, 19 Jul 1999 11:12:29 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07806 for ; Mon, 19 Jul 1999 11:12:24 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id OAA29519 for ; Mon, 19 Jul 1999 14:45:02 -0400 (EDT) Message-ID: <37936AD9.D9556297@locke.ccil.org> Date: Mon, 19 Jul 1999 14:13:45 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs References: <199907191606.JAA19459@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Terry Allen wrote: > | The average user probably will never fetch a document of type > | */xml-dtd. > > I hope that's false. I hope the average user's user agent will be > fetching DTDs all the time, for use with documents marked up in > accordance with them. And I hope their browsers don't display > the DTDs to them. Indeed. I was referring to an explicit fetch. "Users don't fetch DTDs (or stylesheets), their browsers fetch DTDs (or stylesheets)." -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06487 for ietf-xml-mime-bks; Mon, 19 Jul 1999 09:55:22 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06483 for ; Mon, 19 Jul 1999 09:55:21 -0700 (PDT) Received: from thinkpad (slip129-37-221-113.ny.us.ibm.net [129.37.221.113]) by hesketh.net (8.9.3/8.9.3) with SMTP id MAA08624 for ; Mon, 19 Jul 1999 12:57:01 -0400 Message-Id: <199907191657.MAA08624@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 19 Jul 1999 13:00:00 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Proposed Suffix for XML-based media types Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: [This is a more formal expansion of my earlier 'modest proposal' (http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html), which seemed to generate some interest. This is an extremely rough draft and has no official status of any kind. All comments, revisions, improved descriptions, better examples, outrage, etc. are welcome.] ------------------------------------- MIME Media Type Suffixes for XML-based Document Types 1. ABSTRACT This document describes the use of a naming convention (a suffix of '-xml') for identifying XML-based MIME media types, whatever their particular contents may represent. This allows the use of generic XML processors and technologies on a wide variety of different XML document types at a minimum cost, using existing frameworks for media type registration. 2. INTRODUCTION Extensible Markup Language [XML] provides a generic syntax for structured text documents which can be used to define a wide variety of specific document types. RFC 2376 [XML-Media] described two MIME Media Types (text/xml and application/xml) which can be used with 'generic' XML. As XML development continues to develop, new XML document types are appearing rapidly. Many of these XML document types would benefit from the identification possibilities of a more specific MIME media type than text/xml or application/xml can provide, and it is likely that many new media types for XML-based document types will be registered in the near and ongoing future. While the benefits of specific MIME types for particular types of XML documents are significant, all XML documents share common structures and syntax that make possible common processing. XML's supporting standards, notably XPointer, are designed to work with any XML document, whatever vocabulary it uses. Any XML editor should be able to read, modify, and save any XML document. Search engines and agents should be able to read XML documents and extract the content and names of elements and attributes even if they are ignorant of the particular vocabulary used for elements and attributes. XML-oriented storage systems, which keep XML documents internally in a parsed form, should similarly be able to process, store, and recreate any XML document, whatever the MIME media type of that XML document may be. Combining the benefits of more specific typing of documents and generic XML processing requires generic XML applications to adopt one or more of three approaches: 1) Use a trial-and-error approach that involves downloading documents and checking their contents to determine whether or not they are XML documents. 2) Keep track of all MIME media types, and know which types represent XML documents and which do not. 3) Recognize a convention that allows MIME media types to describe specific types of documents created with XML while still identifying that the base syntax is XML. The first approach wastes network and processing resources every time a new media type is encountered. The second is more efficient, but requires manual updating (at present) and may involve fallback to approach number 1. The third approach gives applications a consistent labelling standard that allows for the automatic addition of new media types to generic applications without disruption or wasted connections. This proposal does not address more complex content negotiation issues that may be necessary for applications to determine whether the recipient understands the particular vocabulary sets used within given XML document types. The media type described here could be used by applications to prepare for such negotiation, but the media type only provides a monolithic description of a document type. 3. NEW XML MEDIA TYPES When a new media type is introduced for an XML-based format, the name of the media type should end with "-xml". This will allow applications that can process XML generically to detect that the file is supposed to be an XML document as described in [XML] and process it accordingly. The registration process for these media types is described in RFC 2048 [MIME-Registration]. The registrar for the IETF tree will enforce this rule for all XML-based media types created in the IETF tree. Registrars for other trees should follow this convention in order to ensure maximum interoperability of their XML-based documents. The optional charset parameter may be used with media types following these conventions as described in RFC 2376 or its successors. 4. PROCESSING XML MEDIA TYPES Two general classes of applications will operate on XML documents. The first class operates on specific types of documents indicated by the complete MIME media type. For example, a display applet that renders Scalable Vector Graphics [SVG] will only be interested in XML documents of type 'image/svg-xml', not documents of type 'image/gif' or 'application/xpdl-xml'. Other ('generic') applications may work on any XML documents they encounter, processing any media type that matches the type '*/*xml'. This will match text/xml and application/xml as well as more specific media types ending in -xml, allowing the application to request and process XML documents represented by any XML-specific media type. While these applications may not understand the semantic meaning of particular vocabularies, they will be able to process the information stored in the document, determine its structure, and present it to a human or machine consumer in some form. 5. EXAMPLES XML-based media types may represent information in any of the discrete top-level MIME types described in RFC 2046 [MIME-Types]. The examples below present possible names for XML-based media types using the notation described about. 5.1 text types If a standard XML-based format for memorandums emerged, an appropriate media type might be: text/memo-xml 5.2 image types If the World Wide Web Consortium (W3C) were to register a media type for its XML-based Scalable Vector Graphics [SVG], an appropriate media type might be: image/svg-xml 5.3 audio types While multimedia applications are not considered a likely area for XML development, XML could be used to provide a metadata wrapper around other audio formats or could store some types of audio information directly. An XML-based format for music called MusicML could be registered as: audio/musicml-xml 5.4 video types While multimedia applications are not considered a likely area for XML development, XML could be used to provide a metadata wrapper around other video formats or could store some types of video information directly. An XML-based format for video called VideoML could be registered as: video/videoml-xml 5.5 application types If XML Processing Description Language (XPDL) were to be registered as a media type, it could be registered as: application/xpdl-xml 5.6 model types XML is also suitable for a wide variety of modeling applications. If, for instance, a Structured Programming Modeling Markup Language were to appear, it could be registered as: model/spmml-xml 6. REFERENCES XML Bray, Tim, Paoli, Jean, and Sperberg-McQueen, C.M. Extensible Markup Language (XML) 1.0. (W3C Recommendation 10-February-1998) http://www.w3.org/TR/REC-xml XML-Media Whitehead, E. and Murata, M. XML Media Types. (RFC 2376, July 1998) http://www.rfc-editor.org/rfc/rfc2376.txt MIME-Registration Freed, N., Kleinsin, J., and Postel, J. Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. (RFC 2048, November 1996.) http://www.rfc-editor.org/rfc/rfc2048.txt MIME-Types Freed, N., and Borenstein, N. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. (RFC 2046, November 1996.) http://www.rfc-editor.org/rfc/rfc2046.txt SVG Ferraiolo, Jon, et al. Scalable Vector Graphics. (W3C Working Draft, 06 July 1999.) http://www.w3.org/TR/SVG/ Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06449 for ietf-xml-mime-bks; Mon, 19 Jul 1999 09:54:05 -0700 (PDT) Received: from odin.cromwellmedia.co.uk (odin.cromwellmedia.co.uk [194.164.44.244]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06445 for ; Mon, 19 Jul 1999 09:54:04 -0700 (PDT) Received: by odin.cromwellmedia.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BED20F.330CECA0@odin.cromwellmedia.co.uk>; Mon, 19 Jul 1999 17:50:33 +0100 Message-ID: From: Miles Sabin To: "'ietf-xml-mime@imc.org'" Subject: RE: Introduction of media types for XML DTDs Date: Mon, 19 Jul 1999 17:50:33 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Terry Allen wrote, > John Cowan wrote, > > The average user probably will never fetch a > > document of type */xml-dtd. > > I hope that's false. I hope the average user's user > agent will be fetching DTDs all the time, for use with > documents marked up in accordance with them. A users user-agent fetching a DTD is quite different from a user fetching a DTD directly (eg. by typing it's URL into their UAs address line). Pedantry aside, this is an important distinction (one I presume John had in mind when he wrote what he wrote). If I explicitly fetch a textual DTD resource I'd expect it to be rendered textually without having to take any special action. Most users won't ever do that, but that seems fairly slender grounds for throwing away at MIME level the knowledge that DTD text is text. 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: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06304 for ietf-xml-mime-bks; Mon, 19 Jul 1999 09:39:05 -0700 (PDT) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06300 for ; Mon, 19 Jul 1999 09:39:03 -0700 (PDT) Received: (qmail 28738 invoked from network); 19 Jul 1999 16:40:45 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 19 Jul 1999 16:40:45 -0000 Received: from bolt.sonic.net (root@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id JAA10267; Mon, 19 Jul 1999 09:40:45 -0700 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id JAA19459; Mon, 19 Jul 1999 09:06:05 -0700 Date: Mon, 19 Jul 1999 09:06:05 -0700 From: Terry Allen Message-Id: <199907191606.JAA19459@bolt.sonic.net> To: cowan@locke.ccil.org, ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: John Cowan re Ned Freed: | | > I agree. And I'm sorry, but the argument that "people expect DTDs to be | > displayed as text" just doesn't wash -- technical experts (who are capable | > of configuring their agents to do anything they want)' | | On the contrary; it is a weakness of current browsers that there | is no way to tell them "Display such-and-such a media type as | text/plain in the main window." | | > the average user doesn't know diddly about XML or DTD and doesn't want a | > bunch of incomprehensible stuff displayed on his or her screen. | | The average user probably will never fetch a document of type | */xml-dtd. I hope that's false. I hope the average user's user agent will be fetching DTDs all the time, for use with documents marked up in accordance with them. And I hope their browsers don't display the DTDs to them. For the case when it is desired to display the DTD, Ned stated that text/xml was the wrong way to go, and suggested that something else, such as content-disposition, could be used to cue the user agent to display as text. Does any such method work today? regards, Terry Terry Allen Advanced Technology Group Commerce One, Inc. Walnut Creek, Calif. tallen[at]sonic.net Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05456 for ietf-xml-mime-bks; Mon, 19 Jul 1999 08:30:58 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05452 for ; Mon, 19 Jul 1999 08:30:57 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id MAA24400 for ; Mon, 19 Jul 1999 12:03:22 -0400 (EDT) Message-ID: <379344F9.34DFB99B@locke.ccil.org> Date: Mon, 19 Jul 1999 11:32:09 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs References: <199907171330.AA01139@archlute.apsdc.ksp.fujixerox.co.jp> <01JDO8N7YAYM984JDK@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed wrote: > I agree. And I'm sorry, but the argument that "people expect DTDs to be > displayed as text" just doesn't wash -- technical experts (who are capable > of configuring their agents to do anything they want)' On the contrary; it is a weakness of current browsers that there is no way to tell them "Display such-and-such a media type as text/plain in the main window." > the average user doesn't know diddly about XML or DTD and doesn't want a > bunch of incomprehensible stuff displayed on his or her screen. The average user probably will never fetch a document of type */xml-dtd. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA13275 for ietf-xml-mime-bks; Sun, 18 Jul 1999 19:31:23 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13266 for ; Sun, 18 Jul 1999 19:31:21 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA25736; Mon, 19 Jul 1999 11:32:56 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma025457; Mon, 19 Jul 99 11:32:25 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA18193 for ; Mon, 19 Jul 1999 11:30:47 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id LAA12909 for ; Mon, 19 Jul 1999 11:32:24 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id LAA09877 for ; Mon, 19 Jul 1999 11:29:50 +0900 Message-Id: <199907190233.AA01144@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 19 Jul 1999 11:33:38 +0900 To: ietf-xml-mime@imc.org Subject: Re: Introduction of media types for XML DTDs In-Reply-To: <01JDO8N7YAYM984JDK@INNOSOFT.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-Unsubscribe: Ned Freed wrote: > I agree. And I'm sorry, but the argument that "people expect DTDs to be > displayed as text" just doesn't wash -- technical experts (who are capable > of configuring their agents to do anything they want) may expect this, but > the average user doesn't know diddly about XML or DTD and doesn't want a > bunch of incomprehensible stuff displayed on his or her screen. Ned, since you co-authored MIME RFCs, could you please give us an explicit criteria of text subtypes? You appear to claim that text subtypes have to be readable by casual users. However, text/css, text/rfc822-headers, text/vnd.in3d.3dml, text/rtf are already registered. I do not think that they are quite readable by casual users. On the other hand, Postscript programs are application/postscript rather than text/postscript. Is text/css a mistake? Should XSL become application/xsl-xml rather than text/xsl-xml? Cheers, Makoto ------------------------------------------------------------------------- RFC 2046: defitition of the top-level media type "text" > 4.1. Text Media Type > > The "text" media type is intended for sending material which is > principally textual in form. A "charset" parameter may be used to > indicate the character set of the body text for "text" subtypes, > notably including the subtype "text/plain", which is a generic > subtype for plain text. Plain text does not provide for or allow > formatting commands, font attribute specifications, processing > instructions, interpretation directives, or content markup. Plain > text is seen simply as a linear sequence of characters, possibly > interrupted by line breaks or page breaks. Plain text may allow the > stacking of several characters in the same position in the text. > Plain text in scripts like Arabic and Hebrew may also include > facilitites that allow the arbitrary mixing of text segments with > opposite writing directions. > > Beyond plain text, there are many formats for representing what might > be known as "rich text". An interesting characteristic of many such > representations is that they are to some extent readable even without > the software that interprets them. It is useful, then, to > distinguish them, at the highest level, from such unreadable data as > images, audio, or text represented in an unreadable form. In the > absence of appropriate interpretation software, it is reasonable to > show subtypes of "text" to the user, while it is not reasonable to do > so with most nontextual data. Such formatted textual data should be > represented using subtypes of "text". Here is the list of currently registered subtypes of text. > text plain [RFC1521,Borenstein] > richtext [RFC1521,Borenstein] > enriched [RFC1896] > tab-separated-values [Paul Lindner] > html [RFC1866] > sgml [RFC1874] > vnd.latex-z [Lubos] > vnd.fmi.flexstor [Hurtta] > uri-list [Daniel] > vnd.abc [Allen] > rfc822-headers [RFC1892] > vnd.in3d.3dml [Powers] > prs.lines.tag [Lines] > vnd.in3d.spot [Powers] > css [RFC2318] > xml [RFC2376] > rtf [Lindner] > directory [RFC2425] > calendar [RFC2445] > vnd.wap.wml [Stark] > vnd.wap.wmlscript [Stark] > vnd.motorola.reflex [Patton] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14213 for ietf-xml-mime-bks; Sat, 17 Jul 1999 17:08:59 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14205 for ; Sat, 17 Jul 1999 17:08:57 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDOFRGKL74984JDK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Sat, 17 Jul 1999 17:10:24 PST Date: Sat, 17 Jul 1999 17:07:00 -0800 (PST) From: Ned Freed Subject: RE: Introduction of media types for XML DTDs In-reply-to: "Your message dated Sat, 17 Jul 1999 16:19:27 -0700" <199907172319.QAA21128@bolt.sonic.net> To: Terry Allen Cc: masinter@parc.xerox.com, Ned.Freed@INNOSOFT.COM, ietf-xml-mime@imc.org Message-id: <01JDOFWK0XOK984JDK@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Ned Freed re Larry: > | > I think there is no justification for "text/xml-dtd" in addition > | > to "application/xml-dtd", because there is no utility at all > | > for an unaware recipient to attempt to display a dtd to a > | > user as if it were text, which is the reason for having a > | > "text/" top level type in addition to "application/". > | > | I agree. And I'm sorry, but the argument that "people expect DTDs to be > | displayed as text" just doesn't wash -- technical experts (who are capable > | of configuring their agents to do anything they want) may expect this, but > | the average user doesn't know diddly about XML or DTD and doesn't want a > | bunch of incomprehensible stuff displayed on his or her screen. > Correct. But in some contexts, the entity serving the resource wants > it to be displayed as text. So I can see a case for having both > text and application, as I believe we do for SGML, of which XML is > only a profile. I think the definition of a text subtype for SGML was an error, and as such I don't want to repeat it with XML. As for serving out something with the intent of displaying it as text, I don't think it is the server's business to tell the client how to display something. The MIME media type model is to label things as to what they are, not how they are to be handled. If a server wants to give an indication as to how something is to be handled it should use another mechanism like content-disposition. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13737 for ietf-xml-mime-bks; Sat, 17 Jul 1999 16:17:55 -0700 (PDT) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA13733 for ; Sat, 17 Jul 1999 16:17:54 -0700 (PDT) Received: (qmail 5679 invoked from network); 17 Jul 1999 23:19:27 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 17 Jul 1999 23:19:27 -0000 Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id QAA28032; Sat, 17 Jul 1999 16:19:27 -0700 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id QAA21128; Sat, 17 Jul 1999 16:19:27 -0700 Date: Sat, 17 Jul 1999 16:19:27 -0700 From: Terry Allen Message-Id: <199907172319.QAA21128@bolt.sonic.net> To: masinter@parc.xerox.com, Ned.Freed@INNOSOFT.COM Subject: RE: Introduction of media types for XML DTDs Cc: ietf-xml-mime@imc.org Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed re Larry: | > I think there is no justification for "text/xml-dtd" in addition | > to "application/xml-dtd", because there is no utility at all | > for an unaware recipient to attempt to display a dtd to a | > user as if it were text, which is the reason for having a | > "text/" top level type in addition to "application/". | | I agree. And I'm sorry, but the argument that "people expect DTDs to be | displayed as text" just doesn't wash -- technical experts (who are capable | of configuring their agents to do anything they want) may expect this, but | the average user doesn't know diddly about XML or DTD and doesn't want a | bunch of incomprehensible stuff displayed on his or her screen. Correct. But in some contexts, the entity serving the resource wants it to be displayed as text. So I can see a case for having both text and application, as I believe we do for SGML, of which XML is only a profile. regards, Terry Allen (who reads DTDs) Chairman OASIS Regrep TC (which envisions serving DTDs to be read as well as to be parsed) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA12483 for ietf-xml-mime-bks; Sat, 17 Jul 1999 13:41:21 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA12479 for ; Sat, 17 Jul 1999 13:41:20 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JDO83G4DDS984JDK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Sat, 17 Jul 1999 13:42:03 PST Date: Sat, 17 Jul 1999 13:40:28 -0800 (PST) From: Ned Freed Subject: RE: Introduction of media types for XML DTDs In-reply-to: "Your message dated Sat, 17 Jul 1999 08:25:02 -0700 (PDT)" <000401bed068$8a18a640$79d3000d@copper.parc.xerox.com> To: Larry Masinter Cc: MURATA Makoto , ietf-xml-mime@imc.org Message-id: <01JDO8N7YAYM984JDK@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <199907171330.AA01139@archlute.apsdc.ksp.fujixerox.co.jp> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I think there is no justification for "text/xml-dtd" in addition > to "application/xml-dtd", because there is no utility at all > for an unaware recipient to attempt to display a dtd to a > user as if it were text, which is the reason for having a > "text/" top level type in addition to "application/". I agree. And I'm sorry, but the argument that "people expect DTDs to be displayed as text" just doesn't wash -- technical experts (who are capable of configuring their agents to do anything they want) may expect this, but the average user doesn't know diddly about XML or DTD and doesn't want a bunch of incomprehensible stuff displayed on his or her screen. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10819 for ietf-xml-mime-bks; Sat, 17 Jul 1999 11:28:41 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10815 for ; Sat, 17 Jul 1999 11:28:40 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id LAA21957 for ; Sat, 17 Jul 1999 11:30:11 -0700 Message-Id: <3.0.32.19990717112831.012072c0@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 17 Jul 1999 11:30:15 -0700 To: From: Tim Bray Subject: RE: Introduction of media types for XML DTDs 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 08:25 AM 7/17/99 PDT, Larry Masinter wrote: >I think there is no justification for "text/xml-dtd" in addition >to "application/xml-dtd", because there is no utility at all >for an unaware recipient to attempt to display a dtd to a >user as if it were text Sounds plausible, but empirical evidence is against this position. Lots of people read DTDs all the time, and in fact since they are usually composed in monotype with all sorts of indentation and other pretty-printing apparatus, there is clearly an expectation that they be displayed. -Tim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA09903 for ietf-xml-mime-bks; Sat, 17 Jul 1999 08:23:51 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA09899 for ; Sat, 17 Jul 1999 08:23:50 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52174(2)>; Sat, 17 Jul 1999 08:25:19 PDT Received: from copper.parc.xerox.com ([13.0.211.121]) by thelma.parc.xerox.com with SMTP id <99064>; Sat, 17 Jul 1999 08:25:10 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Introduction of media types for XML DTDs Date: Sat, 17 Jul 1999 08:25:02 PDT Message-ID: <000401bed068$8a18a640$79d3000d@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: <199907171330.AA01139@archlute.apsdc.ksp.fujixerox.co.jp> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I think there is no justification for "text/xml-dtd" in addition to "application/xml-dtd", because there is no utility at all for an unaware recipient to attempt to display a dtd to a user as if it were text, which is the reason for having a "text/" top level type in addition to "application/". Larry -- http://www.parc.xerox.com/masinter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA09245 for ietf-xml-mime-bks; Sat, 17 Jul 1999 06:28:10 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA09241 for ; Sat, 17 Jul 1999 06:28:08 -0700 (PDT) Received: by mx.fujixerox.co.jp; id WAA21156; Sat, 17 Jul 1999 22:29:38 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma021144; Sat, 17 Jul 99 22:29:25 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id WAA22317 for ; Sat, 17 Jul 1999 22:27:45 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id WAA23462 for ; Sat, 17 Jul 1999 22:29:23 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id WAA08507 for ; Sat, 17 Jul 1999 22:26:49 +0900 Message-Id: <199907171330.AA01139@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Sat, 17 Jul 1999 22:30:36 +0900 To: ietf-xml-mime@imc.org Subject: Introduction of media types for XML DTDs 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-Unsubscribe: I believe that we have agreed to introduce media types for XML DTDs (to be precise, external DTD subsets and external parameter entities), since they do not parse as XML documents. I tried to sketch required changes to the current RFC. Here I introduced both text/xml-dtd and application/xml-dtd. One could certainly argue aginst this choice. Comments are greatly appreciated. 1) Revision to "3. XML Media types" > This document introduces four new media types for XML entities, > text/xml, application/xml, text/xml-dtd, and application/xml-dtd. ... > The media types text/xml and application/xml can be used for > "document entities" or "external parsed entities". For backward > compatibility, they can also be used for "external DTD subsets" or > "external parameter entities". The media types text/xml-dtd and > application/xml-dtd can be used for "external DTD subsetes" or > "external parameter entities". 2) Addition of two subsections for text/xml-dtd and application/xml-dtd > 3.3 Text/xml-dtd Registration > > MIME media type name: text > > MIME subtype name: xml-dtd > > Mandatory parameters: none > > Optional parameters: charset > > The charset parameter of text/xml-dtd is handled exactly > the same as that of text/xml. > > Encoding considerations: > > This media type may be encoded exactly the same as text/xml. > > Security considerations: > > See section 4 below. > > Interoperability considerations: > > XML DTDs has proven to be interoperable by DTD authoring > tools and XML WWW browsers among others. > > Published specification: see [REC-XML] > > Applications which use this media type: > > DTD authoring tools handle external DTD subsets as well as external > parameter entities. XML browsers may also access external DTD subests > and external parameter entities. > > Additional information: > > Magic number(s): none > > Although no byte sequences can be counted on to always be present, > external DTD subsets and external parameter entities in ASCII-compatible charsets (including UTF-8) often > begin with hexadecimal 3C 3F 78 6D 6C (" information, see Appendix F of [REC-XML]. > > File extension(s): .dtd > Macintosh File Type Code(s): "TEXT" > > Person & email address for further information: > > Dan Connolly > Murata Makoto (Family Given) > > Intended usage: COMMON > > Author/Change controller: > > The XML specification is a work product of the World Wide Web > Consortium's XML Working Group, and was edited by: > > Tim Bray > Jean Paoli > C. M. Sperberg-McQueen > > The W3C, and the W3C XML working group, has change control over > the XML specification. > > > > 3.4 Application/xml-dtd Registration > > MIME media type name: application > > MIME subtype name: xml-dtd > > Mandatory parameters: none > > Optional parameters: charset > > The charset parameter of text/xml-dtd is handled exactly > the same as that of text/xml. > > Encoding considerations: > > The charset parameter of application/xml-dtd is handled exactly > the same as that of application/xml. > > Security considerations: > > See section 4 below. > > Interoperability considerations: > > XML DTDs has proven to be interoperable by DTD authoring > tools and XML WWW browsers among others. > > Published specification: see [REC-XML] > > Applications which use this media type: > > DTD authoring tools handle external DTD subsets as well as external > parameter entities. XML browsers may also access external DTD subests > and external parameter entities. > > Additional information: > > Magic number(s): none > > Although no byte sequences can be counted on to always be present, > external DTD subsets and external parameter entities in ASCII-compatible charsets (including UTF-8) often > document entities and external parsed entities in ASCII-compatible charsets (including UTF-8) often > begin with hexadecimal 3C 3F 78 6D 6C (" UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D > or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM) > followed by " XML]. > > File extension(s): .dtd > Macintosh File Type Code(s): "TEXT" > > Person & email address for further information: > > Dan Connolly > Murata Makoto (Family Given) > > Intended usage: COMMON > > > Author/Change controller: > > The XML specification is a work product of the World Wide Web > Consortium's XML Working Group, and was edited by: > > Tim Bray > Jean Paoli > C. M. Sperberg-McQueen > > The W3C, and the W3C XML working group, has change control over > the XML specification. 3) Addition of examples in sectino 6 > 6.10 text/xml-dtd with UTF-8 Charset > > Content-type: text/xml-dtd; charset="utf-8" > > > > This is the recommended charset value for use with text/xml-dtd. Since > the charset parameter is provided, MIME and XML processors must treat > the enclosed entity as UTF-8 encoded. > > > > 6.11 application/xml-dtd with UTF-16 Charset > > Content-type: application/xml-dtd; charset="utf-16" > > {BOM} > > This is a recommended charset value for use with application/xml-dtd. > Since the charset parameter is provided, MIME and XML processors must > treat the enclosed entity as UTF-16 encoded. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05703 for ietf-xml-mime-bks; Tue, 13 Jul 1999 18:24:00 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA05688 for ; Tue, 13 Jul 1999 18:23:58 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <55426(4)>; Tue, 13 Jul 1999 18:25:03 PDT Received: from copper.parc.xerox.com ([13.0.211.121]) by thelma.parc.xerox.com with SMTP id <102883>; Tue, 13 Jul 1999 18:24:52 PDT From: "Larry Masinter" To: "Paul Grosso" Cc: Subject: RE: Media typs and XPointer, XLink, XPath, and XSLT Date: Tue, 13 Jul 1999 18:24:51 PDT Message-ID: <000201becd97$aba7a8c0$79d3000d@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: <3.0.32.19990713120225.016ff0c0@pophost.arbortext.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: the meaning of a fragment identifier is determined by the media type of the data being pointed into. You've defined it for XML and HTML. Whether fragment identifiers have any meaning for any other media type is up to the definition of the media type. If a type is defined using XML, the type definition can also indicate "use XML semantics for fragment identifiers", or it can give any other semantics. Larry -- http://www.parc.xerox.com/masinter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18697 for ietf-xml-mime-bks; Tue, 13 Jul 1999 11:09:21 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18693 for ; Tue, 13 Jul 1999 11:09:20 -0700 (PDT) From: dorchard@ca.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA112438 for ; Tue, 13 Jul 1999 14:10:03 -0400 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id OAA53726 for ; Tue, 13 Jul 1999 14:10:13 -0400 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567AD.0063C8BA ; Tue, 13 Jul 1999 14:09:54 -0400 X-Lotus-FromDomain: IBMCA@IBMUS To: ietf-xml-mime@imc.org Message-ID: <852567AD.0063C179.00@D51MTA05.pok.ibm.com> Date: Tue, 13 Jul 1999 13:31:07 -0400 Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'm not sure what you mean by "import other things". XLink has no mechanism for specifying the import of other things. It specifies relationships between things, but not the semantics of importing. As an aside, I think there does need to be a different mechanism for importing things other than external entities, but that's a different discussion. There is no information model for how to represent imported things or transformed things, beit XML or non-XML. The DOM has no APIs that distinguish between pre or post transform XML documents, nor pre or post "importing"/including documents. Even the DOM Level 1 API treats notations as read-only elements, and these only specify an external thing. DOM level 2 has a simple text line stating "Creating EntityReference nodes" will be part of level 2. Please elaborate on what you mean by importing and what you expect of infoset, transformations and APIs. Cheers, Dave Orchard "Shane P. McCarron" on 07/13/99 06:41:35 AM Please respond to s.mccarron@opengroup.org To: cc: ietf-xml-mime@imc.org Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT John Cowan wrote: > > Rick Jelliffe wrote: > > I am confused about a related question: I have heard somewhere that > > the XPointer group was going to make XPointers only valid for pointing > > into XML documents. So, for example, it would not be legitimate for > > an XPointer to point into a WebCGM document or other structured data. Is this true? > > Since XPointers refer explicitly to element trees with attributes, > an XPointer into CGM (which is a binary format) wouldn't make > much sense. The real issue is whether XPointers can point into > things like SMIL documents, which "just happen" to be encoded > in XML. Certainly from the XHTML perspective, the ability to refer to other XML grammars via XPointer/XLink is critical. Imaging an XHTML document that uses some new element defined against XLink to import SVG graphics into a page or a SYMM presentation. These are XML grammars, and they should work. However, it might also be useful to import other things - like plain text. XPointer/XLink needs to work for this as well. I don't see how we can limit the scope of the target. You might need to treat the imported item as a BLOB (Binary Large Object), but it should still be imported. At least, that's my opinion. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: s.mccarron@opengroup.org OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17669 for ietf-xml-mime-bks; Tue, 13 Jul 1999 10:01:27 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17665 for ; Tue, 13 Jul 1999 10:01:25 -0700 (PDT) Message-Id: <3.0.32.19990713120225.016ff0c0@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 Jul 1999 12:02:36 -0500 To: "ietf-xml-mime@imc.org" From: Paul Grosso Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT 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 12:45 1999 07 13 -0400, John Cowan wrote: >Tim Bray wrote: > >> >Paul Grosso wrote: >> > >> >> If the resource is XML, the fragment identifier is to be interpreted >> >> as an XPointer. >> > >> >Yes, but what does it mean to "be XML"? Does that simply mean >> >"be a well-formed XML document", or is it also required that >> >the media-type be "application/xml" or "text/xml"? If the >> >media-type is "application/vnd.foo-systems.bar", but the format >> >happens to be well-formed XML, is the fragment ID necessarily >> >to be interpreted as an XPointer? >> >> How can you possibly know, in this case, whether the resource is WF >> XML? The situation seems clear to me: [prince-of-clarity snipped] > >Me too, me too. But that's not what Paul said. In the one line you quoted, I was speaking imprecisely. I think I stated it clearly several other places several other times previously, and I just posted another message (that agrees with you and Tim) that I hopes makes it crystal clear yet once again. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17659 for ietf-xml-mime-bks; Tue, 13 Jul 1999 10:01:21 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17655 for ; Tue, 13 Jul 1999 10:01:19 -0700 (PDT) Received: from thinkpad (slip129-37-221-28.ny.us.ibm.net [129.37.221.28]) by hesketh.net (8.9.3/8.9.3) with SMTP id NAA10883 for ; Tue, 13 Jul 1999 13:02:32 -0400 Message-Id: <199907131702.NAA10883@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Jul 1999 13:05:59 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT In-Reply-To: <3.0.32.19990713094144.00f73680@pop.intergate.bc.ca> 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 09:41 AM 7/13/99 -0700, Tim Bray wrote: >How can you possibly know, in this case, whether the resource is WF >XML? The situation seems clear to me: If it's application/xml >or text/xml, what comes after the # is an xpointer. If it's >anything-else/anything-else, look in the RFC for anything-else/anything-else >to see how fragment identifiers work. That RFC might say that the >media type happens to be XML and it might (or might not, even if it >happens to be XML) say that fragment identifiers are xpointers. Which is exactly why I'd like to get xml- into the MIME type identifier instead of mucking around with RFC lookup, which doesn't work. XPointers will work with any MIME type that requires its content to be well-formed XML. It seems reasonable to identify that fact in the MIME type to avoid having to check RFCs for fragment identifier information, a process that isn't even automatable (until we write English-language parsers, anyway.) As for non-XPointer fragment identifiers for MIME types based on XML documents, I can't say I have much sympathy. If people really want to go that route, we're going to need something a heck of a lot more sophisticated than the current MIME type to RFC connection, and maybe at the point it's time to just plain start over. Heck, we could come up with an RFC metadata spec that does provide this information in a readily parseable and easily available format... Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17635 for ietf-xml-mime-bks; Tue, 13 Jul 1999 09:59:44 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17631 for ; Tue, 13 Jul 1999 09:59:44 -0700 (PDT) Message-Id: <3.0.32.19990713120003.016f4ad0@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 Jul 1999 12:00:51 -0500 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT 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 12:37 1999 07 13 -0400, John Cowan wrote: >Paul Grosso wrote: > >> If the resource is XML, the fragment identifier is to be interpreted >> as an XPointer. > >Yes, but what does it mean to "be XML"? For the resource [1] referenced by the URI [1] of the URI-reference [1] to have media type [2] "application/xml" or "text/xml". Section 4.1. Fragment Identifier of [1] says: The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. [1] http://www.ietf.org/rfc/rfc2396.txt contains definitions of and/or pointers to definitions of each term. [2] http://www.ietf.org/rfc/rfc2046.txt >Does that simply mean >"be a well-formed XML document", or is it also required that >the media-type be "application/xml" or "text/xml"? If the >media-type is "application/vnd.foo-systems.bar", but the format >happens to be well-formed XML, is the fragment ID necessarily >to be interpreted as an XPointer? No. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17489 for ietf-xml-mime-bks; Tue, 13 Jul 1999 09:45:04 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17485 for ; Tue, 13 Jul 1999 09:45:03 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id NAA20349 for ; Tue, 13 Jul 1999 13:15:16 -0400 (EDT) Message-ID: <378B6D47.A6408551@locke.ccil.org> Date: Tue, 13 Jul 1999 12:45:59 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: "ietf-xml-mime@imc.org" Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT References: <3.0.32.19990713094144.00f73680@pop.intergate.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tim Bray wrote: > >Paul Grosso wrote: > > > >> If the resource is XML, the fragment identifier is to be interpreted > >> as an XPointer. > > > >Yes, but what does it mean to "be XML"? Does that simply mean > >"be a well-formed XML document", or is it also required that > >the media-type be "application/xml" or "text/xml"? If the > >media-type is "application/vnd.foo-systems.bar", but the format > >happens to be well-formed XML, is the fragment ID necessarily > >to be interpreted as an XPointer? > > How can you possibly know, in this case, whether the resource is WF > XML? The situation seems clear to me: [prince-of-clarity snipped] Me too, me too. But that's not what Paul said. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17440 for ietf-xml-mime-bks; Tue, 13 Jul 1999 09:40:42 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17436 for ; Tue, 13 Jul 1999 09:40:41 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id JAA20168; Tue, 13 Jul 1999 09:41:50 -0700 Message-Id: <3.0.32.19990713094144.00f73680@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 Jul 1999 09:41:48 -0700 To: John Cowan , ietf-xml-mime@imc.org From: Tim Bray Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT 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 12:37 PM 7/13/99 -0400, John Cowan wrote: >Paul Grosso wrote: > >> If the resource is XML, the fragment identifier is to be interpreted >> as an XPointer. > >Yes, but what does it mean to "be XML"? Does that simply mean >"be a well-formed XML document", or is it also required that >the media-type be "application/xml" or "text/xml"? If the >media-type is "application/vnd.foo-systems.bar", but the format >happens to be well-formed XML, is the fragment ID necessarily >to be interpreted as an XPointer? How can you possibly know, in this case, whether the resource is WF XML? The situation seems clear to me: If it's application/xml or text/xml, what comes after the # is an xpointer. If it's anything-else/anything-else, look in the RFC for anything-else/anything-else to see how fragment identifiers work. That RFC might say that the media type happens to be XML and it might (or might not, even if it happens to be XML) say that fragment identifiers are xpointers. -Tim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17353 for ietf-xml-mime-bks; Tue, 13 Jul 1999 09:36:31 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17349 for ; Tue, 13 Jul 1999 09:36:30 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id NAA20032 for ; Tue, 13 Jul 1999 13:06:42 -0400 (EDT) Message-ID: <378B6B45.241932FA@locke.ccil.org> Date: Tue, 13 Jul 1999 12:37:25 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT References: <3.0.32.19990713095615.01690f64@pophost.arbortext.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Grosso wrote: > If the resource is XML, the fragment identifier is to be interpreted > as an XPointer. Yes, but what does it mean to "be XML"? Does that simply mean "be a well-formed XML document", or is it also required that the media-type be "application/xml" or "text/xml"? If the media-type is "application/vnd.foo-systems.bar", but the format happens to be well-formed XML, is the fragment ID necessarily to be interpreted as an XPointer? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15381 for ietf-xml-mime-bks; Tue, 13 Jul 1999 07:55:33 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA15377 for ; Tue, 13 Jul 1999 07:55:32 -0700 (PDT) Message-Id: <3.0.32.19990713095615.01690f64@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 Jul 1999 09:56:42 -0500 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT 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 14:09 1999 07 13 +0900, MURATA Makoto wrote: >Having finished my summary, I have one question for clarification. Did the >XML Linking WG want to use XPointer only when the media type is text/xml or >application/xml? Or, did they want to use XPointer for other xml-based media >types, but give up simply because the current media type mechanism cannot >specify "This is of the media type "model/foo" which is based on XML"? If the resource is XML, the fragment identifier is to be interpreted as an XPointer. The inverse (and converse, it therefore follows) of that statement is neither necessarily true nor false. The XLink WG does not want to prevent XPointer from being used in non-XML resources, but it also does not want to say anything one way or the other because that is outside the scope of the XLink WG. Asks Rick Jelliffe: >I am confused about a related question: I have heard somewhere that the >XPointer >group was going to make XPointers only valid for pointing into XML >documents. >So, for example, it would not be legitimate for an XPointer to point into a >WebCGM >document or other structured data. Is this true? No. >Also, there seems to be paradigm difference between the conventional idea >of a URL (which fetches some resource) and an XPointer (which points to some >span in some resource but doesn't necessarily return anything). XPointer doesn't necessarily point to a span. It addresses things (where things might be many of the objects in an XML tree or possibly a "span" of such objects). >I had a bit >of >difficulty with this at first, and I suspect that others with HTML >expectations will >be the same. Murata-san's question relates to this too: does an XLink >always >return a resource. "Return" is a semantic, and XLink's semantics are not finalized. I don't really know how else to answer your question, as it doesn't really make sense to me. XPointer addresses, and XLink (which may use XPointer) links addressed things. What is means to link addressed things is yet a different question. >If XPointers can only be used with XLinks, That is not true. >does that mean >that >XPointers always return a resource too? XPointer never return anything. They address things. >If the resource returned is >different from >a type attribute, is it always an error? This question isn't answerable as it depends on erroneous assumptions. Shane P. McCarron says: >However, it might also be useful to import other things - like plain >text. XPointer/XLink needs to work for this as well. I don't see how >we can limit the scope of the target. XLink should be usable with any addressing mechanism, not just XPointer. XPointer might be usable to address into non-XML resources, but it is not up to the XLink WG (or the XPointer spec) to address [pardon the pun] that issue, so you will not see either XLink or XPointer talk about how to link into plain text. How a fragment identifier of a URI-reference addresses into plain text is up to the "plain text mime type" to decide. Once that's determined, XLink will automatically work with it (you'd just give a URI-reference as the value of the locator attribute of the XLink element). paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA14338 for ietf-xml-mime-bks; Tue, 13 Jul 1999 06:54:03 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14334 for ; Tue, 13 Jul 1999 06:54:02 -0700 (PDT) Received: from thinkpad (slip129-37-221-137.ny.us.ibm.net [129.37.221.137]) by hesketh.net (8.9.3/8.9.3) with SMTP id JAA03713; Tue, 13 Jul 1999 09:55:13 -0400 Message-Id: <199907131355.JAA03713@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Jul 1999 09:58:40 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT Cc: www-xml-linking-comments@w3.org In-Reply-To: <378B3B34.C153791F@locke.ccil.org> References: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> <001f01beccf9$d37473e0$dd066d8c@sinica.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: [I've cross-posted this to www-xml-linking-comments@w3.org. It seems like it might be a good idea for the XPointer folk to be aware of the MIME type discussions going on in ietf-xml-mime, and that text/xml and application/xml may not always remain the only MIME types for XML documents.] The latest (9 July 1999) XPointer draft states that: >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". At 09:12 AM 7/13/99 -0400, John Cowan wrote (on ietf-xml-mime@imc.org): > The real issue is whether XPointers can point into >things like SMIL documents, which "just happen" to be encoded >in XML. This doesn't make sense to me. First, I can see where 'smarter' SMIL documents might make use of XLink/XPointer in more sophisticated ways than is presently possible with their simple href linking. SMIL 2.0, for instance, might take fuller advantage of its XML heritage than SMIL 1.0 did. (If, of course, there ever is a SMIL 2.0.) Second, it seems extremely reasonable that other XML documents might well point into SMIL documents and take advantage of the information stored there. While embedding fragments of multimedia presentations may raise some complex questions, doing something like embedding the closed-caption information (text) from a SMIL presentation inside another document seems perfectly reasonable. In other words, why is this even an issue for the XPointer spec to worry about? It might be something that potentially gives application designers a headache, _if_ they want to present SMIL fragments as multimedia presentations, but that doesn't seem like something the XPointer standard itself should care about. XPointer can work with any kind of XML document. If the application can't deal with how that document is supposed to be displayed, it had better have some alternatives ready. Not displaying it is one option, displaying it as text is another, applying a stylesheet is yet another, etc.... Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA14101 for ietf-xml-mime-bks; Tue, 13 Jul 1999 06:40:26 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14097 for ; Tue, 13 Jul 1999 06:40:25 -0700 (PDT) Received: from opengroup.org (spmcompaq.themacs.com [209.98.204.133]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id IAA15393 for ; Tue, 13 Jul 1999 08:41:35 -0500 Message-ID: <378B420F.4604AFBF@opengroup.org> Date: Tue, 13 Jul 1999 08:41:35 -0500 From: "Shane P. McCarron" Reply-To: s.mccarron@opengroup.org Organization: The Open Group X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-xml-mime@imc.org Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT References: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> <001f01beccf9$d37473e0$dd066d8c@sinica.edu.tw> <378B3B34.C153791F@locke.ccil.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: John Cowan wrote: > > Rick Jelliffe wrote: > > I am confused about a related question: I have heard somewhere that > > the XPointer group was going to make XPointers only valid for pointing > > into XML documents. So, for example, it would not be legitimate for > > an XPointer to point into a WebCGM document or other structured data. Is this true? > > Since XPointers refer explicitly to element trees with attributes, > an XPointer into CGM (which is a binary format) wouldn't make > much sense. The real issue is whether XPointers can point into > things like SMIL documents, which "just happen" to be encoded > in XML. Certainly from the XHTML perspective, the ability to refer to other XML grammars via XPointer/XLink is critical. Imaging an XHTML document that uses some new element defined against XLink to import SVG graphics into a page or a SYMM presentation. These are XML grammars, and they should work. However, it might also be useful to import other things - like plain text. XPointer/XLink needs to work for this as well. I don't see how we can limit the scope of the target. You might need to treat the imported item as a BLOB (Binary Large Object), but it should still be imported. At least, that's my opinion. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: s.mccarron@opengroup.org OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA13542 for ietf-xml-mime-bks; Tue, 13 Jul 1999 06:11:35 -0700 (PDT) Received: from locke.ccil.org (root@locke.ccil.org [192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA13537 for ; Tue, 13 Jul 1999 06:11:34 -0700 (PDT) Received: from locke.ccil.org (cowan@locke.ccil.org [192.190.237.102]) by locke.ccil.org (8.8.5/8.8.5) with ESMTP id JAA14324 for ; Tue, 13 Jul 1999 09:41:33 -0400 (EDT) Message-ID: <378B3B34.C153791F@locke.ccil.org> Date: Tue, 13 Jul 1999 09:12:20 -0400 From: John Cowan Organization: Lojban Peripheral X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT References: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> <001f01beccf9$d37473e0$dd066d8c@sinica.edu.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Rick Jelliffe wrote: > I am confused about a related question: I have heard somewhere that > the XPointer group was going to make XPointers only valid for pointing > into XML documents. So, for example, it would not be legitimate for > an XPointer to point into a WebCGM document or other structured data. Is this true? Since XPointers refer explicitly to element trees with attributes, an XPointer into CGM (which is a binary format) wouldn't make much sense. The real issue is whether XPointers can point into things like SMIL documents, which "just happen" to be encoded in XML. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA28732 for ietf-xml-mime-bks; Mon, 12 Jul 1999 23:33:35 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA28728 for ; Mon, 12 Jul 1999 23:33:32 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id OAA04913 for ; Tue, 13 Jul 1999 14:34:34 +0800 (CST) Message-ID: <001f01beccf9$d37473e0$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: References: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT Date: Tue, 13 Jul 1999 14:34:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: From: MURATA Makoto > > Having finished my summary, I have one question for clarification. Did the > XML Linking WG want to use XPointer only when the media type is text/xml or > application/xml? Or, did they want to use XPointer for other xml-based media > types, but give up simply because the current media type mechanism cannot > specify "This is of the media type "model/foo" which is based on XML"? I am confused about a related question: I have heard somewhere that the XPointer group was going to make XPointers only valid for pointing into XML documents. So, for example, it would not be legitimate for an XPointer to point into a WebCGM document or other structured data. Is this true? Also, there seems to be paradigm difference between the conventional idea of a URL (which fetches some resource) and an XPointer (which points to some span in some resource but doesn't necessarily return anything). I had a bit of difficulty with this at first, and I suspect that others with HTML expectations will be the same. Murata-san's question relates to this too: does an XLink always return a resource. If XPointers can only be used with XLinks, does that mean that XPointers always return a resource too? If the resource returned is different from a type attribute, is it always an error? Rick Jelliffe Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA23874 for ietf-xml-mime-bks; Mon, 12 Jul 1999 22:07:59 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23870 for ; Mon, 12 Jul 1999 22:07:56 -0700 (PDT) Received: by mx.fujixerox.co.jp; id OAA16057; Tue, 13 Jul 1999 14:09:03 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma015936; Tue, 13 Jul 99 14:08:30 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id OAA19520 for ; Tue, 13 Jul 1999 14:06:49 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id OAA20784 for ; Tue, 13 Jul 1999 14:08:28 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id OAA25123 for ; Tue, 13 Jul 1999 14:05:56 +0900 Message-Id: <199907130509.AA01078@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 13 Jul 1999 14:09:37 +0900 To: ietf-xml-mime@imc.org Subject: Media typs and XPointer, XLink, XPath, and XSLT In-Reply-To: <3.0.32.19990712105747.00ea7d04@pophost.arbortext.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-Unsubscribe: Paul Grosso wrote: > I'm not nearly an expert in this area as you are, so I'm a bit > nervous answering, but I'm the one that has been championing that > language in XPointer (and XLink) based on an understanding of things > that is different from what you say above. Thanks for your flattering comments, but I am not a real expert. Probably nobody know all of XLink, XPointer, XML, MIME, conneg, SMTP, HTTP, etc. I certainly do not, as You and Tim proved. Just in case some participants do not know XLink, XPointer, XSLT, and XPath, let me give a very rough overview. XPointer allows you to say "Give me the second of the third
of this XML document". Since XPointer is a string, you can use it as a fragment identifier. XLink provides allows you to specify links with XML elements. Such links may use XPointer to specify ends of links. But XLink can also reference to non-XML data. Thus, even if a link is expressed in XLink, we do not really know whether its ends are XPointer or not. As a special case, if bare names are used as fragment identifiers, they are interpreted as HTML fragment identifiers or XPointer depending on the media type. Since the semantics of bare name XPointers is identical to that of HTML fragment identifiers, this flexibility does not cause any problems. XSLT is a transformation language which transforms XML to XML or HTML. An XSLT stylesheet often contain rules such as "For each , generate a

element" or even "For each below each

, generate ...". Thus, XSLT needs something similar to XPointer. XPath was created to capture common mechanisms between XSLT and XPointer. XPointer and XSLT can be considered as extensions of XPath. Unlike XPointer, neither the XPath nor XSLT specification mention media types text/xml and application/xml. This looks reasonable, since the XSLT engine just knows that it is transforming XML. Note: there is an issue about "Multiple Source Documents" of XSLT. The subsection for the "document" function has an interesting issue as below: Issue (document-media-type): What are legal media types for the resource referenced by document()? For example, what happens if referencing the URI returns data with media type text/plain? Having finished my summary, I have one question for clarification. Did the XML Linking WG want to use XPointer only when the media type is text/xml or application/xml? Or, did they want to use XPointer for other xml-based media types, but give up simply because the current media type mechanism cannot specify "This is of the media type "model/foo" which is based on XML"? Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17286 for ietf-xml-mime-bks; Mon, 12 Jul 1999 10:13:35 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17281 for ; Mon, 12 Jul 1999 10:13:33 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id KAA19629; Mon, 12 Jul 1999 10:14:17 -0700 Message-Id: <3.0.32.19990712101415.0121d380@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 Jul 1999 10:14:26 -0700 To: MURATA Makoto , ietf-xml-mime@imc.org From: Tim Bray Subject: Re: xml-mime status? 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 07:24 PM 7/12/99 +0900, MURATA Makoto wrote: >>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". > >I have a question. Why do we have to use media types here? If an XML >document contains a link which takes advantage of XPointer, we just know >that the URI references to an XML document and thus do not have to be >notified by XML media types. No. Because of the following: 1. You can't tell what the media type of a resource is without getting it 2. Xpointers are not sufficiently distinguishable from all other types of fragment identfiers by syntax alone So you have to ascertain the media type of the resource to determine whether XPointer is the appropriate fragment identifier syntax. -Tim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15361 for ietf-xml-mime-bks; Mon, 12 Jul 1999 08:57:39 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15357 for ; Mon, 12 Jul 1999 08:57:38 -0700 (PDT) Message-Id: <3.0.32.19990712105747.00ea7d04@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 Jul 1999 10:58:43 -0500 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: xml-mime status? 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 19:24 1999 07 12 +0900, MURATA Makoto wrote: >2) Announcement of a new draft of XPointer (http://www.w3.org/TR/WD-xptr) > >>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". > >I have a question. Why do we have to use media types here? If an XML >document contains a link which takes advantage of XPointer, we just know >that the URI references to an XML document and thus do not have to be >notified by XML media types. I'm not nearly an expert in this area as you are, so I'm a bit nervous answering, but I'm the one that has been championing that language in XPointer (and XLink) based on an understanding of things that is different from what you say above. My understanding is that the interpretation of the fragment identifier in URI-references (RFC 2396) is determined by the media type of the resource referenced by the URI in the URI-reference. It is *not* the case that any fragment identifer in any URI-reference *embedded in* an XML resource is necessarily an XPointer. Also, it is not always the case that one can look at a URI-reference and tell that the fragment identifier "takes advantage of XPointer." Finally, though the fragment identifier of a URI-reference into an XML resource must be an XPointer, there is nothing that prevents XPointer from being used as the syntax for a fragment identifier into a non-XML resource (i.e., the converse of "if the resource is XML, the fragment identifier is an XPointer" is not necessarily true). So I'd say that is why XPointer must and should mention media types, and I'd disagree with your statement "If an XML document contains a link which takes advantage of XPointer, we just know that the URI references an XML document...." I hope I will be corrected if I'm mistaken. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA08797 for ietf-xml-mime-bks; Mon, 12 Jul 1999 03:22:27 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA08793 for ; Mon, 12 Jul 1999 03:22:25 -0700 (PDT) Received: by mx.fujixerox.co.jp; id TAA22629; Mon, 12 Jul 1999 19:23:28 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma022587; Mon, 12 Jul 99 19:22:59 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id TAA23779 for ; Mon, 12 Jul 1999 19:21:19 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id TAA22783 for ; Mon, 12 Jul 1999 19:22:58 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id TAA22960 for ; Mon, 12 Jul 1999 19:20:27 +0900 Message-Id: <199907121024.AA01071@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 12 Jul 1999 19:24:07 +0900 To: ietf-xml-mime@imc.org Subject: Re: xml-mime status? In-Reply-To: <199907112238.SAA08884@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent wrote: > The last message on this list was 6/2/99. Is there any activity going on, > or have we all taken the summer (or winter, southern hemisphere) off? Two things recently happened. 1) Announcement of the first draft of XPath (http://www.w3.org/TR/xpath) This specification does not reference to media types. 2) Announcement of a new draft of XPointer (http://www.w3.org/TR/WD-xptr) >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". I have a question. Why do we have to use media types here? If an XML document contains a link which takes advantage of XPointer, we just know that the URI references to an XML document and thus do not have to be notified by XML media types. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06457 for ietf-xml-mime-bks; Sun, 11 Jul 1999 15:37:45 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06453 for ; Sun, 11 Jul 1999 15:37:44 -0700 (PDT) Received: from thinkpad (slip129-37-221-235.ny.us.ibm.net [129.37.221.235]) by hesketh.net (8.9.3/8.9.3) with SMTP id SAA08884 for ; Sun, 11 Jul 1999 18:38:36 -0400 Message-Id: <199907112238.SAA08884@hesketh.net> X-Sender: simonstl@pop.hesketh.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 11 Jul 1999 18:41:48 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: xml-mime status? In-Reply-To: <199906021433.KAA27217@hesketh.net> References: <199905280157.AA00636@archlute.apsdc.ksp.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-Unsubscribe: The last message on this list was 6/2/99. Is there any activity going on, or have we all taken the summer (or winter, southern hemisphere) off? I think all the questions we've examined are still worth solving. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com