Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PF1sZL081716; Fri, 25 Feb 2005 07:01:54 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PF1sGD081715; Fri, 25 Feb 2005 07:01:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from ati-fe01.arbortext.local (smtpgw4.arbortext.com [198.108.59.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PF1mot081691 for ; Fri, 25 Feb 2005 07:01:48 -0800 (PST) (envelope-from pgrosso@arbortext.com) Received: from ati-mail01.arbortext.local ([172.27.10.13]) by ati-fe01.arbortext.local with Microsoft SMTPSVC(6.0.3790.80); Fri, 25 Feb 2005 10:01:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on new draft of 3023bis (fragments, xpointer) Date: Fri, 25 Feb 2005 10:01:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on new draft of 3023bis (fragments, xpointer) thread-index: AcUbPAlSNDsCzYc2RUyDAze6uu/4qQADXCig From: "Paul Grosso" To: "Chris Lilley" Cc: "Martin Duerst" , "Henry S. Thompson" , , "MURATA Makoto" , "Philippe Le Hegaret" X-OriginalArrivalTime: 25 Feb 2005 15:01:41.0480 (UTC) FILETIME=[E9D97680:01C51B4A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1PF1mot081704 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: Chris Lilley [mailto:chris@w3.org] > Sent: Friday, 25 February, 2005 7:15 > To: Paul Grosso > Cc: Martin Duerst; Henry S. Thompson; ietf-xml-mime@vpnc.org; > MURATA Makoto; Philippe Le Hegaret > Subject: Re: Comments on new draft of 3023bis (fragments, xpointer) > > On Friday, February 25, 2005, 5:20:01 AM, Paul wrote: > > PG> That's why I think it is important to say that the > PG> fragment identifier syntax for the XML type is just > PG> the XPointer Framework and Element() scheme, and > PG> nothing else--all other schemes must be ignored. > > To be clear - you are saying that > > - for application/xml > - for unknown +xml media types being processed as xml > > the fragment identifier syntax for the XML type is just the XPointer > Framework and Element() scheme, and nothing else--all other > schemes must be ignored. Correct. > "Ignored" needs to be further defined (ie, it does not cause > an error). I mean "ignored" in the sense that is defined in the XPointer Framework spec which explains how to handle an xpointer with schemes that are not recognized/supported. (I agree we need to get precise wording, but I hope what I'm trying to say is clear by reference to the XPointer Framework spec.) > And to be clear, you are *not* saying that > > - any +xml media type is forbidden from defining its own, richer, > fragment identifier syntax in addition to that defined fro +xml as a > whole. > > Right? Correct--another media type can say whatever it wants in this regard. paul Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDFHnS059231; Fri, 25 Feb 2005 05:15:17 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PDFHnh059210; Fri, 25 Feb 2005 05:15:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDFCGD059198 for ; Fri, 25 Feb 2005 05:15:13 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 7B1E54EF96; Fri, 25 Feb 2005 08:15:09 -0500 (EST) Date: Fri, 25 Feb 2005 14:15:10 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1809025484.20050225141510@w3.org> To: "Paul Grosso" Cc: "Martin Duerst" , "Henry S. Thompson" , ietf-xml-mime@vpnc.org, "MURATA Makoto" , "Philippe Le Hegaret" Subject: Re: Comments on new draft of 3023bis (fragments, xpointer) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, February 25, 2005, 5:20:01 AM, Paul wrote: PG> That's why I think it is important to say that the PG> fragment identifier syntax for the XML type is just PG> the XPointer Framework and Element() scheme, and PG> nothing else--all other schemes must be ignored. To be clear - you are saying that - for application/xml - for unknown +xml media types being processed as xml the fragment identifier syntax for the XML type is just the XPointer Framework and Element() scheme, and nothing else--all other schemes must be ignored. "Ignored" needs to be further defined (ie, it does not cause an error). And to be clear, you are *not* saying that - any +xml media type is forbidden from defining its own, richer, fragment identifier syntax in addition to that defined fro +xml as a whole. Right? -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDBOIG058128; Fri, 25 Feb 2005 05:11:24 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PDBOCc058127; Fri, 25 Feb 2005 05:11:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDBElj058065 for ; Fri, 25 Feb 2005 05:11:15 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id B7E4D4F3FC; Fri, 25 Feb 2005 08:11:10 -0500 (EST) Date: Fri, 25 Feb 2005 14:11:11 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <115882260.20050225141111@w3.org> To: MURATA Makoto Cc: ht@inf.ed.ac.uk (Henry S. Thompson), ietf-xml-mime@vpnc.org Subject: Re: Comments on new draft of 3023bis In-Reply-To: <20050225130310.11B9.MURATA@hokkaido.email.ne.jp> References: <20050225130310.11B9.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, February 25, 2005, 1:19:23 PM, MURATA wrote: MM> Henry, MM> Given the unfortunate history (see below) of XPointer, I would MM> like to introduce a bare minimum into the XML at this stage of MM> the game. MM> XPointer was originally a small part of XLink (links for XML) MM> in 1997. But XPointer grew to become a single specification MM> in 1999. After the addition of the xmlns scheme, XPointer MM> became too complicated as a single specification. Thus, it MM> was divided into four specifications (the framework, element MM> scheme, xmlns scheme, and xpointer scheme) in 2002. Three of MM> them reached the W3C Recommendation status in 2003, but the MM> other (the xpointer scheme) is still a working draft and it MM> has not been revised since 2002. MM> The XPointer framework allows other schemes to be added. Some MM> schemes have been proposed. For example, SVG has its own MM> scheme. W3C may create a registry of such schemes, but we do MM> not know when W3C will do so. In effect, the individual media type registrations are that registry. According to AWWW, the interpretation of a fragment identifier is solely in the context of the media type it is applied to. So in the SVG example, the fragment scheme for SVG applies only to resources served as svg. Similarlyfor WebCGM which defines its own fragment identifiers. MM> Unfortunately, neither XLink nor XPointer has been widely MM> implemented yet. Even the framework and element scheme of MM> XPointer have not been successful. Let alone the xpointer MM> scheme. Some people are against the xpointer scheme, and MM> others are skeptical about the XPointer family as a whole. MM> A small subset of XPointer combined with XInclude is hopeful, MM> however. The Xpath1 scheme is one such possible subset, although it does not seem to be further developed. http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-01.html >> > Who maintains the registry of user-defined schemes? >> >> The W3C has committed to doing so at some point, but no definitive >> timeframe is known. It has? Where? MM> I think that this is already a good reason not allow user-defined MM> schemes for application/xml. When W3C is not willing to acknowledge MM> other schemes, I do not think that IETF has to allow them. >> > I do not want to open this can of worms at this stage of the game. >> >> I guess I do. The XPointer framework spec. is intentionally >> open-ended, _and_ it makes clear that only shorthand pointers >> (i.e. #+barename) MUST be supported, and clearly provides for >> processors to fail if they encounter a scheme they don't support. MM> A minimum conformance level of XPointer is not defined by MM> the XPointer recommendations. You are proposing to define it MM> in the XML media type RFC. I am not thrilled to do so. >> Seems to me straightforward for 3023bis to say, consistently with >> that, that shorthand and element schemes must be supported, and that other >> schemes may be used but SHOULD be avoided for interoperability unless >> the scheme is appropriately registered and standardised. MM> Sounds simple (in theory), but I am worried that the added complexity MM> is good enough to hamper the adoption of XPointer. >> The tremendous advantage of doing it this way is that 3023bis does not >> then have to be re-issued every time a new XPointer scheme is blessed. MM> Anyway, we will have to issue another RFC when W3C starts a registry of MM> xpointer schemes. MM> Cheers, -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PCKucI042025; Fri, 25 Feb 2005 04:20:56 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PCKuTJ042024; Fri, 25 Feb 2005 04:20:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PCKrDs042007 for ; Fri, 25 Feb 2005 04:20:53 -0800 (PST) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (j107063.ppp.asahi-net.or.jp [61.213.107.63]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 8ADF61A701; Fri, 25 Feb 2005 21:20:52 +0900 (JST) Date: Fri, 25 Feb 2005 21:19:54 +0900 From: MURATA Makoto To: Martin Duerst Subject: Re: Comments on new draft of 3023bis (fragments, xpointer) Cc: "Paul Grosso" , "Henry S. Thompson" , ietf-xml-mime@vpnc.org, Philippe Le Hegaret In-Reply-To: <6.0.0.20.2.20050225082654.09d5d760@localhost> References: <6.0.0.20.2.20050225082654.09d5d760@localhost> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.030 Message-Id: <20050225131031.11BB.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Martin, As I said in my reply to Henry, I would like to allow a bare minimum as fragment identifiers for application/xml. > First, I think that the sentence: > > "In particular, the xpointer scheme MUST NOT be specified > since it is still at the W3C working draft stage." > > is rather inappropriate. There is nothing special to the > xpointer scheme here; there may be many other schemes that > are still at a draft stage at one point or another. I am happy to bless the element scheme only and not mention any other schemes. > On top of that, there would be the question of why > xpointer needs to be called out specifically if the use > of any other schemes is prohibited anyway. But I think > prohibiting the use of any other schemes is a bad idea, > and is in conflict with the spirit if not the wording > of the XPointer Framework. Here we disagree. Given that XPointer has not been successful, I would like to keep fragment identifiers as simple as possible. > > I think there are still at least two ways we could define > things to work: > > a) Other XPointer schemes are allowed but SHOULD/MUST be ignored. > > b) Other XPointer schemes are allowed and MAY be interpreted, > but there is no guarantee that any receipient will understand > any of them. Both are attempts to define conformance levels of XPointer implementations. Since the XPointer recommendations do not define such conformance levels, I do not want to try at IETF. Cheers, -- MURATA Makoto Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PCKpLs042003; Fri, 25 Feb 2005 04:20:51 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PCKpfb042002; Fri, 25 Feb 2005 04:20:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PCKduQ041881 for ; Fri, 25 Feb 2005 04:20:48 -0800 (PST) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (j107063.ppp.asahi-net.or.jp [61.213.107.63]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 12F6D18924; Fri, 25 Feb 2005 21:20:22 +0900 (JST) Date: Fri, 25 Feb 2005 21:19:23 +0900 From: MURATA Makoto To: ht@inf.ed.ac.uk (Henry S. Thompson) Subject: Re: Comments on new draft of 3023bis Cc: ietf-xml-mime@vpnc.org In-Reply-To: References: X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.030 Message-Id: <20050225130310.11B9.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Henry, Given the unfortunate history (see below) of XPointer, I would like to introduce a bare minimum into the XML at this stage of the game. XPointer was originally a small part of XLink (links for XML) in 1997. But XPointer grew to become a single specification in 1999. After the addition of the xmlns scheme, XPointer became too complicated as a single specification. Thus, it was divided into four specifications (the framework, element scheme, xmlns scheme, and xpointer scheme) in 2002. Three of them reached the W3C Recommendation status in 2003, but the other (the xpointer scheme) is still a working draft and it has not been revised since 2002. The XPointer framework allows other schemes to be added. Some schemes have been proposed. For example, SVG has its own scheme. W3C may create a registry of such schemes, but we do not know when W3C will do so. Unfortunately, neither XLink nor XPointer has been widely implemented yet. Even the framework and element scheme of XPointer have not been successful. Let alone the xpointer scheme. Some people are against the xpointer scheme, and others are skeptical about the XPointer family as a whole. A small subset of XPointer combined with XInclude is hopeful, however. > > Who maintains the registry of user-defined schemes? > > The W3C has committed to doing so at some point, but no definitive > timeframe is known. I think that this is already a good reason not allow user-defined schemes for application/xml. When W3C is not willing to acknowledge other schemes, I do not think that IETF has to allow them. > > I do not want to open this can of worms at this stage of the game. > > I guess I do. The XPointer framework spec. is intentionally > open-ended, _and_ it makes clear that only shorthand pointers > (i.e. #+barename) MUST be supported, and clearly provides for > processors to fail if they encounter a scheme they don't support. A minimum conformance level of XPointer is not defined by the XPointer recommendations. You are proposing to define it in the XML media type RFC. I am not thrilled to do so. > Seems to me straightforward for 3023bis to say, consistently with > that, that shorthand and element schemes must be supported, and that other > schemes may be used but SHOULD be avoided for interoperability unless > the scheme is appropriately registered and standardised. Sounds simple (in theory), but I am worried that the added complexity is good enough to hamper the adoption of XPointer. > The tremendous advantage of doing it this way is that 3023bis does not > then have to be re-issued every time a new XPointer scheme is blessed. Anyway, we will have to issue another RFC when W3C starts a registry of xpointer schemes. Cheers, -- MURATA Makoto Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P4KHsJ097989; Thu, 24 Feb 2005 20:20:28 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1P4KHj6097988; Thu, 24 Feb 2005 20:20:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from ati-fe01.arbortext.local (smtpgw4.arbortext.com [198.108.59.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P4KFak097979 for ; Thu, 24 Feb 2005 20:20:16 -0800 (PST) (envelope-from pgrosso@arbortext.com) Received: from ati-mail01.arbortext.local ([172.27.10.13]) by ati-fe01.arbortext.local with Microsoft SMTPSVC(6.0.3790.80); Thu, 24 Feb 2005 23:20:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on new draft of 3023bis (fragments, xpointer) Date: Thu, 24 Feb 2005 23:20:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on new draft of 3023bis (fragments, xpointer) thread-index: AcUa5nOtODduBZteTt6qXdDKQyjY4wACNSLA From: "Paul Grosso" To: "Martin Duerst" , "Henry S. Thompson" , , "MURATA Makoto" Cc: "Philippe Le Hegaret" X-OriginalArrivalTime: 25 Feb 2005 04:20:08.0839 (UTC) FILETIME=[4A729170:01C51AF1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1P4KGak097983 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just a couple thoughts in return embedded below in an excerpt of your email. > -----Original Message----- > From: Martin Duerst [mailto:duerst@w3.org] > Sent: Thursday, 24 February, 2005 18:11 > To: Paul Grosso; Henry S. Thompson; ietf-xml-mime@vpnc.org; > MURATA Makoto > Cc: Philippe Le Hegaret > Subject: RE: Comments on new draft of 3023bis (fragments, xpointer) > > I have read the relevant part of the new draft, and I have > to say that I have to agree with Henry on this point. > > First, I think that the sentence: > > "In particular, the xpointer scheme MUST NOT be specified > since it is still at the W3C working draft stage." > > is rather inappropriate. There is nothing special to the > xpointer scheme here; there may be many other schemes that > are still at a draft stage at one point or another. I can agree with that. I think the xpointer scheme was originally called out because of the confusion between "XPointer" (Framework) which is a Rec and the "xpointer scheme" which was what some folks thought xpointer was going to be but which has basically been abandoned. But at this point, I agree there is no strong reason to mention it explicitly. > > I think there are still at least two ways we could define > things to work: > > a) Other XPointer schemes are allowed but SHOULD/MUST be ignored. Saying other xpointer schemes are allowed but MUST be ignored would be fine with me. > > >I want a relatively > >simple fragment identifier for XML, and I don't really > >want it to keep growing. We're talking about something > >that needs to be processed every time someone clicks on > >a URI that references an XML resource, and we don't need > >complexity here. > > Agreed. But if the sender says "I want you to get exactly > here, and if that doesn't work, I don't care if you only > get the document overall", that's just fine, isn't it? No, you're thinking about browsers "going" somewhere. That's not the important case. XML isn't primarily about display, it's about information. Xpointers define a subresource that gets used in some fashion, not just displayed. It can make a big difference if someone is using an xpointer to indicate what part of an XML resource to use as an XSLT stylesheet or to XInclude into a document and instead the entire XML resource is used. That's why I think it is important to say that the fragment identifier syntax for the XML type is just the XPointer Framework and Element() scheme, and nothing else--all other schemes must be ignored. I don't want a lot of flexibility and extensibility here. If someone wants extensibility, let them define another MIME type. paul Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P32oNL091789; Thu, 24 Feb 2005 19:02:50 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1P32oT4091788; Thu, 24 Feb 2005 19:02:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1P32a2d091771 for ; Thu, 24 Feb 2005 19:02:36 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 582EE4F3F5; Thu, 24 Feb 2005 22:02:29 -0500 (EST) Message-Id: <6.0.0.20.2.20050225082654.09d5d760@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 25 Feb 2005 09:11:16 +0900 To: "Paul Grosso" , "Henry S. Thompson" , , MURATA Makoto From: Martin Duerst Subject: RE: Comments on new draft of 3023bis (fragments, xpointer) Cc: Philippe Le Hegaret In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have read the relevant part of the new draft, and I have to say that I have to agree with Henry on this point. First, I think that the sentence: "In particular, the xpointer scheme MUST NOT be specified since it is still at the W3C working draft stage." is rather inappropriate. There is nothing special to the xpointer scheme here; there may be many other schemes that are still at a draft stage at one point or another. I understand that some people like the xpointer scheme, and others don't like it at all, (and I personally don't really care too much,) but we can just avoid a lot of discussion if we simply don't talk about it. Saying something like "In particular, schemes that are still at working draft stage MUST NOT be used." also doesn't make much sense, because in some sense, it doesn't state anything more than the obvious, and in another sense, it would look like it would prohibit experiments. On top of that, there would be the question of why xpointer needs to be called out specifically if the use of any other schemes is prohibited anyway. But I think prohibiting the use of any other schemes is a bad idea, and is in conflict with the spirit if not the wording of the XPointer Framework. I think there are still at least two ways we could define things to work: a) Other XPointer schemes are allowed but SHOULD/MUST be ignored. b) Other XPointer schemes are allowed and MAY be interpreted, but there is no guarantee that any receipient will understand any of them. The reason that I think we should at least have a) is that the XPointer Framework includes this facility for fallbacks, and that this may help for fragment ids to work across different resource types. The typical example would be an application/xml and an image/svg+xml document that are content-type negotiated (the SVG document is sent to user agents that advertise that they know SVG,...). Using the XPointer Framework, it may be possible to construct a fragment identifier that points to a particular part of the graphics in the SVG document, and to the data about that part in the application/xml document. Disallowing other XPointer schemes would make the above impossible, which I think would be a pity. I'd personally be fine with either a) or b) above, but I think being more restrictive than a) is unnesessary and counterproductive. Even in the case of b), things would be written clearly enough to make sure that interoperability expectations are not set too high. We could even extend b) to say: c) Other XPointer schemes are allowed and MAY be produced if there is at least also a shorthand pointer (barename) or an element pointer, and MAY be interpreted, but there is no guarantee that any receipient will understand any of them. But I'm not sure we need to go there; there may be cases where the sender decides that the best fallback for a pointer of a special scheme is just the document as a whole. [more short comments below] At 23:53 05/02/24, Paul Grosso wrote: > >I'm not 100% certain of my position, but I tend to >agree with Makoto here. > >When talking about something as potentially ubiquitous >as fragment identifiers in URI references to XML resources, >I'd rather restrict them to something relatively simple >that we can be sure will work interoperably. Giving clear guidelines on what is expected to interoperate is definitely very good. >I would not like someone to think they can use the xpointer >scheme because it happens to work with their particular tool >set only to find out that it doesn't work when they send it >to someone else with a different tool set. We can clearly express the expectations. And those who don't get it will find out soon enough. >I realize the xpointer framework defines how to give a single >multi-schemed xpointer that provides fallbacks, and this is >supposed to allow someone to (try to) use, say, the xpointer >scheme but then fallback to the element scheme. But in >practice, many people will just use the single scheme that >works for them, and we'll be back in the non-interoperable >situation quickly. I'm not sure about this, but if that happens, people will just get what they asked for. (but also see my proposal c) above). >I guess I see no reason to revise 3023 "every time a new >xpointer scheme is blessed." I don't want new xpointer >schemes getting blessed by 3023. Agreed. >I want a relatively >simple fragment identifier for XML, and I don't really >want it to keep growing. We're talking about something >that needs to be processed every time someone clicks on >a URI that references an XML resource, and we don't need >complexity here. Agreed. But if the sender says "I want you to get exactly here, and if that doesn't work, I don't care if you only get the document overall", that's just fine, isn't it? Also, if simple fragment identifiers are good enough for most cases, that's where we will get interoperability anyway, and we don't have to be worried too much. >[Disclosure: I have always been opposed >to the xpointer scheme from day 1 of the XLink WG.] The xpointer scheme is currently a WD "in limbo", so no reason to worry about it too much, I guess. >paul [speaking only for myself] > >> -----Original Message----- >> From: owner-ietf-xml-mime@mail.imc.org >> [mailto:owner-ietf-xml-mime@mail.imc.org] On Behalf Of Henry >> S. Thompson >> Sent: Thursday, 24 February, 2005 8:11 >> To: ietf-xml-mime@vpnc.org >> Subject: Comments on new draft of 3023bis >> >> >> The new draft [1] says >> >> > 5. Fragment Identifiers >> > >> > . . . [XPointer s]chemes other than the element scheme MUST NOT be >> > specified as part of fragment identifiers for these media >> types. In >> > particular, the xpointer scheme MUST NOT be specified since it is >> > still at the W3C working draft stage. >> >> I said about this to MAKOTO Murata >> >> > This seems overly restrictive to me. The xpointer >> framework provides >> > for user-defined schemes, Yes indeed. >> >and I already know of several >> > implementations of the xpointer scheme Well, given that the xpointer scheme is only a WD, I don't think this is a good example. Of course one can experimentally use not-yet-well-defined schemes with experimental implementations, but to say something in the direction of "I want you to allow other schemes because I want to officially use xpointer now." is not a very well-based request, and I understand that some people who are not particularly fond of the XPointer scheme get a bit nervous when they see that. >> -- it seems unhelpful at least >> > to say I MUST NOT use them. I general, I agree. >> He replied: >> >> > I am sure that there are some implementations of the >> xpointer scheme. >> > However, since xpointer is still a working draft, these >> implementations >> > are not conformant and they are very unlikely to be >> interoperable. The >> > XPointer WD says "It is a draft document and may be >> updated, replaced, >> > or obsoleted by other documents at any time. It is >> inappropriate to use W3C >> > Working Drafts as reference material or to cite them as >> other than 'work >> > in progress'". Very true. But because the XPointer scheme WD already says so clearly, there is no need to mention the XPointer scheme in 3023bis. >> > As for user-defined schemes, you can always create a >> specialized media >> > type. For example, SVG has its own scheme, which is useful for >> > specialized media types for SVG. If we allow user-defined >> schemes for >> > application/xml, the definition of XML fragment >> identifiers becomes >> > open-ended. If it really follows the XPointer Framework, it is already in some sense open-ended. >> > This begs significant questions. Does the current >> > registration procedure of media types allow such open-ended >> definitions? >> >> I don't see why not. >> >> > Who maintains the registry of user-defined schemes? >> >> The W3C has committed to doing so at some point, but no definitive >> timeframe is known. If you have any input on the registration procedure,..., please contact Philippe Le Hegaret (cc'ed). >> > I do not want to open this can of worms at this stage of the game. >> >> I guess I do. The XPointer framework spec. is intentionally >> open-ended, _and_ it makes clear that only shorthand pointers >> (i.e. #+barename) MUST be supported, and clearly provides for >> processors to fail if they encounter a scheme they don't support. >> >> Seems to me straightforward for 3023bis to say, consistently with >> that, that shorthand and element schemes must be supported, >> and that other >> schemes may be used but SHOULD be avoided for interoperability unless >> the scheme is appropriately registered and standardised. I think we don't even have to talk about registered vs. unregistered schemes. Also, I'd rather talk positively about how other schemes MAY be used. The above sentence can be read as "other schemes SHOULD NOT be avoided if the scheme is appropriately registered and standardized", which may be too encourageing. Regards, Martin. >> The tremendous advantage of doing it this way is that 3023bis does not >> then have to be re-issued every time a new XPointer scheme is blessed. >> >> ht >> >> [1] >> http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-x >ml-01.txt >> -- >> Henry S. Thompson, HCRC Language Technology Group, >> University of Edinburgh >> Half-time member of W3C Team >> 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) >> 131 650-4440 >> Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk >> URL: http://www.ltg.ed.ac.uk/~ht/ >> [mail really from me _always_ has this .sig -- mail without >> it is forged spam] >> >> Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEtBWZ038586; Thu, 24 Feb 2005 06:55:11 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OEtBmC038585; Thu, 24 Feb 2005 06:55:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from ati-fe01.arbortext.local (smtpgw4.arbortext.com [198.108.59.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEtAwY038578 for ; Thu, 24 Feb 2005 06:55:10 -0800 (PST) (envelope-from pgrosso@arbortext.com) Received: from ati-mail01.arbortext.local ([172.27.10.13]) by ati-fe01.arbortext.local with Microsoft SMTPSVC(6.0.3790.80); Thu, 24 Feb 2005 09:55:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on new draft of 3023bis Date: Thu, 24 Feb 2005 09:53:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on new draft of 3023bis thread-index: AcUaezKRhh6IFhgQTxy0r20PozMhRgAA4taQ From: "Paul Grosso" To: "Henry S. Thompson" , X-OriginalArrivalTime: 24 Feb 2005 14:55:07.0087 (UTC) FILETIME=[D45C1DF0:01C51A80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1OEtAwY038579 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not 100% certain of my position, but I tend to agree with Makoto here. When talking about something as potentially ubiquitous as fragment identifiers in URI references to XML resources, I'd rather restrict them to something relatively simple that we can be sure will work interoperably. I would not like someone to think they can use the xpointer scheme because it happens to work with their particular tool set only to find out that it doesn't work when they send it to someone else with a different tool set. I realize the xpointer framework defines how to give a single multi-schemed xpointer that provides fallbacks, and this is supposed to allow someone to (try to) use, say, the xpointer scheme but then fallback to the element scheme. But in practice, many people will just use the single scheme that works for them, and we'll be back in the non-interoperable situation quickly. I guess I see no reason to revise 3023 "every time a new xpointer scheme is blessed." I don't want new xpointer schemes getting blessed by 3023. I want a relatively simple fragment identifier for XML, and I don't really want it to keep growing. We're talking about something that needs to be processed every time someone clicks on a URI that references an XML resource, and we don't need complexity here. [Disclosure: I have always been opposed to the xpointer scheme from day 1 of the XLink WG.] paul [speaking only for myself] > -----Original Message----- > From: owner-ietf-xml-mime@mail.imc.org > [mailto:owner-ietf-xml-mime@mail.imc.org] On Behalf Of Henry > S. Thompson > Sent: Thursday, 24 February, 2005 8:11 > To: ietf-xml-mime@vpnc.org > Subject: Comments on new draft of 3023bis > > > The new draft [1] says > > > 5. Fragment Identifiers > > > > . . . [XPointer s]chemes other than the element scheme MUST NOT be > > specified as part of fragment identifiers for these media > types. In > > particular, the xpointer scheme MUST NOT be specified since it is > > still at the W3C working draft stage. > > I said about this to MAKOTO Murata > > > This seems overly restrictive to me. The xpointer > framework provides > > for user-defined schemes, and I already know of several > > implementations of the xpointer scheme -- it seems > unhelpful at least > > to say I MUST NOT use them. > > He replied: > > > I am sure that there are some implementations of the > xpointer scheme. > > However, since xpointer is still a working draft, these > implementations > > are not conformant and they are very unlikely to be > interoperable. The > > XPointer WD says "It is a draft document and may be > updated, replaced, > > or obsoleted by other documents at any time. It is > inappropriate to use W3C > > Working Drafts as reference material or to cite them as > other than 'work > > in progress'". > > > As for user-defined schemes, you can always create a > specialized media > > type. For example, SVG has its own scheme, which is useful for > > specialized media types for SVG. If we allow user-defined > schemes for > > application/xml, the definition of XML fragment > identifiers becomes > > open-ended. This begs significant questions. Does the current > > registration procedure of media types allow such open-ended > definitions? > > I don't see why not. > > > Who maintains the registry of user-defined schemes? > > The W3C has committed to doing so at some point, but no definitive > timeframe is known. > > > I do not want to open this can of worms at this stage of the game. > > I guess I do. The XPointer framework spec. is intentionally > open-ended, _and_ it makes clear that only shorthand pointers > (i.e. #+barename) MUST be supported, and clearly provides for > processors to fail if they encounter a scheme they don't support. > > Seems to me straightforward for 3023bis to say, consistently with > that, that shorthand and element schemes must be supported, > and that other > schemes may be used but SHOULD be avoided for interoperability unless > the scheme is appropriately registered and standardised. > > The tremendous advantage of doing it this way is that 3023bis does not > then have to be re-issued every time a new XPointer scheme is blessed. > > ht > > [1] > http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-x ml-01.txt > -- > Henry S. Thompson, HCRC Language Technology Group, > University of Edinburgh > Half-time member of W3C Team > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) > 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without > it is forged spam] > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEB5oW033931; Thu, 24 Feb 2005 06:11:05 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OEB5Kg033930; Thu, 24 Feb 2005 06:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.216.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEB4Nv033920 for ; Thu, 24 Feb 2005 06:11:05 -0800 (PST) (envelope-from ht@inf.ed.ac.uk) Received: from erasmus.inf.ed.ac.uk (erasmus.inf.ed.ac.uk [129.215.218.2]) by nutty.inf.ed.ac.uk (8.12.8/8.12.8) with ESMTP id j1OEB0X8029551 for ; Thu, 24 Feb 2005 14:11:01 GMT Received: from erasmus.inf.ed.ac.uk (localhost [127.0.0.1]) by erasmus.inf.ed.ac.uk (8.12.8/8.12.8) with ESMTP id j1OEB0BG030396 for ; Thu, 24 Feb 2005 14:11:00 GMT Received: (from ht@localhost) by erasmus.inf.ed.ac.uk (8.12.8/8.12.8/Submit) id j1OEB02U030394; Thu, 24 Feb 2005 14:11:00 GMT X-Authentication-Warning: erasmus.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: ietf-xml-mime@vpnc.org Subject: Comments on new draft of 3023bis From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 24 Feb 2005 14:11:00 +0000 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The new draft [1] says > 5. Fragment Identifiers > > . . . [XPointer s]chemes other than the element scheme MUST NOT be > specified as part of fragment identifiers for these media types. In > particular, the xpointer scheme MUST NOT be specified since it is > still at the W3C working draft stage. I said about this to MAKOTO Murata > This seems overly restrictive to me. The xpointer framework provides > for user-defined schemes, and I already know of several > implementations of the xpointer scheme -- it seems unhelpful at least > to say I MUST NOT use them. He replied: > I am sure that there are some implementations of the xpointer scheme. > However, since xpointer is still a working draft, these implementations > are not conformant and they are very unlikely to be interoperable. The > XPointer WD says "It is a draft document and may be updated, replaced, > or obsoleted by other documents at any time. It is inappropriate to use W3C > Working Drafts as reference material or to cite them as other than 'work > in progress'". > As for user-defined schemes, you can always create a specialized media > type. For example, SVG has its own scheme, which is useful for > specialized media types for SVG. If we allow user-defined schemes for > application/xml, the definition of XML fragment identifiers becomes > open-ended. This begs significant questions. Does the current > registration procedure of media types allow such open-ended definitions? I don't see why not. > Who maintains the registry of user-defined schemes? The W3C has committed to doing so at some point, but no definitive timeframe is known. > I do not want to open this can of worms at this stage of the game. I guess I do. The XPointer framework spec. is intentionally open-ended, _and_ it makes clear that only shorthand pointers (i.e. #+barename) MUST be supported, and clearly provides for processors to fail if they encounter a scheme they don't support. Seems to me straightforward for 3023bis to say, consistently with that, that shorthand and element schemes must be supported, and that other schemes may be used but SHOULD be avoided for interoperability unless the scheme is appropriately registered and standardised. The tremendous advantage of doing it this way is that 3023bis does not then have to be re-issued every time a new XPointer scheme is blessed. ht [1] http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-01.txt -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]