Received: by mail.imc.org (8.9.3/8.9.3) id IAA17794 for ietf-xml-mime-bks; Thu, 30 Sep 1999 08:43:41 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17790 for ; Thu, 30 Sep 1999 08:43:40 -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 LAA23986; Thu, 30 Sep 1999 11:44:30 -0400 Message-ID: <37F3855A.2E88B13E@w3.org> Date: Thu, 30 Sep 1999 17:44:26 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D References: <001b01bf0b52$d361f7a0$f84a5c8b@makoto> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: MURATA Makoto wrote: > > Chris, > > I think that this is a very interesting issue. Let me ask some questions. > > Q1. If you introduce a media type "image/svg", you can certainly introduce > SVG-specific fragment > identifiers. There are two issues here. Firstly, since it is defining a media type, it needs to define what the fragment identifier syntax is. We use XPointer, but in this release restict it to pointing to IDs. This is because we want a spec that is fully implemented very rapidly. Later versions will probably remove this restriction, once XLink and XPointer are more established. Secondly, since XPointer wisely moved toa prefixed syntax, ie xptr(), it becomes possible to define other syntaxes. For example, a means of linking to particular time periods, or a way of linking to particular geometric regions, and so on. Thisis sonmething that SVG might be intereste din later, but we have not done this for SVG 1.0 > But are you willing to give up referencing into SVG embedded > into XHTML? I don't see how I am giving this up. Such a file would not be served up as image/svg (or indeed as image/svg-xml) - it would be served up as application/xml, or application/xhtml-xml, or something else. > Q2. How do you feel about making fragment identifiers namespace -sensitive? > For example, "if the > root element is of the namespace for SVG, the fragment identifier is > interpreted as ...." That might be possible, but at the moment they are dependent on the media type only. > Q3. If we really want to make fragment identifiers namespace- sensitive, we > can even interpret > different portions of a single fragment identifier differently. For > example, the first two conditions > are interpreted as XPath and the third condition is interpreted as SVG > fragment identifier, and You seem to be under the impresion that SVG has some special fragment syntax. It has a proper subset of XPointer. > the forth condition is intepreted as XPath (i.e., references into XHTML > embedded in the SVG). > How do you feel? I would like to understand what you mean by "SVG fragment identifier" before being able to answer how I feel. I need to understand your question better first. -- Chris Received: by mail.imc.org (8.9.3/8.9.3) id HAA16815 for ietf-xml-mime-bks; Thu, 30 Sep 1999 07:46:55 -0700 (PDT) Received: from out1.prserv.net (out1.prserv.net [165.87.194.252]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA16811 for ; Thu, 30 Sep 1999 07:46:54 -0700 (PDT) Received: from makoto (slip139-92-74-248.pa.fr.ibm.net [139.92.74.248]) by out1.prserv.net (/) with SMTP id OAA39018 for ; Thu, 30 Sep 1999 14:47:45 GMT Message-ID: <001b01bf0b52$d361f7a0$f84a5c8b@makoto> Reply-To: "MURATA Makoto" From: "MURATA Makoto" To: Subject: RE: Announcement of an I-D Date: Thu, 30 Sep 1999 23:48:03 +0900 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 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Chris, I think that this is a very interesting issue. Let me ask some questions. Q1. If you introduce a media type "image/svg", you can certainly introduce SVG-specific fragment identifiers. But are you willing to give up referencing into SVG embedded into XHTML? Q2. How do you feel about making fragment identifiers namespace -sensitive? For example, "if the root element is of the namespace for SVG, the fragment identifier is interpreted as ...." Q3. If we really want to make fragment identifiers namespace- sensitive, we can even interpret different portions of a single fragment identifier differently. For example, the first two conditions are interpreted as XPath and the third condition is interpreted as SVG fragment identifier, and the forth condition is intepreted as XPath (i.e., references into XHTML embedded in the SVG). How do you feel? Q3 might be a crazy idea. But we have to consider non-monolithic XML seriously, since it is so common. Cheers, -----Original Message----- >> Although we >> do not actually believe this I-D is the right place for these media types, we strongly >> believe that we need some consistent story for XML-based languages of W3C. > >I agree. > >The SVG WG (of which I am chair) plans to submit an Internet Media Type >registration for SVG once that specification is stable (ie, W3C >Recommendation). > >-- >Chris > Received: by mail.imc.org (8.9.3/8.9.3) id JAA28668 for ietf-xml-mime-bks; Wed, 29 Sep 1999 09:40:21 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA28664 for ; Wed, 29 Sep 1999 09:40:18 -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 MAA26339; Wed, 29 Sep 1999 12:40:50 -0400 Message-ID: <37F24112.7CC34039@w3.org> Date: Wed, 29 Sep 1999 18:40:50 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Simon St.Laurent" CC: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D References: <199909270230.AA02229@archlute.fujixerox.co.jp> <199909291221.IAA29207@hesketh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Simon St.Laurent" wrote: > > At 01:46 PM 9/29/99 +0200, Chris Lilley wrote: > > I need to read this ID closely to see what an > >implementation might be expected to infer (or not) on getting a > >foo/bar-xml-baz mimetype. Is this written in XML or not? > > I don't think xml- is introduced as a general convention for anything. > xml-dtd can be the form for XML DTD information in large part because DTD > files are not themselves well-formed XML documents. Agreed. Could the same type be used for other "parts of xml" which are not by themselves well-formed xml documents? I am thinking of external parsed entities. > According to this draft, foo/bar-xml-baz should _not_ be XML, and neither > should foo/xml-bar-baz. foo/bar-baz-xml should be XML. OK, so it has to be the terminal part of the name. Good. > >OK, will check exactly what promises image/svg-xml makes (in particular > >regarding XPointer as a fragment identifier) > > All suggestions regarding the fragment identifier issue are welcome. My > personal take is that non-SVG XML could (and in fact would probably have > to) use conventional XPointers to reference _into_ SVG documents, making > the -xml suffix important for identification. This would not, however, > constrain SVG documents from using their own fragment identifiers to > reference other SVG documents. Hmm. I think you have that backwards. It is not where the reference comes *from* that is important, but what it points *into*. Because the fragment goes onto the end of a url. Consider for example an xml file which contained a link to the third picture in a CGM file. The URL would be that of the CGM, and the fragment syntax used would be the WebCGM fragment syntax, not Xpointer. Conversely, A WebCGM which contained a link into the third paragraph of an XML file would use XPointer as the fragment identifier on the end of the URL that pointed to the XML document. -- Chris Received: by mail.imc.org (8.9.3/8.9.3) id FAA25289 for ietf-xml-mime-bks; Wed, 29 Sep 1999 05:20:38 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA25285 for ; Wed, 29 Sep 1999 05:20:36 -0700 (PDT) Received: from thinkpad (slip129-37-221-4.ny.us.ibm.net [129.37.221.4]) by hesketh.net (8.9.3/8.9.3) with SMTP id IAA29207; Wed, 29 Sep 1999 08:21:12 -0400 Message-Id: <199909291221.IAA29207@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 29 Sep 1999 08:24:45 -0400 To: Chris Lilley , ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Announcement of an I-D Cc: ietf-xml-mime@imc.org In-Reply-To: <37F1FC23.6137D013@w3.org> References: <199909270230.AA02229@archlute.fujixerox.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 01:46 PM 9/29/99 +0200, Chris Lilley wrote: >MURATA Makoto wrote: >> 1. On top of text/xml and application/xml, this I-D further introduces >> application/xml-dtd. >> >> 2. The "*/*-xml" convention is introduced. Throw a rock on it if you disagree. > >OK, so both -xml and xml- are intrduced, with differeing meanings. This >is fine, but I need to read this ID closely to see what an >implementation might be expected to infer (or not) on getting a >foo/bar-xml-baz mimetype. Is this written in XML or not? I don't think xml- is introduced as a general convention for anything. xml-dtd can be the form for XML DTD information in large part because DTD files are not themselves well-formed XML documents. According to this draft, foo/bar-xml-baz should _not_ be XML, and neither should foo/xml-bar-baz. foo/bar-baz-xml should be XML. >> 4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and image/svg-xml >> are used as examples. Concerned citizens are invited to send comments. > >OK, will check exactly what promises image/svg-xml makes (in particular >regarding XPointer as a fragment identifier) All suggestions regarding the fragment identifier issue are welcome. My personal take is that non-SVG XML could (and in fact would probably have to) use conventional XPointers to reference _into_ SVG documents, making the -xml suffix important for identification. This would not, however, constrain SVG documents from using their own fragment identifiers to reference other SVG documents. This is a critical point that needs more discussion from as many parties as possible. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com Received: by mail.imc.org (8.9.3/8.9.3) id EAA24986 for ietf-xml-mime-bks; Wed, 29 Sep 1999 04:46:10 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA24982 for ; Wed, 29 Sep 1999 04:46:08 -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 HAA02458; Wed, 29 Sep 1999 07:46:52 -0400 Message-ID: <37F1FC23.6137D013@w3.org> Date: Wed, 29 Sep 1999 13:46:43 +0200 From: Chris Lilley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: Announcement of an I-D References: <199909270230.AA02229@archlute.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: MURATA Makoto wrote: > 1. On top of text/xml and application/xml, this I-D further introduces > application/xml-dtd. > > 2. The "*/*-xml" convention is introduced. Throw a rock on it if you disagree. OK, so both -xml and xml- are intrduced, with differeing meanings. This is fine, but I need to read this ID closely to see what an implementation might be expected to infer (or not) on getting a foo/bar-xml-baz mimetype. Is this written in XML or not? > 4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and image/svg-xml > are used as examples. Concerned citizens are invited to send comments. OK, will check exactly what promises image/svg-xml makes (in particular regarding XPointer as a fragment identifier) > Although we > do not actually believe this I-D is the right place for these media types, we strongly > believe that we need some consistent story for XML-based languages of W3C. I agree. The SVG WG (of which I am chair) plans to submit an Internet Media Type registration for SVG once that specification is stable (ie, W3C Recommendation). -- Chris Received: by mail.imc.org (8.9.3/8.9.3) id TAA19554 for ietf-xml-mime-bks; Sun, 26 Sep 1999 19:30:23 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA19545 for ; Sun, 26 Sep 1999 19:30:21 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA12924; Mon, 27 Sep 1999 11:30:56 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma012256; Mon, 27 Sep 99 11:30:10 +0900 Received: from pumpkin.greens.fxis.fujixerox.co.jp ([131.221.160.133]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA20720 for ; Mon, 27 Sep 1999 11:28:43 +0900 (JST) Received: from archlute.fujixerox.co.jp (dhcp-1a6-169.greens.fxis.fujixerox.co.jp [131.221.160.169]) by pumpkin.greens.fxis.fujixerox.co.jp (8.9.3/3.7W) with SMTP id LAA71115 for ; Mon, 27 Sep 1999 11:28:26 +0900 (JST) Message-Id: <199909270230.AA02229@archlute.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 27 Sep 1999 11:30:52 +0900 To: ietf-xml-mime@imc.org Subject: Announcement of an I-D 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 and I co-authored an I-D for XML media types. It is available at: http://www.ietf.org/internet-drafts/draft-murata-xml-00.txt This I-D is based on the discussion in this mailing list. Major differences from RFC 2376 are as below: 1. On top of text/xml and application/xml, this I-D further introduces application/xml-dtd. 2. The "*/*-xml" convention is introduced. Throw a rock on it if you disagree. 3. Some remaining issues are pointed out. 4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and image/svg-xml are used as examples. Concerned citizens are invited to send comments. Although we do not actually believe this I-D is the right place for these media types, we strongly believe that we need some consistent story for XML-based languages of W3C. FYI: An I-D for text/html is avilable at: http://www.ietf.org//internet-drafts/draft-connolly-text-html-00.txt Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp