From owner-ietf-xml-use Tue Apr 9 08:02:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39F2xw21157 for ietf-xml-use-bks; Tue, 9 Apr 2002 08:02:59 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39F2vm21150 for ; Tue, 9 Apr 2002 08:02:57 -0700 (PDT) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA25919 for ; Tue, 9 Apr 2002 10:42:37 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 11:02:53 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B8EE@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-xml-use@imc.org'" Subject: FW: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-00.txt Date: Tue, 9 Apr 2002 11:02:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forwarded to put a copy of the announcement into the mailing list archives (sorry if any long lines get wrapped).... -Scott- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, April 08, 2002 9:51 AM To: IETF-Announce; @loki.ietf.org Subject: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines For The Use of XML in IETF Protocols Author(s) : S. Hollenbeck, M. Rose, L. Masinter Filename : draft-hollenbeck-ietf-xml-guidelines-00.txt Pages : 22 Date : 05-Apr-02 The eXtensible Markup Language (XML) is a framework for structuring data. While it evolved from SGML -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely- used mechanism for representing structured data. There are a wide variety of Internet protocols; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hollenbeck-ietf-xml-guidelines-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hollenbeck-ietf-xml-guidelines-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From owner-ietf-xml-use Tue Apr 9 08:11:16 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39FBG021557 for ietf-xml-use-bks; Tue, 9 Apr 2002 08:11:16 -0700 (PDT) Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39FBDm21553 for ; Tue, 9 Apr 2002 08:11:13 -0700 (PDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g39FBAb20027 for ietf-xml-use@imc.org; Tue, 9 Apr 2002 11:11:10 -0400 Date: Tue, 9 Apr 2002 11:11:10 -0400 From: Daniel Veillard To: ietf-xml-use@imc.org Subject: Feedback on draft-hollenbeck-ietf-xml-guidelines-00.txt Message-ID: <20020409111110.R11960@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, Thanks for providing this draft, it goes a long way ensuring XML is used appropriately in the context of interoperable network applications. However it IMHO misses one very important design point that I have seen my users struggling with in the last years. The key point is that an XML stream has no ending determination: http://www.w3.org/TR/REC-xml#NT-document [1] document ::= prolog element Misc* Misc* clearly indicate that the framework *has to* indicate the end of the document stream, and any solution designed to work by having the parser "guess" when its stream ends is fundamentally broken. I think that such mistake has already been made in a protocol used to carry informations to TV set, unfortunately I never got precise contextual informations. My suggestion is to recommend the approach taken by Jabber in the case where a streaming set of informations need to be carried between client and server, rather than push a succession of document instances on a stream which generate a serious problem to also carry the document terminations as part of the protocol independantly of the XML representation, it is far better to push a set of *subdocuments* of a connection-long document. Basically at the handshake level the client and servers sends opening tags which are equivalents to SMTP HELLO and only at connection closing time is that encapsulating element closed. There is only 2 drawbacks I know of such an approach: - the receiving side need to keep a parser context available for the duration of the connection, it may become a resource issue, but seems not to be a significant problem for Jabber servers implementations - it is very difficult to use XML entities in such a context, as they need to be declared at the DTD declaration level. But since 4.4 Validity seems to suggest deprecating DTD use in IETF specifications this also implies that entities should not be used. Actually I would insert a 4.5 Entities section after 4.4 reinforcing the message about deprecation of DTDs and warning about the unreliability of entities use in the context of protocols, except of course for the entities predefined by the XML spec itself lt, gt, amp, quot and apos. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From owner-ietf-xml-use Tue Apr 9 08:14:11 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39FEBF21765 for ietf-xml-use-bks; Tue, 9 Apr 2002 08:14:11 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39FE9m21761 for ; Tue, 9 Apr 2002 08:14:09 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g39FE7g03421 for ; Tue, 9 Apr 2002 11:14:07 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Guidelines comments From: "Simon St.Laurent" To: ietf-xml-use@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 11:19:20 -0400 Message-Id: <1018365570.13361.1446.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Congratulations on the publication of: http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html In general, I think this looks like a very promising set of guidelines for developers trying to use XML in IETF development contexts. I have only two major questions. As there is not an archive presently available at http://www.imc.org/ietf-xml-use/mail-archive/, it's very difficult to determine the degree of attention which has already been paid to these issues. I'll raise these two sets of concerns in separate messages to simplify thread-tracking. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Tue Apr 9 08:17:25 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39FHPX21862 for ietf-xml-use-bks; Tue, 9 Apr 2002 08:17:25 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39FHOm21858 for ; Tue, 9 Apr 2002 08:17:24 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g39FHMg03561 for ; Tue, 9 Apr 2002 11:17:22 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: ietf-xml-use@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 11:22:42 -0400 Message-Id: <1018365764.13363.1450.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The guidelines state [1]: ----------------------------- XML Schema provides powerful features to define a complete and precise specification of allowable protocol syntax and data type definitions. In order to obtain the advantages of XML as a data structure specification system, protocol specifications should supply an XML Schema and insist that XML instances MUST be valid according to that schema. ----------------------------- I'm not sure that this is a reasonable recommendation in the light of alternatives to W3C XML Schema. It appears to give the W3C an enormous political benefit without much visible exploration of its technical merit. I would particularly recommend that the authors of this document investigate RELAX NG [2], Schematron [3], and the recent ISO/IEC 19757 Document Schema Definition Language (DSDL) [4] work. XML.com offers a comparison of these languages [5], as well as more detail on both RELAX NG [6] and Schematron [7] application. Perhaps the approach taken in Section 3 of the guidelines [8], which explores alternative approaches to XML itself, would be more appropriate here. Identifying validation needs and providing choices for appropriate validation mechanisms seems more appropriate than insisting on a particular technology with a mixed reputation. [1] - http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html#anchor7 [2] - http://www.oasis-open.org/committees/relax-ng/ [3] - http://www.ascc.net/xml/resource/schematron/schematron.html [4] - http://www.dsdl.org/ [5] - http://www.xml.com/pub/a/2001/12/12/schemacompare.html [6] - http://www.xml.com/pub/a/2002/01/23/relaxng.html [7] - http://www.xml.com/pub/a/2002/01/23/perl-schematron.html [8] -http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html#alternatives -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Tue Apr 9 08:18:05 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39FI5121898 for ietf-xml-use-bks; Tue, 9 Apr 2002 08:18:05 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39FI4m21894 for ; Tue, 9 Apr 2002 08:18:04 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g39FI2g03603 for ; Tue, 9 Apr 2002 11:18:02 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Processing instructions and IETF XML Usage Guidelines From: "Simon St.Laurent" To: ietf-xml-use@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 11:23:18 -0400 Message-Id: <1018365805.13361.1452.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Guidelines suggest [1]: ------------------------- However, XML processing instructions appear to have rare applicability to XML fragments embedded in Internet protocols, and it is recommended that their use be explicitly disallowed ("MUST NOT use"). In cases where XML processing instructions are allowed, the nature of the allowable processing instructions should be specified explicitly. ------------------------- I'm not certain what the motivation for constraining processing instructions is in this case, as applications are permitted simply to ignore them if they don't understand them. If this proposal is trying to avoid embrace-and-extend, those concerns should probably be made explicit. I'd also suggest reading the discussion of PIs on www-tag [2]. [1] - http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html#anchor5 [2] - http://lists.w3.org/Archives/Public/www-tag/2002Feb/0057.html (follow the thread, not just the first message) -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Tue Apr 9 09:30:11 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39GUB727768 for ietf-xml-use-bks; Tue, 9 Apr 2002 09:30:11 -0700 (PDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39GUBm27764 for ; Tue, 9 Apr 2002 09:30:11 -0700 (PDT) Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g39GSOZ16650 for ; Tue, 9 Apr 2002 09:28:24 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g39GTTo04502 for ; Tue, 9 Apr 2002 09:29:29 -0700 (PDT) Received: from larrypad ([153.32.165.80]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUB74E00.KWA; Tue, 9 Apr 2002 09:29:02 -0700 Reply-To: From: "Larry Masinter" To: "'Simon St.Laurent'" Cc: Subject: RE: Validation and IETF XML Usage Guidelines Date: Tue, 9 Apr 2002 09:29:00 -0700 Message-ID: <000601c1dfe3$a7da5b00$50a52099@larrypad> 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, Build 10.0.3416 In-Reply-To: <1018365764.13363.1450.camel@localhost.localdomain> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have no problem with pointing to alternatives to XML schema, and think that it's reasonable to give a longer justification for why the document recommends (at least to some degree) W3C XML Schema as a "best practice" for IETF standards track documents. I don't think it's reasonable to leave the choice open -- we should provide some guidance. Having each standard use a different validity mechanism would be a shame. For the particular application in mind -- data fragments used in Internet protocols in lieu of ABNF-defined text or data tables -- XML Schema's significant advantage is its determinism and data typing. That there are classes of documents that can't be readily expressed in XML schema isn't a significant disadvantage, it may even be a feature. Larry From owner-ietf-xml-use Tue Apr 9 09:40:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39Geqg27971 for ietf-xml-use-bks; Tue, 9 Apr 2002 09:40:52 -0700 (PDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Gepm27967 for ; Tue, 9 Apr 2002 09:40:51 -0700 (PDT) Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g39GgWY20468 for ; Tue, 9 Apr 2002 09:42:32 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g39GcAY29915 for ; Tue, 9 Apr 2002 09:38:10 -0700 (PDT) Received: from larrypad ([153.32.165.80]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUB7M700.DWK; Tue, 9 Apr 2002 09:39:43 -0700 Reply-To: From: "Larry Masinter" To: "'Simon St.Laurent'" Cc: Subject: RE: Processing instructions and IETF XML Usage Guidelines Date: Tue, 9 Apr 2002 09:39:41 -0700 Message-ID: <000701c1dfe5$25d2ee90$50a52099@larrypad> 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, Build 10.0.3416 In-Reply-To: <1018365805.13361.1452.camel@localhost.localdomain> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The Guidelines suggest [1]: > ------------------------- > However, XML processing instructions appear to have rare applicability > to XML fragments embedded in Internet protocols, and it is recommended > that their use be explicitly disallowed ("MUST NOT use"). In > cases where > XML processing instructions are allowed, the nature of the allowable > processing instructions should be specified explicitly. > ------------------------- > > I'm not certain what the motivation for constraining processing > instructions is in this case, as applications are permitted simply to > ignore them if they don't understand them. If this proposal is trying > to avoid embrace-and-extend, those concerns should probably be made > explicit. I'd also suggest reading the discussion of PIs on www-tag > [2]. I agree that the section may need more motivation. In general, the recommendation follows a general protocol design principle that it's a good idea to avoid private "extensibility" mechanisms ("sender can send, receiver can ignore if the receiver doesn't understand") without a clear model for how extensibility will be managed. There are a lot of failure modes for uncontrolled extensibility, of which "embrace and extend" is merely one of the deliberate ones. As is pointed out in the referenced thread, PI extensibility doesn't _require_ namespaces, etc. In general, the designer of protocols already has ample extensibility mechanisms at hand, so allowing them in XML components seems unwarranted. [2] - http://lists.w3.org/Archives/Public/www-tag/2002Feb/0057.html (follow the thread, not just the first message) From owner-ietf-xml-use Tue Apr 9 11:36:04 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39Ia4g04820 for ietf-xml-use-bks; Tue, 9 Apr 2002 11:36:04 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Ia3m04816 for ; Tue, 9 Apr 2002 11:36:03 -0700 (PDT) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g39IImd04087; Tue, 9 Apr 2002 11:18:49 -0700 (PDT) Date: Tue, 9 Apr 2002 11:34:30 -0700 From: Marshall Rose To: Cc: simonstl@simonstl.com, ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines Message-Id: <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> In-Reply-To: <000601c1dfe3$a7da5b00$50a52099@larrypad> References: <1018365764.13363.1450.camel@localhost.localdomain> <000601c1dfe3$a7da5b00$50a52099@larrypad> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I have no problem with pointing to alternatives to XML schema, > and think that it's reasonable to give a longer justification > for why the document recommends (at least to some degree) > W3C XML Schema as a "best practice" for IETF standards track > documents. hmmm. this troubles me. the document is a set of guidelines not a full menu of options. i think it just confuses matters to list 10 alternative approaches... > I don't think it's reasonable to leave the choice open -- > we should provide some guidance. Having each standard use > a different validity mechanism would be a shame. > > For the particular application in mind -- data fragments > used in Internet protocols in lieu of ABNF-defined text > or data tables -- XML Schema's significant advantage is > its determinism and data typing. > > That there are classes of documents that can't be readily > expressed in XML schema isn't a significant disadvantage, > it may even be a feature. i agree. realistically, the choice is either dtd, which is reviled by all, or schema, which is reviled by some. choosing anything else is problematic given the scope of the document. /mtr From owner-ietf-xml-use Tue Apr 9 12:01:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39J1D005494 for ietf-xml-use-bks; Tue, 9 Apr 2002 12:01:13 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39J1Bm05490 for ; Tue, 9 Apr 2002 12:01:11 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g39J18g17388 for ; Tue, 9 Apr 2002 15:01:09 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: ietf-xml-use@imc.org In-Reply-To: <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> References: <1018365764.13363.1450.camel@localhost.localdomain> <000601c1dfe3$a7da5b00$50a52099@larrypad> <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 15:06:31 -0400 Message-Id: <1018379193.13363.1466.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2002-04-09 at 14:34, Marshall Rose wrote: > i agree. realistically, the choice is either dtd, which is reviled > by all, or schema, which is reviled by some. choosing anything else is > problematic given the scope of the document. I think the developers who will be bound by this document deserve at least a detailed technical explanation of why the IETF feels this way - equivalent in quality if not in conclusion to the discussion of XML, ASN.1, and BNF. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Tue Apr 9 13:00:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39K0m609918 for ietf-xml-use-bks; Tue, 9 Apr 2002 13:00:48 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39K0lm09913 for ; Tue, 9 Apr 2002 13:00:47 -0700 (PDT) Received: from GK-VAIO.NineByNine.org (dyn85-41.sftm-212-159.plus.net [212.159.41.85]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3A3g6410205 for ; Tue, 9 Apr 2002 20:42:06 -0700 Message-Id: <5.1.0.14.2.20020409200350.03dec140@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Apr 2002 20:03:53 +0100 To: ietf-xml-use@imc.org From: Graham Klyne Subject: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This looks like useful work. I have a few comments: 1. Discussion venue: the name of the mailing list is given as "ietf-xml-use", without a domain part. (Full email address is provided for subscription, but not posting.) 2. Section 2 refers to XML as a "data encapsulation" protocol, where elsewhere it is described (correctly IMO) as a "structured data representation" (or words to that effect). I view "data encapsulation" as describing a protocol like MIME. 3. Section 3 talks about internationalization. I think a reference to [charmod] would be in order: . Hopefully, it will be stable by the time this draft makes BCP. 4. Section 3 talks about extensibility in XML, but is vague about the role of XML namespaces (although these are mentioned later). Suggest replace: [[[ Extensibility: XML has a rich extensibility model: XML representations can frequently be versioned independently. Many XML representations can be extended by adding tokens to the XML namespace (if done compatibly); other extensions can be added by adding to the namespace. ASN.1 is similarly extensible through the use of Object Identifiers (OIDs). XDR representations tend to not be independently extensible by different parties because the framing and datatypes are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned. ]]] with: [[[ Extensibility: XML has a rich extensibility model: XML representations can frequently be versioned independently. Many XML representations can be extended by adding new element names and attributes (if done compatibly); other extensions can be added by defining new XML namespaces [XML-NAMES]. ASN.1 is similarly extensible through the use of Object Identifiers (OIDs). XDR representations tend to not be independently extensible by different parties because the framing and datatypes are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned. ]]] (all changes in the second sentence.) Also add: [[[ There is no standard mechanism in XML for indicating whether or not new extensions are mandatory to recognize. ]]] (I'd also recommend that XML-based protocol specifications explictly address this aspect of protocol extrensibility -- examples can be see in APEX and also in http://www.ninebynine.org/IETF/Messaging/draft-klyne-message-rfc822-xml-02.txt [which is just expired - I plan to re-issue it].) 5. Section 4.6: I think that the most important difference for attributes there can be no more than one instance of a given attribute for a given containing XML element. 6. Section 4.7: Also mention data: URL: ?? 7. Section 5. Also reference [charmod] here? 8. Reference [20]. Michael Mealling prepared two internet drafts about URN namespaces - this one and also this one which I think may be more relevant: [xx] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "A URN Sub-namespace for Registered Protocol Patameters", draft-mealling-iana-urn-01.txt (work in progress), August 2001. According to Michael, both were supposed to be in the RFC-editor's queue but this second one seems to have fallen through the cracks. I recently pinged Michael about it and he says he will chase it but I've heard nothing more. (I also have a couple of other drafts in the works that use this.) 9. Section 4.5, in the discussion of namespaces, add something like: [[[ There is a frequently misunderstood aspect of the relationship between unprefixed attributes and the default XML namespace - the natural assumption is that an unprefixed attribute is qualified by the default namespace, but this is not true. Rather, the unprefixed attribute belongs to a set of attributes that are defined specifically for the element to which it is applied. Thus, in the following: the meaning of attribute "a=" is defined separately for each element. By comparison, a prefixed attribute name is defined independently of the element to which it is applied. For details, see , appendix A.2 (i.e. ). Thge main practical consequence of this is that an attribute that can be applied to any element from any namespace should always be used with a namespace prefix, even when that namespace is also the default namespace. ]]] This probably needs a little fixing up, but I hope you get the idea. (We ran into this problem in the design of RDF and rdf:id= and rdf:about=.) #g ------------------- Graham Klyne From owner-ietf-xml-use Tue Apr 9 13:18:36 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39KIar10442 for ietf-xml-use-bks; Tue, 9 Apr 2002 13:18:36 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39KIYm10438 for ; Tue, 9 Apr 2002 13:18:34 -0700 (PDT) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g39K1ud04394; Tue, 9 Apr 2002 13:01:56 -0700 (PDT) Date: Tue, 9 Apr 2002 13:18:29 -0700 From: Marshall Rose To: "Simon St.Laurent" Cc: ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines Message-Id: <20020409131829.066c61a5.mrose@dbc.mtview.ca.us> In-Reply-To: <1018379193.13363.1466.camel@localhost.localdomain> References: <1018365764.13363.1450.camel@localhost.localdomain> <000601c1dfe3$a7da5b00$50a52099@larrypad> <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> <1018379193.13363.1466.camel@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > On Tue, 2002-04-09 at 14:34, Marshall Rose wrote: > > i agree. realistically, the choice is either dtd, which is reviled > > by all, or schema, which is reviled by some. choosing anything else is > > problematic given the scope of the document. > > I think the developers who will be bound by this document deserve at > least a detailed technical explanation of why the IETF feels this way - > equivalent in quality if not in conclusion to the discussion of XML, > ASN.1, and BNF. simon - i think there is a fundamental disconnect here as visited by terms "bound" and "IETF feels this way". this isn't going to be a standards-track document reflectig the "feelings of the IETF" and even if it were, no one would be "bound" to use it or not. what i want to avoid is having the document turn into a laundry list of all possible choices for all possible tasks. that is contrary to the goal of the document. further, i want to avoid appearing to pick winners in long-running disputes regarding how to express validity constraints. that's up to the market to do. personally, i prefer to use the dtd syntax rather than the schema syntax simply because no one is mucking with it. i'll take stability over incremental functionality any time i get a choice... /mtr From owner-ietf-xml-use Tue Apr 9 14:18:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39LIhR13411 for ietf-xml-use-bks; Tue, 9 Apr 2002 14:18:43 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39LIgm13407 for ; Tue, 9 Apr 2002 14:18:42 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g39LIcg26087 for ; Tue, 9 Apr 2002 17:18:39 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: ietf-xml-use@imc.org In-Reply-To: <20020409131829.066c61a5.mrose@dbc.mtview.ca.us> References: <1018365764.13363.1450.camel@localhost.localdomain> <000601c1dfe3$a7da5b00$50a52099@larrypad> <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> <1018379193.13363.1466.camel@localhost.localdomain> <20020409131829.066c61a5.mrose@dbc.mtview.ca.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 17:23:58 -0400 Message-Id: <1018387444.13363.1485.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2002-04-09 at 16:18, Marshall Rose wrote: > simon - i think there is a fundamental disconnect here as visited by terms "bound" and "IETF feels this way". > > this isn't going to be a standards-track document reflectig the "feelings of the IETF" > > and even if it were, no one would be "bound" to use it or not. So this is a purely advisory exercise, and will have no impact on considerations of standards-track projects? > what i want to avoid is having the document turn into a laundry list of all > possible choices for all possible tasks. that is contrary to the goal of > the document. Picking technologies as preferable without providing justification for the choices seems like a worse alternative to me than noting the existence of other possibilities, especially in a highly-contested space. > further, i want to avoid appearing to pick winners in long-running disputes > regarding how to express validity constraints. Unfortuantely, that's precisely what the document does in its current form. It picks W3C XML Schema over DTDs and doesn't mention anything else. "XML Schema provides powerful features to define a complete and precise specification of allowable protocol syntax and data type definitions. In order to obtain the advantages of XML as a data structure specification system, protocol specifications should supply an XML Schema and insist that XML instances MUST be valid according to that schema." The "should" doesn't exactly have the force of the "MUST" it supposedly moderates. > personally, i prefer to use the dtd syntax rather than the schema syntax > simply because no one is mucking with it. i'll take stability over > incremental functionality any time i get a choice... Perhaps it would be wise simply to drop the discussion of various approaches and simply note that validation of various kinds may be appropriate for some kinds of protocols. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Tue Apr 9 16:12:25 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39NCPd19135 for ietf-xml-use-bks; Tue, 9 Apr 2002 16:12:25 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39NCLm19131 for ; Tue, 9 Apr 2002 16:12:21 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g39N5UX64650; Tue, 9 Apr 2002 19:05:30 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200204092305.g39N5UX64650@nic-naa.net> To: Marshall Rose cc: LMM@acm.org, simonstl@simonstl.com, ietf-xml-use@imc.org, brunner@nic-naa.net Subject: Re: Validation and IETF XML Usage Guidelines In-Reply-To: Your message of "Tue, 09 Apr 2002 11:34:30 PDT." <20020409113430.494ae49e.mrose@dbc.mtview.ca.us> Date: Tue, 09 Apr 2002 19:05:30 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I have no problem with pointing to alternatives to XML schema, > > and think that it's reasonable to give a longer justification > > for why the document recommends (at least to some degree) > > W3C XML Schema as a "best practice" for IETF standards track > > documents. > > hmmm. this troubles me. the document is a set of guidelines not a full > menu > of options. i think it just confuses matters to list 10 alternative > approaches... I've used dtd for cpexchange [1], schema for p3p [2], and schema for epp [3], specification and implementation. My suggestion is stick with this portion of the draft as-is, and with the schema as a w3c bcp. Eric From owner-ietf-xml-use Tue Apr 9 16:25:39 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39NPdf19601 for ietf-xml-use-bks; Tue, 9 Apr 2002 16:25:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g39NPcm19597 for ; Tue, 9 Apr 2002 16:25:38 -0700 (PDT) Received: (qmail 2165 invoked by uid 0); 9 Apr 2002 23:25:35 -0000 Received: from pd950c3e1.dip.t-dialin.net (HELO lisa) (217.80.195.225) by mail.gmx.net (mp006-rz3) with SMTP; 9 Apr 2002 23:25:35 -0000 From: "Julian Reschke" To: Subject: Comments on draft 00 Date: Wed, 10 Apr 2002 01:25:37 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1018379193.13363.1466.camel@localhost.localdomain> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm sorry if I'm repeating something that was already said, but I was sort of a "first post victim" (mailing list wasn't opened yet when I tried to post this). 4.1 XML Declarations I think it's up to the XML recommendation to define when an XML declaration is required and when it isn't. Requiring it's presence or absence in an XML application won't fly, because implementors may not be able to influence what their XML parser or serializer does. So a "MUST NOT be used" may not be implementable at all. 4.2 XML PIs The draft correctly says that they are for out-of-band information. Thus I would conclude that the protocol *itself* should not use processing instructions at all (if it's in the protocol spec, it's not out-of-band, right?). However, I don't see any reason to disallow their use for private protocol extensions, debugging and so on. Even if a protocol doesn't use PIs, I don't want my request to fail just because a request *did* contain a PI. 4.3 Well-formedness I think the draft should make even clearer that XML *is* well-formed. If it isn't it's not XML and it's not worth discussing it. 4.4 Validity I don't like the bias in favor to XML Schema. I agree that it makes sense to recommend formal syntax descriptions, but XML Schema may not work in every case. For instance, WebDAV's XML syntax can't be defined using XML Schema, however RelaxNG (or completely different approaches like Schematron) may. Keep in mind that extensibility and Schema-based constraints do not work well together. 4.5 Namespaces The draft should require that the XML format must comply to the namespaces recommendation (that is, it doesn't need to *use* namespaces, but it should be namespace-wellformed). I also don't understand why the fact that a protocol is published by the IETF changes the current thinking about what kind of namespace name should be chosen. As expected, TimBL already mentioned this on the TAG mailing list. Regarding the example abc:xmlns="urn:ietf:params:xml:ns:abc" This seems to mix the concept of namespace prefix with the id defined in "draft-mealling-iana-xmlns-registry-03". Are they really the same? 4.7 Binary data I think this would be a good place to also talk about the issue of marshalling control characters in text content (either stating that it doesn't work out-of-the-box, or preferrably suggesting a common format for usage in many protocols). Regards, Julian From owner-ietf-xml-use Tue Apr 9 16:29:47 2002 Received: by above.proper.com (8.11.6/8.11.3) id g39NTlG19804 for ietf-xml-use-bks; Tue, 9 Apr 2002 16:29:47 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39NTjm19800 for ; Tue, 9 Apr 2002 16:29:45 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g39NN9X64737; Tue, 9 Apr 2002 19:23:09 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200204092323.g39NN9X64737@nic-naa.net> To: "Julian Reschke" cc: ietf-xml-use@imc.org, brunner@nic-naa.net Subject: Re: Comments on draft 00 In-Reply-To: Your message of "Wed, 10 Apr 2002 01:25:37 +0200." Date: Tue, 09 Apr 2002 19:23:09 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I also don't understand why the fact that a protocol is published by the > IETF changes the current thinking about what kind of namespace name should > be chosen. As expected, TimBL already mentioned this on the TAG mailing > list. See Marshall's note to Mr. St. Laurent. From owner-ietf-xml-use Tue Apr 9 18:01:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A11Td23045 for ietf-xml-use-bks; Tue, 9 Apr 2002 18:01:29 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A11Rm23040 for ; Tue, 9 Apr 2002 18:01:27 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA24974; Tue, 9 Apr 2002 20:40:38 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 21:00:54 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B8F6@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Graham Klyne'" , ietf-xml-use@imc.org Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Date: Tue, 9 Apr 2002 21:00:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Graham Klyne [mailto:GK@NineByNine.org] > Sent: Tuesday, April 09, 2002 3:04 PM > To: ietf-xml-use@imc.org > Subject: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt > > > > This looks like useful work. I have a few comments: > > > 1. Discussion venue: the name of the mailing list is given as > "ietf-xml-use", without a domain part. (Full email address > is provided for > subscription, but not posting.) OK... > 2. Section 2 refers to XML as a "data encapsulation" protocol, where > elsewhere it is described (correctly IMO) as a "structured data > representation" (or words to that effect). I view "data > encapsulation" as > describing a protocol like MIME. OK, consistency is good... > 3. Section 3 talks about internationalization. I think a > reference to > [charmod] would be in order: > . Hopefully, > it will be stable by the time this draft makes BCP. Is there a specific section that you have in mind? The charmod WD provides "a common reference for interoperable text manipulation on the World Wide Web"; what portion of the WD might be applicable to the text encoding paragraph? > 4. Section 3 talks about extensibility in XML, but is vague > about the role > of XML namespaces (although these are mentioned later). > > Suggest replace: > [[[ > Extensibility: XML has a rich extensibility model: XML > representations can frequently be versioned > independently. Many XML > representations can be extended by adding tokens to the > XML namespace > (if done compatibly); other extensions can be added by > adding to the > namespace. ASN.1 is similarly extensible through the use > of Object > Identifiers (OIDs). XDR representations tend to not be > independently > extensible by different parties because the framing and > datatypes are > implicit and not self-describing. The extensibility of BNF-based > protocol elements needs to be explicitly planned. > ]]] > > with: > [[[ > Extensibility: XML has a rich extensibility model: XML > representations can frequently be versioned > independently. Many XML > representations can be extended by adding new element names and > attributes (if done compatibly); other extensions can be added by > defining new XML namespaces [XML-NAMES]. > ASN.1 is similarly extensible through the use of Object > Identifiers (OIDs). XDR representations tend to not be > independently > extensible by different parties because the framing and > datatypes are > implicit and not self-describing. The extensibility of BNF-based > protocol elements needs to be explicitly planned. > ]]] > (all changes in the second sentence.) > > Also add: > [[[ > There is no standard mechanism in XML for indicating whether > or not new > extensions are mandatory to recognize. > ]]] > > (I'd also recommend that XML-based protocol specifications explictly > address this aspect of protocol extrensibility -- examples > can be see in > APEX and also in > http://www.ninebynine.org/IETF/Messaging/draft-klyne-message-r > fc822-xml-02.txt > [which is just expired - I plan to re-issue it].) OK... > 5. Section 4.6: I think that the most important difference > for attributes > there can be no more than one instance of a given attribute > for a given > containing XML element. OK... > 6. Section 4.7: Also mention data: URL: ?? I'm not sure I understand - can you suggest additional text? > 7. Section 5. Also reference [charmod] here? > Again, is there a particular section of the WD that fits into the flow of this section, and/or how would you suggest weaving in a reference? > 8. Reference [20]. Michael Mealling prepared two internet > drafts about URN > namespaces - this one and also this one which I think may be > more relevant: > > [xx] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, > "A URN Sub-namespace for Registered Protocol Patameters", > draft-mealling-iana-urn-01.txt (work in progress), > August 2001. > > According to Michael, both were supposed to be in the > RFC-editor's queue > but this second one seems to have fallen through the cracks. > I recently > pinged Michael about it and he says he will chase it but I've > heard nothing > more. (I also have a couple of other drafts in the works > that use this.) OK, I can weave this in... > 9. Section 4.5, in the discussion of namespaces, add something like: > > [[[ > There is a frequently misunderstood aspect of the > relationship between > unprefixed attributes and the default XML namespace - the natural > assumption is that an unprefixed attribute is qualified by > the default > namespace, but this is not true. Rather, the unprefixed > attribute belongs > to a set of attributes that are defined specifically for the > element to > which it is applied. Thus, in the following: > > > > > > the meaning of attribute "a=" is defined separately for each > element. By > comparison, a prefixed attribute name is defined independently of the > element to which it is applied. For details, see > , appendix A.2 (i.e. > ). > > Thge main practical consequence of this is that an attribute > that can be > applied to any element from any namespace should always be > used with a > namespace prefix, even when that namespace is also the > default namespace. > ]]] Again, OK by me. Thanks for the suggested text. Any objections or alternative viewpoints? -Scott- From owner-ietf-xml-use Tue Apr 9 21:31:00 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A4V0P01660 for ietf-xml-use-bks; Tue, 9 Apr 2002 21:31:00 -0700 (PDT) Received: from adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A4Uxm01656 for ; Tue, 9 Apr 2002 21:30:59 -0700 (PDT) Received: from inner-relay-3.corp.adobe.com (inner-relay-3.sea.adobe.com [153.32.251.51]) by adobe.com (8.12.1/8.12.1) with ESMTP id g3A4UK7g004638 for ; Tue, 9 Apr 2002 21:30:20 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.1/8.12.1) with ESMTP id g3A4SP8q004907 for ; Tue, 9 Apr 2002 21:28:25 -0700 (PDT) Received: from larrypad ([130.248.184.163]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUC4JG00.Q3M; Tue, 9 Apr 2002 21:30:52 -0700 Reply-To: From: "Larry Masinter" To: "'Simon St.Laurent'" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Tue, 9 Apr 2002 21:30:43 -0700 Message-ID: <001801c1e048$7ba17310$6ace8642@larrypad> 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, Build 10.0.3416 In-Reply-To: <1018387444.13363.1485.camel@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's my own intention that this document will IETF policy, be released as BCP, and that as a matter of policy would have as much weight as, say, RFC 3205 ("On the use of HTTP as a Substrate") or RFC 2277 ("IETF Policy on Character Sets and Languages"). (Neither of these are mandatory, but they do document policy.) > So this is a purely advisory exercise, and will have no impact on > considerations of standards-track projects? For my part, I don't see any point in bothering unless we have an impact. On the particular point about the choice of Schema languages, I think we should take another pass at writing something and see if we can get a tone that you can agree with. How about this: With XML, there are also formal mechanisms for defining structural and data content constraints: to constrain the identity of elements or attributes or the values contained within them. The "Document Type Definition" (DTD) is defined in section 2.8 of [8]; it was derived from a similar mechanism originally defined for SGML. XML Schema (defined in [10] and [11]) provides additional features to allow a complete and precise specification of allowable protocol syntax and data type specifications. There are also a number of other mechanisms for describing XML instance validity. (See [xml.org article], for example, for a discussion.) While the applicability and appropriateness of various schema and validity mechanisms is still undergoing some discussion, it seems important that, at least for IETF standards track documents, there be a single consistent mechanism recommended. While many protocols and XML protocol elements have been successfully specified using DTDs, the features in XML Schema for data types and constraining values (and the fact that it is the W3C Recommendation) leads to the recommendation that standards track documents define an XML Schema for any allowable XML protocol element, and that protocol definitions require that XML protocol elements be valid according to the schema. From owner-ietf-xml-use Tue Apr 9 22:15:06 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A5F6n02845 for ietf-xml-use-bks; Tue, 9 Apr 2002 22:15:06 -0700 (PDT) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A5F5m02841 for ; Tue, 9 Apr 2002 22:15:05 -0700 (PDT) Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g3A5DKZ13921 for ; Tue, 9 Apr 2002 22:13:20 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g3A5ESo15830 for ; Tue, 9 Apr 2002 22:14:28 -0700 (PDT) Received: from larrypad ([130.248.184.163]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUC6JB00.4DV; Tue, 9 Apr 2002 22:13:59 -0700 Reply-To: From: "Larry Masinter" To: "'Hollenbeck, Scott'" Cc: Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Date: Tue, 9 Apr 2002 22:13:58 -0700 Message-ID: <002301c1e04e$8559cb90$6ace8642@larrypad> 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, Build 10.0.3416 In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B8F6@vsvapostal3.bkup6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > There is no standard mechanism in XML for indicating whether > > or not new extensions are mandatory to recognize. I'm not sure, but unless you put an 'ANY' in, new extensions aren't allowed. Should we say something about this in the section on validity? I also thought at one point that we should reference 'charmod' but couldn't think of anything to say about it. So I agree with your pushback there. I also agree with the sense of the other comments from Graham that you've accepted. Larry From owner-ietf-xml-use Wed Apr 10 01:16:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A8GmB29059 for ietf-xml-use-bks; Wed, 10 Apr 2002 01:16:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3A8Gkm29045 for ; Wed, 10 Apr 2002 01:16:46 -0700 (PDT) Received: (qmail 23924 invoked by uid 0); 10 Apr 2002 08:16:40 -0000 Received: from pd950c381.dip.t-dialin.net (HELO lisa) (217.80.195.129) by mail.gmx.net (mp001-rz3) with SMTP; 10 Apr 2002 08:16:40 -0000 From: "Julian Reschke" To: , "'Hollenbeck, Scott'" Cc: Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Date: Wed, 10 Apr 2002 10:16:38 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <002301c1e04e$8559cb90$6ace8642@larrypad> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-xml-use@mail.imc.org > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Larry Masinter > Sent: Wednesday, April 10, 2002 7:14 AM > To: 'Hollenbeck, Scott' > Cc: ietf-xml-use@imc.org > Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt > > > > > > There is no standard mechanism in XML for indicating whether > > > or not new extensions are mandatory to recognize. > > I'm not sure, but unless you put an 'ANY' in, new > extensions aren't allowed. Should we say something about > this in the section on validity? That's exactly the problem why I think XML Schema cannot easily be used. For instance, WebDAV's extensibility works by allowing new elements in any place, however requiring that any element which *is* definied by WebDAV (RFC2518) obeys some constraints (like: you can't have and as childs in the same parent element). This is something I can't describe in XML Schema. > I also thought at one point that we should reference > 'charmod' but couldn't think of anything to say about it. > So I agree with your pushback there. > > I also agree with the sense of the other comments from Graham > that you've accepted. > > > Larry > > From owner-ietf-xml-use Wed Apr 10 01:19:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A8Joo00189 for ietf-xml-use-bks; Wed, 10 Apr 2002 01:19:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3A8Jmm00181 for ; Wed, 10 Apr 2002 01:19:48 -0700 (PDT) Received: (qmail 30097 invoked by uid 0); 10 Apr 2002 08:19:43 -0000 Received: from pd950c381.dip.t-dialin.net (HELO lisa) (217.80.195.129) by mail.gmx.net (mp015-rz3) with SMTP; 10 Apr 2002 08:19:43 -0000 From: "Julian Reschke" To: "Hollenbeck, Scott" , "'Graham Klyne'" , Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Date: Wed, 10 Apr 2002 10:19:39 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3CD14E451751BD42BA48AAA50B07BAD60189B8F6@vsvapostal3.bkup6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-xml-use@mail.imc.org > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Hollenbeck, Scott > Sent: Wednesday, April 10, 2002 3:01 AM > To: 'Graham Klyne'; ietf-xml-use@imc.org > Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt > > ... > > > > [[[ > > There is a frequently misunderstood aspect of the > > relationship between > > unprefixed attributes and the default XML namespace - the natural > > assumption is that an unprefixed attribute is qualified by > > the default > > namespace, but this is not true. Rather, the unprefixed > > attribute belongs > > to a set of attributes that are defined specifically for the > > element to > > which it is applied. Thus, in the following: > > > > > > > > > > > > the meaning of attribute "a=" is defined separately for each > > element. By > > comparison, a prefixed attribute name is defined independently of the > > element to which it is applied. For details, see > > , appendix A.2 (i.e. > > ). I think the text is a bit misleading. The namespaces REC does not define semantics at all. All it says is that unprefixed attributes aren't in a namespace, and that it's up to the XML application to decide what this means in each particular case. > > Thge main practical consequence of this is that an attribute > > that can be > > applied to any element from any namespace should always be > > used with a > > namespace prefix, even when that namespace is also the > > default namespace. Why? For instance, XSLT's version attribute is only qualified if it occurs in a non-XSLT element. > > ]]] > > Again, OK by me. Thanks for the suggested text. Any objections or > alternative viewpoints? From owner-ietf-xml-use Wed Apr 10 01:32:12 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A8WCE01486 for ietf-xml-use-bks; Wed, 10 Apr 2002 01:32:12 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A8W6m01456 for ; Wed, 10 Apr 2002 01:32:06 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 0DF4915EB; Wed, 10 Apr 2002 17:31:56 +0900 (JST) Message-Id: <4.2.0.58.J.20020410172848.02aa9250@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 10 Apr 2002 17:31:21 +0900 To: "Julian Reschke" , , "'Hollenbeck, Scott'" From: Martin Duerst Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Cc: In-Reply-To: References: <002301c1e04e$8559cb90$6ace8642@larrypad> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:16 02/04/10 +0200, Julian Reschke wrote: > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Larry Masinter > > I'm not sure, but unless you put an 'ANY' in, new > > extensions aren't allowed. Should we say something about > > this in the section on validity? I guess yes. >That's exactly the problem why I think XML Schema cannot easily be used. DTDs would be a lot worse, of course. >For instance, WebDAV's extensibility works by allowing new elements in any >place, however requiring that any element which *is* definied by WebDAV >(RFC2518) obeys some constraints (like: you can't have and > as childs in the same parent element). This is something I can't >describe in XML Schema. Please note that with every formalism, there are always some things that cannot be described (unless you make the thing Touring-complete,...). Maybe it's a good idea to say that these formalisms only describe some of the conditions, but there are often cases where additional conditions have to be given in text. Regards, Martin. From owner-ietf-xml-use Wed Apr 10 01:32:08 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A8W8501467 for ietf-xml-use-bks; Wed, 10 Apr 2002 01:32:08 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A8W6m01455 for ; Wed, 10 Apr 2002 01:32:06 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 616B815D3; Wed, 10 Apr 2002 17:31:55 +0900 (JST) Message-Id: <4.2.0.58.J.20020410170425.02bb1ad0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 10 Apr 2002 17:13:18 +0900 To: veillard@redhat.com, ietf-xml-use@imc.org From: Martin Duerst Subject: Re: Feedback on draft-hollenbeck-ietf-xml-guidelines-00.txt In-Reply-To: <20020409111110.R11960@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:11 02/04/09 -0400, Daniel Veillard wrote: > Hi all, > > Thanks for providing this draft, it goes a long way ensuring XML is used >appropriately in the context of interoperable network applications. > > However it IMHO misses one very important design point that I have seen >my users struggling with in the last years. The key point is that an >XML stream has no ending determination: > > http://www.w3.org/TR/REC-xml#NT-document > [1] document ::= prolog element Misc* > > Misc* clearly indicate that the framework *has to* indicate the end >of the document stream, and any solution designed to work by having the >parser "guess" when its stream ends is fundamentally broken. Misc is only comment or PI or whitespace (see http://www.w3.org/TR/REC-xml#NT-Misc). So the easiest way to solve this problem is to say that the end tag of the root element closes the communication. This is equivalent to saying that the protocol doesn't use PIs or comments or whitespace after the root element end tag, or that the sender may send these, but the receiver may ignore them and should close the connection when seeing the root element end tag. In most cases, PIs,... after the root element end tag doesn't really make sense anyway, except maybe for something like and for the additional newline at the end of a text file. This is different from what Daniel says below (which is also true and important), namely that a communication is best modeled as a single XML document (see production [1] above) rather than as (some subset of) an External Parsed Entity http://www.w3.org/TR/REC-xml#NT-extParsedEnt [78] extParsedEnt ::= TextDecl? content Regards, Martin. > I think that such mistake has already been made in a protocol used >to carry informations to TV set, unfortunately I never got precise >contextual informations. My suggestion is to recommend the approach >taken by Jabber in the case where a streaming set of informations need to >be carried between client and server, rather than push a succession of >document instances on a stream which generate a serious problem to also >carry the document terminations as part of the protocol independantly of >the XML representation, it is far better to push a set of *subdocuments* >of a connection-long document. > > Basically at the handshake level the client and servers sends opening >tags which are equivalents to SMTP HELLO and only at connection closing >time is that encapsulating element closed. > >There is only 2 drawbacks I know of such an approach: > - the receiving side need to keep a parser context available for > the duration of the connection, it may become a resource issue, > but seems not to be a significant problem for Jabber servers > implementations > - it is very difficult to use XML entities in such a context, as > they need to be declared at the DTD declaration level. But since > 4.4 Validity seems to suggest deprecating DTD use in IETF specifications > this also implies that entities should not be used. > > Actually I would insert a 4.5 Entities section after 4.4 reinforcing >the message about deprecation of DTDs and warning about the unreliability >of entities use in the context of protocols, except of course for the >entities predefined by the XML spec itself lt, gt, amp, quot and apos. > >Daniel > >-- >Daniel Veillard | Red Hat Network https://rhn.redhat.com/ >veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From owner-ietf-xml-use Wed Apr 10 01:59:36 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A8xat05292 for ietf-xml-use-bks; Wed, 10 Apr 2002 01:59:36 -0700 (PDT) Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A8xYm05288 for ; Wed, 10 Apr 2002 01:59:34 -0700 (PDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g3A8wxA21693; Wed, 10 Apr 2002 04:58:59 -0400 Date: Wed, 10 Apr 2002 04:58:59 -0400 From: Daniel Veillard To: Martin Duerst Cc: ietf-xml-use@imc.org Subject: Re: Feedback on draft-hollenbeck-ietf-xml-guidelines-00.txt Message-ID: <20020410045859.Z11960@redhat.com> Reply-To: veillard@redhat.com References: <20020409111110.R11960@redhat.com> <4.2.0.58.J.20020410170425.02bb1ad0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4.2.0.58.J.20020410170425.02bb1ad0@localhost>; from duerst@w3.org on Wed, Apr 10, 2002 at 05:13:18PM +0900 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Apr 10, 2002 at 05:13:18PM +0900, Martin Duerst wrote: > At 11:11 02/04/09 -0400, Daniel Veillard wrote: > > > Hi all, > > > > Thanks for providing this draft, it goes a long way ensuring XML is used > >appropriately in the context of interoperable network applications. > > > > However it IMHO misses one very important design point that I have seen > >my users struggling with in the last years. The key point is that an > >XML stream has no ending determination: > > > > http://www.w3.org/TR/REC-xml#NT-document > > [1] document ::= prolog element Misc* > > > > Misc* clearly indicate that the framework *has to* indicate the end > >of the document stream, and any solution designed to work by having the > >parser "guess" when its stream ends is fundamentally broken. > > Misc is only comment or PI or whitespace > (see http://www.w3.org/TR/REC-xml#NT-Misc). > > So the easiest way to solve this problem is to say that the end > tag of the root element closes the communication. This is equivalent This is broken architecture wise. The layer recognizing the end of tag is not the one controlling the stream flow usually and creating document parser instances. It's an hack, no more no less, and I say this should be advised against based on user feedback. It is also possible to design protocols based on TCP-IP without termination, letting TCP detect the close of the connection and assimilating it to their own termination, but it makes thing very messy to cross layers like this. > to saying that the protocol doesn't use PIs or comments or whitespace > after the root element end tag, or that the sender may send these, > but the receiver may ignore them and should close the connection when > seeing the root element end tag. Note that in this scheme the following sequence would result in a error on the second document: ---------- ---------- The second document would start just after 'doc/>': ---------- ---------- And "; Wed, 10 Apr 2002 02:18:29 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn94-32.sftm-212-159.plus.net [212.159.32.94]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3AGxf411480; Wed, 10 Apr 2002 09:59:41 -0700 Message-Id: <5.1.0.14.2.20020410092616.0380fec0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Apr 2002 09:42:10 +0100 To: "Hollenbeck, Scott" From: Graham Klyne Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Cc: "'Graham Klyne'" , ietf-xml-use@imc.org In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B8F6@vsvapostal3.bkup6 > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:00 PM 4/9/02 -0400, Hollenbeck, Scott wrote: > > 3. Section 3 talks about internationalization. I think a > > reference to > > [charmod] would be in order: > > . Hopefully, > > it will be stable by the time this draft makes BCP. > >Is there a specific section that you have in mind? The charmod WD provides >"a common reference for interoperable text manipulation on the World Wide >Web"; what portion of the WD might be applicable to the text encoding >paragraph? That was before I'd read the later sections. I don't think more is needed here. > > 6. Section 4.7: Also mention data: URL: ?? > >I'm not sure I understand - can you suggest additional text? Hmm... I'm not claiming this is a Good Idea, just something to consider. Add one more paragraph to section 4.7: [[[ Another way to include modest amounts of binary data in an XML document might be to use a data: URL with base64 encoding; e.g. (adapted from RFC 2397): This approach might be usable with protocols like APEX [x] that have in their design a provision for either inline XML content or a URI reference to external content. A data: URL could be an alternative to (say) a cid: URL referencing another part of a multipart/related MIME structure. ]]] > > 7. Section 5. Also reference [charmod] here? > > > >Again, is there a particular section of the WD that fits into the flow of >this section, and/or how would you suggest weaving in a reference? OK. Either an addition to section 5.1, or a new sub-section in section 5. I don't really understand this stuff very well, but am aware that there are some tricky issues that I believe are being addressed by the [charmod] work. But I imagine something like: [[[ There are a number of tricky issues that can arise when using extended character sets with XML document formats: - there are different ways of representing characters consisting of combining characters - there has been some debate about whether URIs should be represented using a restricted US-ASCII subset or arbitrary Unicode (c.f. "URI character sequence" vs "original character sequence" in RFC 2396). Some of these issues are discussed, with recommendations, in [charmod]. ]]] I'm sorry this isn't really adequate as suggested text, but I hope it points to the kinds of issue I'm suggesting might be mentioned. ... #g ------------------- Graham Klyne From owner-ietf-xml-use Wed Apr 10 02:21:32 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A9LWE07824 for ietf-xml-use-bks; Wed, 10 Apr 2002 02:21:32 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A9LVm07820 for ; Wed, 10 Apr 2002 02:21:31 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn94-32.sftm-212-159.plus.net [212.159.32.94]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3AGxc411474; Wed, 10 Apr 2002 09:59:39 -0700 Message-Id: <5.1.0.14.2.20020410090327.037fee20@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Apr 2002 09:21:26 +0100 To: Eric Brunner-Williams in Portland Maine From: Graham Klyne Subject: Re: Comments on draft 00 Cc: ietf-xml-use@imc.org In-Reply-To: <200204092323.g39NN9X64737@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:23 PM 4/9/02 -0400, Eric Brunner-Williams in Portland Maine wrote: > > I also don't understand why the fact that a protocol is published by the > > IETF changes the current thinking about what kind of namespace name should > > be chosen. As expected, TimBL already mentioned this on the TAG mailing > > list. I'll agree that there are no purely *technical* reasons to be different. But, as Larry pointed out in the TAG forum [1], IETF isn't accustomed to create stable URIs in its http: URI space. (Unlike W3C, who have adopted the "cool URIs don't change" philosophy as a corporate required practice.) I think there's also a more substantive point in favour of URNs for this purpose: to register a URN namespace involves a degree of IETF consensus. So, when we see an ietf URN namespace used for an XML namespace id, we've got a fair indication that this is likely to be one that has IETF consensus, compared with using a random HTTP URL. (This is a purely social issue, not a technical argument.) #g [1] http://lists.w3.org/Archives/Public/www-tag/2002Apr/0082.html ------------------- Graham Klyne From owner-ietf-xml-use Wed Apr 10 02:41:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A9foA10128 for ietf-xml-use-bks; Wed, 10 Apr 2002 02:41:50 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A9fnm10122 for ; Wed, 10 Apr 2002 02:41:49 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.33.97]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3AHN4411525; Wed, 10 Apr 2002 10:23:05 -0700 Message-Id: <5.1.0.14.2.20020410104345.038d01d0@joy.songbird.com> X-Sender: gk-bulk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Apr 2002 10:47:00 +0100 To: Martin Duerst From: Graham Klyne Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Cc: In-Reply-To: <4.2.0.58.J.20020410172848.02aa9250@localhost> References: <002301c1e04e$8559cb90$6ace8642@larrypad> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:31 PM 4/10/02 +0900, Martin Duerst wrote: >Please note that with every formalism, there are always some things >that cannot be described (unless you make the thing Touring-complete,...). Does that mean you have to go round the world to get where you want to be ;-) (Sorry, a cheap shot I couldn't resist: I think you meant "Turing-complete".) Your point, though, is well made: I think that formalisms gain their utility as much from the things they don't describe as the things that they can describe. #g ------------------- Graham Klyne From owner-ietf-xml-use Wed Apr 10 02:42:02 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3A9g2j10174 for ietf-xml-use-bks; Wed, 10 Apr 2002 02:42:02 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A9g1m10169 for ; Wed, 10 Apr 2002 02:42:01 -0700 (PDT) Received: from GK-VAIO.NineByNine.org ([212.159.33.97]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3AHN4411526; Wed, 10 Apr 2002 10:23:05 -0700 Message-Id: <5.1.0.14.2.20020410103617.038d5dc0@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Apr 2002 10:42:42 +0100 To: "Julian Reschke" From: Graham Klyne Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt Cc: "Hollenbeck, Scott" , In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60189B8F6@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:19 AM 4/10/02 +0200, Julian Reschke wrote: > > From: owner-ietf-xml-use@mail.imc.org > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Hollenbeck, Scott > > Sent: Wednesday, April 10, 2002 3:01 AM > > To: 'Graham Klyne'; ietf-xml-use@imc.org > > Subject: RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt > > > > ... > > > > > > [[[ > > > There is a frequently misunderstood aspect of the > > > relationship between > > > unprefixed attributes and the default XML namespace - the natural > > > assumption is that an unprefixed attribute is qualified by > > > the default > > > namespace, but this is not true. Rather, the unprefixed > > > attribute belongs > > > to a set of attributes that are defined specifically for the > > > element to > > > which it is applied. Thus, in the following: > > > > > > > > > > > > > > > > > > the meaning of attribute "a=" is defined separately for each > > > element. By > > > comparison, a prefixed attribute name is defined independently of the > > > element to which it is applied. For details, see > > > , appendix A.2 (i.e. > > > ). > >I think the text is a bit misleading. The namespaces REC does not define >semantics at all. All it says is that unprefixed attributes aren't in a >namespace, and that it's up to the XML application to decide what this means >in each particular case. I agree, and acknowledge the words need work. I was mainly trying to get the issue out in the open, so to speak. > > > Thge main practical consequence of this is that an attribute > > > that can be > > > applied to any element from any namespace should always be > > > used with a > > > namespace prefix, even when that namespace is also the > > > default namespace. > >Why? For instance, XSLT's version attribute is only qualified if it occurs >in a non-XSLT element. Again, I agree my wording isn't quite right. But the reasoning here is quite subtle -- when applied to an XSLT attribute without a prefix, it's not the same attribute name. But the defined XSLT element and attribute semantics can be such that they mean the same thing. This cannot apply when an unprefixed attribute is applied to an element defined by a different namespace. Better might be something like: [[[ One practical way to deal with this is to always use any attribute that can be applied to any element from any namespace with a namespace prefix, even when that namespace is also the default namespace. ]]] Again, my main reason for raising this was to point out that there are subtleties that can trap the unwary. #g ------------------- Graham Klyne From owner-ietf-xml-use Wed Apr 10 03:52:02 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3AAq2515895 for ietf-xml-use-bks; Wed, 10 Apr 2002 03:52:02 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AAq0m15888 for ; Wed, 10 Apr 2002 03:52:01 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 50C6815B8; Wed, 10 Apr 2002 19:51:47 +0900 (JST) Message-Id: <4.2.0.58.J.20020410191949.00a99178@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 10 Apr 2002 19:36:57 +0900 To: veillard@redhat.com From: Martin Duerst Subject: Re: Feedback on draft-hollenbeck-ietf-xml-guidelines-00.txt Cc: ietf-xml-use@imc.org In-Reply-To: <20020410045859.Z11960@redhat.com> References: <4.2.0.58.J.20020410170425.02bb1ad0@localhost> <20020409111110.R11960@redhat.com> <4.2.0.58.J.20020410170425.02bb1ad0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Daniel, I'm a bit confused. You wrote one mail earlier: >>>> Basically at the handshake level the client and servers sends opening tags which are equivalents to SMTP HELLO and only at connection closing time is that encapsulating element closed. >>>> So that would look like ... ... ... How is that different from: >On Wed, Apr 10, 2002 at 05:13:18PM +0900, Martin Duerst wrote: > > So the easiest way to solve this problem is to say that the end > > tag of the root element closes the communication. This is equivalent Or is it that when you say "only at connection closing time is that encapsulating element closed", you mean that actually, something like this happens: ... ... ... ... or more generally you mean that there is something that causes the connection to be closed, which then causes the encapsulating element to be closed? (rather than that the closing the enclosing element causes the connection to be closed?) > This is broken architecture wise. The layer recognizing the end of >tag is not the one controlling the stream flow Agreed. But without the ability to flush things on the sending side at the end of some element, you will end up with deadlocks very quickly. Same if your implementation isn't able to push such flushes up to the application on the receiving side. > > to saying that the protocol doesn't use PIs or comments or whitespace > > after the root element end tag, or that the sender may send these, > > but the receiver may ignore them and should close the connection when > > seeing the root element end tag. > > Note that in this scheme the following sequence would result in a >error on the second document: > >---------- > > > > >---------- I was never assuming anything like this. And I was never assuming you would want to do anything like this. If you say you want to keep the parser context, and that you start a connection with an opening tag, and close that element at connection closing time. But: is not legal XML, and so I never thought you wanted to do something like this, and I never myself proposed something like this. What should be done is: At least that's what I was able to deduce from your mail. If you propose something else, then please give a full example to avoid misunderstandings. Regards, Martin. From owner-ietf-xml-use Wed Apr 10 06:28:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ADSxi24524 for ietf-xml-use-bks; Wed, 10 Apr 2002 06:28:59 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ADSvm24520 for ; Wed, 10 Apr 2002 06:28:57 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3ADSsg24282; Wed, 10 Apr 2002 09:28:55 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: RE: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: LMM@acm.org Cc: ietf-xml-use@imc.org In-Reply-To: <001801c1e048$7ba17310$6ace8642@larrypad> References: <001801c1e048$7ba17310$6ace8642@larrypad> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 10 Apr 2002 09:34:16 -0400 Message-Id: <1018445658.982.7.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2002-04-10 at 00:30, Larry Masinter wrote: > It's my own intention that this document will IETF policy, > be released as BCP, and that as a matter of policy would have as much > weight as, say, RFC 3205 ("On the use of HTTP as a Substrate") > or RFC 2277 ("IETF Policy on Character Sets and Languages"). > (Neither of these are mandatory, but they do document policy.) > > For my part, I don't see any point in bothering unless we > have an impact. That's more consistent with what I'd expected this document to attempt. > On the particular point about the choice of Schema languages, > I think we should take another pass at writing something > and see if we can get a tone that you can agree with. It's a large improvement, no question. I really only have two remaining concerns: 1) The alternatives to XML Schema support data typing. RELAX NG, for instance, supports the use of XML Schema data types. 2) I worry that this call for strong typing represents a substantial change from prior IETF practice. I have to admit that I am disappointed to see the IETF shift from its much more flexible handling of text-based standards to a rigid conformity for XML-based standards. On (2), Julian Reschke has raised WebDAV as an example, but there are lots and lots of cases beyond that. I'm not sure that imposing a rule like "if W3C XML Schema can't represent it, it must be a bad idea" makes any sense whatsoever. It seems to be a new set of constraints with some very heavy implications for protocol design. I suspect the implications of this are well worth discussing in more general IETF forums than this XML-focused list. I'm deeply concerned that the notion of "extensibility" in XML is being discarded in favor of as many constraints as possible. That may be what you want, but for a lot of us it feels like a combination hair shirt-straitjacket. > How about this: > > With XML, there are also formal mechanisms for defining > structural and data content constraints: to constrain the > identity of elements or attributes or the values contained > within them. > > The "Document Type Definition" (DTD) is defined in section 2.8 > of [8]; it was derived from a similar mechanism originally > defined for SGML. > > XML Schema (defined in [10] and [11]) provides additional > features to allow a complete and precise specification > of allowable protocol syntax and data type specifications. > > There are also a number of other mechanisms for describing > XML instance validity. (See [xml.org article], for example, > for a discussion.) > > While the applicability and appropriateness of various schema > and validity mechanisms is still undergoing some discussion, > it seems important that, at least for IETF standards track > documents, there be a single consistent mechanism recommended. > While many protocols and XML protocol elements have been > successfully specified using DTDs, the features in XML Schema > for data types and constraining values (and the fact that it is > the W3C Recommendation) leads to the recommendation that > standards track documents define an XML Schema for any > allowable XML protocol element, and that protocol definitions > require that XML protocol elements be valid according to > the schema. > -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Wed Apr 10 09:29:55 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGTt006256 for ietf-xml-use-bks; Wed, 10 Apr 2002 09:29:55 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGTrm06252 for ; Wed, 10 Apr 2002 09:29:53 -0700 (PDT) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA20293; Wed, 10 Apr 2002 12:07:04 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 12:27:20 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B8FE@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'LMM@acm.org'" , "'Simon St.Laurent'" , ietf-xml-use@imc.org Subject: RE: Validation and IETF XML Usage Guidelines Date: Wed, 10 Apr 2002 12:27:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > There are also a number of other mechanisms for describing > XML instance validity. (See [xml.org article], for example, > for a discussion.) I assume Larry means this: http://www.xml.com/pub/a/2001/12/12/schemacompare.html when he writes "[xml.org article]" in the above text. There's some risk in referring to an online article that may or may not exist at a given URL in the future. Rather than adding such a reference, can we just say something like this: "There are also a number of other mechanisms for describing XML instance validity. Interested readers can browse various online resources (such as http://www.xml.com) for additional information describing several alternatives." -Scott- From owner-ietf-xml-use Wed Apr 10 09:36:40 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3AGaen06629 for ietf-xml-use-bks; Wed, 10 Apr 2002 09:36:40 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGacm06623 for ; Wed, 10 Apr 2002 09:36:38 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3AGaYg00903; Wed, 10 Apr 2002 12:36:35 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: RE: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: "Hollenbeck, Scott" Cc: ietf-xml-use@imc.org In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B8FE@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B8FE@vsvapostal3.bkup6> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 10 Apr 2002 12:41:55 -0400 Message-Id: <1018456918.982.14.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2002-04-10 at 12:27, Hollenbeck, Scott wrote: > There's some risk in referring to an online article that may or may not > exist at a given URL in the future. Rather than adding such a reference, > can we just say something like this: > > "There are also a number of other mechanisms for describing XML instance > validity. Interested readers can browse various online resources (such as > http://www.xml.com) for additional information describing several > alternatives." It might be wiser simply to point to the sites for the specifications, which are not likely to change: http://www.oasis-open.org/committees/relax-ng/ (RELAX NG) http://www.ascc.net/xml/resource/schematron/schematron.html (Schematron) http://dsdl.org (ISO DSDL) I'm not exactly sure what the value of mentioning but not naming alternatives is supposed to be. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Wed Apr 10 09:59:09 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGx9f07391 for ietf-xml-use-bks; Wed, 10 Apr 2002 09:59:09 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGx7m07386 for ; Wed, 10 Apr 2002 09:59:07 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA22079; Wed, 10 Apr 2002 12:38:42 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 12:58:58 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B8FF@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Simon St.Laurent'" Cc: ietf-xml-use@imc.org Subject: RE: Validation and IETF XML Usage Guidelines Date: Wed, 10 Apr 2002 12:58:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'm not exactly sure what the value of mentioning but not naming > alternatives is supposed to be. It avoids the problem of producing a list that is very likely to be incomplete. I don't mind mentioning a few alternatives more specifically, but only if they are clearly described as representative of the possibilities. -Scott- From owner-ietf-xml-use Wed Apr 10 10:07:05 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AH75807640 for ietf-xml-use-bks; Wed, 10 Apr 2002 10:07:05 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AH73m07636 for ; Wed, 10 Apr 2002 10:07:03 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3AH6xg02244; Wed, 10 Apr 2002 13:06:59 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: RE: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: "Hollenbeck, Scott" Cc: ietf-xml-use@imc.org In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B8FF@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B8FF@vsvapostal3.bkup6> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 10 Apr 2002 13:12:14 -0400 Message-Id: <1018458743.982.19.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2002-04-10 at 12:58, Hollenbeck, Scott wrote: > > I'm not exactly sure what the value of mentioning but not naming > > alternatives is supposed to be. > > It avoids the problem of producing a list that is very likely to be > incomplete. I don't mind mentioning a few alternatives more specifically, > but only if they are clearly described as representative of the > possibilities. I think it's safe at this point to describe DTDs, W3C XML Schema, RELAX NG, and Schematron as the set of schema possibilities. DSDL provides a framework for working with any or all of them. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com From owner-ietf-xml-use Wed Apr 10 14:03:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AL3mE23056 for ietf-xml-use-bks; Wed, 10 Apr 2002 14:03:48 -0700 (PDT) Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AL3km23052 for ; Wed, 10 Apr 2002 14:03:47 -0700 (PDT) Received: from col (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA03472 for ; Wed, 10 Apr 2002 17:03:48 -0400 Message-ID: <011601c1e0d3$73f51f50$0301a8c0@w3.org> From: "Tim Berners-Lee" To: Subject: Re: "Guidelines for the Use of XML in IETF Protocols" Date: Wed, 10 Apr 2002 17:05:32 -0400 Organization: W3C 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Re-sent now I am allowed through the spam-filter. >Message-ID: <004d01c1e02e$6c428220$0301a8c0@w3.org> >From: "Tim Berners-Lee" >To: , "'www-tag'" >Cc: >References: <000801c1df5d$dd802540$50a52099@larrypad> >Subject: Re: "Guidelines for the Use of XML in IETF Protocols" >Date: Tue, 9 Apr 2002 21:24:12 -0400 >Organization: W3C > > >----- Original Message ----- >From: "Larry Masinter" >To: "'Tim Berners-Lee'" ; "'www-tag'" >Cc: >Sent: Monday, April 08, 2002 8:31 PM >Subject: RE: "Guidelines for the Use of XML in IETF Protocols" > > >> (suggest followup to ietf-xml-use@imc.org) > >http://www.imc.org/ietf-xml-use/index.html >is the archive, for anyone on www-tag who witshes to follow this. >For folks on that list, the www-tag archive is at >http://lists.w3.org/Archives/Public/www-tag/2002Apr/thread.html#78 > >> > FYI. I note that this note encourages/mandates urn:s >> > instead of http: URIs for namespaces in direct contradiction >> > with the current draft by Tim Bray. >> > >> >> Please look carefully: the recommendation narrowly applies >> only to IETF standards-track documents; given recent discussions >> about (the difficulty of establishing) IETF policy on maintenance >> of various web resources, using the urn:ietf: namespace for >> such seemed prudent. >> >> What HTTP URI would you suggest instead? > >http://www.ietf.org/2001/foobar >or >http://persistent.ietf.org/2001/foobar > > >along with a commitment that as long as the Internet and >DNS remain, the given URI will be honored by some >useful information, machine and/or human-readable, >about the thing defined. This is of course not esential >for XML to work, but is a practical service to the community. > >The difficulty of establishing IETF policy on maintenance >of various web resources is only a matter of policy. >At least the identifier space and the look-up system have been >designed and do not need reinventing. > >We would be happy to discuss with IETF people >a mutual W3C-IETF mirroring system, and possibly contracts >for perpetual care. But I do not see in fact there being >any problem in the next 5 years with the IETF just >supporting a service itself. > >> Larry >> --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-use Thu Apr 11 00:28:53 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3B7SrQ26133 for ietf-xml-use-bks; Thu, 11 Apr 2002 00:28:53 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B7Sqm26125 for ; Thu, 11 Apr 2002 00:28:52 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E6CB413D7; Thu, 11 Apr 2002 16:28:40 +0900 (JST) Message-Id: <4.2.0.58.J.20020411100713.03421e90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 11 Apr 2002 16:26:00 +0900 To: "Simon St.Laurent" , LMM@acm.org From: Martin Duerst Subject: RE: Validation and IETF XML Usage Guidelines Cc: ietf-xml-use@imc.org In-Reply-To: <1018445658.982.7.camel@localhost.localdomain> References: <001801c1e048$7ba17310$6ace8642@larrypad> <001801c1e048$7ba17310$6ace8642@larrypad> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:34 02/04/10 -0400, Simon St.Laurent wrote: >On Wed, 2002-04-10 at 00:30, Larry Masinter wrote: > > On the particular point about the choice of Schema languages, > > I think we should take another pass at writing something > > and see if we can get a tone that you can agree with. > >It's a large improvement, no question. I really only have two remaining >concerns: >2) I worry that this call for strong typing represents a substantial >change from prior IETF practice. I have to admit that I am disappointed >to see the IETF shift from its much more flexible handling of text-based >standards to a rigid conformity for XML-based standards. I think this document is about 'how to use XML if you use it', not about 'everybody in the IETF has to use XML'. And if you use XML, you preferably use it for what you can get from it, rather than just because it sounds good. If you could give an example of what you mean by 'much more flexible handling of text-based standards' that would be endangered by XML, that could help. It's not clear what you mean. >On (2), Julian Reschke has raised WebDAV as an example, but there are >lots and lots of cases beyond that. I'm not sure that imposing a rule >like "if W3C XML Schema can't represent it, it must be a bad idea" makes >any sense whatsoever. I'm sure it does not make sense. I don't think anybody has proposed it. As I have already said, I think that for every formalism, you can come up with cases that it doesn't cover. I think it would be good to add something like: Whatever formalism chosen, there is a chance that there will be requirements on your format/data that cannot be expressed in that formalism. These additional requirements should clearly be called out in the specification. >It seems to be a new set of constraints with some >very heavy implications for protocol design. I suspect the implications >of this are well worth discussing in more general IETF forums than this >XML-focused list. I think you are reading too much into the document. If there is language that you are not happy with, please cite it and propose a replacement. If you think something is missing and can be misunderstood, please provide some additional wording. >I'm deeply concerned that the notion of "extensibility" in XML is being >discarded in favor of as many constraints as possible. That may be what >you want, but for a lot of us it feels like a combination hair >shirt-straitjacket. I don't understand why you are saying this. I think that the document needs to say more about extensibility. The main message should be that protocol designers have to design extensibility into the protocol (XML is a good tool to do this, but only if you use it well). I think Larry said something like this already. XML Schema doesn't limit extensibility. DTDs limit extensibility because ANY means 'ANY element defined in the DTD'. This is not the same for XML Schema. XML Scheam allows to say where you want to allow other namespaces, and where not. As far as I understand, it is not as powerful as e.g. Relax-NG in defining how and under what conditions what kinds of things can be mixed. But that's not a main problem for extensibility. > > How about this: > > > > With XML, there are also formal mechanisms for defining > > structural and data content constraints: to constrain the > > identity of elements or attributes or the values contained > > within them. > > > > The "Document Type Definition" (DTD) is defined in section 2.8 > > of [8]; it was derived from a similar mechanism originally > > defined for SGML. > > > > XML Schema (defined in [10] and [11]) provides additional > > features to allow a complete and precise specification > > of allowable protocol syntax and data type specifications. Please change 'complete and precise' to 'tighter and more precise'. Regards, Martin. From owner-ietf-xml-use Thu Apr 11 00:37:33 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3B7bXp27438 for ietf-xml-use-bks; Thu, 11 Apr 2002 00:37:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3B7bWm27434 for ; Thu, 11 Apr 2002 00:37:32 -0700 (PDT) Received: (qmail 2483 invoked by uid 0); 11 Apr 2002 07:37:26 -0000 Received: from p3ee24747.dip.t-dialin.net (HELO lisa) (62.226.71.71) by mail.gmx.net (mp014-rz3) with SMTP; 11 Apr 2002 07:37:26 -0000 From: "Julian Reschke" To: "Martin Duerst" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Thu, 11 Apr 2002 09:37:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.0.58.J.20020411100713.03421e90@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Martin, > XML Schema doesn't limit extensibility. DTDs limit extensibility > because ANY means 'ANY element defined in the DTD'. This is not > the same for XML Schema. XML Scheam allows to say where you want > to allow other namespaces, and where not. As far as I understand, > it is not as powerful as e.g. Relax-NG in defining how and under > what conditions what kinds of things can be mixed. But that's not > a main problem for extensibility. in XML Schema, can I model the following rules (which are actually in use in WebDAV): {DAV}:propfind MUST contain exactly one of {DAV}:prop, {DAV}:propname or {DAV}:allprop. It MAY be extended by any other element, no matter in which namespace? I think you can't, yet this seems to be a very natural thing for an extensible protocol. (if you can, I'd like to learn how). From owner-ietf-xml-use Thu Apr 11 01:42:56 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3B8guY08950 for ietf-xml-use-bks; Thu, 11 Apr 2002 01:42:56 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B8gtm08942 for ; Thu, 11 Apr 2002 01:42:55 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 5967FDF3; Thu, 11 Apr 2002 17:42:44 +0900 (JST) Message-Id: <4.2.0.58.J.20020411173244.031e1b18@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 11 Apr 2002 17:38:40 +0900 To: "Julian Reschke" , From: Martin Duerst Subject: RE: Validation and IETF XML Usage Guidelines In-Reply-To: References: <4.2.0.58.J.20020411100713.03421e90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:37 02/04/11 +0200, Julian Reschke wrote: >Martin, > > > XML Schema doesn't limit extensibility. DTDs limit extensibility > > because ANY means 'ANY element defined in the DTD'. This is not > > the same for XML Schema. XML Scheam allows to say where you want > > to allow other namespaces, and where not. As far as I understand, > > it is not as powerful as e.g. Relax-NG in defining how and under > > what conditions what kinds of things can be mixed. But that's not > > a main problem for extensibility. > >in XML Schema, can I model the following rules (which are actually in use in >WebDAV): Just to make sure, my main point was not that XML Schema can model anything, but that's the same for other formalisms. >{DAV}:propfind MUST contain exactly one of {DAV}:prop, {DAV}:propname or >{DAV}:allprop. It MAY be extended by any other element, no matter in which >namespace? > >I think you can't, yet this seems to be a very natural thing for an >extensible protocol. (if you can, I'd like to learn how). Here is a first variant that assumes that the prop/propfind/allprop element comes first: I hope I (or actualy XML Spy :-) got it right. If DAV allows to have other elements before prop/propfind/allprop, then that is a tiny bit more complicated, but it can be done, too. Please tell me if you need it. Regards, Martin. From owner-ietf-xml-use Thu Apr 11 01:53:57 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3B8rvk10203 for ietf-xml-use-bks; Thu, 11 Apr 2002 01:53:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3B8rtm10195 for ; Thu, 11 Apr 2002 01:53:55 -0700 (PDT) Received: (qmail 24043 invoked by uid 0); 11 Apr 2002 08:53:49 -0000 Received: from p3ee24747.dip.t-dialin.net (HELO lisa) (62.226.71.71) by mail.gmx.net (mp010-rz3) with SMTP; 11 Apr 2002 08:53:49 -0000 From: "Julian Reschke" To: "Martin Duerst" , "Julian Reschke" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Thu, 11 Apr 2002 10:53:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.0.58.J.20020411173244.031e1b18@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-xml-use@mail.imc.org > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Martin Duerst > Sent: Thursday, April 11, 2002 10:39 AM > To: Julian Reschke; ietf-xml-use@imc.org > Subject: RE: Validation and IETF XML Usage Guidelines > > > > At 09:37 02/04/11 +0200, Julian Reschke wrote: > > >Martin, > > > > > XML Schema doesn't limit extensibility. DTDs limit extensibility > > > because ANY means 'ANY element defined in the DTD'. This is not > > > the same for XML Schema. XML Scheam allows to say where you want > > > to allow other namespaces, and where not. As far as I understand, > > > it is not as powerful as e.g. Relax-NG in defining how and under > > > what conditions what kinds of things can be mixed. But that's not > > > a main problem for extensibility. > > > >in XML Schema, can I model the following rules (which are > actually in use in > >WebDAV): > > Just to make sure, my main point was not that XML Schema can model > anything, but that's the same for other formalisms. > > > >{DAV}:propfind MUST contain exactly one of {DAV}:prop, {DAV}:propname or > >{DAV}:allprop. It MAY be extended by any other element, no > matter in which > >namespace? > > > >I think you can't, yet this seems to be a very natural thing for an > >extensible protocol. (if you can, I'd like to learn how). > > Here is a first variant that assumes that the prop/propfind/allprop > element comes first: > > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > > > > > > > minOccurs="0" > maxOccurs="unbounded"/> > > > > > > > > > I hope I (or actualy XML Spy :-) got it right. > If DAV allows to have other elements before prop/propfind/allprop, > then that is a tiny bit more complicated, but it can be done, too. > Please tell me if you need it. Wouldn't that allow ? From owner-ietf-xml-use Thu Apr 11 02:49:30 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3B9nUn15162 for ietf-xml-use-bks; Thu, 11 Apr 2002 02:49:30 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B9nTm15158 for ; Thu, 11 Apr 2002 02:49:29 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id EDC5B15BB; Thu, 11 Apr 2002 18:49:18 +0900 (JST) Message-Id: <4.2.0.58.J.20020411183640.00a972f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 11 Apr 2002 18:39:38 +0900 To: "Julian Reschke" , "Julian Reschke" , From: Martin Duerst Subject: RE: Validation and IETF XML Usage Guidelines In-Reply-To: References: <4.2.0.58.J.20020411173244.031e1b18@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:53 02/04/11 +0200, Julian Reschke wrote: >Wouldn't that allow > > > > > > >? Why should it? It's the same as (except that DTDs don't have ##other). The above wouldn't allow , would it? Regards, Martin. > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Martin Duerst > > At 09:37 02/04/11 +0200, Julian Reschke wrote: > > > > >Martin, > > >in XML Schema, can I model the following rules (which are > > actually in use in > > >WebDAV): > > > > Just to make sure, my main point was not that XML Schema can model > > anything, but that's the same for other formalisms. > > > > > > >{DAV}:propfind MUST contain exactly one of {DAV}:prop, {DAV}:propname or > > >{DAV}:allprop. It MAY be extended by any other element, no > > matter in which > > >namespace? > > > > > >I think you can't, yet this seems to be a very natural thing for an > > >extensible protocol. (if you can, I'd like to learn how). > > > > Here is a first variant that assumes that the prop/propfind/allprop > > element comes first: > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > elementFormDefault="qualified" > > attributeFormDefault="unqualified"> > > > > > > > > > > > > > > > > > > > minOccurs="0" > > maxOccurs="unbounded"/> > > > > > > > > > > > > > > > > > > I hope I (or actualy XML Spy :-) got it right. > > If DAV allows to have other elements before prop/propfind/allprop, > > then that is a tiny bit more complicated, but it can be done, too. > > Please tell me if you need it. From owner-ietf-xml-use Thu Apr 11 03:36:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3BAaqP19169 for ietf-xml-use-bks; Thu, 11 Apr 2002 03:36:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3BAaom19160 for ; Thu, 11 Apr 2002 03:36:51 -0700 (PDT) Received: (qmail 24746 invoked by uid 0); 11 Apr 2002