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 10:36:45 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 11 Apr 2002 10:36:45 -0000 From: "Julian Reschke" To: "Martin Duerst" , "Julian Reschke" , "Julian Reschke" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Thu, 11 Apr 2002 12:36:45 +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) Importance: Normal In-Reply-To: <4.2.0.58.J.20020411183640.00a972f0@localhost> 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: > 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 11:40 AM > To: Julian Reschke; Julian Reschke; ietf-xml-use@imc.org > Subject: RE: Validation and IETF XML Usage Guidelines > > > > 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? OK, I'm learning: "##other: Any well-formed XML that is not from the target namespace of the type being defined" So then it would forbid: propfind xmlns="DAV:"> right? From owner-ietf-xml-use Thu Apr 11 06:14:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3BDEqp27932 for ietf-xml-use-bks; Thu, 11 Apr 2002 06:14:52 -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 g3BDEnm27924 for ; Thu, 11 Apr 2002 06:14:49 -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 g3BDEmg31054 for ; Thu, 11 Apr 2002 09:14:48 -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: <4.2.0.58.J.20020411100713.03421e90@localhost> References: <001801c1e048$7ba17310$6ace8642@larrypad> <001801c1e048$7ba17310$6ace8642@larrypad> <4.2.0.58.J.20020411100713.03421e90@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 11 Apr 2002 09:20:07 -0400 Message-Id: <1018531211.982.53.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 2002-04-11 at 03:26, Martin Duerst wrote: > >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'. I didn't make any such claim. My concern is simply that protocols being built in XML are being told by this document to conform to a much more rigorous and not especially flexible (or human-readable) set of structural rules than text-based protocols. Some people may see that as progress - I see it as a step back. > And if you use XML, you preferably use it for what you can get from > it, rather than just because it sounds good. Sure - but validation constraints aren't the only thing you can get from using XML. Well-formed XML is often useful in its own right, and there are lots of people who get a lot out of XML without ever going near W3C XML Schema. There are also lots of people who need validation and find W3C XML Schema unsuitable for a wide variety of reasons. Insisting that IETF protocol work use W3C XML Schema adds an enormous layer of learning and potentially processing to the development of such standards. In short, I think the document uses W3C XML Schema "just because it sounds good". I don't believe it has really begun to justify that choice on technical grounds. > 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. The open extensibility of headers seems like a pretty fundamental thing. -- 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 Thu Apr 11 09:16:14 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3BGGEg09063 for ietf-xml-use-bks; Thu, 11 Apr 2002 09:16:14 -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 g3BGGDm09059 for ; Thu, 11 Apr 2002 09:16:13 -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 g3BGHtY18386 for ; Thu, 11 Apr 2002 09:17:55 -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 g3BGDkY29341 for ; Thu, 11 Apr 2002 09:13:46 -0700 (PDT) Received: from larrypad ([130.248.184.197]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUEVTI00.NKF; Thu, 11 Apr 2002 09:15:18 -0700 Reply-To: From: "Larry Masinter" To: "'Simon St.Laurent'" Cc: Subject: RE: Validation and IETF XML Usage Guidelines Date: Thu, 11 Apr 2002 09:15:21 -0700 Message-ID: <003b01c1e174$175e3370$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1018531211.982.53.camel@localhost.localdomain> Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We want to give appropriate guidance for when and when not to use the various mechanisms of XML, in a context where the XML is embedded within some other protocol. We should try to capture the issue, that using XML schema, requiring validity according to the schema, limits the kind of extensibility that is allowed in a particular way. In many contexts, there are other extensibility mechanisms already in place -- the protocol has its own versioning mechanism, ways of updating the schema or pointing to a new one. So I think that it's not unreasonable to expect that in many cases, XML Schema are exactly the right thing. There may be some other contexts where more extensibility in the XML is actually required, and some other mechanism for describing validity is required; in those circumstances, alternatives to XML schema can be considered. I'm less certain about how far we should go enumerating them, but a look at some existing protocols (like WebDAV) might be useful. There is some controversy about XML Schema, and many people are more comfortable with the (admittedly easier to read) DTD mechanism. It's also true that in some circumstances a DTD will suffice for describing the data structures allowed, e.g., if all of the elements only contain text and the data typing mechanisms of XML Schema aren't applicable or useful. We should take another pass at this; you may not be fully satisfied (given what I sense as a strong distaste for the W3C XML Schema Recommendation), but I hope we can at least lay out what the tradeoffs are. Larry -- http://larry.masinter.net From owner-ietf-xml-use Thu Apr 11 10:19:57 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BHJvu10880 for ietf-xml-use-bks; Thu, 11 Apr 2002 10:19:57 -0700 (PDT) Received: from nic-naa.net (ptd-24-198-34-29.maine.rr.com [24.198.34.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BHJum10876 for ; Thu, 11 Apr 2002 10:19:56 -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 g3BHD4X74227 for ; Thu, 11 Apr 2002 13:13:04 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200204111713.g3BHD4X74227@nic-naa.net> To: ietf-xml-use@imc.org Subject: Comments on Section 5 Date: Thu, 11 Apr 2002 13:13:04 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 5. Internationalization Considerations This section describes internationalization considerations for the use of XML to represent data in IETF protocols. Readers should be familiar with IETF policy on the use of character sets and languages as described in RFC 2277 [3]. Suggestion: This section describes character set and language attribute declarations available to authors of protocols using XML, and the text directionality attribute declarations available using XHTML. Readers are encouraged to be familiar with RFC 2277, which requires protocols MUST identify which charset is used and suggests protocols contain a mechanism for charset negotiation, and additionaly requires that UTF-8 support MUST be possible. RFC 2277 also requires protocols MUST provide a mechanism capable of carrying information about the language of that text, and also suggests protocols contain a mechanism for language naming , and for language negotiation, and additionaly requires a default value for language, which MUST be understandable by an English-speaking person. This section does not describe considerations for the use of locales in XML to represent character properties, such as collation orderings, word breaking or formats for dates, numbers, or currency. [Meta-Comment: I doubt the wisdom of leaving locales out of IETF i18n boiler-plate, and its my experience that most IETF contributors who encounter i18n casually read 2277 as an issue-free license cum requirement to use Unicode.] 5.1 Character Sets XML provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8 [4] and UTF-16 [26]. Other encodings are also supported and can be specified using an "encoding" attribute in a document's XML declaration. It is strongly recommended that UTF-8 be mandated for protocols that represent data using XML. Suggestion: ... UTF-8 [4] and UTF-16 [26]. Other encodings are also supported and may be specified using the encoding pseudo-attribute in the xml declaration at the start of a document or the text declaration at the start of an entity. Examples: ... ... [Comment: Even if I agreed with the last sentance of the original paragraph, real examples are a good thing.] Guidelines for the use of XML declarations can be found in Section 4.1. [Comment: I don't see the import of this back-reference. How does sec. 4.1 provide guidelines for use, and meaningfully for charsets?] ... If an XML declaration is omitted, it is strongly urged to require use of a consistent character set, and to require UTF-8 as the most appropriate character set. If an XML declaration is allowed, it is again strongly urged to require use of a consistent character set, to require UTF-8 as the most appropriate character set, and to recommend inclusion of an "encoding" attribute that explicitly notes use of UTF-8 encoding. Suggestion: ... and to require UTF-8 as the most appropriate character set, if it is in fact the most appropriate character set. ... [Comment: The original text is over-reaching. Either it is repeating, and removing the conditional applicability from, 2277, or it is promoting a universal structured data over protocol-specific data. Now the W3C can discard the encoding pseudo-attribute, and mandate UTF-8, in XML, but that's their business. Ours is interoperability, legacy systems included. This shouldn't seem to be an end-run on the non-UTF-8 bits of 2277 and 3066. Remove the UTF-8 theocracy, and retain secular data exchange. Thx.] 5.2 Language Declaration [Comment: The reference to http://www.w3.org/TR/2000/REC-xml-20001006, sec. 1.12, refers to rfc1766, which in turn refers to iso636 and iso3166. The substitution of International Treaty Organization normative references and Nation State identifiers for the purpose of interoperable text concerns me. My concerns of course may be misplaced, I'm just an ignorant Indian. I suggest that we invite more comments, e.g., To: golla@ssila.org , endangered-languages-l@cleo.murdoch.edu.au Subject: Request for Comments: Proposed IETF Guidelines for Language Identifiers in protocols using XML Body The IETF is considering a proposal for the authors of protocols using XML to limit the identifiers for human languages to the set defined in iso639-1 [1] and iso3166 [2]. This would have the effect of discouraging the development of internet protocols which use XML for structured data exchange, and which use identifiers not defined in these references. For reference, using North America as an example The set of Indigenous Languages of North America for which an iso639-1 identifers exist is: ik (inupiaq), iu (inuktitut), nv (navajo), qu (quechua) The set of additional identifers for which a value exists in iso3166 for North America is: gr (greenland), ca (canada), us (united states of america), mx (united states of mexico) Comments, particularly those that describe use cases for which the above is unsuitable, and any alternatives, should be sent to the ietf-xml-use@imc.org mailing list. To join the list, send a message to "ietf-xml-use-request@imc.org" with the word "subscribe" in the body of the message. There is a web site for the list archives at http:// www.imc.org/ietf-xml-use/. [1] http://linux.infoterm.org/infoterm-e/i-infoterm.htm?raiso639-1_start.htm~Mitte [2] http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html EOT SSILA == Society for the Study of the Indigenous Languages of the Americas. Both scholarly and affected community input would be useful. The alternative is an inapplicability statement, something of the form "the use of minority, rare, infrequently taught, endangered, or extinct languages is depricated in IETF standards-track protocols that use XML for the delivery of structured text." ] Suggestion: language used to represent data in an XML document. The xml:lang attribute is defined in section 2.12 of [8], and has and values defined in [ISO 639]. [Add to References] It is strongly recommended that protocols representing data in a human language use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts, and if the language identifier is defined in [ISO 639]. Meta-Nit: 2277, sec 6, lines 325 - 328, suggests that "Internationalization considerations", be placed next to the Security Considerations section. Suggestion: Reorder sections 6 and 7. Eric From owner-ietf-xml-use Thu Apr 11 12:21:28 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3BJLST16370 for ietf-xml-use-bks; Thu, 11 Apr 2002 12:21:28 -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 g3BJLQm16366 for ; Thu, 11 Apr 2002 12:21:26 -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 g3BJLMg15874; Thu, 11 Apr 2002 15:21: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: RE: Validation and IETF XML Usage Guidelines From: "Simon St.Laurent" To: LMM@acm.org Cc: ietf-xml-use@imc.org In-Reply-To: <003b01c1e174$175e3370$6ace8642@larrypad> References: <003b01c1e174$175e3370$6ace8642@larrypad> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 11 Apr 2002 15:26:46 -0400 Message-Id: <1018553209.1026.70.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The discussion below is precisely what I'd like to see, both on the list and in the document. I think you've done an excellent job describing when extensibility may or may not be appropriate in a given protocol circumstance. Some general discussion of the balance between extensibility and constraints seems appropriate to this document. As far as W3C XML Schema is concerned, I have no problem with people using it. I have serious problems with mandating W3C XML Schema for a large class of projects for which it may or may not be appropriate. This feels like good progress to me. On Thu, 2002-04-11 at 12:15, Larry Masinter wrote: > > We want to give appropriate guidance for when and when > not to use the various mechanisms of XML, in a context > where the XML is embedded within some other protocol. > > We should try to capture the issue, that using XML schema, > requiring validity according to the schema, limits > the kind of extensibility that is allowed in a particular > way. > > In many contexts, there are other extensibility mechanisms > already in place -- the protocol has its own versioning > mechanism, ways of updating the schema or pointing to > a new one. So I think that it's not unreasonable to > expect that in many cases, XML Schema are exactly the > right thing. > > There may be some other contexts where more extensibility > in the XML is actually required, and some other mechanism > for describing validity is required; in those circumstances, > alternatives to XML schema can be considered. > > I'm less certain about how far we should go enumerating > them, but a look at some existing protocols (like WebDAV) > might be useful. > > There is some controversy about XML Schema, and > many people are more comfortable with the (admittedly > easier to read) DTD mechanism. It's also true that > in some circumstances a DTD will suffice for describing > the data structures allowed, e.g., if all of the elements > only contain text and the data typing mechanisms of XML > Schema aren't applicable or useful. > > We should take another pass at this; you may not be fully > satisfied (given what I sense as a strong distaste for the > W3C XML Schema Recommendation), but I hope we can at least > lay out what the tradeoffs are. > > Larry > -- > http://larry.masinter.net > > > -- 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 Fri Apr 12 05:18:33 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3CCIX426516 for ietf-xml-use-bks; Fri, 12 Apr 2002 05:18:33 -0700 (PDT) Received: from nic-naa.net (ptd-24-198-34-29.maine.rr.com [24.198.34.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CCIWm26512 for ; Fri, 12 Apr 2002 05:18:32 -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 g3CCBSX78795; Fri, 12 Apr 2002 08:11:28 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200204121211.g3CCBSX78795@nic-naa.net> To: Eric Brunner-Williams in Portland Maine cc: ietf-xml-use@imc.org, brunner@nic-naa.net Subject: Re: Comments on Section 5 In-Reply-To: Your message of "Thu, 11 Apr 2002 13:13:04 EDT." <200204111713.g3BHD4X74227@nic-naa.net> Date: Fri, 12 Apr 2002 08:11:28 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Uh, guys, I've gotten back my appeal on the IDN mess, and if you want to push Unicode on contributors, well, fundamentally it is their look-out whether or not it meets their needs. Likewise, if you want to push 639 and 3166 on contributors, well, fundamentally it also is their look-out if their languages have an approved lang tag from the two or three controlling authorities. Also, if the POSIX locale mechanism, which I did have something to do with, is unsightly to the eye, well, I'm told Unicode cures all ailements. As those brain-dead corporate MUAs are wont to say "User Brunner-Williams would like to retract or cancel message FOO". No direct replies please, Eric From owner-ietf-xml-use Sat Apr 13 23:33:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3E6XDj26027 for ietf-xml-use-bks; Sat, 13 Apr 2002 23:33:13 -0700 (PDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3E6XCm26020 for ; Sat, 13 Apr 2002 23:33:12 -0700 (PDT) Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g3E6YraW023414 for ; Sat, 13 Apr 2002 23:34:53 -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.12.3/8.12.3) with ESMTP id g3E6WTZW007997 for ; Sat, 13 Apr 2002 23:32:30 -0700 (PDT) Received: from larrypad ([130.248.184.130]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUJOTC00.ELO; Sat, 13 Apr 2002 23:32:00 -0700 Reply-To: From: "Larry Masinter" To: "'Julian Reschke'" , Subject: RE: Comments on draft 00 Date: Sat, 13 Apr 2002 23:32:00 -0700 Message-ID: <001501c1e37e$154e4500$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm realizing that I never sent this reply. We've been working on updates that address some of your comments, but there are questions about others.. > 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. If you're using a generic XML parser or serializer, you can always implement "MUST NOT be used" by adding (or stripping) the XML declaration, no? I've been thinking about this comment and a private comment about XML-in-Jabber, and realizing that in some cases, the 'protocol element' is not an XML document, it's a fragment of an XML document. So, for example, you could define a protocol which takes a string from the protocol and prepends it with an XML declaration and then sends it on to an XML processor. > 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. You can do whatever you want in private... after all, it's private. You can do whatever you want when debugging, too. But requests can fail when they contain processing instructions because the processing instructions are misinterpreted, can't they? I suppose there are a lot of alternatives here. But we're making 3rd-level indirect recommendations here: we're recommending to protocol designers what they should say in the protocol that will affect the implementation of senders and receivers that will determine what happens on particular instances, and you've made a first-level objection. Your request won't fail if it contains a PI, as long as the protocol allows for PIs. Protocols allow for PIs if they have a reason for allowing for PIs. Maybe you want protocols to allow senders to send PIs but receivers must ignore PIs during standard operation? > 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. For this kind of document and for the target audience, things that you think should go without saying shouldn't go without saying. If you can't suggest more explicit text, I'll take a whack at it next go-round. > 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. We've made a pass at dealing with this, so please re-review when the next draft is ready. > > 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). OK -- probably for the -02 draft. > > 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. Check out the revised wording. > 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? I'm uncertain about including this example. > 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). I don't understand this issue, could you explain? From owner-ietf-xml-use Sun Apr 14 01:37:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3E8bD513414 for ietf-xml-use-bks; Sun, 14 Apr 2002 01:37:13 -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 g3E8bBm13402 for ; Sun, 14 Apr 2002 01:37:11 -0700 (PDT) Received: (qmail 9782 invoked by uid 0); 14 Apr 2002 08:37:05 -0000 Received: from pd950c3f6.dip.t-dialin.net (HELO lisa) (217.80.195.246) by mail.gmx.net (mp007-rz3) with SMTP; 14 Apr 2002 08:37:05 -0000 From: "Julian Reschke" To: , Subject: RE: Comments on draft 00 Date: Sun, 14 Apr 2002 10:37:00 +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: <001501c1e37e$154e4500$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: Sunday, April 14, 2002 8:32 AM > To: 'Julian Reschke'; ietf-xml-use@imc.org > Subject: RE: Comments on draft 00 > > > > I'm realizing that I never sent this reply. We've been working > on updates that address some of your comments, but there are > questions about others.. Thanks for the feedback... > > 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. > > If you're using a generic XML parser or serializer, you can always > implement "MUST NOT be used" by adding (or stripping) the XML > declaration, no? For reading XML when using a generic XML parser, I don't have any control at all. The processor isn't required to report the declaration, so the application will never know whether there was a declaration or not. When *writing* XML things are a bit more complicated, because there are currently no widely used standard serializer APIs. > I've been thinking about this comment and a private comment > about XML-in-Jabber, and realizing that in some cases, the > 'protocol element' is not an XML document, it's a fragment > of an XML document. So, for example, you could define a protocol > which takes a string from the protocol and prepends it with > an XML declaration and then sends it on to an XML processor. If the goal is to allow exchange of XML fragments, this should be said, and it will probably require more work. When forbidding XML declaration, how do you handle encoding and version detection (see discussion around XML 1.1 draft)? > > 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. > > You can do whatever you want in private... after all, it's private. > You can do whatever you want when debugging, too. But requests > can fail when they contain processing instructions because the > processing instructions are misinterpreted, can't they? Yes, they can. But does this mean that they MUST? > I suppose there are a lot of alternatives here. But we're making > 3rd-level indirect recommendations here: we're recommending to > protocol designers what they should say in the protocol that will > affect the implementation of senders and receivers that will determine > what happens on particular instances, and you've made a first-level > objection. Your request won't fail if it contains a PI, as long > as the protocol allows for PIs. Protocols allow for PIs if they > have a reason for allowing for PIs. Maybe you want protocols to > allow senders to send PIs but receivers must ignore PIs during > standard operation? ...unless they understand them. That's the standard use case I was thinking of (and actually the standard usage of PIs). I think the spec should also say that PIs MUST not be used for in-band information. > > 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). > > I don't understand this issue, could you explain? See for a recent thread on xml-dev. From owner-ietf-xml-use Sun Apr 14 21:46:23 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3F4kNl04132 for ietf-xml-use-bks; Sun, 14 Apr 2002 21:46:23 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F4kKm04128 for ; Sun, 14 Apr 2002 21:46:20 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3F4kOZw018092 for ; Sun, 14 Apr 2002 21:46:24 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id VAA01652 for ; Sun, 14 Apr 2002 21:46:23 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Sun, 14 Apr 2002 21:46:23 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: ietf-xml-use@imc.org Subject: Comments on OO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On my website I have two articles that I think are relevant to this working group. The first article is mentioned in 00 (http://www.goland.org/xmlschema.htm) and the second I just added yesterday (http://www.goland.org/myxmlwish.htm). Below I do a quick review of the 00 document and discuss where my documents may be relevant. Section 3 - The issues mentioned in my second article probably merit an additional point on the strength/weakness of XML. Validity - We really need to discuss Relax-NG (http://www.oasis-open.org/committees/relax-ng/) as well. The W3C schema is unreadable and un-implement-able outside of its core features. Besides, normal human beings have no chance of actually writing a W3C schema. They have a much better shot with Relax-NG. Although I haven't figured out how you specify that new elements can be added to an existing element in Relax-NG. 4.5 Namespaces - Obviously I agree with this since it's the first entry in article 1. 4.6 Attributes - I would rewrite the example as:
10.1.2.3
That way, in the future, you could mark up the data. For example:
10.1.2.3
If you use an attribute then that sort of extensibility isn't possible. In addition if you use the string "ipv4" (either as an attribute value or as the value of an element) rather then the element IPV4 (with a namespace) then you create a namespace management problem. But all that having been said it still isn't clear that the alternate design given above is necessarily better. It depends, does someone have to routinely type this message in or is it mostly machine produced? If it's mostly human produced then ease of entry probably trumps everything and an attribute should be used. Otherwise go for the more extensible approach. 5.1 character sets - I'm told that the majority of XML implementations are actually non-compliant and only support UTF-8 (not UTF-16). Has anyone verified this? 5.2 Language Declaration - This reminded me of a very important design pattern that I just added to the bottom of article 1 regarding the use of xml:lang. Larry asked me to give general comments on the appropriateness of the issues in my first article to this spec. Given that this discussion is about a BCP there is a lot of latitude in terms of what is put in the draft. Specifically, good design patterns are (in my opinion) appropriate for a BCP. Most of my article 1 is about those design patterns. To help along this discussion I re-ordered the entries in my article to reflect their relative importance. As indicated by it position on top I think the ANY rule is the most important. Without this any future extensibility is impossible. Default attributes are next because the use of these attributes prevents the ability to sign/encrypt XML reliably. Namespaces come next only because, at least in theory, ANY would allow a schema without namespaces to add namespace qualified elements later. ElementFormDefault follows namespaces because if you turn on elementformDefault namespaces are a lot less useful. Avoiding uncontrolled namespaces in strings is next up because this kills the ability to extend a schema in a decentralized manner. Avoiding attributes is next up because attributes make extensibility difficult. Schema versioning is this high on the list only because so many people get it so horribly wrong. I don't think the community realizes how bad a time bomb it has left for itself because so few schemas are old enough to have been versioned yet. Global vs. local is next up because it's just good design practice. Avoiding strings for enumerated types comes closely after, it's a common mistake and should probably even be bumped up the list. XML:Lang is at the bottom of the list because it isn't as general an observation, it is just a common mistake rather then a systemic flaw. Anyway, that's just my two cents, Yaron From owner-ietf-xml-use Mon Apr 15 08:08:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FF8Dc19901 for ietf-xml-use-bks; Mon, 15 Apr 2002 08:08:13 -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 g3FF8Bm19896 for ; Mon, 15 Apr 2002 08:08:11 -0700 (PDT) Received: (qmail 20455 invoked by uid 0); 15 Apr 2002 15:08:06 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 15 Apr 2002 15:08:06 -0000 From: "Julian Reschke" To: "Yaron Y. Goland" , Subject: RE: Comments on OO Date: Mon, 15 Apr 2002 17:08:01 +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: 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 Yaron Y. Goland > Sent: Monday, April 15, 2002 6:46 AM > To: ietf-xml-use@imc.org > Subject: Comments on OO > ... > > 5.1 character sets - I'm told that the majority of XML implementations are > actually non-compliant and only support UTF-8 (not UTF-16). Has anyone > verified this? It's certainly not true for MSXML/Xerces/Expat (which would cover the Windows/Java/C world). Where does this rumour come from? From owner-ietf-xml-use Mon Apr 15 14:16:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FLGG204449 for ietf-xml-use-bks; Mon, 15 Apr 2002 14:16:16 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FLGDm04441 for ; Mon, 15 Apr 2002 14:16:13 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3FLGDZw006651; Mon, 15 Apr 2002 14:16:13 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id OAA11973; Mon, 15 Apr 2002 14:16:13 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Mon, 15 Apr 2002 14:16:12 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: Julian Reschke cc: ietf-xml-use@imc.org Subject: RE: Comments on OO In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A damn good point. Nobody really does put together their own XML parser anymore do they? Everyone just uses one of the mainstream ones which are all compliant. Well, that answers that question. On Mon, 15 Apr 2002, Julian Reschke wrote: > > From: owner-ietf-xml-use@mail.imc.org > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Yaron Y. Goland > > Sent: Monday, April 15, 2002 6:46 AM > > To: ietf-xml-use@imc.org > > Subject: Comments on OO > > ... > > > > 5.1 character sets - I'm told that the majority of XML implementations are > > actually non-compliant and only support UTF-8 (not UTF-16). Has anyone > > verified this? > > It's certainly not true for MSXML/Xerces/Expat (which would cover the > Windows/Java/C world). Where does this rumour come from? > From owner-ietf-xml-use Mon Apr 15 14:23:28 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FLNSE04566 for ietf-xml-use-bks; Mon, 15 Apr 2002 14:23:28 -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 g3FLNQm04561 for ; Mon, 15 Apr 2002 14:23:27 -0700 (PDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g3FLNET07607; Mon, 15 Apr 2002 17:23:14 -0400 Date: Mon, 15 Apr 2002 17:23:14 -0400 From: Daniel Veillard To: "Yaron Y. Goland" Cc: Julian Reschke , ietf-xml-use@imc.org Subject: Re: Comments on OO Message-ID: <20020415172314.W27043@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from modulus@cinenet.net on Mon, Apr 15, 2002 at 02:16:12PM -0700 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 15, 2002 at 02:16:12PM -0700, Yaron Y. Goland wrote: > > A damn good point. Nobody really does put together their own XML parser > anymore do they? Hum, I would not bet much on this one especially for protocol processing. Just in the world of XML-RPC and Jabber I have seens very strange code handling XML data. > Everyone just uses one of the mainstream ones which are > all compliant. Well, that answers that question. Independantly of this, it's not a good idea to try to impose a given encoding between UTF8 and UTF16 (being the two mandatory ones). Most data are in practice better carried by UTF8, but some large framework have also standardized on UTF-16 and the status quo of the XML spec is probably the best to point at. 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 Mon Apr 15 16:43:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3FNhhl07336 for ietf-xml-use-bks; Mon, 15 Apr 2002 16:43:43 -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 g3FNhfm07332 for ; Mon, 15 Apr 2002 16:43:41 -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 TAA05836 for ; Mon, 15 Apr 2002 19:23:25 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5TMKP>; Mon, 15 Apr 2002 19:43:39 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B939@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-xml-use@imc.org'" Subject: Guidelines Document Update Date: Mon, 15 Apr 2002 19:43:31 -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: Earlier today I sent the -01 version of "Guidelines For The Use of XML in IETF Protocols" to the IETF I-D administrator. Typically that means the document will be announced and placed in the IETF archives by some time tomorrow, but if you can't wait you can obtain a preview copy from the mailing list web site (thanks, Paul!): http://www.imc.org/ietf-xml-use/index.html You _might_ have a problem if you try to view the XML version directly in a web browser; I ran into an access error with IE 6 as it tried to retrieve the XML stylesheet. The text and HTML versions should be OK. -Scott- From owner-ietf-xml-use Mon Apr 15 18:14:03 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3G1E3N09343 for ietf-xml-use-bks; Mon, 15 Apr 2002 18:14:03 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G1E0m09339 for ; Mon, 15 Apr 2002 18:14:00 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3G1E3Zw019329; Mon, 15 Apr 2002 18:14:03 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id SAA14385; Mon, 15 Apr 2002 18:14:02 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Mon, 15 Apr 2002 18:14:01 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: "Hollenbeck, Scott" cc: "'ietf-xml-use@imc.org'" Subject: Re: Guidelines Document Update In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B939@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Appendix A is useful but what would be perfect is a change marked version. On Mon, 15 Apr 2002, Hollenbeck, Scott wrote: > > Earlier today I sent the -01 version of "Guidelines For The Use of XML in > IETF Protocols" to the IETF I-D administrator. Typically that means the > document will be announced and placed in the IETF archives by some time > tomorrow, but if you can't wait you can obtain a preview copy from the > mailing list web site (thanks, Paul!): > > http://www.imc.org/ietf-xml-use/index.html > > You _might_ have a problem if you try to view the XML version directly in a > web browser; I ran into an access error with IE 6 as it tried to retrieve > the XML stylesheet. The text and HTML versions should be OK. > > -Scott- > From owner-ietf-xml-use Mon Apr 15 19:04:35 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G24Zh10340 for ietf-xml-use-bks; Mon, 15 Apr 2002 19:04:35 -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 g3G24Xm10335 for ; Mon, 15 Apr 2002 19:04:33 -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 VAA08367; Mon, 15 Apr 2002 21:44:08 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5TNLV>; Mon, 15 Apr 2002 22:04:22 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B93C@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Yaron Y. Goland'" Cc: "'ietf-xml-use@imc.org'" Subject: RE: Guidelines Document Update Date: Mon, 15 Apr 2002 22:04:21 -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: Yaron Y. Goland [mailto:modulus@cinenet.net] > Sent: Monday, April 15, 2002 9:14 PM > To: Hollenbeck, Scott > Cc: 'ietf-xml-use@imc.org' > Subject: Re: Guidelines Document Update > > > > Appendix A is useful but what would be perfect is a change > marked version. That gets quite ugly to implement by hand in ASCII text (the IETF's "official" I-D format), especially since things like overstrikes and underlines are expressly forbidden in the I-D/RFC authoring guidelines. You might want to consider a file comparison utility like "diff" to compare -01 to -00 if you'd like to see word-for-word changes. -Scott- From owner-ietf-xml-use Tue Apr 16 00:52:38 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3G7qcJ06556 for ietf-xml-use-bks; Tue, 16 Apr 2002 00:52:38 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G7qam06544 for ; Tue, 16 Apr 2002 00:52:36 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3G7qPZw006679; Tue, 16 Apr 2002 00:52:35 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id AAA18435; Tue, 16 Apr 2002 00:52:25 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Tue, 16 Apr 2002 00:52:24 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: "Hollenbeck, Scott" cc: "'ietf-xml-use@imc.org'" Subject: RE: Guidelines Document Update In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B93C@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks to the wonders of Word (hey, who threw that tomato?) it's easy to do diffs. All I ask is that you keep the current version and the previous version easily accessable from the same web page. That will let me generate my own diffs. Thanks, Yaron P.S. I wasn't suggesting that the draft submitted to the IETF have change marking. I was just hoping that an 'extra' draft (ala the HTTP version) could be generated and posted. But so long as the current and previous versions are available this isn't a big deal. On Mon, 15 Apr 2002, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Yaron Y. Goland [mailto:modulus@cinenet.net] > > Sent: Monday, April 15, 2002 9:14 PM > > To: Hollenbeck, Scott > > Cc: 'ietf-xml-use@imc.org' > > Subject: Re: Guidelines Document Update > > > > > > > > Appendix A is useful but what would be perfect is a change > > marked version. > > That gets quite ugly to implement by hand in ASCII text (the IETF's > "official" I-D format), especially since things like overstrikes and > underlines are expressly forbidden in the I-D/RFC authoring guidelines. You > might want to consider a file comparison utility like "diff" to compare -01 > to -00 if you'd like to see word-for-word changes. > > -Scott- > From owner-ietf-xml-use Tue Apr 16 04:13:30 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3GBDU013296 for ietf-xml-use-bks; Tue, 16 Apr 2002 04:13:30 -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 g3GBDSm13283 for ; Tue, 16 Apr 2002 04:13:28 -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 GAA16197; Tue, 16 Apr 2002 06:52:57 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5TPXA>; Tue, 16 Apr 2002 07:13:11 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B93F@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Yaron Y. Goland'" Cc: "'ietf-xml-use@imc.org'" Subject: RE: Guidelines Document Update Date: Tue, 16 Apr 2002 07:13:10 -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'll ask the keeper of the web page if he can keep previous versions of the document available as well. Watch the page for progress... -Scott- > -----Original Message----- > From: Yaron Y. Goland [mailto:modulus@cinenet.net] > Sent: Tuesday, April 16, 2002 3:52 AM > To: Hollenbeck, Scott > Cc: 'ietf-xml-use@imc.org' > Subject: RE: Guidelines Document Update > > > Thanks to the wonders of Word (hey, who threw that tomato?) > it's easy to > do diffs. All I ask is that you keep the current version and > the previous > version easily accessable from the same web page. That will let me > generate my own diffs. > Thanks, > Yaron > > P.S. I wasn't suggesting that the draft submitted to the IETF > have change > marking. I was just hoping that an 'extra' draft (ala the > HTTP version) > could be generated and posted. But so long as the current and previous > versions are available this isn't a big deal. > > On Mon, 15 Apr 2002, Hollenbeck, Scott wrote: > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:modulus@cinenet.net] > > > Sent: Monday, April 15, 2002 9:14 PM > > > To: Hollenbeck, Scott > > > Cc: 'ietf-xml-use@imc.org' > > > Subject: Re: Guidelines Document Update > > > > > > > > > > > > Appendix A is useful but what would be perfect is a change > > > marked version. > > > > That gets quite ugly to implement by hand in ASCII text (the IETF's > > "official" I-D format), especially since things like overstrikes and > > underlines are expressly forbidden in the I-D/RFC authoring > guidelines. You > > might want to consider a file comparison utility like > "diff" to compare -01 > > to -00 if you'd like to see word-for-word changes. > > > > -Scott- From owner-ietf-xml-use Tue Apr 16 08:38:49 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GFcnT01864 for ietf-xml-use-bks; Tue, 16 Apr 2002 08:38:49 -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 g3GFclm01859 for ; Tue, 16 Apr 2002 08:38:47 -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 LAA28469; Tue, 16 Apr 2002 11:18:21 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQW5Y4>; Tue, 16 Apr 2002 11:38:34 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B951@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Yaron Y. Goland'" Cc: "'ietf-xml-use@imc.org'" Subject: RE: Guidelines Document Update Date: Tue, 16 Apr 2002 11:38:31 -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: Yaron Y. Goland [mailto:modulus@cinenet.net] > Sent: Tuesday, April 16, 2002 3:52 AM > To: Hollenbeck, Scott > Cc: 'ietf-xml-use@imc.org' > Subject: RE: Guidelines Document Update > > > Thanks to the wonders of Word (hey, who threw that tomato?) > it's easy to > do diffs. All I ask is that you keep the current version and > the previous > version easily accessable from the same web page. That will let me > generate my own diffs. The fellow maintaining the web page isn't keen on keeping old versions of the documents around, but Larry was kind enough to produce a PDF file comparing -01 and -00. You can find it here: http://www.imc.org/ietf-xml-use/xml-guide-diff.pdf -Scott- From owner-ietf-xml-use Tue Apr 16 17:36:04 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3H0a4u03641 for ietf-xml-use-bks; Tue, 16 Apr 2002 17:36:04 -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 g3H0a2m03637 for ; Tue, 16 Apr 2002 17:36:02 -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 g3H0Zug01390; Tue, 16 Apr 2002 20:35:56 -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: Schemas (was Re: Guidelines Document Update) From: "Simon St.Laurent" To: "Hollenbeck, Scott" Cc: "'ietf-xml-use@imc.org'" In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B939@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B939@vsvapostal3.bkup6> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 16 Apr 2002 20:41:21 -0400 Message-Id: <1019004089.1026.198.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The new language in 4.4, Validity and Extensibility [1] is a huge improvement. I have one minor concern. Paragraph seven states: -------------------- Many protocols have successfully used the DTD mechanism for describing validity, whether or not they insist that all XML elements are valid. However, the features in XML Schema for data typing and constraining values seem very appropriate for many of the uses of XML. For this reason, this document recommends that, in lieu of reasons to choose some other mechanism, protocol designs use W3C XML Schema as the language for describing validity. -------------------- In the last sentence, I think "in lieu of" should be replaced by "in the absence of", as "in lieu of" can be read "in the place of". I don't think that's what it means to say. [1] - http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html#xmlv -- 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 17 03:03:10 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3HA3Aq18778 for ietf-xml-use-bks; Wed, 17 Apr 2002 03:03:10 -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 g3HA35m18762 for ; Wed, 17 Apr 2002 03:03:05 -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 26999164B for ; Wed, 17 Apr 2002 19:02:53 +0900 (JST) Message-Id: <4.2.0.58.J.20020417185126.00a96e60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 17 Apr 2002 18:55:01 +0900 To: ietf-xml-use@imc.org From: Martin Duerst Subject: Re: Comments on OO In-Reply-To: <20020415172314.W27043@redhat.com> 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 17:23 02/04/15 -0400, Daniel Veillard wrote: > Independantly of this, it's not a good idea to try to impose a given >encoding between UTF8 and UTF16 (being the two mandatory ones). Most >data are in practice better carried by UTF8, but some large framework >have also standardized on UTF-16 and the status quo of the XML spec >is probably the best to point at. The XML spec requires XML *parsers* to support both UTF-8 and UTF-16. The IETF has a strong preference for UTF-8, because this avoids the endianess problems. The current wording doesn't exclude that a protocol chooses to use UTF-16, or some other encoding, or that a protocol allows several encodings. So it's fine in my view. Regards, Martin. From owner-ietf-xml-use Wed Apr 17 06:21:17 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3HDLHH03653 for ietf-xml-use-bks; Wed, 17 Apr 2002 06:21:17 -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 g3HDLGm03644 for ; Wed, 17 Apr 2002 06:21:16 -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 JAA04881; Wed, 17 Apr 2002 09:00:42 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF54BZZ>; Wed, 17 Apr 2002 09:20:56 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B95C@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Simon St.Laurent'" Cc: "'ietf-xml-use@imc.org'" Subject: RE: Schemas (was Re: Guidelines Document Update) Date: Wed, 17 Apr 2002 09:20: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: Simon St.Laurent [mailto:simonstl@simonstl.com] > Sent: Tuesday, April 16, 2002 8:41 PM > To: Hollenbeck, Scott > Cc: 'ietf-xml-use@imc.org' > Subject: Schemas (was Re: Guidelines Document Update) > > > The new language in 4.4, Validity and Extensibility [1] is a huge > improvement. I have one minor concern. Paragraph seven states: > -------------------- > Many protocols have successfully used the DTD mechanism for describing > validity, whether or not they insist that all XML elements are valid. > However, the features in XML Schema for data typing and constraining > values seem very appropriate for many of the uses of XML. For this > reason, this document recommends that, in lieu of reasons to > choose some > other mechanism, protocol designs use W3C XML Schema as the > language for > describing validity. > -------------------- > > In the last sentence, I think "in lieu of" should be replaced > by "in the absence of", as "in lieu of" can be read "in the place of". > > I don't think that's what it means to say. Seems reasonable... -Scott- From owner-ietf-xml-use Wed Apr 17 08:31:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HFVlt11815 for ietf-xml-use-bks; Wed, 17 Apr 2002 08:31:47 -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 g3HFVkm11810 for ; Wed, 17 Apr 2002 08:31:46 -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 LAA13679 for ; Wed, 17 Apr 2002 11:11:28 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQXYNS>; Wed, 17 Apr 2002 11:31:42 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B960@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-xml-use@imc.org'" Subject: FW: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-01.txt Date: Wed, 17 Apr 2002 11:31:41 -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: Here's the formal announcement for -01. Though we updated the abstract (changing eXtensible to Extensible), it looks like the change wasn't captured in whatever is used to extract the abstract for announcement purposes... -Scott- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, April 17, 2002 9:54 AM To: IETF-Announce; @loki.ietf.org Subject: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-01.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-01.txt Pages : 25 Date : 16-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-01. 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-01.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-01.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 Sun Apr 21 02:43:32 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3L9hW803282 for ietf-xml-use-bks; Sun, 21 Apr 2002 02:43:32 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3L9hU303278 for ; Sun, 21 Apr 2002 02:43:30 -0700 (PDT) Received: from RELAX (g039158.ppp.asahi-net.or.jp [211.132.39.158]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 7A99D6173 for ; Sun, 21 Apr 2002 18:43:28 +0900 (JST) Date: Sun, 21 Apr 2002 18:44:05 +0900 From: MURATA Makoto To: ietf-xml-use@imc.org Subject: RE: Validation and IETF XML Usage Guidelines Message-Id: <20020421181437.FDF3.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The second I-D is a big improvement. But I am not happy with the following sentences and I would like to delete them. > However, the features in XML Schema for data typing and > constraining values seem very appropriate for many of the uses of > XML. For this reason, this document recommends that, in lieu of > reasons to choose some other mechanism, protocol designs use W3C XML > Schema as the language for describing validity. In the XML developer mailing list, it has been repeatedly reported that XML Schema implementations fail to interwork. If IETF still cares "rough consensus and running code", I think that the guideline document MUST NOT recommend XML Schema. Rather, implementors should be encouraged to peruse their favorite languages. Simon St.Laurent wrote: > As far as W3C XML Schema is concerned, I have no problem with people > using it. I have serious problems with mandating W3C XML Schema for a > large class of projects for which it may or may not be appropriate. Very strong opposition to XML Schema does exist in the XML community. I am certainly against XML Schema and bet my career on RELAX NG. (More about this, see two chapters written by me in an upcoming book "XML and Java, second edition" from Addison-Wesley.) In stead of the two sentences quoted above, I would propose: However, DTDs do not have strong datatypes and cannot handle namespaces properly. For this reason, implementors are encouraged to try not only DTDs but also other schema languages mentioned above. Cheers, -- MURATA Makoto From owner-ietf-xml-use Sun Apr 21 10:48:48 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3LHmmE01541 for ietf-xml-use-bks; Sun, 21 Apr 2002 10:48:48 -0700 (PDT) Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3LHmla01537 for ; Sun, 21 Apr 2002 10:48:47 -0700 (PDT) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g3LHm5PB001762 for ; Sun, 21 Apr 2002 10:48:05 -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.3/8.12.3) with ESMTP id g3LHkBIC012624 for ; Sun, 21 Apr 2002 10:46:11 -0700 (PDT) Received: from larrypad ([130.248.184.146]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GUXIT700.JQE for ; Sun, 21 Apr 2002 10:48:43 -0700 Reply-To: From: "Larry Masinter" To: Subject: Guidelines in use: IMPP working group considerations Date: Sun, 21 Apr 2002 10:48:37 -0700 Message-ID: <002b01c1e95c$c5e35e80$6ace8642@larrypad> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 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: FYI, there's a discussion of the applicability of these guidelines in the IMPP working group, e.g., http://www.imppwg.org/ml-archive/IMPP-WG/200204/msg00050.html and messages surrounding. From owner-ietf-xml-use Mon Apr 22 05:33:05 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3MCX5c08908 for ietf-xml-use-bks; Mon, 22 Apr 2002 05:33:05 -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 g3MCX3a08903 for ; Mon, 22 Apr 2002 05:33:03 -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 IAA07918; Mon, 22 Apr 2002 08:12:44 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5VW9L>; Mon, 22 Apr 2002 08:32:56 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'MURATA Makoto'" , ietf-xml-use@imc.org Subject: RE: Validation and IETF XML Usage Guidelines Date: Mon, 22 Apr 2002 08:32:49 -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: > In the XML developer mailing list, it has been repeatedly > reported that > XML Schema implementations fail to interwork. If IETF still cares > "rough consensus and running code", I think that the > guideline document > MUST NOT recommend XML Schema. Rather, implementors should > be encouraged > to peruse their favorite languages. I can't agree with this suggestion - a recommendation of "use your favorite language" is no recommendation at all for someone who doesn't have a favorite language. I don't have a problem, though, with noting that there are alternatives to XML Schema (done in -01) and that the issue is still somewhat controversial (can be emphasized in -02). > Simon St.Laurent wrote: > > > As far as W3C XML Schema is concerned, I have no problem with people > > using it. I have serious problems with mandating W3C XML > Schema for a > > large class of projects for which it may or may not be appropriate. > > Very strong opposition to XML Schema does exist in the XML > community. I am > certainly against XML Schema and bet my career on RELAX NG. > (More about this, > see two chapters written by me in an upcoming book "XML and > Java, second edition" > from Addison-Wesley.) > > In stead of the two sentences quoted above, I would propose: > > However, DTDs do not have strong datatypes and cannot handle > namespaces properly. For this reason, implementors are > encouraged > to try not only DTDs but also other schema languages > mentioned above. Again, I can't agree to this specific change. The whole idea of the document is to give people who have decided to use XML as part of a protocol specification some specific guidelines to help them accomplish their task. Saying "try DTDs" (which are known to have limitations when used to specify protocols) "and try other schema languages" doesn't necessarily help a protocol designer - if anything, it may be more confusing. I don't have a problem with noting that there is still some controversy surrounding the topic in the XML community, but with this document's limited context (IETF protocols) that's as much as I'd care to note. -Scott- From owner-ietf-xml-use Mon Apr 22 06:00:25 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3MD0PM09829 for ietf-xml-use-bks; Mon, 22 Apr 2002 06:00:25 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MD0Oa09820 for ; Mon, 22 Apr 2002 06:00:24 -0700 (PDT) Received: from RELAX (j103016.ppp.asahi-net.or.jp [61.213.103.16]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 12CCD6149; Mon, 22 Apr 2002 22:00:09 +0900 (JST) Date: Mon, 22 Apr 2002 22:01:01 +0900 From: MURATA Makoto To: "Hollenbeck, Scott" Subject: Re: Validation and IETF XML Usage Guidelines Cc: ietf-xml-use@imc.org In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> Message-Id: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Apr 2002 08:32:49 -0400 "Hollenbeck, Scott" wrote: > > In the XML developer mailing list, it has been repeatedly > > reported that > > XML Schema implementations fail to interwork. If IETF still cares > > "rough consensus and running code", I think that the > > guideline document > > MUST NOT recommend XML Schema. Rather, implementors should > > be encouraged > > to peruse their favorite languages. > > I can't agree with this suggestion - a recommendation of "use your favorite > language" is no recommendation at all for someone who doesn't have a > favorite language. I don't have a problem, though, with noting that there > are alternatives to XML Schema (done in -01) and that the issue is still > somewhat controversial (can be emphasized in -02). I claim that I am an expert of XML in general and schema languages in particular. If I am asked by users, I cannot recommend any of the schema languages at hand. Although I certainly think RELAX NG is technically the best, I cannot guarantee it will make it in the market. XML Schema just sucks. If no schema languages can be recommended, it is a good idea not to recommend any of them. If we recommend one of them, we run the risk of deceiving readers. I thus continue to oppose to the two sentences below: > However, the features in XML Schema for data typing and > constraining values seem very appropriate for many of the uses of > XML. For this reason, this document recommends that, in lieu of > reasons to choose some other mechanism, protocol designs use W3C XML > Schema as the language for describing validity. > Again, I can't agree to this specific change. The whole idea of the > document is to give people who have decided to use XML as part of a protocol > specification some specific guidelines to help them accomplish their task. I don't stick to my specific wording. But I strongly oppose to recommend a single specific schema language, when the situation is so debatable and controversial. I think that the current I-D misleads readers and makes them waste their time and money. > Saying "try DTDs" (which are known to have limitations when used to specify > protocols) "and try other schema languages" doesn't necessarily help a > protocol designer - if anything, it may be more confusing. When the reality is confusing, we cannot avoid confusing statements while being honest. All what we can do is to honestly write that the situation is confusing and that we are confused. >I don't have a > problem with noting that there is still some controversy surrounding the > topic in the XML community, but with this document's limited context (IETF > protocols) that's as much as I'd care to note. I also think that it is a good idea to add more text about the controversy. MURATA Makoto From owner-ietf-xml-use Mon Apr 22 06:51:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3MDpqp12787 for ietf-xml-use-bks; Mon, 22 Apr 2002 06:51:52 -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 g3MDppa12783 for ; Mon, 22 Apr 2002 06:51:51 -0700 (PDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g3MDpf919132; Mon, 22 Apr 2002 09:51:41 -0400 Date: Mon, 22 Apr 2002 09:51:41 -0400 From: Daniel Veillard To: MURATA Makoto Cc: "Hollenbeck, Scott" , ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines Message-ID: <20020422095141.B27043@redhat.com> Reply-To: veillard@redhat.com References: <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp>; from murata@hokkaido.email.ne.jp on Mon, Apr 22, 2002 at 10:01:01PM +0900 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > I claim that I am an expert of XML in general and schema languages in particular. > If I am asked by users, I cannot recommend any of the schema languages at hand. > Although I certainly think RELAX NG is technically the best, I cannot guarantee > it will make it in the market. XML Schema just sucks. Seems a bit strongly worded to me, and the Datatype part of XML Schemas looks an useful foundation for doing verification on a receiving endpoint independantly of the mechanism used to specify the structure. 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 Mon Apr 22 07:23:22 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MENMS15000 for ietf-xml-use-bks; Mon, 22 Apr 2002 07:23:22 -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 g3MENLa14996 for ; Mon, 22 Apr 2002 07:23:21 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA12507 for ; Mon, 22 Apr 2002 10:23:21 -0400 Date: Mon, 22 Apr 2002 16:20:49 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <10787344609.20020422162049@w3.org> To: IETF XML Subject: Notes on draft-hollenbeck-ietf-xml-guidelines-01.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------7312E173E2221AB" Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------------7312E173E2221AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello there, I made these notes to further my understanding of draft-hollenbeck-ietf-xml-guidelines-01.txt as I was reading it. I figured they might be useful to others, either to agree with points that occured to me or to disagree with points I made because I was wrong or misunderstood the document I was reading. I have subscribed to ietf-xml-use but not yet read the archives; however I wanted to share these notes now in case they are useful and before I forgot. My apologies if they raise issues that are already discussed and resolved. -- Chris mailto:chris@w3.org ------------7312E173E2221AB Content-Type: text/plain; name="hollenbeck-notes.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hollenbeck-notes.txt" Tm90ZXMgb24gDQpHdWlkZWxpbmVzIEZvciBUaGUgVXNlIG9mIFhNTCBpbiBJRVRGIFByb3RvY29s cw0KZHJhZnQtaG9sbGVuYmVjay1pZXRmLXhtbC1ndWlkZWxpbmVzLTAxLnR4dA0KaHR0cDovL3d3 dy5pbWMub3JnL2lldGYteG1sLXVzZS9kcmFmdC1ob2xsZW5iZWNrLWlldGYteG1sLWd1aWRlLmh0 bWwNCg0KR2VuZXJhbCAtIGdvb2QsIHdlbGwgdGhvdWdodCBvdXQgZG9jdW1lbnQsIGFkbWlyYWJs eSBjb25jaXNlIGFuZCB3ZWxsIHJlZmVyZW5jZWQuIFNvbWUgdmFnYXJpdGllcyByZW1haW4sIHdo aWNoIEkgYXNzdW1lIGFyZSBpbmFkdmVydGVudCByYXRoZXIgdGhhbiBkZWxpYmVyYXRlIGxvb3Bo b2xlcyBzbyB0aGVzZSBzaG91bGQgYmUgdGlnaHRlbmVkIHVwLiBPdmVyYWxsLCBhIG1vZGVsIG9m IHRoZSBzb3J0IG9mIHBpdGh5IEJDUCBkaXJlY3RpdmVzIEkgd291bGQgbGlrZSB0byBzZWUgdGhl IFRBRyBwcm9kdWNpbmcuDQoNCjEuMiBTY29wZSAtIGlzIGl0IHByb3RvY29sIGluIHRoZSBzZW5z ZSBvZiBhbiB4bWwtYmFzZWQgdHJhbnNwb3J0LCBvciBpbiB0aGUgc2Vuc2Ugb2YgZGF0YSB0aGF0 IGlzIHRyYW5zcG9ydGVkIG92ZXIgbmV0d29ya3MuICJ3aWRlbHktdXNlZCBtZWNoYW5pc20gZm9y IHJlcHJlc2VudGluZyBzdHJ1Y3R1cmVkIGRhdGEgaW4gcHJvdG9jb2wgZXhjaGFuZ2VzIiBzZWVt cyB0byBpbXBseSB0aGUgbGF0dGVyLiBJdHMgaW1wb3J0YW50IHRvIGtub3cgd2hpY2ggb25lLCB0 byBiZSBhYmxlIHRvIGV2YWx1YXRlIHRoaXMgZG9jdW1lbnQuIFRoZSBzY29wZSBzdGF0ZW1lbnQg aXMgY29uZnVzaW5nLiBPbiB0aGUgb25lIGhhbmQgdGhlIHNjb3BlIGlzICJndWlkZWxpbmVzIGZv ciB0aGUgdXNlIG9mIFhNTCBjb250ZW50IHdpdGhpbiBhIGxhcmdlciBwcm90b2NvbCIgYW5kIG9u IHRoZSBvdGhlciwgdXNlIG9mICJoaWdoZXItbGV2ZWwgcmVwcmVzZW50YXRpb24gZnJhbWV3b3Jr cywgYmFzZWQgb24gWE1MLCB0aGF0IGhhdmUgYmVlbiBkZXNpZ25lZCBhcyBjYXJyaWVycyBvZiBj ZXJ0YWluIGNsYXNzZXMgb2YgaW5mb3JtYXRpb24iIGlzIG91dCBvZiBzY29wZS4gVGhpcyBpcyBj b25mdXNpbmcuDQoNCkZyb20gcmVhZGluZyB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQsIHNtYWxs IHhtbCBmcmFnbWVudHMgdGhhdCBmb3JtIHBhcnQgb2YgYSBsYXJnZXIgcHJvdG9jb2wgKGZvciBl eGFtcGxlLCB4bWwgaGVhZGVycykgc2VlbSBzIHRvIGJlIHRoZSB0YXJnZXQuIFRoZSBzY29wZSBj b3VsZCBtb3JlIGV4cGxpY2l0bHkgbm90ZSB0aGF0ICJhbGwgWE1MIHdoaXMgaXMgdHJhbnNtaXR0 ZWQgb3ZlciBhIG5ldHdvcmsiIGlzIG91dCBvZiBzY29wZS4NCg0KMi4gWE1MIFNlbGVjdGlvbiBD b25zaWRlcmF0aW9ucw0KIlhNTCBwcm9jZXNzaW5nIHNwZWVkIGNhbiBiZSBhbiBpc3N1ZSBpbiBz b21lIGVudmlyb25tZW50cy4gWE1MIHByb2Nlc3NpbmcgY2FuIGJlIHNsb3dlciBiZWNhdXNlIFhN TCBkYXRhIHN0cmVhbXMgbWF5IGJlIGxhcmdlciB0aGFuIG90aGVyIHJlcHJlc2VudGF0aW9ucywg YW5kIHRoZSB1c2Ugb2YgZ2VuZXJhbCBwdXJwb3NlIFhNTCBwYXJzZXJzIHdpbGwgYWRkIGEgc29m dHdhcmUgbGF5ZXIgd2l0aCBpdHMgb3duIHBlcmZvcm1hbmNlIGNvc3RzLiIgDQpHaXZlcyByZWFz b25zICpub3QqIHRvIHVzZSBYTUwgYnV0IGxpdHRsZSBjb3VudGVyIGFyZ3VtZW50LiBQZXJoYXBz IHRoZSBkZXNpcmUgaXMgdG8gc3RvcCB3aGxlc2FsZSB0aG91Z2h0bGVzcyBhZG9wdGlvbiBvZiBY TUwgcmVnYXJkbGVzcyBvZiBhcHBsaWNhYmlsaXR5LCBidXQgYSBiYWxhbmNlZCBzZWxlY3Rpb24g c2VjdGlvbiBzaG91bGQgYWxzbyBtZW50aW8gYmVuZWZpcnRzLiBBbiBleGFtcGxlIGZvciB0aGUg cGllY2UgcXVvdGVkIGFib3ZlIHdvdWxkIGJlIHRvIGFwcGVuZCAid2hpY2ggc2hvdWxkIGJlIGJh bGFuY2VkIGFnYWluc3QgdGhlIGZvb3RwcmludCBhbmQgbGFjayBvZiBvcHRpbWlzYXRpb24gb2Yg YSBteXJpYWQgb2Ygc3BlY2lhbCBwdXJwb3NlIHBhcnNlcnMgaW4gdGhlIHNhbWUgc29mdHdhcmUi Lg0KDQo0LjEgWE1MIERlY2xhcmF0aW9ucw0KIkluIHNvbWUgY2FzZXMsIHRoZSBYTUwgdXNlZCBp cyBhIHNtYWxsIGZyYWdtZW50IGluIGEgbGFyZ2VyIGNvbnRleHQsIHdoZXJlIHRoZSBYTUwgdmVy c2lvbiBhbmQgY2hhcmFjdGVyIGVuY29kaW5nIGFyZSBzcGVjaWZpZWQgZXh0ZXJuYWxseS4gSW4g dGhvc2UgY2FzZXMsIHRoZSBYTUwgZGVjbGFyYXRpb24gbWlnaHQgYWRkIGV4dHJhIG92ZXJoZWFk LiAiIA0KVGhpcyBzZWVtcyB0byBpbXBseSB0aGF0IFhNTCBtaWdodCBiZSBlbmNvZGVkIGluIHNv bWV0aGluZyBvdGhlciB0aGFuIFVURi04IG9yIFVURi0xNiwgb3IgdXNlIGEgdmVyc2lvbiBvdGhl ciB0aGFuIDEuMCwgYW5kIG9taXQgdGhpcyBpbXBvcnRhbnQgaW5mb3JtYXRpb24gaWYgdGhlIHBl cmNlbnRhZ2Ugb2YgWE1MIHRvIG92ZXJhbGwgZGF0YSBpcyBzbWFsbC4gVGhpcyBpcyBjbGVhcmx5 IHdyb25nLCBhbmQgd2lsbCByZXN1bHQgaW4gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCB0 aGUgZ3Jvd3RoIG9mIHNuaWZmaW5nLiBTb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIGdpdmUgd2Vs bCBmb3JtZWRuZXNzIGVycm9yLCBvdGhlcnMgd2lsbCBub3QuIFRoaXMgaXMgdmVyeSBiYWQuIFRo ZSBncm93dGggb2Ygb3V0IG9mIGJhbmQgYWx0ZXJuYXRpdmVzIHRvIHRoZSB4bWwgZW5jb2Rpbmcg ZGVjbGFyYXRpb24gc2hvdWxkIGJlIHJlc2lzdGVkLiBXZSBoYXZlIG9uZSBhbHJlYWR5LCBkdWUg dG8gdGhlIGludGVyYWN0aW9uIHdpdGggdGhlIHRleHQvKiBtZWRpYSB0eXBlcywgYW5kIGl0IGlz IG9uZSB0b28gbWFueS4NCg0KNC4zIFdlbGwtRm9ybWVkbmVzcw0KIkFuIFhNTCBpbnN0YW5jZSB0 aGF0IGlzIG5vdCB3ZWxsLWZvcm1lZCBpcyBub3QgcmVhbGx5IFhNTDsgd2VsbC1mb3JtZWRuZXNz IGlzIHRoZSBiYXNpcyBmb3Igc3ludGFjdGljIGNvbXBhdGliaWxpdHkgd2l0aCBYTUwuIFdpdGhv dXQgd2VsbC1mb3JtZWRuZXNzLCBtb3N0IG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHVzaW5nIFhNTCBk aXNhcHBlYXIuIEZvciB0aGlzIHJlYXNvbiwgaXQgaXMgaW1wZXJhdGl2ZSB0aGF0IHByb3RvY29s IHNwZWNpZmljYXRpb25zIFJFUVVJUkUgdGhhdCBYTUwgaW5zdGFuY2VzIGJlIHdlbGwtZm9ybWVk LiINCg0KVGhpcyBpcyBnb29kIGJ1dCBzaG91bGQgYmUgc3RydGVuZ3RoZW5lZC4gcy9ub3QgcmVh bGx5L05PVC4gQWRkIHRoYXQgdGhlIHBhcnNlciBNVVNUIGhhbHQgb24gd2VsbCBmb3JtZWRuZXNz IGVycm9yLiBzL21vc3Qgb2YgdGhlIGFkdmFudGFnZXMvYWxsIG9mIHRoZSBhZHZhbnRhZ2VzLiBX aGF0IGFkdmFudGFnZXMgY291bGQgcmVtYWluIGlmIGEgcHJvdG9jb2wgc3BlY2lmaWVzIGEgbm9u LXdlbGwtZm9ybWVkIHVzZSBvZiBYTUw/IE5vbmUgdGhhdCBJIGNhbiBzZWUsIGFuZCBhIGh1Z2Ug ZG93bnNpZGUgdGhlIGZpcnN0IHRpbWUgdGhhdCBzdWNoIGEgcHJvdG9jb2wgZ2V0cyBkZWZpbmVk LiBOaXRwaWNraW5nLCAiUkVRVUlSRSIgbG9va3MgaW1wcmVzc2l2ZSBidXQgaXMgbm90IHBhcnQg b2YgdGhlIHZvY2FidWxhcnkgb2YgUkZDIDIxMTkuICJSRVFVSVJFRCIgaXMsIGFuZCBpcyBhIHN5 bm9ueW0gZm9yICJNVVNUIi4gUmV3b3JkaW5nIHRvICJGb3IgdGhpcyByZWFzb24sIHByb3RvY29s IHNwZWNpZmljYXRpb25zIE1VU1QgcmVxdWlyZSB0aGF0IFhNTCBpbnN0YW5jZXMgYmUgd2VsbC1m b3JtZWQgYW5kIHRoYXQgcHJvY2Vzc29ycyBNVVNUIGhhbHQgb24gd2VsbCBmb3JtZWRuZXNzIGVy cm9yLiIgd291bGQgYmUgY2xlYXJlci4NCg0KKEluY2lkZW50YWxseSB0aGUgbGluayBpbiB0aGUg ZG9jdW1lbnQgZm9yIFJGQyAyMTE5IHBvaW50cyB0byBhbiBmdHAgc2l0ZSBhbmQgd2FzIGJyb2tl biB3aGVuIEkgdHJpZWQgaXQsIGJ1dCBodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMyMTE5LnR4 dCB3b3JrZWQuLi4gYWxzbywgaXRzIG5vdCBjbGVhciB3aGV0aGVyIHRoZXkgdXNlICJtdXN0IiB0 byBtZWFuICJNVVNUIiBvciBub3Qgd2hpY2ggYWZmZWN0cyB0aGUgbWVhbmluZyBvZiBhIGxvdCBv ZiB0aGUgZG9jdW1lbnQpLg0KDQo0LjQgVmFsaWRpdHkgYW5kIEV4dGVuc2liaWxpdHkNCldhZGlu ZyBwYXN0IHRoZSB2ZXJ5IG5lY2Vzc2FyeSAnc2hvdWxkIHdlIG1hbmRhdGUgVzNDIFhNTCBTY2hl bWEgb3IgbGV0IGEgdGhvdXNhbmQgZmxvd2VycyBibG9vbScgcG9ydGlvbnMsIHRoZSBtb3N0IGlt cG9ydGFudCBwYXJ0IHRvIG15IG1pbmQgaXM6DQoiRm9yIHdoYXRldmVyIGZvcm1hbGlzbSBjaG9z ZW4sIHRoZXJlIGFyZSBvZnRlbiBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIHRoYXQgY2Fubm90IGJl IGV4cHJlc3NlZCBpbiB0aGF0IGZvcm1hbGlzbS4gVGhlc2UgYWRkaXRpb25hbCByZXF1aXJlbWVu dHMgc2hvdWxkIGJlIGNsZWFybHkgY2FsbGVkIG91dCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4gIg0K SSBhZ3JlZTsgdXNpbmcgYSBEVEQvU2NoZW1hL3doYXRldmVyIGFzIHRoZSBwcmltYXJ5IGZvcm1h bGlzbSBzaG91bGQgdHJpZ2dlciBhIHNlYXJjaCBmb3IgcmVtYWluaW5nIGNvbnN0cmFpbnRzIHRo YXQgY2Fubm90IGJlIGRlc2NyaWJlZCBpbiB0aGF0IGZvcm1hbGlzbSBhbmQgc3RyZW51b3VzIGVm Zm9ydCB0byBtYWtlIHN1Y2ggYWRkaXRpb25hbCBjb25zdHJhaW50cyBleGFjdGx5IGRlc2NyaWJl ZCwgY2xlYXJseSBmbGFnZ2VkIGFzIGFkZGl0aW9ucyBiZXlvbmQgdGhlIHByaW1hcnkgZm9ybWFs aXNtLCBhbmQgaWRlYWxseSBtYWNoaW5lIGNoZWNrYWJsZS4gDQoNClN1Z2dlc3QgYWRkaW5nIGEg c2VudGVuY2UgYWJvdXQgdGhlIGRlc2lyYWJpbGl0eSBvZiBhbiBvdmVyYWxsIHZhbGlkYXRvciBm b3IgYSBwYXJ0aWN1bGFyIHVzYWdlLCB0aGF0IGZpcnN0IGNoZWNrcyBmb3Igd2VsbCBmb3JtZWRu ZXNzOyBpZiBvaywgYXBwbGllcyB0aGUgcHJpbWFyeSBmb3JtYWxpc20gYW5kLCBpZiB0aGUgaW5z dGFuY2UgcGFzc2VzLCBhcHBsaWVzIHRoZSBvdGhlciBjb25zdHJhaW50cyBzbyB0aGF0IHRoZSBl bnRpcmUgc2V0LCBvciBhcyBtdWNoIGFzIGlzIG1hY2hpbmUgcHJvY2Vzc2FibGUsIGNhbiBiZSBj aGVja2VkIGF0IHRoZSBvbmUgdGltZS4NCg0KNC41IDQuNSBOYW1lc3BhY2VzDQpHb29kLCBidXQg aW1wbGllcyB0aGF0IHRoZSBvbmx5IGZ1bmN0aW9uIG9mIG5hbWVzcGFjZXMgaXMgYXZvaWRhbmNl IG9mIGVsZW1lbnQgYW5kIGF0dHJpYnV0ZSBuYW1lIGNvbmZsaWN0cy4gU2luY2UgdGhleSBkZWZp bmUgIlhNTCIgdG8gbWVhbiAidGhlIGFzc29jaWF0ZWQgYm9keSBvZiBYTUwtcmVsYXRlZCBzcGVj aWZpY2F0aW9ucyIgKG9yIEkgYXNzdW1lIHRoZXkgZG8sIG90aGVyd2lzZSB0aGUgY2xhaW0gaW4g Mi4gWE1MIFNlbGVjdGlvbiBDb25zaWRlcmF0aW9ucyB0aGF0ICJYTUwgaXMgc3RpbGwgZXZvbHZp bmcuIFRoZSBmb3JtYWwgc3BlY2lmaWNhdGlvbnMgYXJlIHN0aWxsIGJlaW5nIGluZmx1ZW5jZWQg YW5kIHVwZGF0ZWQgYXMgdXNlIGV4cGVyaWVuY2UgaXMgZ2FpbmVkIGFuZCBhcHBsaWVkLiIgaGFz IGxpdHRsZSBtZXJpdCkgdGhlbiBzaW1pbGFybHkgIm5hbWVzcGFjZXMiIHNob3VsZCBtZWFuICJ0 aGUgYXNzb2NpYXRlZCBib2R5IG9mIG5hbWVzcGFjZS1yZWxhdGVkLCBvciBuYW1lc3BhY2UtYXdh cmUsIHNwZWNpZmljYXRpb25zLiANCg0KVGhhdCBiZWluZyB0aGUgY2FzZTsgZmlyc3RseSwgdGhl aXIgd29yZGluZyBpbXBsaWVzIHRoYXQgYW55IHJhbmRvbSBuYW1lc3BhY2UgVVJJIGNhbiBiZSBj aG9zZW4gYXMgbG9uZyBhcyBpdCBhdm9pZHMgYSBuYW1lIGNsYXNoIGluIGEgZ2l2ZW4gaW5zdGFu Y2UgYW5kIHRoaXMgaXMgaW5jb3JyZWN0OyBzZWNvbmRseSwgdGhlIGltcGFjdCBvZiBuYW1lc3Bh Y2VzIG9ubiBvYmplY3QgbW9kZWxzIHNob3VsZCBiZSBtZW50aW9uZWQuIFRoZSBtZXRob2RzIGFu ZCBhdHRyaWJ1dGVzIG9uIGFuIG9iamVjdCB3aWxsIHZhcnkgZGVwZW5kaW5nIG9uIHdoZXRoZXIg dGhhdCBvYmplY3QgaXMgaW4gaXRzIG93biBuYW1lc3BhY2UsIG5vIG5hbWVzcGFjZSwgb3IgdGhl IHdlcm9uZyAocmFuZG9tbHkgY2hvc2VuKSBuYW1lc3BhY2UuIEVsZW1lbnRzIGFuZCBhdHRyaWJ1 dGVzIHNob3VsZCBiZSBpbiB0aGVpciBjb3JyZWN0IG5hbWVzcGFjZXMgYW5kIHRoZSBuYW1lc3Bh Y2VzIHNob3VsZCBiZSBkZWNsYXJlZCBldmVuIGlmIHRoZXJlIGlzIG5vIGNsYXNoLg0KDQpUaGUg cG9pbnRzIGFib3V0IGRlc2lyYWJpbGl0eSBvZiBuYW1lc3BhY2UgVVJJcyBwb2ludGluZyB0byAi c29tZXRoaW5nIiB1c2luZyBIVFRQIGlzIHdlbGwgbWFkZSBhbmQgYWJvdXQgYXMgc3Ryb25nIGFz IGN1cnJlbnQgcHJhY3RpY2UgYWxsb3dzLg0KDQoiSW4gdGhlIGNhc2Ugb2YgbmFtZXNwYWNlcyBp biBJRVRGIHN0YW5kYXJkcy10cmFjayBkb2N1bWVudHMsIGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB0 aGVyZSB3ZXJlIHNvbWUgcGVybWFuZW50IHBhcnQgb2YgdGhlIElFVEYncyBvd24gd2ViIHNwYWNl IHRoYXQgY291bGQgYmUgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLiAiDQpZZXMsIGdyZWF0LiBXaXNo IHdlIGNvdWxkIGFzc2lnbiB0aGVtIGFuIGFjdGlvbiB0byBnbyBkbyB0aGF0IGFuZCBzYXkgd2hh dCB0aGUgYmFzZSBVUkkgaXM/DQoNCiJJbiBsaWV1IG9mIHN1Y2gsIG90aGVyIHBlcm1hbmVudCBV UklzIGNhbiBiZSB1c2VkLCBlLmcuLCBVUk5zIGluIHRoZSBJRVRGIFVSTiBuYW1lc3BhY2UgKHNl ZSBbMTNdIGFuZCBbMTRdKS4iIFRoYXQgbWFrZXMgbWUgZmVlbCB1bmNvbWZvcnRhYmxlLCBidXQg aSBkb24nJ3QgaGF2ZSBhcnRpY3VsYXRlIGFyZ3VtZW50cyByaWdodCBub3cgdG8gY2xhcmlmeSB0 aGUgc291cmNlIG9mIGRpc2NvbWZvcnQgc28gaSBub3QgaXQgaGVyZSBhbmQgbWF5IGdldCBiYWNr IHRvIGl0IGxhdGVyLCBvciBvdGhlcnMgbWlnaHQuDQoNCjQuNS4xIE5hbWVzcGFjZXMgYW5kIEF0 dHJpYnV0ZXMNCiJUaGVyZSBpcyBhIGZyZXF1ZW50bHkgbWlzdW5kZXJzdG9vZCBhc3BlY3Qgb2Yg dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHVucHJlZml4ZWQgYXR0cmlidXRlcyBhbmQgdGhlIGRl ZmF1bHQgWE1MIG5hbWVzcGFjZSINCkdyZWF0IHN0dWZmLCB3ZWxsIGRvbmUgZm9yIHBvaW50aW5n IHRoaXMgb3V0Lg0KDQoiQXMgZGVzY3JpYmVkIGluIFhNTCBBbHRlcm5hdGl2ZXMgdGhlcmUgaXMg bm8gc3RhbmRhcmQgbWVjaGFuaXNtIGluIFhNTCBmb3IgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5v dCBuZXcgZXh0ZW5zaW9ucyBhcmUgbWFuZGF0b3J5IHRvIHJlY29nbml6ZS4gWE1MLWJhc2VkIHBy b3RvY29sIHNwZWNpZmljYXRpb25zIHNob3VsZCB0aHVzIGV4cGxpY2l0bHkgZGVzY3JpYmUgZXh0 ZW5zaW9uIG1lY2hhbmlzbXMgYW5kIHJlcXVpcmVtZW50cyB0byByZWNvZ25pemUgb3IgaWdub3Jl IGV4dGVuc2lvbnMuIg0KVHJ1ZSBpbiBnZW5lcmFsIGJ1dCB0aGVyZSBhcmUgc3BlY2lmaWMgZXhh bXBsZXMgb2Ygc3VjaCBtZWNoYW5pc21zIHNvIHRoZXkgc2hvdWxkIGJlIGxpc3RlZCBoZXJlIGFu ZCB0aGUgYWR2aWNlIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQgdG8gcmUtdXNlIGV4aXN0aW5n IG1lY2hhbmlzbXMgc2hvdWxkIGJlIGFwcGxpZWQgaGVyZSBhbHNvLiBJJ20gdGhpbmtpbmcgb2Yg dGhlIERPTSBmZWF0dXJlIHRlc3RzIGFuZCB0aGUgU01JTCBhbmQgU1ZHIHJlcXVpcmVkRmVhdHVy ZXMsIHJlcXVpcmVkRXh0ZW5zaW9ucyBhbmQgdGVzdCBhbmQgc3dpdGNoIGNhcGFiaWxpdGllcy4N Cg0KNC42IEVsZW1lbnQgYW5kIEF0dHJpYnV0ZSBEZXNpZ24gQ29uc2lkZXJhdGlvbnMNCkdvb2Qg bWF0ZXJpYWwgaW4gZ2VuZXJhbCwgaGVscGZ1bCB0byB0aGUgWE1MIHByb3RvY29sIGRlc2lnbmVy LiAiQXR0cmlidXRlIHZhbHVlcyBjYW4gY29udGFpbiBvbmx5IHNpbXBsZSBYTUwgZGF0YSB0eXBl cyIgaXMgdHJ1ZSB0byBhIGxpbWl0ZWQgZXh0ZW50IGRlcGVuZGluZyBvbiB0aGUgZm9ybWFsaXNt IHVzZWQgYW5kIGl0cyBleHByZXNzaXZlIHBvd2VyLiBBdHRyaWJ1dGUgZGF0YSBpcyBjbGVhcmx5 IHVzZWQgdG8gZGVzY3JpYmUgcmljaGVyIGNvbnRlbnQgdGhhbiBtYW55IHNjaGVtYSBsYW5ndWFn ZXMgY2FuIGV4cHJlc3MgKHN1Y2ggYXMgdGhlIHZlcnkgc2ltcGxlIHdpZHRoPSIzLjVtbSIpIGFu ZCB0aGUgaW50ZXJhY3Rpb24gd2l0aCBzZWN0aW9uIDQuNCBWYWxpZGl0eSBhbmQgRXh0ZW5zaWJp bGl0eSBpbiB0ZXJtcyBvZiAiYWRkaXRpb25hbCBjb25zdHJhaW50cyB0aGF0IGNhbm5vdCBiZSBl eHByZXNzZWQgaW4gdGhhdCBmb3JtYWxpc20iIHNob3VsZCBiZSBtYWRlIGV4cGxpY2l0IC0gaXRz IGEgdHJhZGUgb2ZmIHdpdGggYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyB0aGF0IHNob3Vs ZCBiZSBtYWRlIG9uIGEgY2FzZSBieSBjYXNlIGJhc2lzLCBub3QgYSAiY2FuIG9ubHkgY29udGFp biIuIFRoaXMgYXBwbGllcyB0byBlbGVtZW50IGNvbnRlbnQgdG9vLCBvZiBjb3Vyc2UuDQoNCiJB dHRyaWJ1dGVzIHVzZWQgaW4gcHJvdG9jb2wgZWxlbWVudHMgc2hvdWxkIGNvbnRhaW4gb25seSBt ZXRhLWRhdGEgdGhhdCBkZXNjcmliZXMgdGhlIHZhbHVlIG9mIHRoZSBlbmNsb3NpbmcgZWxlbWVu dC4gIiBZZXMsIGJ1dCB0aGF0IGRvZXMgbm90IHByZWNsdWRlIHJpY2hlciBhdHRyaWJ1dGUgZGF0 YSBvciBpbmRlZWQsIHNwYXJzZXIgdGhhbiBwb3NzaWJsZSBtYXJrdXAgYXMgdGhlaXIgb3duIGV4 YW1wbGUgaWxsdXN0cmF0ZXMuIEZ1bGx5IG1hcmtlZCB1cCBpdCBtaWdodCBiZQ0KDQo8YWRkcmVz cz4NCiAgICAgIDx0eXBlPg0KCQk8cHJvdG9jb2w+aXA8L3Byb3RvY29sPg0KCQk8dmVyc2lvbj40 PC92ZXJzaW9uPg0KCTwvdHlwZT4NCiAgICAgIDx2NHZhbHVlPg0KCQk8Zmlyc3Q+MTA8Zmlyc3Q+ DQoJCTxzZWNvbmQ+MTxzZWNvbmQ+DQoJCTx0aGlyZD4yPHRoaXJkPg0KCQk8Zm91cnRoPjM8Zm91 cnRoPg0KCTwvdjR2YWx1ZT4NCjwvYWRkcmVzcz4NCg0KMjYgRE9NIG5vZGVzIGluY2x1aWRpbmcg dGV4dCBub2RlcyBpbmNsdWRpbmcgb25lcyB0aGF0IGhhdmUganVzdCBzcGFjZXMuDQoNCkFuZCBl dmVuIHNvLCBzY2hlbWEgbGFuZ3VhZ2VzIG1pZ2h0IGhhdmUgZGlmZmljdWx0eSBleHByZXNzaW5n IHRoZSBjb25zdHJhaW50IHRoYXQgdGhlIHNlY29uZCBjaGlsZCBvZiBhZGRyZXNzIGlzIHY0dmFs dWUgaWYgdGhlIHZhbHVlIG9mIHRoZSBjb250ZW50IG9mIHRoZSB2ZXJzaW9uIGNoaWxkIG9mIHRo ZSBmaXJzdCBjaGlsZCB0eXBlIGVsZW1lbnQgaXMgIjQiLiBJdHMgY2xlYXIgdGhhdCAgY29tYmlu aW5nIHRoZSBpcCBhbmQgdGhlIDQgaW50byBhIGNvbW1vbmx5IHVzZWQgY29tcG91bmQgaXB2NCBh bmQgYXBwbHlpbmcgaXQgYXMgYW4gYXR0cmlidXRlIG9uIGFkZHJlc3MgaXMgYSBiZXR0ZXIgbWV0 aG9kLg0KDQo8YWRkcmVzcyB0eXBlPSJpcHY0Ij4NCiAgICAgIDx2NHZhbHVlPg0KCQk8Zmlyc3Q+ MTA8Zmlyc3Q+DQoJCTxzZWNvbmQ+MTxzZWNvbmQ+DQoJCTx0aGlyZD4yPHRoaXJkPg0KCQk8Zm91 cnRoPjM8Zm91cnRoPg0KCTwvdjR2YWx1ZT4NCjwvYWRkcmVzcz4NCg0KMTcgRE9NIG5vZGVzDQoN Ckl0cyBhbHNvIGF0IGxlYXN0IGEgZGVmZW5zaWJsZSBkZXNpZ24gY2hvaWNlIHRvIGNvbWJpbmUg dGhlIGZvdXIgY2hpbGRyZW4gb2YgdjR2YWx1ZSBpbnRvIGEgY29tbW9ubHkgdXNlZCBkb3R0ZWQg cXVhZCBldmVuIHRob3VnaCB0aGlzIGZvcmdvZXMgdmFsaWRhdGlvbiB1c2luZyBzY2hlbWFzIHRo YXQgdGhlcmUgYXJlIGZvdXIgY2hpbGRyZW4sIGluIHRoZSBjb3JyZWN0IG9yZGVyIGFuZCB3aXRo IGNvbnRlbnQgaW4gdGhlIGFsbG93ZWQgcmFuZ2UuDQoNCjxhZGRyZXNzIHR5cGU9ImlwdjQiPjEw LjEuMi4zPC9hZGRyZXNzPg0KDQo8YXNiZXN0b3M+DQpUaHJlZSBET00gbm9kZXMsIGVhc3kgcmVh ZGFiaWxpdHksIGltbWVkaWF0ZWx5IHVuZGVyc3Rvb2QgYnkgdGFyZ2V0IGF1ZGllbmNlLCB2YWxp ZGF0aW9uIHJlcXVpcmVzIGEgbWljcm9wYXJzZXIsIHNvIHdoYXQuDQo8L2FzYmVzdG9zPg0KDQo1 LiBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb25zaWRlcmF0aW9ucw0KR29vZCB0byBzZWUgdGhpcyBj b25zaWRlcmVkLiBHb29kIHRvIHNlZSBhIHNpbWlsYXIgZm9ybSBvZiB0aXRsZSB0byAiU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMiIHNpbmNlIEludGVybmF0aW9uYWxpc2F0aW9uLCBsaWtlIFNlY3Vy aXR5LCBpcyBhIGRlc2lnbiBub3QgYSBmZWF0dXJlLg0KDQo1LjEgQ2hhcmFjdGVyIFNldHMNCiJY TUwgcHJvdmlkZXMgbmF0aXZlIHN1cHBvcnQgZm9yIGVuY29kaW5nIGluZm9ybWF0aW9uIHVzaW5n IHRoZSBVbmljb2RlIGNoYXJhY3RlciBzZXQgYW5kIGl0cyBtb3JlIGNvbXBhY3QgcmVwcmVzZW50 YXRpb25zIGluY2x1ZGluZyBVVEYtOCBbNF0gYW5kIFVURi0xNiBbMjFdLiINCg0KVWdoLiBNaXhl cyB1cCB0aGUgdW5pdmVyc2FsIGNoYXJhY3RlciBzZXQsIGNoYXJhY3RlciByZXBlcnRvaXJlcyBh bmQgY2hhcmFjdGVyIGVuY29kaW5ncyBzdHJhaWdodCBvZmYgdGhlIGJhdC4gU2VlDQpDaGFyYWN0 ZXIgU2V0IENvbnNpZGVyZWQgSGFybWZ1bA0KTWF5IDIsIDE5OTUNCmh0dHA6Ly93d3cudzMub3Jn L01hcmtVcC9odG1sLXNwZWMvY2hhcnNldC1oYXJtZnVsDQpsaW5rZWQgZnJvbSBodHRwOi8vd3d3 LnczLm9yZy9UUg0KU2lkZSBub3RlIHRvIERhbiBDb25ub2x5IC0gdGVjaG5pY2FsbHkgdGhhdCBl eHBpcmVkIGluIE5vdmVtYmVyLCAxOTk1IGJ1dCBpcyBzdGlsbCBhcHBsaWNhYmxlLiBTdWdnZXN0 IGVuc3VyaW5nIGl0IGlzIGZ1bGx5IHJlZmxlY3RlZCBpbiB0aGUgY2hhcmFjdGVyIG1vZGVsIHdv cmsgZnJvbSBJMThOIFdHLg0KDQoNClN1Z2dlc3RlZCByZXdvcmRpbmcgKHJlcXVpcmVzIHJlbnVt YmVyaW5nIG9mIHN1YnNlcXVlbnQgc2VjdGlvbnMpDQoNCjUuMSBDaGFyYWN0ZXIgUmVwZXJ0b2ly ZQ0KWE1MIHBlcmZvcm1zIGFsbCBjaGFyYWN0ZXIgcHJvY2Vzc2luZyBpbiB0ZXJtcyBvZiB0aGUg VW5pdmVyc2FsIENoYXJhY3RlciBTZXQgKFVDUywgbGluayB0byBVbmljb2RlIDMuMiBhbmQgSVNP IDEwNjQ2KS4gVGhpcyBwcm92aWRlcyBhIGJhc2UgZm9yLCBidXQgZG9lcyBub3QgaXRzZWxmIGd1 YXJhbnRlZSwgYW4gaW50ZXJuYXRpb25hbGl6ZWQgdXNlIG9mIFhNTCBmb3IgcHJvdG9jb2xzLiBU aGVyZSBpcyBhIGZyZXF1ZW50bHkgbWlzdW5kZXJzdG9vZCBhc3BlY3Qgb2YgdGhlIHJlbGF0aW9u c2hpcCBiZXR3ZWVuIG51bWVyaWNhbCBjaGFyYWN0ZXIgcmVmZXJlbmNlcyAoTkNScykgYW5kIGVu Y29kaW5nLiBOQ1JzIGFsd2F5cyByZWZlciB0byB0aGUgVUNTLCBuZXZlciB0byB0aGUgZW5jb2Rp bmcgaW4gdXNlLiBUaHVzLCBhbnkgZW5jb2RpbmcgY2FuIHJlcHJlc2VudCB0aGUgZW50aXJlIGNo YXJhY3RlciByZXBlcnRvaXJlIG9mIHRoZSBVQ1MgYnkgdXNpbmcgTkNScy4NCg0KNS4yIEVuY29k aW5nDQpYTUwgbWFuZGF0ZXMgc3VwcG9ydCBvZiB0aGUgVVRGLTggWzRdIGFuZCBVVEYtMTYgWzIx XSBlbmNvZGluZ3MgKGluIG9sZGVyIElFVEYgcGFybGFuY2UsICJjaGFyYWN0ZXIgc2V0cyIpIGFu ZCBzdWNoIHVzYWdlIG1heSBoYXZlIGJ1dCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuY29kaW5nIGRl Y2xhcmF0aW9uLiBPdGhlciBlbmNvZGluZ3MgYXJlIGFsc28gcGVybWl0dGVkLCB3aXRoIG5vIGd1 YXJhbnRlZSBvZiBzdXBwb3J0IGluIGEgZ2l2ZW4gWE1MIHBhcnNlciwgYW5kIGlmIHVzZWQgTVVT VCBiZSBzcGVjaWZpZWQgdXNpbmcgYW4gImVuY29kaW5nIiBhdHRyaWJ1dGUgaW4gYSBkb2N1bWVu dCdzIFhNTCBkZWNsYXJhdGlvbi4gWE1MIHBhcnNlcnMgb2Z0ZW4gc3VwcG9ydCBhZGRpdGlvbmFs IGVuY29kaW5ncyBidXQgdGhlIHNlbGVjdGlvbiBvZiB0aGVzZSBpcyByZWdpb25hbGx5IGRlcGVu ZGVudCBhbmQgc2hvdWxkIG5vdCBiZSByZWxpZWQgdXBvbiBldmVuIGZvciBkYXRhIGV4Y2hhbmdl IHdpdGhpbmcgYSBnZW9ncmFwaGljYWxseSBsaW1pdGVkIHJlZ2lvbi4gQmVjYXVzZSBvZiB0aGlz LCB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSwgaXQgaXMgc3Ryb25nbHkgcmVjb21tZW5kZWQg dGhhdCBVVEYtOCBvciBVVEYtMTYgU0hPVUxEIGJlIG1hbmRhdGVkIGZvciBwcm90b2NvbHMgdGhh dCByZXByZXNlbnQgZGF0YSB1c2luZyBYTUwuIA0KDQo1LjMgT3RoZXIgQ29uc2lkZXJhdGlvbnMN Ckdvb2QgcG9pbnRzIGFib3V0IG5lZWRpbmcgbWFya3VwIHRvIGNvbnZleSBjZXJ0YWluIGluZm9y bWF0aW9uIHN1Y2ggYXMgcnVieSBhbmQgZW1iZWRkaW5nIGNvbnRyb2xzLiBUaGUgdXNlIG9mIG1h cmt1cCB0byBzcGVjaWZ5IGxhbmd1YWdlIGNoYW5nZXMgYW5kIHRvIGFsbG93IGJpZGkgZW1iZWRk aW5nIG1vcmUgdGhhbiBvbmUgbGV2ZWwgZGVlcCBjb3VsZCBhbHNvIHVzZWZ1bGx5IGJlIG5vdGVk IGhlcmUuDQoNCnMvZXh0ZW5kZWQgY2hhcmFjdGVyIHNldHMvY2hhcmFjdGVyIHJlcGVydG9pcmVz IGdyZWF0ZXIgdGhhbiBVUy1BU0NJSQ0KYmVjYXVzZSAiY2hhcmFjdGVyIHNldCcgaXMgb2Z0ZW4g c2VlbiBhcyBzeW5vbnltb3VzIHdpdGggImNoYXJzZXQiIGFuZCB0aHVzIHdpdGggImVuY29kaW5n IiBhbmQgdGhhdCBpcyBub3QgdGhlIGlzc3VlIGhlcmUuDQoNCg== ------------7312E173E2221AB-- From owner-ietf-xml-use Mon Apr 22 09:13:10 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MGDAu20634 for ietf-xml-use-bks; Mon, 22 Apr 2002 09:13:10 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MGD8a20630 for ; Mon, 22 Apr 2002 09:13:08 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3MGBs9X011468; Mon, 22 Apr 2002 12:11:54 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3MGBLRY011463; Mon, 22 Apr 2002 12:11:21 -0400 (EDT) Date: Mon, 22 Apr 2002 09:49:24 -0400 From: Michael Mealling To: MURATA Makoto Cc: "Hollenbeck, Scott" , ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines Message-ID: <20020422094924.A9971@bailey.dscga.com> Reply-To: Michael Mealling References: <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > On Mon, 22 Apr 2002 08:32:49 -0400 > "Hollenbeck, Scott" wrote: > > > In the XML developer mailing list, it has been repeatedly > > > reported that > > > XML Schema implementations fail to interwork. If IETF still cares > > > "rough consensus and running code", I think that the > > > guideline document > > > MUST NOT recommend XML Schema. Rather, implementors should > > > be encouraged > > > to peruse their favorite languages. > > > > I can't agree with this suggestion - a recommendation of "use your favorite > > language" is no recommendation at all for someone who doesn't have a > > favorite language. I don't have a problem, though, with noting that there > > are alternatives to XML Schema (done in -01) and that the issue is still > > somewhat controversial (can be emphasized in -02). > > I claim that I am an expert of XML in general and schema languages in > particular. If I am asked by users, I cannot recommend any of the > schema languages at hand. Although I certainly think RELAX NG is > technically the best, I cannot guarantee it will make it in the market. > XML Schema just sucks. > > If no schema languages can be recommended, it is a good idea not to recommend > any of them. If we recommend one of them, we run the risk of deceiving > readers. I thus continue to oppose to the two sentences below: But how badly does it suck? Its much more productive to apply this discussion to current examples of XML protocols than simply make unmeasurable statements of general suckiness. The one I'm familiar with is CNRP which is fairly simple. PROVREG is fairly complex. Are there features of either one that XML Schema simply can't handle? If so then, IMHO that's a reason not to recommend it. But if XML Schema can handle the currently proposed XML parts of IETF protocols then, IMHO, it makes a perfectly reasonable default. > > However, the features in XML Schema for data typing and > > constraining values seem very appropriate for many of the uses of > > XML. For this reason, this document recommends that, in lieu of > > reasons to choose some other mechanism, protocol designs use W3C XML > > Schema as the language for describing validity. > > > Again, I can't agree to this specific change. The whole idea of the > > document is to give people who have decided to use XML as part of a protocol > > specification some specific guidelines to help them accomplish their task. > > I don't stick to my specific wording. But I strongly oppose to recommend > a single specific schema language, when the situation is so debatable and > controversial. I think that the current I-D misleads readers and makes > them waste their time and money. Then list the others. But as a document author I would like some guidance as to which one I should start with and which one has a higher degree of success given the particular complexity of what I'm doing. I.e. don't just list them. Say what's wrong with each one so that the reader has more to go on that "Murato thinks it sucks" ;-). If I know that XML Schema can't handle statements about character encodings then I'd know that it probably wouldn't be good for CNRP Version 2.0.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | mailto:michael@research.netsol.com Advanced Naming Research Manager | go:Michael Mealling Verisign Applied Research | urn:pin:1 From owner-ietf-xml-use Mon Apr 22 09:27:40 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MGRee21023 for ietf-xml-use-bks; Mon, 22 Apr 2002 09:27:40 -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 g3MGRda21019 for ; Mon, 22 Apr 2002 09:27:39 -0700 (PDT) Received: (qmail 26371 invoked by uid 0); 22 Apr 2002 16:27:34 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 22 Apr 2002 16:27:34 -0000 From: "Julian Reschke" To: "Michael Mealling" , "MURATA Makoto" Cc: "Hollenbeck, Scott" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Mon, 22 Apr 2002 18:27:30 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020422094924.A9971@bailey.dscga.com> 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 Michael Mealling > Sent: Monday, April 22, 2002 3:49 PM > To: MURATA Makoto > Cc: Hollenbeck, Scott; ietf-xml-use@imc.org > Subject: Re: Validation and IETF XML Usage Guidelines > > > > On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > > On Mon, 22 Apr 2002 08:32:49 -0400 > > "Hollenbeck, Scott" wrote: > > > > In the XML developer mailing list, it has been repeatedly > > > > reported that > > > > XML Schema implementations fail to interwork. If IETF still cares > > > > "rough consensus and running code", I think that the > > > > guideline document > > > > MUST NOT recommend XML Schema. Rather, implementors should > > > > be encouraged > > > > to peruse their favorite languages. > > > > > > I can't agree with this suggestion - a recommendation of "use > your favorite > > > language" is no recommendation at all for someone who doesn't have a > > > favorite language. I don't have a problem, though, with > noting that there > > > are alternatives to XML Schema (done in -01) and that the > issue is still > > > somewhat controversial (can be emphasized in -02). > > > > I claim that I am an expert of XML in general and schema languages in > > particular. If I am asked by users, I cannot recommend any of the > > schema languages at hand. Although I certainly think RELAX NG is > > technically the best, I cannot guarantee it will make it in the > market. > > XML Schema just sucks. > > > > If no schema languages can be recommended, it is a good idea > not to recommend > > any of them. If we recommend one of them, we run the risk of deceiving > > readers. I thus continue to oppose to the two sentences below: > > But how badly does it suck? Its much more productive to apply > this discussion > to current examples of XML protocols than simply make > unmeasurable statements > of general suckiness. The one I'm familiar with is CNRP which is fairly > simple. PROVREG is fairly complex. Are there features of either one that > XML Schema simply can't handle? If so then, IMHO that's a reason not to > recommend it. But if XML Schema can handle the currently proposed > XML parts > of IETF protocols then, IMHO, it makes a perfectly reasonable default. We had this already. WebDAV has a completely sane extensibility model, yet it can't be modeled using XML Schema. From owner-ietf-xml-use Mon Apr 22 11:26:00 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MIQ0w28134 for ietf-xml-use-bks; Mon, 22 Apr 2002 11:26:00 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MIPva28130 for ; Mon, 22 Apr 2002 11:25:57 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3MIPqpP019621; Mon, 22 Apr 2002 11:25:52 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id LAA23357; Mon, 22 Apr 2002 11:25:51 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Mon, 22 Apr 2002 11:25:51 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: Julian Reschke cc: Michael Mealling , MURATA Makoto , "Hollenbeck, Scott" , Subject: RE: Validation and IETF XML Usage Guidelines In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Really? I thought you could model WebDAV's extensability using an infinite number of elements with the 'don't parse' attribute set. BTW, as reported in the press, WS-I (which I was at last week) will adopt XML Schema, for whatever that's worth. I happen to like Relax NG more then W3C Schema although I never figured out how to do the equivalent of 'any' in Relax NG. On Mon, 22 Apr 2002, Julian Reschke wrote: > > > From: owner-ietf-xml-use@mail.imc.org > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Michael Mealling > > Sent: Monday, April 22, 2002 3:49 PM > > To: MURATA Makoto > > Cc: Hollenbeck, Scott; ietf-xml-use@imc.org > > Subject: Re: Validation and IETF XML Usage Guidelines > > > > > > > > On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > > > On Mon, 22 Apr 2002 08:32:49 -0400 > > > "Hollenbeck, Scott" wrote: > > > > > In the XML developer mailing list, it has been repeatedly > > > > > reported that > > > > > XML Schema implementations fail to interwork. If IETF still cares > > > > > "rough consensus and running code", I think that the > > > > > guideline document > > > > > MUST NOT recommend XML Schema. Rather, implementors should > > > > > be encouraged > > > > > to peruse their favorite languages. > > > > > > > > I can't agree with this suggestion - a recommendation of "use > > your favorite > > > > language" is no recommendation at all for someone who doesn't have a > > > > favorite language. I don't have a problem, though, with > > noting that there > > > > are alternatives to XML Schema (done in -01) and that the > > issue is still > > > > somewhat controversial (can be emphasized in -02). > > > > > > I claim that I am an expert of XML in general and schema languages in > > > particular. If I am asked by users, I cannot recommend any of the > > > schema languages at hand. Although I certainly think RELAX NG is > > > technically the best, I cannot guarantee it will make it in the > > market. > > > XML Schema just sucks. > > > > > > If no schema languages can be recommended, it is a good idea > > not to recommend > > > any of them. If we recommend one of them, we run the risk of deceiving > > > readers. I thus continue to oppose to the two sentences below: > > > > But how badly does it suck? Its much more productive to apply > > this discussion > > to current examples of XML protocols than simply make > > unmeasurable statements > > of general suckiness. The one I'm familiar with is CNRP which is fairly > > simple. PROVREG is fairly complex. Are there features of either one that > > XML Schema simply can't handle? If so then, IMHO that's a reason not to > > recommend it. But if XML Schema can handle the currently proposed > > XML parts > > of IETF protocols then, IMHO, it makes a perfectly reasonable default. > > We had this already. > > WebDAV has a completely sane extensibility model, yet it can't be modeled > using XML Schema. > From owner-ietf-xml-use Mon Apr 22 11:35:07 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MIZ7Y28378 for ietf-xml-use-bks; Mon, 22 Apr 2002 11:35:07 -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 g3MIZ5a28373 for ; Mon, 22 Apr 2002 11:35:05 -0700 (PDT) Received: (qmail 8788 invoked by uid 0); 22 Apr 2002 18:35:00 -0000 Received: from pd950c394.dip.t-dialin.net (HELO lisa) (217.80.195.148) by mail.gmx.net (mp011-rz3) with SMTP; 22 Apr 2002 18:35:00 -0000 From: "Julian Reschke" To: "Yaron Y. Goland" , "Julian Reschke" Cc: "Michael Mealling" , "MURATA Makoto" , "Hollenbeck, Scott" , Subject: RE: Validation and IETF XML Usage Guidelines Date: Mon, 22 Apr 2002 20:34:54 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Yaron Y. Goland [mailto:modulus@cinenet.net] > Sent: Monday, April 22, 2002 8:26 PM > To: Julian Reschke > Cc: Michael Mealling; MURATA Makoto; Hollenbeck, Scott; > ietf-xml-use@imc.org > Subject: RE: Validation and IETF XML Usage Guidelines > > > Really? I thought you could model WebDAV's extensability using an infinite > number of elements with the 'don't parse' attribute set. No, that would allow things like right? > BTW, as reported in the press, WS-I (which I was at last week) will adopt > XML Schema, for whatever that's worth. I happen to like Relax NG more then > W3C Schema although I never figured out how to do the equivalent of 'any' > in Relax NG. > > On Mon, 22 Apr 2002, Julian Reschke wrote: > > > > > > From: owner-ietf-xml-use@mail.imc.org > > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Michael Mealling > > > Sent: Monday, April 22, 2002 3:49 PM > > > To: MURATA Makoto > > > Cc: Hollenbeck, Scott; ietf-xml-use@imc.org > > > Subject: Re: Validation and IETF XML Usage Guidelines > > > > > > > > > > > > On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > > > > On Mon, 22 Apr 2002 08:32:49 -0400 > > > > "Hollenbeck, Scott" wrote: > > > > > > In the XML developer mailing list, it has been repeatedly > > > > > > reported that > > > > > > XML Schema implementations fail to interwork. If IETF > still cares > > > > > > "rough consensus and running code", I think that the > > > > > > guideline document > > > > > > MUST NOT recommend XML Schema. Rather, implementors should > > > > > > be encouraged > > > > > > to peruse their favorite languages. > > > > > > > > > > I can't agree with this suggestion - a recommendation of "use > > > your favorite > > > > > language" is no recommendation at all for someone who > doesn't have a > > > > > favorite language. I don't have a problem, though, with > > > noting that there > > > > > are alternatives to XML Schema (done in -01) and that the > > > issue is still > > > > > somewhat controversial (can be emphasized in -02). > > > > > > > > I claim that I am an expert of XML in general and schema > languages in > > > > particular. If I am asked by users, I cannot recommend any of the > > > > schema languages at hand. Although I certainly think RELAX NG is > > > > technically the best, I cannot guarantee it will make it in the > > > market. > > > > XML Schema just sucks. > > > > > > > > If no schema languages can be recommended, it is a good idea > > > not to recommend > > > > any of them. If we recommend one of them, we run the risk > of deceiving > > > > readers. I thus continue to oppose to the two sentences below: > > > > > > But how badly does it suck? Its much more productive to apply > > > this discussion > > > to current examples of XML protocols than simply make > > > unmeasurable statements > > > of general suckiness. The one I'm familiar with is CNRP > which is fairly > > > simple. PROVREG is fairly complex. Are there features of > either one that > > > XML Schema simply can't handle? If so then, IMHO that's a > reason not to > > > recommend it. But if XML Schema can handle the currently proposed > > > XML parts > > > of IETF protocols then, IMHO, it makes a perfectly reasonable default. > > > > We had this already. > > > > WebDAV has a completely sane extensibility model, yet it can't > be modeled > > using XML Schema. > > > From owner-ietf-xml-use Mon Apr 22 15:02:40 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MM2eG11171 for ietf-xml-use-bks; Mon, 22 Apr 2002 15:02:40 -0700 (PDT) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MM2ca11167 for ; Mon, 22 Apr 2002 15:02:38 -0700 (PDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.34 2002/04/15 17:47:41 root Exp $) with SMTP id g3MM2aT09004 for ; Mon, 22 Apr 2002 22:02:36 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002042215094603757 for ; Mon, 22 Apr 2002 15:09:47 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 15:02:36 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C219@orsmsx120.jf.intel.com> From: "Carr, Wayne" To: "'ietf-xml-use@imc.org'" Subject: FW: PIDF - using xml schema Date: Mon, 22 Apr 2002 15:02:35 -0700 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: This didn't get sent to the list because of anti-spam - so here it is again. -----Original Message----- From: Carr, Wayne Sent: Monday, April 22, 2002 12:33 PM To: 'bateman@acm.org'; LMM@acm.org Cc: Carr, Wayne; ietf-xml-use@imc.org Subject: RE: PIDF - using xml schema > In terms of difficulty, Wayne might be better placed to give > an opinion. From my standpoint it is both useful and relatively straightforward. Hi Larry, Writing the xml schema for pidf was trivial. I wrote it as I read the pidf draft for the first time to understand the format. I think it is also much easier for someone not familiar with either dtd's or xml schema to read a simple schema than a dtd. It's a good way to understand precisely what's permitted in the format. As Adrian pointed out, pidf is using an extensibility mechanism like SOAP uses - extensibility is a key part of the design - and XML Schema lets you specify that precisely. DTD's don't. DTD's are also a real pain to be able to use properly with namespaces, wheras XML Schema takes namespaces into account. So all around XML Schema is a better way to define something like this. Wayne > -----Original Message----- > From: Adrian Bateman [mailto:bateman@acm.org] > Sent: Sunday, April 21, 2002 2:40 PM > To: LMM@acm.org > Cc: 'Carr, Wayne'; ietf-xml-use@imc.org > Subject: RE: PIDF - using xml schema > > > On 21 April 2002 17:14, Larry Masinter wrote: > > > > > I've just finished reading > > > draft-hollenbeck-ietf-xml-guidelines-00.txt > > > and have the following observations for consideration: > > > > Version -00 was our first shot, there's now an -01, > > and there's significant discussion over the applicability > > of XML schema. It would be very helpful to get your review > > on the guidelines: > > Hi Larry, > > I've scanned through the -01 document now. As far as the discussion of > XML Schema goes, I think it all makes sense thus far. My preference is > for XML Schema for two reasons, the first a personal > deficiency: I don't > really understand all the DTD syntax, just about enough to > read one, but > certainly not to write one. The second is more practical: for PIDF in > the IMPP group we have described our extensibility mechanism using > namespaces. Clearly DTD's don't handle this and XML Schema seems an > ideal tool to address this. > > > > Which guidelines are helpful? Which don't make sense or > > have confusing applicability? > > I pretty much skipped the sections on XML Selection Considerations and > XML Alternatives. I guess they do have a place in this document, but > weren't really relevant for the point we've reached in IMPP (and I > suppose I already have some of my own views about XML applicability > ;^>). > > Aside from that, I think everything in section 4 is useful > and thinking > back a couple of years, I think if we'd had this document > then, a lot of > pointless argument might have been avoided in IMPP (perhaps > not though, > but at least we'd have had some ground rules, and in this context the > sections on XML Selection, etc. would have been useful). > > > Are there other topics that you wish were covered? > > One thing that affects us that is mentioned in the text is how to > determine extensions that are mandatory to recognise. As you > say, there > is no standard mechanism in XML, but perhaps an example might be given > which would tend to help protocol authors end up with the same or > similar solutions which can't be a bad thing? > > > There's been significant pushback on the recommendation to use XML > > Schema (from Relax NG proponents). How useful/difficult was it to > > define an XML Schema? > > I imagine different groups might wish to present different > recommendations. The suggestion to treat XML Schema as first > preference > seems sensible to me, but I haven't really encountered many > of the other > mechanisms (which can be interpreted in different ways and others can > draw their conclusions from that). > > In terms of difficulty, Wayne might be better placed to give > an opinion. > From my standpoint it is both useful and relatively straightforward. > > Best regards, > > Adrian. > > From owner-ietf-xml-use Mon Apr 22 16:04:44 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MN4i912393 for ietf-xml-use-bks; Mon, 22 Apr 2002 16:04:44 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MN4fa12384 for ; Mon, 22 Apr 2002 16:04:41 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3MN4ipP007671; Mon, 22 Apr 2002 16:04:44 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id QAA26204; Mon, 22 Apr 2002 16:04:43 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Mon, 22 Apr 2002 16:04:43 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: "Carr, Wayne" cc: "'ietf-xml-use@imc.org'" Subject: Re: FW: PIDF - using xml schema In-Reply-To: <86DB568235A8D511ABAC0002A5072CA50316C219@orsmsx120.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Unfortunately I lack sufficient intelligence to write XML schemas unaided. I am forced to use a tool like XML spy. On the other hand, I was able to write a correct Relax NG schema after just quickly skiming the draft using windows Notepad. Personally I doubt that there exist any two truly interoperable implementations of XML schema, at least if you try to use features beyond the very core set. I strongly dislike XML schema, I think it is a hinderance to protocol development, to interoperability and to good design. But unfortunately it may be "good enough". That having been said a few facts are quite clear. 1. The only widely accepted XML type system is the one provided by XML schema. If memory serves (and it probably doesn't) even Relax NG points readers there. 2. XML Schema has enormous support, mostly because the alternatives are not seen as being credible. Most folks see the W3C as the gospel of XML standards and are unwilling to adopt anything XML that hasn't been blessed by it. The end result is that all the major commercial XML houses (Microsoft, IBM, Sun, etc.) support XML schema as their primary schema mechanism. Furthermore WS-I, which much to my surprise is not just an IBM/Microsoft pet forum, will (I predict) adopt XML schema as part of its basic profile. Near as I can tell (and much to my disapointment) XML schema seems a done deal. I would love to be convinced otherwise. However, if indeed XML schema (as deeply flawed as it is) has won then perhaps the most value we can add is to provide a guide to which features in it should be used based on: A) How well they are supported across various systems B) How likely they are to produce useful schemas. I have already made a stab at this in my own comments - http://www.goland.geek/#04032002 or http://www.goland.org/#04032002. BTW, I fully expect that WS-I will perform this same exercise. I wish there was another way, any ideas? Yaron On Mon, 22 Apr 2002, Carr, Wayne wrote: > > This didn't get sent to the list because of anti-spam - so here it is again. > > -----Original Message----- > From: Carr, Wayne > Sent: Monday, April 22, 2002 12:33 PM > To: 'bateman@acm.org'; LMM@acm.org > Cc: Carr, Wayne; ietf-xml-use@imc.org > Subject: RE: PIDF - using xml schema > > > > In terms of difficulty, Wayne might be better placed to give > > an opinion. From my standpoint it is both useful and relatively > straightforward. > > Hi Larry, > > Writing the xml schema for pidf was trivial. I wrote it as I read the pidf > draft for the first time to understand the format. I think it is also much > easier for someone not familiar with either dtd's or xml schema to read a > simple schema than a dtd. It's a good way to understand precisely what's > permitted in the format. > > As Adrian pointed out, pidf is using an extensibility mechanism like SOAP > uses - extensibility is a key part of the design - and XML Schema lets you > specify that precisely. DTD's don't. DTD's are also a real pain to be able > to use properly with namespaces, wheras XML Schema takes namespaces into > account. So all around XML Schema is a better way to define something like > this. > > Wayne > > > -----Original Message----- > > From: Adrian Bateman [mailto:bateman@acm.org] > > Sent: Sunday, April 21, 2002 2:40 PM > > To: LMM@acm.org > > Cc: 'Carr, Wayne'; ietf-xml-use@imc.org > > Subject: RE: PIDF - using xml schema > > > > > > On 21 April 2002 17:14, Larry Masinter wrote: > > > > > > > I've just finished reading > > > > draft-hollenbeck-ietf-xml-guidelines-00.txt > > > > and have the following observations for consideration: > > > > > > Version -00 was our first shot, there's now an -01, > > > and there's significant discussion over the applicability > > > of XML schema. It would be very helpful to get your review > > > on the guidelines: > > > > Hi Larry, > > > > I've scanned through the -01 document now. As far as the discussion of > > XML Schema goes, I think it all makes sense thus far. My preference is > > for XML Schema for two reasons, the first a personal > > deficiency: I don't > > really understand all the DTD syntax, just about enough to > > read one, but > > certainly not to write one. The second is more practical: for PIDF in > > the IMPP group we have described our extensibility mechanism using > > namespaces. Clearly DTD's don't handle this and XML Schema seems an > > ideal tool to address this. > > > > > > > Which guidelines are helpful? Which don't make sense or > > > have confusing applicability? > > > > I pretty much skipped the sections on XML Selection Considerations and > > XML Alternatives. I guess they do have a place in this document, but > > weren't really relevant for the point we've reached in IMPP (and I > > suppose I already have some of my own views about XML applicability > > ;^>). > > > > Aside from that, I think everything in section 4 is useful > > and thinking > > back a couple of years, I think if we'd had this document > > then, a lot of > > pointless argument might have been avoided in IMPP (perhaps > > not though, > > but at least we'd have had some ground rules, and in this context the > > sections on XML Selection, etc. would have been useful). > > > > > Are there other topics that you wish were covered? > > > > One thing that affects us that is mentioned in the text is how to > > determine extensions that are mandatory to recognise. As you > > say, there > > is no standard mechanism in XML, but perhaps an example might be given > > which would tend to help protocol authors end up with the same or > > similar solutions which can't be a bad thing? > > > > > There's been significant pushback on the recommendation to use XML > > > Schema (from Relax NG proponents). How useful/difficult was it to > > > define an XML Schema? > > > > I imagine different groups might wish to present different > > recommendations. The suggestion to treat XML Schema as first > > preference > > seems sensible to me, but I haven't really encountered many > > of the other > > mechanisms (which can be interpreted in different ways and others can > > draw their conclusions from that). > > > > In terms of difficulty, Wayne might be better placed to give > > an opinion. > > From my standpoint it is both useful and relatively straightforward. > > > > Best regards, > > > > Adrian. > > > > > From owner-ietf-xml-use Mon Apr 22 17:31:12 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3N0VCD16254 for ietf-xml-use-bks; Mon, 22 Apr 2002 17:31:12 -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 g3N0VAa16250 for ; Mon, 22 Apr 2002 17:31:10 -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 UAA15689; Mon, 22 Apr 2002 20:10:50 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5W1B1>; Mon, 22 Apr 2002 20:31:02 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B989@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Carr, Wayne'" , "'ietf-xml-use@imc.org'" Subject: RE: PIDF - using xml schema Date: Mon, 22 Apr 2002 20:30:55 -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: > Writing the xml schema for pidf was trivial. I wrote it as I > read the pidf > draft for the first time to understand the format. I think > it is also much > easier for someone not familiar with either dtd's or xml > schema to read a > simple schema than a dtd. It's a good way to understand > precisely what's > permitted in the format. I can confirm Wayne's assessment. Last December I suggested that the IMPP WG consider XML Schema for PIDF; it took all of about an hour to craft a working sample. The idea wasn't well received at the time, but that's another story. -Scott- From owner-ietf-xml-use Mon Apr 22 18:09:47 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3N19lb16808 for ietf-xml-use-bks; Mon, 22 Apr 2002 18:09:47 -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 g3N19ka16804 for ; Mon, 22 Apr 2002 18:09:46 -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 B06F315B9; Tue, 23 Apr 2002 10:09:42 +0900 (JST) Message-Id: <4.2.0.58.J.20020423100319.0465c038@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 23 Apr 2002 10:07:35 +0900 To: Michael Mealling From: Martin Duerst Subject: Re: Validation and IETF XML Usage Guidelines Cc: ietf-xml-use@imc.org In-Reply-To: <20020422094924.A9971@bailey.dscga.com> References: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> 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:49 02/04/22 -0400, Michael Mealling wrote: >If I know that XML Schema >can't handle statements about character encodings then I'd know that >it probably wouldn't be good for CNRP Version 2.0.... Hello Michael, I'm confused. The only thing I have found about character encodings in CNRP is: >>>> 3.4 Character encoding To guarantee interoperability, the following provisions apply: o XML queries and responses MUST be encoded as UTF-8. Note: As in any XML document, numeric character references may be used. o The encoding of characters in the CNRP URI is based on UTF-8; for details, please see [9] Any interfaces electing to present/accept protocol elements in other representations are responsible for accurate transcoding for use in CNRP protocol elements, per the above provisions. >>>> This is from http://www.ietf.org/internet-drafts/draft-ietf-cnrp-12.txt, which may not be the newest one. No schema language I know allows to say 'only UTF-8 allowed'. This is always handled externally to the schema, for very good reasons. Regards, Martin. From owner-ietf-xml-use Mon Apr 22 18:58:23 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3N1wNR17825 for ietf-xml-use-bks; Mon, 22 Apr 2002 18:58:23 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3N1wLa17820 for ; Mon, 22 Apr 2002 18:58:21 -0700 (PDT) Received: from RELAX (j085230.ppp.asahi-net.or.jp [61.213.85.230]) by mail.asahi-net.or.jp (Postfix) with ESMTP id D0734617F for ; Tue, 23 Apr 2002 10:58:24 +0900 (JST) Date: Tue, 23 Apr 2002 10:59:04 +0900 From: MURATA Makoto To: ietf-xml-use@imc.org Subject: Re: PIDF - using xml schema In-Reply-To: References: <86DB568235A8D511ABAC0002A5072CA50316C219@orsmsx120.jf.intel.com> Message-Id: <20020423105438.FC45.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Apr 2002 16:04:43 -0700 (PDT) "Yaron Y. Goland" wrote: > I have already made a stab at this in my own comments - > http://www.goland.geek/#04032002 or http://www.goland.org/#04032002. BTW, > I fully expect that WS-I will perform this same exercise. > > I wish there was another way, any ideas? Here is another useful guideline for using XML Schema. I would propose to reference it from the I-D. http://www.kohsuke.org/xmlschema/XMLSchemaDOsAndDONTs.html -- MURATA Makoto From owner-ietf-xml-use Mon Apr 22 19:06:57 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3N26vP18022 for ietf-xml-use-bks; Mon, 22 Apr 2002 19:06:57 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3N26ta18018 for ; Mon, 22 Apr 2002 19:06:55 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3N25t9X013063; Mon, 22 Apr 2002 22:05:56 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3N25sjC013062; Mon, 22 Apr 2002 22:05:54 -0400 (EDT) Date: Mon, 22 Apr 2002 22:05:54 -0400 From: Michael Mealling To: Martin Duerst Cc: Michael Mealling , ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines Message-ID: <20020422220554.G9971@bailey.dscga.com> Reply-To: Michael Mealling References: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> <3CD14E451751BD42BA48AAA50B07BAD60189B972@vsvapostal3.bkup6> <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> <4.2.0.58.J.20020423100319.0465c038@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20020423100319.0465c038@localhost> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 23, 2002 at 10:07:35AM +0900, Martin Duerst wrote: > At 09:49 02/04/22 -0400, Michael Mealling wrote: > >If I know that XML Schema > >can't handle statements about character encodings then I'd know that > >it probably wouldn't be good for CNRP Version 2.0.... > > Hello Michael, > > I'm confused. The only thing I have found about character > encodings in CNRP is: > > >>>> > 3.4 Character encoding > > To guarantee interoperability, the following provisions apply: > > o XML queries and responses MUST be encoded as UTF-8. > > Note: As in any XML document, numeric character references may be > used. > > o The encoding of characters in the CNRP URI is based on UTF-8; for > details, please see [9] > > Any interfaces electing to present/accept protocol elements in other > representations are responsible for accurate transcoding for use in > CNRP protocol elements, per the above provisions. > >>>> > > This is from http://www.ietf.org/internet-drafts/draft-ietf-cnrp-12.txt, > which may not be the newest one. > > No schema language I know allows to say 'only UTF-8 allowed'. > This is always handled externally to the schema, for very good > reasons. Note that I said "CNRP Version 2.0" above which is a fictional example. After discussions with several experts in Chinese and other Asian languages it is becoming apparent that for certain applications UTF-8 might not be sufficient. I don't know what that means yet but I simply threw it out there as an example of something that might, in the future, need some feature that a particular schema language might not be able to support.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Mon Apr 22 19:20:09 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3N2K9O18255 for ietf-xml-use-bks; Mon, 22 Apr 2002 19:20:09 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3N2K8a18250 for ; Mon, 22 Apr 2002 19:20:08 -0700 (PDT) Received: from RELAX (h221162.ppp.asahi-net.or.jp [61.114.221.162]) by mail.asahi-net.or.jp (Postfix) with ESMTP id A49766121 for ; Tue, 23 Apr 2002 11:20:11 +0900 (JST) Date: Tue, 23 Apr 2002 11:20:50 +0900 From: MURATA Makoto To: ietf-xml-use@imc.org Subject: Re: Validation and IETF XML Usage Guidelines In-Reply-To: <20020422095141.B27043@redhat.com> References: <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> <20020422095141.B27043@redhat.com> Message-Id: <20020423101806.FC42.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Apr 2002 09:51:41 -0400 Daniel Veillard wrote: > Seems a bit strongly worded to me, and the Datatype part of XML Schemas > looks an useful foundation for doing verification on a receiving endpoint > independantly of the mechanism used to specify the structure. I agree that XML Schema Part 2 (datatypes) is much better than XML Schema Part 1 (structure). However, since Part 2 also contains many errors about datatypes such as date, time and language, it is helpful to reference to the following documents from the I-D. XML Schema: Comments on Recommendation http://www.w3.org/2001/05/xmlschema-rec-comments XML Schema 1.0 Specification Errata http://www.w3.org/2001/05/xmlschema-errata Cheers, -- MURATA Makoto From owner-ietf-xml-use Mon Apr 22 22:20:13 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3N5KDr22663 for ietf-xml-use-bks; Mon, 22 Apr 2002 22:20:13 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3N5KBa22659 for ; Mon, 22 Apr 2002 22:20:12 -0700 (PDT) Received: from RELAX (j082228.ppp.asahi-net.or.jp [61.213.82.228]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 477AD6148; Tue, 23 Apr 2002 14:20:15 +0900 (JST) Date: Tue, 23 Apr 2002 14:20:55 +0900 From: MURATA Makoto To: "Yaron Y. Goland" Subject: Re: PIDF - using xml schema Cc: "Carr, Wayne" , "'ietf-xml-use@imc.org'" In-Reply-To: References: <86DB568235A8D511ABAC0002A5072CA50316C219@orsmsx120.jf.intel.com> Message-Id: <20020423141425.FC4E.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Apr 2002 16:04:43 -0700 (PDT) "Yaron Y. Goland" wrote: > > Near as I can tell (and much to my disapointment) XML schema seems a done > deal. I would love to be convinced otherwise. It is true that many companies implement tools for XML Schema. It is also true that adopters of the other languages (except DTDs) are few and that quite a few users have adopted XML Schema. However, if we consider the potential market size of schema languages, most potential users are still waiting and would like to make sure that some schema language becomes mature. In particular, mobile device people have just started to use XML and have not started to use schema languages yet, and it is unclear if XML Schema fits in small computers. Therefore, I don't think that this is a done deal. -- MURATA Makoto From owner-ietf-xml-use Tue Apr 23 02:56:33 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3N9uXE27929 for ietf-xml-use-bks; Tue, 23 Apr 2002 02:56: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 g3N9uVa27916 for ; Tue, 23 Apr 2002 02:56:31 -0700 (PDT) Received: (qmail 18296 invoked by uid 0); 23 Apr 2002 09:56:26 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 23 Apr 2002 09:56:26 -0000 From: "Julian Reschke" To: Subject: RE: Validation and IETF XML Usage Guidelines Date: Tue, 23 Apr 2002 11:56:21 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seems that I should try to explain this again :-) In WebDAV, extensibility is done by *allowing* any element that is not defined by WebDAV in any place (no matter which namespace it's in). So for instance, the definition for {DAV:}propfind requires a content of exactly one of {DAV:}allprop, {DAV:}prop or {DAV:}propname (easily written as XPath based assertion), but allows *any* other additional element (even from the DAV: namespace, as long as it's not defined in the *current* WebDAV RFC). I think this extensibility model is completely sane, because it enforces rules for those elements that are known to the consumer of the message, while it allows the sender to extend the request (be it with private extensions frowm his own namespace, or new WebDAV protocol features). If a schema language fails to offer validation for this kind of extensibility, it can't be used for validation here. AFAIK, XML Schema allows me to allow extension elements from different namespaces, but not new elements from the same namespace (if this can be achieved with XML Schema, I'd like to learn how). Julian > -----Original Message----- > From: owner-ietf-xml-use@mail.imc.org > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Julian Reschke > Sent: Monday, April 22, 2002 6:28 PM > To: Michael Mealling; MURATA Makoto > Cc: Hollenbeck, Scott; ietf-xml-use@imc.org > Subject: RE: Validation and IETF XML Usage Guidelines > > > > > From: owner-ietf-xml-use@mail.imc.org > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Michael Mealling > > Sent: Monday, April 22, 2002 3:49 PM > > To: MURATA Makoto > > Cc: Hollenbeck, Scott; ietf-xml-use@imc.org > > Subject: Re: Validation and IETF XML Usage Guidelines > > > > > > > > On Mon, Apr 22, 2002 at 10:01:01PM +0900, MURATA Makoto wrote: > > > On Mon, 22 Apr 2002 08:32:49 -0400 > > > "Hollenbeck, Scott" wrote: > > > > > In the XML developer mailing list, it has been repeatedly > > > > > reported that > > > > > XML Schema implementations fail to interwork. If IETF still cares > > > > > "rough consensus and running code", I think that the > > > > > guideline document > > > > > MUST NOT recommend XML Schema. Rather, implementors should > > > > > be encouraged > > > > > to peruse their favorite languages. > > > > > > > > I can't agree with this suggestion - a recommendation of "use > > your favorite > > > > language" is no recommendation at all for someone who doesn't have a > > > > favorite language. I don't have a problem, though, with > > noting that there > > > > are alternatives to XML Schema (done in -01) and that the > > issue is still > > > > somewhat controversial (can be emphasized in -02). > > > > > > I claim that I am an expert of XML in general and schema languages in > > > particular. If I am asked by users, I cannot recommend any of the > > > schema languages at hand. Although I certainly think RELAX NG is > > > technically the best, I cannot guarantee it will make it in the > > market. > > > XML Schema just sucks. > > > > > > If no schema languages can be recommended, it is a good idea > > not to recommend > > > any of them. If we recommend one of them, we run the risk of > deceiving > > > readers. I thus continue to oppose to the two sentences below: > > > > But how badly does it suck? Its much more productive to apply > > this discussion > > to current examples of XML protocols than simply make > > unmeasurable statements > > of general suckiness. The one I'm familiar with is CNRP which is fairly > > simple. PROVREG is fairly complex. Are there features of either one that > > XML Schema simply can't handle? If so then, IMHO that's a reason not to > > recommend it. But if XML Schema can handle the currently proposed > > XML parts > > of IETF protocols then, IMHO, it makes a perfectly reasonable default. > > We had this already. > > WebDAV has a completely sane extensibility model, yet it can't be modeled > using XML Schema. > From owner-ietf-xml-use Tue Apr 23 06:03:03 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ND33e11406 for ietf-xml-use-bks; Tue, 23 Apr 2002 06:03:03 -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 g3ND32a11401 for ; Tue, 23 Apr 2002 06:03:02 -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 44DD915BC; Tue, 23 Apr 2002 22:02:52 +0900 (JST) Message-Id: <4.2.0.58.J.20020423122535.046690d8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 23 Apr 2002 12:26:49 +0900 To: MURATA Makoto , ietf-xml-use@imc.org From: Martin Duerst Subject: Re: Validation and IETF XML Usage Guidelines In-Reply-To: <20020423101806.FC42.MURATA@hokkaido.email.ne.jp> References: <20020422095141.B27043@redhat.com> <20020422213928.FC3F.MURATA@hokkaido.email.ne.jp> <20020422095141.B27043@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:20 02/04/23 +0900, MURATA Makoto wrote: >it is helpful to reference to the following >documents from the I-D. > >XML Schema: Comments on Recommendation >http://www.w3.org/2001/05/xmlschema-rec-comments > >XML Schema 1.0 Specification Errata >http://www.w3.org/2001/05/xmlschema-errata If you do, I suggest you make them http://www.w3.org/2001/05/xmlschema-rec-comments.html http://www.w3.org/2001/05/xmlschema-errata.html to reduce dependencies on stylesheets, scripts,... Regards, Martin. From owner-ietf-xml-use Tue Apr 23 09:57:16 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3NGvGi26822 for ietf-xml-use-bks; Tue, 23 Apr 2002 09:57:16 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NGv9a26816 for ; Tue, 23 Apr 2002 09:57:09 -0700 (PDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3NGuME05306 for ; Tue, 23 Apr 2002 16:56:24 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3NGxDH05965 for ; Tue, 23 Apr 2002 16:59:13 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002042310011703094 ; Tue, 23 Apr 2002 10:01:19 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2LKCBZDA>; Tue, 23 Apr 2002 09:57:04 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C21C@orsmsx120.jf.intel.com> From: "Carr, Wayne" To: "'MURATA Makoto'" , "Yaron Y. Goland" Cc: "Carr, Wayne" , "'ietf-xml-use@imc.org'" Subject: RE: PIDF - using xml schema Date: Tue, 23 Apr 2002 09:56:59 -0700 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: > In particular, mobile device people have just started to use XML and have > not started to use schema languages yet, and it is unclear if XML Schema > fits in small computers. I think for uses like impp or for W3C's XForms (which is aimed at devices like phones), the expectation is that there is no need to do XML Schema validation in the target device. XML Schema is very useful for defining the permitted format precisely and validation is useful in developing software that produces the format properly. But for these types of things, it wouldn't be necessary to do it in a phone. That said, the part of XML Schema used in the impp xml schema is so simple, a phone surely could do it (though it almost certainly doesn't need to). The XML Schema WG I think is at the point of planning 1.1 and a very useful thing for them to do would be to produce a subset of schema that can be used to validate in devices like phones. > -----Original Message----- > From: MURATA Makoto [mailto:murata@hokkaido.email.ne.jp] > Sent: Monday, April 22, 2002 10:21 PM > To: Yaron Y. Goland > Cc: Carr, Wayne; 'ietf-xml-use@imc.org' > Subject: Re: PIDF - using xml schema > > > > On Mon, 22 Apr 2002 16:04:43 -0700 (PDT) > "Yaron Y. Goland" wrote: > > > > > Near as I can tell (and much to my disapointment) XML > schema seems a done > > deal. I would love to be convinced otherwise. > > It is true that many companies implement tools for XML > Schema. It is also > true that adopters of the other languages (except DTDs) are > few and that quite > a few users have adopted XML Schema. However, if we consider > the potential > market size of schema languages, most potential users are > still waiting and > would like to make sure that some schema language becomes > mature. In particular, > mobile device people have just started to use XML and have > not started to use > schema languages yet, and it is unclear if XML Schema fits in > small computers. > Therefore, I don't think that this is a done deal. > > -- > MURATA Makoto > From owner-ietf-xml-use Tue Apr 23 23:00:39 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3O60dE00478 for ietf-xml-use-bks; Tue, 23 Apr 2002 23:00:39 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O60Xa00459 for ; Tue, 23 Apr 2002 23:00:37 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3O60RpP020137; Tue, 23 Apr 2002 23:00:28 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id XAA15021; Tue, 23 Apr 2002 23:00:27 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Tue, 23 Apr 2002 23:00:27 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: MURATA Makoto cc: "Carr, Wayne" , "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: <20020423141425.FC4E.MURATA@hokkaido.email.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Having just come from working for Openwave I have some insight into the mobile issue, I would strongly expect them to adopt XML Schema and I equally strongly expect that any schema validation will only be done up on the proxies not on the handsets. In my experience XML protocol systems do not use schemas during run time. At least not as an explicit step. Any schema checking is usually just baked into the code. The one glorious exception is RelaxNGCC whose design (I haven't had a chance to validate how well it works in practice) is truly beautiful. In general however I expect XML schemas to mostly play the role of formally defining message syntax inside of specifications rather then being used for run time validation. On Tue, 23 Apr 2002, MURATA Makoto wrote: > > On Mon, 22 Apr 2002 16:04:43 -0700 (PDT) > "Yaron Y. Goland" wrote: > > > > > Near as I can tell (and much to my disapointment) XML schema seems a done > > deal. I would love to be convinced otherwise. > > It is true that many companies implement tools for XML Schema. It is also > true that adopters of the other languages (except DTDs) are few and that quite > a few users have adopted XML Schema. However, if we consider the potential > market size of schema languages, most potential users are still waiting and > would like to make sure that some schema language becomes mature. In particular, > mobile device people have just started to use XML and have not started to use > schema languages yet, and it is unclear if XML Schema fits in small computers. > Therefore, I don't think that this is a done deal. > > -- > MURATA Makoto > From owner-ietf-xml-use Wed Apr 24 00:37:09 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3O7b9m16210 for ietf-xml-use-bks; Wed, 24 Apr 2002 00:37:09 -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 g3O7b8a16204 for ; Wed, 24 Apr 2002 00:37:08 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.33.35]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3OFH9412653; Wed, 24 Apr 2002 08:17:10 -0700 Message-Id: <5.1.0.14.2.20020424075449.00a83600@joy.songbird.com> X-Sender: gk-bulk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Apr 2002 07:57:47 +0100 To: "Carr, Wayne" From: Graham Klyne Subject: RE: PIDF - using xml schema Cc: "'ietf-xml-use@imc.org'" In-Reply-To: <86DB568235A8D511ABAC0002A5072CA50316C21C@orsmsx120.jf.inte l.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 09:56 AM 4/23/02 -0700, Carr, Wayne wrote: >I think for uses like impp or for W3C's XForms (which is aimed at devices >like phones), the expectation is that there is no need to do XML Schema >validation in the target device. XML Schema is very useful for defining the >permitted format precisely and validation is useful in developing software >that produces the format properly. I agree. My intuition is that full XML-schema validation in applications will be the exception rather than the rule. I'd surely think twice about using it. Where I have seem schemas apparently used to good effect is for the creation of code to generate and check XML application data. #g ------------------- Graham Klyne From owner-ietf-xml-use Wed Apr 24 02:35:38 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3O9ZcY04806 for ietf-xml-use-bks; Wed, 24 Apr 2002 02:35:38 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O9Zba04798 for ; Wed, 24 Apr 2002 02:35:37 -0700 (PDT) Received: from RELAX (h220148.ppp.asahi-net.or.jp [61.114.220.148]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 85879612B for ; Wed, 24 Apr 2002 18:35:26 +0900 (JST) Date: Wed, 24 Apr 2002 18:36:16 +0900 From: MURATA Makoto To: "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: References: <20020423141425.FC4E.MURATA@hokkaido.email.ne.jp> Message-Id: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 23 Apr 2002 23:00:27 -0700 (PDT) "Yaron Y. Goland" wrote: > In general however I expect XML schemas to mostly play the role of > formally defining message syntax inside of specifications rather then > being used for run time validation. I think that this is the logical consensus of adoption of XML Schema as a schema language. Since it is heavy, it cannot be used for run time validation in mobile devices. > Having just come from working for Openwave I have some insight into the > mobile issue, I would strongly expect them to adopt XML Schema and I > equally strongly expect that any schema validation will only be done up on > the proxies not on the handsets. Some people have said that use of XML for mobile devices is useless, since XML is verbose. I'm not sure if they are right. Some people believe that well-formedness checking on mobile devices is useless. I don't know. And you believe that validity checking at run-time on mobile devices is useless. Again, I am not sure. But I do have security concerns. I do not believe those XML documents which I receive from the Internet. > In my experience XML protocol systems do not use schemas during run time. > At least not as an explicit step. Any schema checking is usually just > baked into the code. The one glorious exception is RelaxNGCC whose design > (I haven't had a chance to validate how well it works in practice) is > truly beautiful. As you pointed out, schemas are used not only for validation but also for programming (as in RelaxNGCC). If we keep the door open for the latter, we have to consider small schema languages. Cheers, Makoto From owner-ietf-xml-use Wed Apr 24 07:45:08 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OEj8906162 for ietf-xml-use-bks; Wed, 24 Apr 2002 07:45: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 g3OEj7a06158 for ; Wed, 24 Apr 2002 07:45:07 -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 622E513EC; Wed, 24 Apr 2002 23:44:56 +0900 (JST) Message-Id: <4.2.0.58.J.20020424232534.026c3ef8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 24 Apr 2002 23:37:28 +0900 To: MURATA Makoto , "'ietf-xml-use@imc.org'" From: Martin Duerst Subject: Re: PIDF - using xml schema In-Reply-To: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> References: <20020423141425.FC4E.MURATA@hokkaido.email.ne.jp> 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: It may well be worth mentioning that XML Schema Structures was carefully designed with quick validation in mind. In particular, a great deal of care was taken to make sure that validation can be done without a lot of lookahead. Schemas that may look obvious to a human user but can lead to such problems are made illegal. So you know that when you write an XML Schema, it is possible to validate/process it efficiently (not necessarily with a generalized processor). This is one of the properties that make XML Schema complicated and difficult for many users, but on the other hand, this may be something that guarantees a certain efficiency for things such as mobile devices. Regards, Martin. At 18:36 02/04/24 +0900, MURATA Makoto wrote: >On Tue, 23 Apr 2002 23:00:27 -0700 (PDT) >"Yaron Y. Goland" wrote: > > > In general however I expect XML schemas to mostly play the role of > > formally defining message syntax inside of specifications rather then > > being used for run time validation. > >I think that this is the logical consensus of adoption of XML Schema as a >schema language. Since it is heavy, it cannot be used for run time >validation >in mobile devices. > > > Having just come from working for Openwave I have some insight into the > > mobile issue, I would strongly expect them to adopt XML Schema and I > > equally strongly expect that any schema validation will only be done up on > > the proxies not on the handsets. > >Some people have said that use of XML for mobile devices is useless, since >XML >is verbose. I'm not sure if they are right. Some people believe that >well-formedness >checking on mobile devices is useless. I don't know. And you believe >that validity >checking at run-time on mobile devices is useless. Again, I am not >sure. But I do have >security concerns. I do not believe those XML documents which I receive >from the Internet. > > > In my experience XML protocol systems do not use schemas during run time. > > At least not as an explicit step. Any schema checking is usually just > > baked into the code. The one glorious exception is RelaxNGCC whose design > > (I haven't had a chance to validate how well it works in practice) is > > truly beautiful. > >As you pointed out, schemas are used not only for validation but also >for programming (as in RelaxNGCC). If we keep the door open for the latter, >we have to consider small schema languages. > >Cheers, > >Makoto From owner-ietf-xml-use Wed Apr 24 09:03:50 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3OG3oH14199 for ietf-xml-use-bks; Wed, 24 Apr 2002 09:03:50 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OG3ha14183 for ; Wed, 24 Apr 2002 09:03:47 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3OG3gpP016344; Wed, 24 Apr 2002 09:03:42 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id JAA21320; Wed, 24 Apr 2002 09:03:42 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Wed, 24 Apr 2002 09:03:42 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: MURATA Makoto cc: "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In mobile systems deployment always consists of a proxy and a handset. All messages pass through the proxy before reach the handset. Therefore the carrier is able to add value (and take control) through the proxy. If any kind of validation is necessary then it will be performed on the proxy. As for 'heavy weight'. This is not a fundamental aspect of XML schema but any schema language. RelaxNG is no different in this matter from any other schema language. If you do simple things then they can be validated simply. If you do complicated things then they will be expensive. It is just as possible (although not as easy) to do simple, lightweight things in XML schema as in RelaxNG. We should not confuse performance with ease of use. On Wed, 24 Apr 2002, MURATA Makoto wrote: > > > On Tue, 23 Apr 2002 23:00:27 -0700 (PDT) > "Yaron Y. Goland" wrote: > > > In general however I expect XML schemas to mostly play the role of > > formally defining message syntax inside of specifications rather then > > being used for run time validation. > > I think that this is the logical consensus of adoption of XML Schema as a > schema language. Since it is heavy, it cannot be used for run time validation > in mobile devices. > > > Having just come from working for Openwave I have some insight into the > > mobile issue, I would strongly expect them to adopt XML Schema and I > > equally strongly expect that any schema validation will only be done up on > > the proxies not on the handsets. > > Some people have said that use of XML for mobile devices is useless, since XML > is verbose. I'm not sure if they are right. Some people believe that well-formedness > checking on mobile devices is useless. I don't know. And you believe that validity > checking at run-time on mobile devices is useless. Again, I am not sure. But I do have > security concerns. I do not believe those XML documents which I receive from the Internet. > > > In my experience XML protocol systems do not use schemas during run time. > > At least not as an explicit step. Any schema checking is usually just > > baked into the code. The one glorious exception is RelaxNGCC whose design > > (I haven't had a chance to validate how well it works in practice) is > > truly beautiful. > > As you pointed out, schemas are used not only for validation but also > for programming (as in RelaxNGCC). If we keep the door open for the latter, > we have to consider small schema languages. > > Cheers, > > Makoto > From owner-ietf-xml-use Wed Apr 24 09:09:34 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OG9Yi15058 for ietf-xml-use-bks; Wed, 24 Apr 2002 09:09:34 -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 g3OG9Wa15051 for ; Wed, 24 Apr 2002 09:09:32 -0700 (PDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g3OG9Qi02438; Wed, 24 Apr 2002 12:09:26 -0400 Date: Wed, 24 Apr 2002 12:09:26 -0400 From: Daniel Veillard To: "Yaron Y. Goland" Cc: MURATA Makoto , "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema Message-ID: <20020424120926.S26241@redhat.com> Reply-To: veillard@redhat.com References: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from modulus@cinenet.net on Wed, Apr 24, 2002 at 09:03:42AM -0700 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Apr 24, 2002 at 09:03:42AM -0700, Yaron Y. Goland wrote: > > In mobile systems deployment always consists of a proxy and a handset. All > messages pass through the proxy before reach the handset. Therefore the > carrier is able to add value (and take control) through the proxy. If any > kind of validation is necessary then it will be performed on the proxy. > > As for 'heavy weight'. This is not a fundamental aspect of XML schema but > any schema language. RelaxNG is no different in this matter from any other > schema language. If you do simple things then they can be validated > simply. If you do complicated things then they will be expensive. It is > just as possible (although not as easy) to do simple, lightweight things > in XML schema as in RelaxNG. > > We should not confuse performance with ease of use. I think the underlying point of Martin message was that XML Schemas allows only deterministic content models, hence there is no risk of resource exhaution on the proxy (or wherever the validation is done). 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 24 09:58:20 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3OGwK119099 for ietf-xml-use-bks; Wed, 24 Apr 2002 09:58:20 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OGwIa19092 for ; Wed, 24 Apr 2002 09:58:18 -0700 (PDT) Received: from RELAX (h220148.ppp.asahi-net.or.jp [61.114.220.148]) by mail.asahi-net.or.jp (Postfix) with ESMTP id BC40F613C; Thu, 25 Apr 2002 01:58:09 +0900 (JST) Date: Thu, 25 Apr 2002 01:59:00 +0900 From: MURATA Makoto To: "Yaron Y. Goland" Subject: Re: PIDF - using xml schema Cc: "'ietf-xml-use@imc.org'" In-Reply-To: References: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> Message-Id: <20020425015632.C237.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 24 Apr 2002 09:03:42 -0700 (PDT) "Yaron Y. Goland" wrote: > As for 'heavy weight'. This is not a fundamental aspect of XML schema but > any schema language. RelaxNG is no different in this matter from any other > schema language. If you do simple things then they can be validated > simply. If you do complicated things then they will be expensive. It is > just as possible (although not as easy) to do simple, lightweight things > in XML schema as in RelaxNG. No. Since RELAX NG is directly based on the tree automata theory, it is possible to generate a small table, just like we can generate automata from regular expressions. -- MURATA Makoto From owner-ietf-xml-use Wed Apr 24 10:04:14 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OH4EG19291 for ietf-xml-use-bks; Wed, 24 Apr 2002 10:04:14 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OH4Ca19287 for ; Wed, 24 Apr 2002 10:04:12 -0700 (PDT) Received: from RELAX (h220148.ppp.asahi-net.or.jp [61.114.220.148]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 1CF5A613C; Thu, 25 Apr 2002 02:04:13 +0900 (JST) Date: Thu, 25 Apr 2002 02:04:54 +0900 From: MURATA Makoto To: Martin Duerst Subject: Re: PIDF - using xml schema Cc: "'ietf-xml-use@imc.org'" In-Reply-To: <4.2.0.58.J.20020424232534.026c3ef8@localhost> References: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> <4.2.0.58.J.20020424232534.026c3ef8@localhost> Message-Id: <20020425020034.C23A.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 24 Apr 2002 23:37:28 +0900 Martin Duerst wrote: > It may well be worth mentioning that XML Schema Structures was > carefully designed with quick validation in mind. In particular, > a great deal of care was taken to make sure that validation can > be done without a lot of lookahead. It is true that XML Schema is designed so that SAX-based validation is possible. I thus agree with your first sentence. > > Schemas that may look obvious to a human user but can lead to such > problems are made illegal. So you know that when you write an XML > Schema, it is possible to validate/process it efficiently (not > necessarily with a generalized processor). I disagree entirely. It is possible to validate documents very efficiently even when we allow the full power of tree regular languages. See my note [1] and James's memo [2] [1] http://citeseer.nj.nec.com/439547.html [2] http://www.thaiopensource.com/relaxng/implement.html Cheers, Makoto From owner-ietf-xml-use Wed Apr 24 16:45:10 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3ONjA828793 for ietf-xml-use-bks; Wed, 24 Apr 2002 16:45:10 -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 g3ONj8a28788 for ; Wed, 24 Apr 2002 16:45:09 -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 AB1EC135B; Thu, 25 Apr 2002 08:45:07 +0900 (JST) Message-Id: <4.2.0.58.J.20020425075145.03f3efa0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 25 Apr 2002 07:52:13 +0900 To: veillard@redhat.com, "Yaron Y. Goland" From: Martin Duerst Subject: Re: PIDF - using xml schema Cc: MURATA Makoto , "'ietf-xml-use@imc.org'" In-Reply-To: <20020424120926.S26241@redhat.com> References: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> 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 12:09 02/04/24 -0400, Daniel Veillard wrote: > I think the underlying point of Martin message was that XML Schemas >allows only deterministic content models, hence there is no risk of >resource exhaution on the proxy (or wherever the validation is done). Yes, exactly. Thanks for putting it in the right words. Martin. From owner-ietf-xml-use Wed Apr 24 16:45:18 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3ONjIj28803 for ietf-xml-use-bks; Wed, 24 Apr 2002 16:45:18 -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 g3ONjGa28798 for ; Wed, 24 Apr 2002 16:45:17 -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 02F4713EC; Thu, 25 Apr 2002 08:45:06 +0900 (JST) Message-Id: <4.2.0.58.J.20020425074911.03cfa798@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 25 Apr 2002 07:51:14 +0900 To: "Yaron Y. Goland" From: Martin Duerst Subject: Re: PIDF - using xml schema Cc: "'ietf-xml-use@imc.org'" In-Reply-To: References: <20020424182704.9FF7.MURATA@hokkaido.email.ne.jp> 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:03 02/04/24 -0700, Yaron Y. Goland wrote: >In mobile systems deployment always consists of a proxy and a handset. Hello Yaron, Please be careful with this. It's not too much of a surprise that you say this, as you said that you were involved with OpenWave. But e.g. the i-mode service by NTT DoCoMo in Japan is much less dependent on proxy functionality than a WAP system. Regards, Martin. >All >messages pass through the proxy before reach the handset. Therefore the >carrier is able to add value (and take control) through the proxy. If any >kind of validation is necessary then it will be performed on the proxy. > >As for 'heavy weight'. This is not a fundamental aspect of XML schema but >any schema language. RelaxNG is no different in this matter from any other >schema language. If you do simple things then they can be validated >simply. If you do complicated things then they will be expensive. It is >just as possible (although not as easy) to do simple, lightweight things >in XML schema as in RelaxNG. > >We should not confuse performance with ease of use. From owner-ietf-xml-use Wed Apr 24 17:19:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3P0JZM29397 for ietf-xml-use-bks; Wed, 24 Apr 2002 17:19:35 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P0JWa29392 for ; Wed, 24 Apr 2002 17:19:32 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3P0JPpP016350; Wed, 24 Apr 2002 17:19:25 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id RAA26350; Wed, 24 Apr 2002 17:19:25 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Wed, 24 Apr 2002 17:19:24 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: Martin Duerst cc: "Yaron Y. Goland" , "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: <4.2.0.58.J.20020425074911.03cfa798@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I-Mode is designed pretty much the way WAP 2.0 proxies are designed. I-Mode just seems a little lighter then most because they require all web servers to run their proprietary software in order to interoperate with I-Mode phones. So some of the heavy lifting normally done by WAP proxies are actually performed by I-Mode's software running on the end point servers. Think of it as a 'spread out' proxy. The point of this whole thing isn't to say that the end points (i.e. clients) aren't going to get bigger and smarter. Rather it is to say that things like schema validation in the near term are not likely to be attempted on the client but will actually happen upon the proxy. In the medium to long term the proxies may very well disappear as handsets get more powerful and network speeds increase. On Thu, 25 Apr 2002, Martin Duerst wrote: > > At 09:03 02/04/24 -0700, Yaron Y. Goland wrote: > > >In mobile systems deployment always consists of a proxy and a handset. > > Hello Yaron, > > Please be careful with this. It's not too much of a surprise that > you say this, as you said that you were involved with OpenWave. > But e.g. the i-mode service by NTT DoCoMo in Japan is much less > dependent on proxy functionality than a WAP system. > > Regards, Martin. > > > > >All > >messages pass through the proxy before reach the handset. Therefore the > >carrier is able to add value (and take control) through the proxy. If any > >kind of validation is necessary then it will be performed on the proxy. > > > >As for 'heavy weight'. This is not a fundamental aspect of XML schema but > >any schema language. RelaxNG is no different in this matter from any other > >schema language. If you do simple things then they can be validated > >simply. If you do complicated things then they will be expensive. It is > >just as possible (although not as easy) to do simple, lightweight things > >in XML schema as in RelaxNG. > > > >We should not confuse performance with ease of use. > From owner-ietf-xml-use Thu Apr 25 10:48:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PHml004286 for ietf-xml-use-bks; Thu, 25 Apr 2002 10:48:47 -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 g3PHmja04282 for ; Thu, 25 Apr 2002 10:48:45 -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 NAA16916; Thu, 25 Apr 2002 13:48:33 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5X3ZV>; Thu, 25 Apr 2002 13:48:11 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B9B6@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Chris Lilley'" , IETF XML Subject: RE: Notes on draft-hollenbeck-ietf-xml-guidelines-01.txt Date: Thu, 25 Apr 2002 13:48:09 -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: Thanks for the comments, Chris. Larry, Marshall, and I have been looking them over and will do our best to work things in as part of -02. We did have some thoughts on a few of your thoughts, though: (reference: http://www.imc.org/ietf-xml-use/mail-archive/msg00066.html) > 4.5 Namespaces > "In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN > namespace (see [13] and [14])." That makes me feel uncomfortable, but i don''t > have articulate arguments right now to clarify the source of discomfort so i > not it here and may get back to it later, or others might. We're inclined to leave the text as-is in the absence of alternative text. > 4.5.1 Namespaces and Attributes > "As described in XML Alternatives there is no standard mechanism in XML for > indicating whether or not new extensions are mandatory to recognize. XML-based > protocol specifications should thus explicitly describe extension mechanisms > and requirements to recognize or ignore extensions." > True in general but there are specific examples of such mechanisms so they > should be listed here and the advice elsewhere in the document to re-use > existing mechanisms should be applied here also. I'm thinking of the DOM > feature tests and the SMIL and SVG requiredFeatures, requiredExtensions > and test and switch capabilities. We'd prefer to leave this text as-is instead of attempting to enumerate extension mechanism options as the purpose of the section isn't to describe alternatives, but to help ensure that designers explicitly address the issue in specifications. > 4.6 Element and Attribute Design Considerations [long markup options example described] We're going to rewrite this section, though we don't really want to try to explain all of the possible ways that an IPv4 address can be represented in XML. What you see in -02 won't be exactly what you suggested but it'll hopefully address the spirit of your comments. > 5. Internationalization Considerations Again, we're going to try to rewrite this section. The words might not match yours exactly, but we'll incorporate your thoughts. -Scott- From owner-ietf-xml-use Thu Apr 25 10:59:38 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PHxcG04604 for ietf-xml-use-bks; Thu, 25 Apr 2002 10:59:38 -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 g3PHxba04600 for ; Thu, 25 Apr 2002 10:59:37 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA11746; Thu, 25 Apr 2002 13:59:35 -0400 Date: Thu, 25 Apr 2002 19:57:04 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <18885397296.20020425195704@w3.org> To: "Hollenbeck, Scott" CC: IETF XML Subject: Re: Notes on draft-hollenbeck-ietf-xml-guidelines-01.txt In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B9B6@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B9B6@vsvapostal3.bkup6> 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 Thursday, April 25, 2002, 7:48:09 PM, Scott wrote: HS> Thanks for the comments, Chris. Larry, Marshall, and I have been looking HS> them over and will do our best to work things in as part of -02. We did HS> have some thoughts on a few of your thoughts, though: HS> (reference: HS> http://www.imc.org/ietf-xml-use/mail-archive/msg00066.html) >> 4.5 Namespaces >> "In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF HS> URN >> namespace (see [13] and [14])." That makes me feel uncomfortable, but i HS> don''t >> have articulate arguments right now to clarify the source of discomfort so HS> i >> not it here and may get back to it later, or others might. HS> We're inclined to leave the text as-is in the absence of alternative text. As indeed you should. Those started off as notes for myself - portions are not well articulated, as you noticed. They were also sent to the TAG, and will be discussed next week. I made no good argument in that section so you should of course feel free to not be persuaded by it ;-) >> 4.5.1 Namespaces and Attributes >> "As described in XML Alternatives there is no standard mechanism in XML HS> for >> indicating whether or not new extensions are mandatory to recognize. HS> XML-based >> protocol specifications should thus explicitly describe extension HS> mechanisms >> and requirements to recognize or ignore extensions." >> True in general but there are specific examples of such mechanisms so they >> should be listed here and the advice elsewhere in the document to re-use >> existing mechanisms should be applied here also. I'm thinking of the DOM >> feature tests and the SMIL and SVG requiredFeatures, requiredExtensions >> and test and switch capabilities. HS> We'd prefer to leave this text as-is instead of attempting to enumerate HS> extension mechanism options as the purpose of the section isn't to describe HS> alternatives, but to help ensure that designers explicitly address the issue HS> in specifications. Okay, understood. >> 4.6 Element and Attribute Design Considerations HS> [long markup options example described] HS> We're going to rewrite this section, though we don't really want to try to HS> explain all of the possible ways that an IPv4 address can be represented in HS> XML. What you see in -02 won't be exactly what you suggested but it'll HS> hopefully address the spirit of your comments. Great, I look forward to reading it. My main point was that maximal element oriented markup is not necessarily the optimal solution. >> 5. Internationalization Considerations HS> Again, we're going to try to rewrite this section. The words might not HS> match yours exactly, but we'll incorporate your thoughts. Again, thanks. Glad some of the comments were helpful. -- Chris mailto:chris@w3.org From owner-ietf-xml-use Thu Apr 25 17:08:58 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q08wb12705 for ietf-xml-use-bks; Thu, 25 Apr 2002 17:08:58 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q08ua12701 for ; Thu, 25 Apr 2002 17:08:56 -0700 (PDT) Received: from RELAX (j084215.ppp.asahi-net.or.jp [61.213.84.215]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 3D83E6C6D for ; Fri, 26 Apr 2002 09:08:59 +0900 (JST) Date: Fri, 26 Apr 2002 09:09:42 +0900 From: MURATA Makoto To: "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: References: <4.2.0.58.J.20020425074911.03cfa798@localhost> Message-Id: <20020426090532.8AD3.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 24 Apr 2002 17:19:24 -0700 (PDT) "Yaron Y. Goland" wrote: > The point of this whole thing isn't to say that the end points (i.e. > clients) aren't going to get bigger and smarter. Rather it is to say that > things like schema validation in the near term are not likely to be > attempted on the client but will actually happen upon the proxy. Yesterday, I bought a magazine caled "Java World". The first article is how to write i-mode Java application programs which downloads information from WWW servers. At present, i-mode imposes a severe restriction on the size of Java programs and i-mode does not have pre-installed XML parsers. Both will change in the near future. I thus think many i-mode programs will download XML from the WWW soon. Cheers, -- MURATA Makoto From owner-ietf-xml-use Thu Apr 25 17:41:24 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3Q0fOA13193 for ietf-xml-use-bks; Thu, 25 Apr 2002 17:41:24 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q0fMa13189 for ; Thu, 25 Apr 2002 17:41:22 -0700 (PDT) Received: from RELAX (j084215.ppp.asahi-net.or.jp [61.213.84.215]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 89D4F6BAD; Fri, 26 Apr 2002 09:41:24 +0900 (JST) Date: Fri, 26 Apr 2002 09:42:08 +0900 From: MURATA Makoto To: Martin Duerst Subject: Re: PIDF - using xml schema Cc: veillard@redhat.com, "Yaron Y. Goland" , "'ietf-xml-use@imc.org'" In-Reply-To: <4.2.0.58.J.20020425075145.03f3efa0@localhost> References: <20020424120926.S26241@redhat.com> <4.2.0.58.J.20020425075145.03f3efa0@localhost> Message-Id: <20020426091159.8AD9.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 25 Apr 2002 07:52:13 +0900 Martin Duerst wrote: > > > I think the underlying point of Martin message was that XML Schemas > >allows only deterministic content models, hence there is no risk of > >resource exhaution on the proxy (or wherever the validation is done). > > Yes, exactly. Thanks for putting it in the right words. Martin. In my opinion, deterministic content models help validation only when people do not know automata or derivatives[1] and they naively interpret content models directly. Note: Deterministic content models prohibits seemingly innocent regular expressions such as (a*, (a|b)). Ever since SGML, schema authors have been annoyed by this restriction. This is one reason that XML Schema is hard to use. One standard validation technique is to construct string automata from content models or tree automata from schemas. We only have to defeminize string or tree automata or execute non-deterministic (string or tree) automata by simulating all possibilities. It is true that creation of automata is expensive. For this reason, Jing and MSV directly interpret content models by repeatedly rewriting content models. This technique is called "derivatives of regular expressions" in formal computer science. We can assume this technique as lazy construction of automata. This technique does not require deterministic content models either. Note: It has been recently pointed out that type inference becomes easier (i.e., the time complexity becomes lower), if we use deterministic content models. On the other hand, XDuce[2] does not use deterministic content models and still efficiently provides type inference. The underlying theory of XML is tree automata. In the area of programming language research (POPL), XDuce[2] uses tree automata for XML type inference. In the area of theoretical database research (PODS), tree automata has become the main stream for XML research (e.g., [3]). In the XML community, tree automata has also been widely recognized [4]. I think that it is unfortunate that XML Schema ignores this theory, since it hampers further progress of this area. [1] J.A. Brzozowski, Derivatives of Regular Expressions, Journal of ACM Vol. 11, No.4, pp. 481-494, 1964. [2] http://xduce.sourceforge.net/ [3] http://citeseer.nj.nec.com/context/1741693/448486 [4] http://www.oasis-open.org/cover/hedgeAutomata.html From owner-ietf-xml-use Thu Apr 25 17:56:55 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q0ut513405 for ietf-xml-use-bks; Thu, 25 Apr 2002 17:56:55 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q0uqa13396 for ; Thu, 25 Apr 2002 17:56:52 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3Q0urpP004580; Thu, 25 Apr 2002 17:56:53 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id RAA11433; Thu, 25 Apr 2002 17:56:53 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Thu, 25 Apr 2002 17:56:52 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: MURATA Makoto cc: Martin Duerst , , "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: <20020426091159.8AD9.MURATA@hokkaido.email.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is the issue - should the BCP recommend XML schema versus Relax NG? Clearly we wish to pick one. Supporting both won't help interoperability. When writing a spec I often find it useful to write requirments. What would be the requirements for deciding which schema language to pick? Once we agree on the list of requirements we can then measure each language against it and see who wins. My own requirements would read something like: 1. Easy to read (can a newbie look at it and have a pretty good idea of what it says?) 2. Easy to write (can it pass the notepad test?) 3. Easy to use to describe how schemas should be extended (do I have to shove into every single element?) 4. Expressive Model that can describe any reasonable XML structure (can it describe a graph?) 5. Widely supported by the entire community (loads of well supported existing toolsets and wide mindshare) 6. Well designed for processing in small devices/constrained environments etc. I realize that all of these criteria are subjective but just getting a list out will at least help us to see how deep the pit the choice represents is. Just a thought, Yaron On Fri, 26 Apr 2002, MURATA Makoto wrote: > > > On Thu, 25 Apr 2002 07:52:13 +0900 > Martin Duerst wrote: > > > > > > I think the underlying point of Martin message was that XML Schemas > > >allows only deterministic content models, hence there is no risk of > > >resource exhaution on the proxy (or wherever the validation is done). > > > > Yes, exactly. Thanks for putting it in the right words. Martin. > > In my opinion, deterministic content models help validation only when people do not know > automata or derivatives[1] and they naively interpret content models directly. > > Note: Deterministic content models prohibits seemingly innocent regular expressions > such as (a*, (a|b)). Ever since SGML, schema authors have been annoyed by this > restriction. This is one reason that XML Schema is hard to use. > > One standard validation technique is to construct string automata from content > models or tree automata from schemas. We only have to defeminize string or > tree automata or execute non-deterministic (string or tree) automata by simulating > all possibilities. > > It is true that creation of automata is expensive. For this reason, Jing and MSV > directly interpret content models by repeatedly rewriting content models. This > technique is called "derivatives of regular expressions" in formal computer science. > We can assume this technique as lazy construction of automata. This technique does > not require deterministic content models either. > > > Note: It has been recently pointed out that type inference becomes easier (i.e., the > time complexity becomes lower), if we use deterministic content models. On the other > hand, XDuce[2] does not use deterministic content models and still efficiently provides > type inference. > > The underlying theory of XML is tree automata. In the area of programming > language research (POPL), XDuce[2] uses tree automata for XML type inference. > In the area of theoretical database research (PODS), tree automata has become > the main stream for XML research (e.g., [3]). In the XML community, tree automata > has also been widely recognized [4]. I think that it is unfortunate that XML Schema > ignores this theory, since it hampers further progress of this area. > > [1] J.A. Brzozowski, Derivatives of Regular Expressions, Journal of ACM Vol. 11, No.4, > pp. 481-494, 1964. > [2] http://xduce.sourceforge.net/ > [3] http://citeseer.nj.nec.com/context/1741693/448486 > [4] http://www.oasis-open.org/cover/hedgeAutomata.html > From owner-ietf-xml-use Mon Apr 29 08:27:31 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3TFRVv08174 for ietf-xml-use-bks; Mon, 29 Apr 2002 08:27:31 -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 g3TFRTa08168 for ; Mon, 29 Apr 2002 08:27:29 -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 LAA07785 for ; Mon, 29 Apr 2002 11:27:48 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5YTMG>; Mon, 29 Apr 2002 11:27:25 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B9CD@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: ietf-xml-use@imc.org Subject: XML Guidelines -02 Date: Mon, 29 Apr 2002 11:27:22 -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've just sent the an updated XML guidelines Internet-Draft to the I-D administrator, and Paul Hoffman has graciously updated the web page containing the document in various forms. Here are links to the -02 document in various forms for your pre-announcement reading pleasure: Text: http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt HTML: http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html Differences between -02 and -01 (thanks again, Larry): http://www.imc.org/ietf-xml-use/xml-guide-diff.pdf -Scott- From owner-ietf-xml-use Mon Apr 29 10:29:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3THTCA13506 for ietf-xml-use-bks; Mon, 29 Apr 2002 10:29:12 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3THT9a13501 for ; Mon, 29 Apr 2002 10:29:09 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3THTBpP027845; Mon, 29 Apr 2002 10:29:11 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id KAA03995; Mon, 29 Apr 2002 10:29:10 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Mon, 29 Apr 2002 10:29:10 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: "Hollenbeck, Scott" cc: ietf-xml-use@imc.org Subject: Re: XML Guidelines -02 In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B9CD@vsvapostal3.bkup6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thank you Larry! :) I think the draft provides useful information but I also believe that the core of interoperability is the schema. Can we really ignore it? On Mon, 29 Apr 2002, Hollenbeck, Scott wrote: > > I've just sent the an updated XML guidelines Internet-Draft to the I-D > administrator, and Paul Hoffman has graciously updated the web page > containing the document in various forms. Here are links to the -02 > document in various forms for your pre-announcement reading pleasure: > > Text: > http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt > > HTML: > http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html > > Differences between -02 and -01 (thanks again, Larry): > http://www.imc.org/ietf-xml-use/xml-guide-diff.pdf > > -Scott- > From owner-ietf-xml-use Mon Apr 29 11:01:30 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TI1UC14802 for ietf-xml-use-bks; Mon, 29 Apr 2002 11:01:30 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TI1Ra14797 for ; Mon, 29 Apr 2002 11:01:27 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id EF2851030F for ; Mon, 29 Apr 2002 11:01:23 -0700 (PDT) Message-ID: <3CCD8A69.2010907@textuality.com> Date: Mon, 29 Apr 2002 11:01:13 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-xml-use@imc.org Subject: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is good stuff. The points below are mostly at the detail level. 4.2 Processing instructions Why take the trouble to discourage them? The syntax is such that they are easily ignored and need not disrupt the operation of any software module, and they can be awfully handy. 4.4 Validity and Extensibility It might be worthwhile to invest a sentence to dispel the too-common myth that when you've written your schema or DTD, you've finished defining your language. For any conceivable application, there are going to be semantic constraints on message content that are not expressable in a declarative schema. Furthermore, programmers who have to implement IETF protocols are highly dependent on human-readable prose explaining message semantics; don't give protocol designers an escape hatch to wiggle out of writing them down. I think however you should recommend that language designers SHOULD create a schema of some flavor or another; doing so is a valuable help to your design discipline. Finally, it might be worth pointing out that even if you specify many constraints via some sort of schema, it's perfectly reasonable to avoid doing schema validation at run-time, relying instead on ad-hoc code; the reasons being the possibly high compute expense of schema validation and the fact that you're probably going to have to do some hand-crafted semantic validation anyhow. 4.5 Namespaces WHile I don't disagree with the language, is there any way to put pressure on IETF to build some webspace for this purpose? Failing this, the effect is likely to be widespread use of URNs, which is not ideal practice for namespaces. 4.5.1 Namepaces and Attributes I don't understand the paragraph beginning "One practical way to deal with this..." so I suspect lots of others won't either. Maybe an example would help? The final paragraph "As described in XML Alternatives..." - does it really belong in this section? 4.6 Element & Attribute Design Considerations It's really useful to provide a list of the special characteristics that distinguish attributes from elements. The list is currently not quite right. First, there should be an item pointing out that unlike element content, attribute values are normalized (arguably a design error in XML, but we're stuck with it). Also the last point, "Attribue values can contain only simple XML data types" is a bit confusing. The phrase "simple XML data types" is language specific to XML schema. Obviously, an attribute value can be a URI or a date-time string or a library call number or a list of floating-point numbers, which are not simple at all. I think what you mean to say is that unlike elements, there is no XML markup provided for providing structure internal to an attribute that an XSML parser will catch. I really think that you'd do better to stay away from the elements-vs-attributes controversy. Little definitive can be said, and too much has already been said. In your case of your address type/value example, there are 4 possible permutations of element/attribute, and I could easily construct a cogent argumetn in favor of each of them. If you want to get discouraged, read http://xml.coverpages.org/elementsAndAttrs.html. Even better, don't read it, and don't try to make recommendations on this subject. 5.1 Character sets and encodings I'm not sure why protocols have to support both UTF8 and UTF16. I've seen scenarios where there are good application reasons to use only UTF8 or for that matter only USASCII. By definition, the XML processor won't care, but there are going to be other modules in the stream, and they shouldn't have to process multiple encodings unless there's a good reason to. 6. IANA consideration Might this be a good place to ask for some webspace to point namespace names at? Cheers, Tim Bray From owner-ietf-xml-use Mon Apr 29 13:36:58 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3TKawu22502 for ietf-xml-use-bks; Mon, 29 Apr 2002 13:36:58 -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 g3TKava22498 for ; Mon, 29 Apr 2002 13:36:57 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.33.108]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3U4GS426653; Mon, 29 Apr 2002 21:16:28 -0700 Message-Id: <5.1.0.14.2.20020429205540.0394e050@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 21:07:36 +0100 To: Tim Bray From: Graham Klyne Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Cc: ietf-xml-use@imc.org In-Reply-To: <3CCD8A69.2010907@textuality.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:01 AM 4/29/02 -0700, Tim Bray wrote: >4.2 Processing instructions > >Why take the trouble to discourage them? The syntax is such that they >are easily ignored and need not disrupt the operation of any software >module, and they can be awfully handy. Maybe the key point here is to discourage design of protocols that *depend* on PIs? >4.5.1 Namepaces and Attributes > >I don't understand the paragraph beginning "One practical way to deal with >this..." so I suspect lots of others won't either. Maybe an example would help? Ooops, I seem to recall suggesting these words! The experience I had in mind was that of the W3C RDF core working group, where certain attributes in the original RDF spec (ID=, about=, resource=) could sometimes be used with non-RDF-namespace elements. In order to be sure that the semantics were unambiguous, it turns out important to say that the attributes MUST be namespace qualified. But that example is a long way from protocol design, so I'm not sure how to translate it. >4.6 Element & Attribute Design Considerations > >It's really useful to provide a list of the special characteristics that >distinguish attributes from elements. The list is currently not quite >right. First, there should be an item pointing out that unlike element >content, attribute values are normalized (arguably a design error in XML, >but we're stuck with it). "normalized"? in what sense? (A simple XML spec reference will suffice.) >I really think that you'd do better to stay away from the >elements-vs-attributes controversy. Little definitive can be said, and >too much has already been said. In your case of your address type/value >example, there are 4 possible permutations of element/attribute, and I >could easily construct a cogent argumetn in favor of each of them. If you >want to get discouraged, read >http://xml.coverpages.org/elementsAndAttrs.html. Even better, don't read >it, and don't try to make recommendations on this subject. Interesting you should say this ;-) I've taken a view that attributes are better for expressing how to interpret some related element content, rather than for expressing content in their own right. So attributes like xml:lang= and xmlns:xx= make good sense to me. Using attributes as an alternative form of element content seems less so (apart from considerations of compactness). So my question: what sort of purpose were attributes *expected* to fulfill in the use of XML? #g ------------------- Graham Klyne From owner-ietf-xml-use Mon Apr 29 14:00:26 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TL0Qe25523 for ietf-xml-use-bks; Mon, 29 Apr 2002 14:00:26 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TL0Oa25515 for ; Mon, 29 Apr 2002 14:00:24 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id F069F10311; Mon, 29 Apr 2002 14:00:20 -0700 (PDT) Message-ID: <3CCDB459.4090600@textuality.com> Date: Mon, 29 Apr 2002 14:00:09 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne Cc: ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt References: <5.1.0.14.2.20020429205540.0394e050@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham Klyne wrote: > > Maybe the key point here is to discourage design of protocols that > *depend* on PIs? That makes excellent sense. >> 4.5.1 Namepaces and Attributes >> >> I don't understand the paragraph beginning "One practical way to deal >> with this..." so I suspect lots of others won't either. Maybe an >> example would help? > > Ooops, I seem to recall suggesting these words! > > The experience I had in mind was that of the W3C RDF core working group... I get it now. I think you just need to say that protocol designers have the choice of (a) requiring attributes be namespaced (b) requiring they not be namespaced (c) allowing either form and they MUST be explicit about which is the case, and they SHOULD stay away from option (c). I can see good cases for either (a) or (b). >> 4.6 Element & Attribute Design Considerations >> >> It's really useful to provide a list of the special characteristics >> that distinguish attributes from elements. The list is currently not >> quite right. First, there should be an item pointing out that unlike >> element content, attribute values are normalized (arguably a design >> error in XML, but we're stuck with it). > > "normalized"? in what sense? (A simple XML spec reference will suffice.) http://www.w3.org/TR/REC-xml#AVNormalize >> I really think that you'd do better to stay away from the >> elements-vs-attributes controversy. > > I've taken a view that attributes are better for expressing how to > interpret some related element content, rather than for expressing > content in their own right. So attributes like xml:lang= and xmlns:xx= > make good sense to me. Using attributes as an alternative form of > element content seems less so (apart from considerations of compactness). I think that the view you've taken, whichever it is, is irrelevant. XML provides no normative guidance as to the proper use. I repeat my assertion that I can argue either side of this issue convincingly. The bottom line is that XML provides two distinct ways of encoding structure (elements and attributes), that the two have some significant differences (which you should enumerate) and that history shows that language designers like having these two things and use them in the ways that seem good to them, and that software designed to pull information out of XML therefore MUST be able to pull information out of either elements or attributes on demand. Obviously, if you are encoding short strings which are going to be accessed by unique key with duplicates not allowed, this would suggest the use of attributes. If you are encoding unpredictable numbers of repeating instances of the same thing, this would suggest the use of elements. But I repeat, why waste your time trying to establish policy when 16 years of SGML and XML history has led to a complete lack of consensus in the community about what the best-practice guidelines are? > So my question: what sort of purpose were attributes *expected* to > fulfill in the use of XML? The people who designed XML, based on the 10 years of experience with SGML, knew perfectly well that there was no reliable decision procedure and thus correctly refrained from any commentary on the subject. IETF should do the same. -Tim From owner-ietf-xml-use Mon Apr 29 20:51:33 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3U3pX312966 for ietf-xml-use-bks; Mon, 29 Apr 2002 20:51:33 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U3pVa12960 for ; Mon, 29 Apr 2002 20:51:32 -0700 (PDT) Received: from RELAX (h223246.ppp.asahi-net.or.jp [61.114.223.246]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 7E4956D12 for ; Tue, 30 Apr 2002 12:51:24 +0900 (JST) Date: Tue, 30 Apr 2002 12:52:25 +0900 From: MURATA Makoto To: "'ietf-xml-use@imc.org'" Subject: Re: PIDF - using xml schema In-Reply-To: References: <20020426091159.8AD9.MURATA@hokkaido.email.ne.jp> Message-Id: <20020430124848.5420.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 25 Apr 2002 17:56:52 -0700 (PDT) "Yaron Y. Goland" wrote: > Is the issue - should the BCP recommend XML schema versus Relax NG? > Clearly we wish to pick one. Supporting both won't help interoperability. I still think that there are no reasons to pick one. Different protocols can use different ones without having any inconvertibility problems. > I realize that all of these criteria are subjective but just getting a > list out will at least help us to see how deep the pit the choice > represents is. I think that discussion based on these criteria will continue forever. Thus, I think that IETF should be stay away from such discussion. Cheers, Makoto From owner-ietf-xml-use Mon Apr 29 21:08:39 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3U48dL13651 for ietf-xml-use-bks; Mon, 29 Apr 2002 21:08:39 -0700 (PDT) Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U48ba13645 for ; Mon, 29 Apr 2002 21:08:37 -0700 (PDT) Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g3U46hHX015343 for ; Mon, 29 Apr 2002 21:06:43 -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.12.3/8.12.3) with ESMTP id g3U46oBA004278 for ; Mon, 29 Apr 2002 21:06:50 -0700 (PDT) Received: from larrypad ([130.248.184.138]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GVD4U700.UD5; Mon, 29 Apr 2002 21:08:31 -0700 Reply-To: From: "Larry Masinter" To: "'MURATA Makoto'" Cc: Subject: RE: PIDF - using xml schema Date: Mon, 29 Apr 2002 21:08:30 -0700 Message-ID: <000101c1effc$b04edd00$6ace8642@larrypad> 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, Build 10.0.3416 In-Reply-To: <20020430124848.5420.MURATA@hokkaido.email.ne.jp> 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: We've tried to address the controversy around recommending XML schema in the -02 document, without leaving readers without any guidance at all. Any comments on the actual wording in -02? Larry From owner-ietf-xml-use Mon Apr 29 21:56:01 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3U4u1Y15734 for ietf-xml-use-bks; Mon, 29 Apr 2002 21:56:01 -0700 (PDT) Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U4u0a15730 for ; Mon, 29 Apr 2002 21:56:00 -0700 (PDT) Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g3U4s6HX020687 for ; Mon, 29 Apr 2002 21:54:06 -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.12.3/8.12.3) with ESMTP id g3U4sDBA006551 for ; Mon, 29 Apr 2002 21:54:13 -0700 (PDT) Received: from larrypad ([130.248.184.138]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GVD71600.EX3; Mon, 29 Apr 2002 21:55:54 -0700 Reply-To: From: "Larry Masinter" To: "'Tim Bray'" Cc: Subject: RE: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Date: Mon, 29 Apr 2002 21:55:54 -0700 Message-ID: <000301c1f003$4f447860$6ace8642@larrypad> 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, Build 10.0.3416 In-Reply-To: <3CCD8A69.2010907@textuality.com> 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: > Why take the trouble to discourage them? The syntax is such that they > are easily ignored and need not disrupt the operation of any software > module, and they can be awfully handy. I think it's another kind of extensibility issue -- if you rely on processing instructions for a private extension, you can wind up with interoperability problems, because the processing instructions are an uncontrolled namespace. At least, that's the theory. "Are easily ignored and need not disrupt the operation of any software module and can be awfully handy" applied to tags, too. > 4.4 Validity and Extensibility > > It might be worthwhile to invest a sentence to dispel the too-common > myth that when you've written your schema or DTD, you've finished > defining your language. For any conceivable application, there are > going to be semantic constraints on message content that are not > expressable in a declarative schema. Furthermore, programmers who have > to implement IETF protocols are highly dependent on human-readable prose > explaining message semantics; don't give protocol designers an escape > hatch to wiggle out of writing them down. The first two sentences of the last paragraph of section 4.4... is there more we should say? > I think however you should recommend that language designers SHOULD > create a schema of some flavor or another; doing so is a > valuable help to your design discipline. Is paragraph 6 of section 4.4 "This document recommends that..." sufficient? > Finally, it might be worth pointing out that even if you specify many > constraints via some sort of schema, it's perfectly reasonable to avoid > doing schema validation at run-time, relying instead on ad-hoc code; the > reasons being the possibly high compute expense of schema validation and > the fact that you're probably going to have to do some hand-crafted > semantic validation anyhow. This is different advice from the wording from Chris Lilly that was incorporated in the last sentence of the last paragraph of section 4.4. Maybe the problem is "ideally" which isn't really implementation advice, but conceptual advice. > 4.5 Namespaces > > WHile I don't disagree with the language, is there any way to put > pressure on IETF to build some webspace for this purpose? RFC 2434 provides no way to ask IANA to maintain perpetual web space for IETF namespaces. I agree this might be an issue, but I can't see holding up this document for the resolution of what seems to be an independent mismatch of organizational roles. As has been discussed in the IETF/W3C coordination group, the issue isn't "build some webspace", it's "guarantee perpetual care of some webspace". In any case, the current wording is an attempt to let the resolution of the issue proceed independently. > 4.5.1 Namepaces and Attributes > > I don't understand the paragraph beginning "One practical way to deal > with this..." so I suspect lots of others won't either. Maybe > an example would help? Yes. > The final paragraph "As described in XML Alternatives..." - does it > really belong in this section? No. It probably belongs in 4.4 "Validity and Extensibility" > 4.6 Element & Attribute Design Considerations > > It's really useful to provide a list of the special characteristics that > distinguish attributes from elements. The list is currently not quite > right. First, there should be an item pointing out that unlike element > content, attribute values are normalized (arguably a design error in > XML, but we're stuck with it). Also the last point, "Attribue values > can contain only simple XML data types" is a bit confusing. > The phrase "simple XML data types" is language specific to XML schema. > Obviously, an attribute value can be a URI or a date-time string or a > library call number or a list of floating-point numbers, which are not > simple at all. > I think what you mean to say is that unlike elements, there is no XML > markup provided for providing structure internal to an attribute that an > XSML parser will catch. Yes, something like this. > I really think that you'd do better to stay away from the > elements-vs-attributes controversy. Little definitive can be said, and > too much has already been said. In your case of your address type/value > example, there are 4 possible permutations of element/attribute, and I > could easily construct a cogent argument in favor of each of them. If > you want to get discouraged, read > http://xml.coverpages.org/elementsAndAttrs.html. Even better, don't > read it, and don't try to make recommendations on this subject. I think we have some obligation to point out the difficult issues, and tell people what they are, even if we avoid making specific advice. "One persistent design issue with XML that protocol designers will encounter is the decision of how to code data structures with elements or attributes. This section gives a flavor for some of the considerations, although much more has been written about the topic. ...." and then give enough examples to convince the reader that there actually is an issue. > 5.1 Character sets and encodings > > I'm not sure why protocols have to support both UTF8 and UTF16. I've > seen scenarios where there are good application reasons to use only UTF8 > or for that matter only USASCII. By definition, the XML processor won't > care, but there are going to be other modules in the stream, and they > shouldn't have to process multiple encodings unless there's a good > reason to. RFC 2277 makes a strong case for UTF-8. It's hard to imagine scenarios in IETF standards-track protocols that only allows US ASCII. I suppose that mandating UTF-16 might add additional burden, and that "XML compatibility" doesn't actually mandate that other protocols allow UTF-16. However, in any situation where the output of XML processors might be UTF-16, you'd have to provide a transcoder. > 6. IANA consideration > > Might this be a good place to ask for some webspace to point > namespace names at? If IANA considerations allowed for one to petition for perpetual care web space, it would be. Again, I think we should handle this issue outside of this document. From owner-ietf-xml-use Tue Apr 30 02:13:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3U9DZ521529 for ietf-xml-use-bks; Tue, 30 Apr 2002 02:13:35 -0700 (PDT) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U9DXa21522 for ; Tue, 30 Apr 2002 02:13:33 -0700 (PDT) Received: from RELAX (h223246.ppp.asahi-net.or.jp [61.114.223.246]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 48E906D4F for ; Tue, 30 Apr 2002 18:13:32 +0900 (JST) Date: Tue, 30 Apr 2002 18:14:23 +0900 From: MURATA Makoto To: ietf-xml-use@imc.org Subject: Re: PIDF - using xml schema In-Reply-To: <000101c1effc$b04edd00$6ace8642@larrypad> References: <20020430124848.5420.MURATA@hokkaido.email.ne.jp> <000101c1effc$b04edd00$6ace8642@larrypad> Message-Id: <20020430175144.5423.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 29 Apr 2002 21:08:30 -0700 "Larry Masinter" wrote: > We've tried to address the controversy around recommending > XML schema in the -02 document, without leaving readers > without any guidance at all. > > Any comments on the actual wording in -02? I can live with the latest wording about the controversy. It might be a good idea to add some discussion about default values and entity declarations of DTDs as well as infoset contributions of XML Schema. These features make it impossible to safely eliminate validation, since they change the elements and attributes returned by XML parsers. I would propose to discourage such features wherever possible. Cheers, -- MURATA Makoto From owner-ietf-xml-use Tue Apr 30 06:31:37 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UDVb405652 for ietf-xml-use-bks; Tue, 30 Apr 2002 06:31:37 -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 g3UDVZa05637 for ; Tue, 30 Apr 2002 06:31:35 -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 JAA19013 for ; Tue, 30 Apr 2002 09:31:54 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5ZBT8>; Tue, 30 Apr 2002 09:31:31 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B9D9@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'ietf-xml-use@imc.org'" Subject: FW: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-02.txt Date: Tue, 30 Apr 2002 09:31:21 -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: Here's the formal announcement for -02. Larry, Marshall, and I would like to try to wrap this document up in the very near future. To that end, we'd like to issue a one-week "last call" on the document with comments due to the list no later than Wednesday 8 May 2002. We'll review whatever comes in, edit the document as needed, publish an update if needed, and then ask the IESG to review the document (and issue an IETF last call) for publication as an RFC. Does this give the TAG enough time to complete their review? We can be flexible... -Scott- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 30, 2002 7:15 AM To: IETF-Announce; @loki.ietf.org Subject: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-02.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-02.txt Pages : 28 Date : 29-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 being developed; 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-02. 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-02.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-02.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 30 07:18:27 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UEIRb08925 for ietf-xml-use-bks; Tue, 30 Apr 2002 07:18:27 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UEIPa08921 for ; Tue, 30 Apr 2002 07:18:25 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UEHKqB007260; Tue, 30 Apr 2002 10:17:20 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UEHK7P007259; Tue, 30 Apr 2002 10:17:20 -0400 (EDT) Date: Tue, 30 Apr 2002 10:17:19 -0400 From: Michael Mealling To: Tim Bray Cc: ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430101719.K1904@bailey.dscga.com> Reply-To: Michael Mealling References: <3CCD8A69.2010907@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CCD8A69.2010907@textuality.com> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 29, 2002 at 11:01:13AM -0700, Tim Bray wrote: > 4.5 Namespaces > > WHile I don't disagree with the language, is there any way to put > pressure on IETF to build some webspace for this purpose? Failing this, > the effect is likely to be widespread use of URNs, which is not ideal > practice for namespaces. Could you please either explain or point to a discussion that says why it isn't ideal? The Namespaces Rec uses them all over the place and specifically says: "The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals." I wrote draft-mealling-iana-xmlns-registry to use URNs for IETF created XML namespaces specifically because the IANA and the IESG didn't want to create yet another single point of failure by turning some portion of either the IANA or IETF webspace into a downloadable schema server. I'm in the process of updating draft-mealling-iana-xmlns-registry and I'd like to pull this meme out into the open instead of leaving it in the realm of FUD. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 07:25:23 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UEPNV09085 for ietf-xml-use-bks; Tue, 30 Apr 2002 07:25:23 -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 g3UEPLa09081 for ; Tue, 30 Apr 2002 07:25:21 -0700 (PDT) Received: (qmail 11271 invoked by uid 0); 30 Apr 2002 14:25:16 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp002-rz3) with SMTP; 30 Apr 2002 14:25:16 -0000 From: "Julian Reschke" To: "Michael Mealling" , "Tim Bray" Cc: Subject: RE: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Date: Tue, 30 Apr 2002 16:25:10 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020430101719.K1904@bailey.dscga.com> 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 Michael Mealling > Sent: Tuesday, April 30, 2002 4:17 PM > To: Tim Bray > Cc: ietf-xml-use@imc.org > Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt > > > > On Mon, Apr 29, 2002 at 11:01:13AM -0700, Tim Bray wrote: > > 4.5 Namespaces > > > > WHile I don't disagree with the language, is there any way to put > > pressure on IETF to build some webspace for this purpose? > Failing this, > > the effect is likely to be widespread use of URNs, which is not ideal > > practice for namespaces. > > Could you please either explain or point to a discussion that says why it > isn't ideal? The Namespaces Rec uses them all over the place and > specifically says: > > "The namespace name, to serve its intended purpose, should have the > characteristics of uniqueness and persistence. It is not a goal > that it be > directly usable for retrieval of a schema (if any exists). An > example of a > syntax that is designed with these goals in mind is that for > Uniform Resource > Names [RFC2141]. However, it should be noted that ordinary URLs > can be managed > in such a way as to achieve these same goals." > > I wrote draft-mealling-iana-xmlns-registry to use URNs for IETF created > XML namespaces specifically because the IANA and the IESG didn't want > to create yet another single point of failure by turning some portion > of either the IANA or IETF webspace into a downloadable schema server. What has a namespace name being an HTTP URL to do with any kind of downloads of schemas? Even if the namespace name uses the http: scheme, it's still just a name, right? Even if a piece of software decides to access it, this MUST not be critical for what the namespace name is for (identifying names). From owner-ietf-xml-use Tue Apr 30 07:41:19 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UEfJ209507 for ietf-xml-use-bks; Tue, 30 Apr 2002 07:41:19 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UEfIa09503 for ; Tue, 30 Apr 2002 07:41:18 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UEe6qB007338; Tue, 30 Apr 2002 10:40:07 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UEe6lh007337; Tue, 30 Apr 2002 10:40:06 -0400 (EDT) Date: Tue, 30 Apr 2002 10:40:05 -0400 From: Michael Mealling To: Julian Reschke Cc: Michael Mealling , Tim Bray , ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430104005.L1904@bailey.dscga.com> Reply-To: Michael Mealling References: <20020430101719.K1904@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 30, 2002 at 04:25:10PM +0200, Julian Reschke wrote: > > From: owner-ietf-xml-use@mail.imc.org > > [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Michael Mealling > > Sent: Tuesday, April 30, 2002 4:17 PM > > To: Tim Bray > > Cc: ietf-xml-use@imc.org > > Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt > > > > On Mon, Apr 29, 2002 at 11:01:13AM -0700, Tim Bray wrote: > > > 4.5 Namespaces > > > > > > WHile I don't disagree with the language, is there any way to put > > > pressure on IETF to build some webspace for this purpose? > > Failing this, > > > the effect is likely to be widespread use of URNs, which is not ideal > > > practice for namespaces. > > > > Could you please either explain or point to a discussion that says why it > > isn't ideal? The Namespaces Rec uses them all over the place and > > specifically says: > > > > "The namespace name, to serve its intended purpose, should have the > > characteristics of uniqueness and persistence. It is not a goal > > that it be > > directly usable for retrieval of a schema (if any exists). An > > example of a > > syntax that is designed with these goals in mind is that for > > Uniform Resource > > Names [RFC2141]. However, it should be noted that ordinary URLs > > can be managed > > in such a way as to achieve these same goals." > > > > I wrote draft-mealling-iana-xmlns-registry to use URNs for IETF created > > XML namespaces specifically because the IANA and the IESG didn't want > > to create yet another single point of failure by turning some portion > > of either the IANA or IETF webspace into a downloadable schema server. > > What has a namespace name being an HTTP URL to do with any kind of downloads > of schemas? Even if the namespace name uses the http: scheme, it's still > just a name, right? Even if a piece of software decides to access it, this > MUST not be critical for what the namespace name is for (identifying names). First let me say this: The issue for me isn't to say that 'http:' is a bad choice for an XML Namespace name scheme. I use 'em all the time for certain things. The issue is whether or not 'urn:' is bad as Tim states and what the IETF wishes to do given its design principles and the way it does its job. Now, there is intent and then there is real world use. Regardless of what people in either the IETF or W3C may say about 'http:' being able to be treated as just an identifier (all URIs have this feature), the fact that it has 'http:' in the front has come to mean that is is 'GET-able' and that the attempt can and will be made. If it succeeds then it will be relied on to succeed in the future. So, within the people I talked to in the IETF, the IESG and specifically the IANA, the concensus was that creating a section of web space for things like this was a bad idea because it would create an operational expectation for the IANA and for the IETF that neither party was willing to accept (from an operational and design aspect). So, again, the question isn't suggesting that 'http:' based XML Namespace names are a bad thing. I'm merely trying to clear up the FUD about URNs being bad.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 07:52:31 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UEqVc09793 for ietf-xml-use-bks; Tue, 30 Apr 2002 07:52:31 -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 g3UEqTa09789 for ; Tue, 30 Apr 2002 07:52:29 -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 g3UEqPg08668; Tue, 30 Apr 2002 10:52:25 -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: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt From: "Simon St.Laurent" To: Michael Mealling Cc: Tim Bray , ietf-xml-use@imc.org In-Reply-To: <20020430101719.K1904@bailey.dscga.com> References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 10:58:02 -0400 Message-Id: <1020178683.984.16.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-30 at 10:17, Michael Mealling wrote: > Could you please either explain or point to a discussion that says why it > isn't ideal? The Namespaces Rec uses them all over the place and > specifically says: > > "The namespace name, to serve its intended purpose, should have the > characteristics of uniqueness and persistence. It is not a goal that it be > directly usable for retrieval of a schema (if any exists). An example of a > syntax that is designed with these goals in mind is that for Uniform Resource > Names [RFC2141]. However, it should be noted that ordinary URLs can be managed > in such a way as to achieve these same goals." I think it may just be that the XML community has sufferered too many years of endless what-do-URIs-add-to-namespaces debates since this was written. At its foundation, I think the decision to use URIs generically as namespace identifiers was disastrous. I'm not sure I've seen a canonical explanation of why URNs are evil, but you might look at http://rddl.org for some explanation of why more transparent approaches are preferable. To the extent that DDDS and similar services can provide RDDL-like information about namespaces identified with URNs, my opposition drops. It might or might not be interesting for the IETF to discuss such namespace processing either here or in a separate document. -- 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 30 08:04:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UF4Gc10126 for ietf-xml-use-bks; Tue, 30 Apr 2002 08:04:16 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UF4Fa10122 for ; Tue, 30 Apr 2002 08:04:15 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UF3BqB007422; Tue, 30 Apr 2002 11:03:11 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UF3AAm007421; Tue, 30 Apr 2002 11:03:10 -0400 (EDT) Date: Tue, 30 Apr 2002 11:03:10 -0400 From: Michael Mealling To: "Simon St.Laurent" Cc: Michael Mealling , Tim Bray , ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430110310.M1904@bailey.dscga.com> Reply-To: Michael Mealling References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <1020178683.984.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020178683.984.16.camel@localhost.localdomain> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 30, 2002 at 10:58:02AM -0400, Simon St.Laurent wrote: > On Tue, 2002-04-30 at 10:17, Michael Mealling wrote: > > Could you please either explain or point to a discussion that says why it > > isn't ideal? The Namespaces Rec uses them all over the place and > > specifically says: > > > > "The namespace name, to serve its intended purpose, should have the > > characteristics of uniqueness and persistence. It is not a goal that it be > > directly usable for retrieval of a schema (if any exists). An example of a > > syntax that is designed with these goals in mind is that for Uniform Resource > > Names [RFC2141]. However, it should be noted that ordinary URLs can be managed > > in such a way as to achieve these same goals." > > I think it may just be that the XML community has sufferered too many > years of endless what-do-URIs-add-to-namespaces debates since this was > written. At its foundation, I think the decision to use URIs > generically as namespace identifiers was disastrous. I wouldn't say disastrous. I would just call it incomplete. The lineage from SGML (FPIs) to XML (URIs) just wasn't finished..... > I'm not sure I've seen a canonical explanation of why URNs are evil, but > you might look at http://rddl.org for some explanation of why more > transparent approaches are preferable. To the extent that DDDS and > similar services can provide RDDL-like information about namespaces > identified with URNs, my opposition drops. If that is what's required for an application then it is possible to take a URN (or any URI if you're using the DDDS method) and resolve it to some RDDL information about that URI. But the question is still whether or not a URN is a bad namespace name (assuming you don't have other specific application needs). > It might or might not be interesting for the IETF to discuss such > namespace processing either here or in a separate document. Sure. I'm in the process of writing that document using RESCAP.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 08:14:33 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UFEXn10472 for ietf-xml-use-bks; Tue, 30 Apr 2002 08:14:33 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UFEWa10468 for ; Tue, 30 Apr 2002 08:14:32 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id LAA18540; Tue, 30 Apr 2002 11:21:45 -0400 Date: Tue, 30 Apr 2002 11:21:45 -0400 From: Mark Baker To: "Hollenbeck, Scott" Cc: "'ietf-xml-use@imc.org'" Subject: Re: FW: I-D ACTION:draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430112145.F7782@www.markbaker.ca> References: <3CD14E451751BD42BA48AAA50B07BAD60189B9D9@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B9D9@vsvapostal3.bkup6>; from shollenbeck@verisign.com on Tue, Apr 30, 2002 at 09:31:21AM -0400 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for sending my earlier comments to the wrong list (ietf-xml-mime), but there was a brief discussion there between the usual suspects that I don't see reflected in -02. (not to mention the URN bashing 8-) My message which kicked it off was; http://www.imc.org/ietf-xml-mime/mail-archive/msg00791.html I'll attempt to summarize the discussion; - some concern over recommendation to use "application/xml" from myself, and Tim Bray, but met with push back from Keith - the use of "+xml" should at least be mentioned, if not recommended, where appropriate (per RFC 3023 sec 7.1) - "text/xml" should be explicitly not recommended MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From owner-ietf-xml-use Tue Apr 30 09:26:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UGQGb12473 for ietf-xml-use-bks; Tue, 30 Apr 2002 09:26:16 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UGQ5a12468 for ; Tue, 30 Apr 2002 09:26:13 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3UGQ6pP009589; Tue, 30 Apr 2002 09:26:06 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id JAA18056; Tue, 30 Apr 2002 09:26:05 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Tue, 30 Apr 2002 09:26:04 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: "Simon St.Laurent" cc: Michael Mealling , Tim Bray , Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt In-Reply-To: <1020178683.984.16.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: While I agree that using a HTTP URL is sub-optimal for an XML namespaces due to the expectation that it can be de-referenced I have never had any sort of operational problem using URNs or other URIs in deployed XML protocols. Since it sounds like this issue has been beaten to death I wonder if any of those opposing the use of URIs has any articles that explain the issue in the context of protocols. RDDL is neat in that it provides a single point of description but it is really most applicable for long lived XML documents, not protocol messages. In a protocol one doesn't generally provide too much data describing the message. Rather one sends along (ideally) a single identifier that says "I am defined by X" and either the destination understands X or the communication fails. (NOTE: I am not talking about 'ignore this if you don't understand it' functionality) Generally speaking the destination won't even try to de-reference X to see if it can 'dynamically support' the protocol because there are just too many semantic issues that can not be programmatically expressed. There may be exceptions some day where de-referencing X might produce XSL transforms that can be applied to the incoming message to translate it to a known format but for the foreseable future that is generally not a workable strategy due to subtle variations in meaning between the source and destination protocol message formats. So I strongly doubt you would ever see a RDDL being sent inside of a protocol communication. It would be useful, however, inside of various schema documents (e.g. SOAP, WSDL, UDDI, etc.). I think we should keep in mind that this document is not meant as a general description of good XML behavior, it is specifically meant as a description of good XML protocol behavior and hence restrictions that would not necessarily make sense generally do make sense here. Yaron P.S. It is in the sense of the previous paragraph that I think it fine to recommend against the use of attributes in this document. The attributes vs. element debate has occured in the general XML context. This is not the general XML context. This is the 'use of XML in protocol messages' context. A much more restricted world. Just as such a world is served just fine by a single URI as the XML namespace so it is best served via attributes not elements. Due to the long deployment times of protocols it is necessary when extending them to ensure that it can be done in a backwards compatible way. Think of HTTP where one can throw in a new header and the worst thing that happens is that the header is ignored. The ability to throw in a new command with a 'ignore this if you don't understand it' semantic is that it means you don't have to first negotiate with the person you are talking to in order to find out if they support the new command you want to send. This is critical in protocols because round trips take a long time. While bandwidth may be forever increasing the speed of light isn't going anywhere. So optimizing for latency is going to be the primary protocol design challenge, pretty much forever. As I discuss in http://www.goland.org/rpc.htm it takes 0.04 seconds for a beam of light to travel from one point on the equator to it's opposite point and that assumes that a hole has been drilled through the middle of the earth and filled with a perfect vacuum. On 30 Apr 2002, Simon St.Laurent wrote: > > On Tue, 2002-04-30 at 10:17, Michael Mealling wrote: > > Could you please either explain or point to a discussion that says why it > > isn't ideal? The Namespaces Rec uses them all over the place and > > specifically says: > > > > "The namespace name, to serve its intended purpose, should have the > > characteristics of uniqueness and persistence. It is not a goal that it be > > directly usable for retrieval of a schema (if any exists). An example of a > > syntax that is designed with these goals in mind is that for Uniform Resource > > Names [RFC2141]. However, it should be noted that ordinary URLs can be managed > > in such a way as to achieve these same goals." > > I think it may just be that the XML community has sufferered too many > years of endless what-do-URIs-add-to-namespaces debates since this was > written. At its foundation, I think the decision to use URIs > generically as namespace identifiers was disastrous. > > I'm not sure I've seen a canonical explanation of why URNs are evil, but > you might look at http://rddl.org for some explanation of why more > transparent approaches are preferable. To the extent that DDDS and > similar services can provide RDDL-like information about namespaces > identified with URNs, my opposition drops. > > It might or might not be interesting for the IETF to discuss such > namespace processing either here or in a separate document. > > -- > 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 30 09:36:21 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UGaLJ12747 for ietf-xml-use-bks; Tue, 30 Apr 2002 09:36:21 -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 g3UGaJa12743 for ; Tue, 30 Apr 2002 09:36:19 -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 g3UGaFg14194; Tue, 30 Apr 2002 12:36:15 -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: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt From: "Simon St.Laurent" To: "Yaron Y. Goland" Cc: Michael Mealling , Tim Bray , ietf-xml-use@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 12:41:53 -0400 Message-Id: <1020184914.2161.49.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-30 at 12:26, Yaron Y. Goland wrote: > RDDL is neat in that it provides a single point of description but it is > really most applicable for long lived XML documents, not protocol > messages. I'm not sure the lifespan of the message has any bearing on whether RDDL is useful. I'd guess the lifespan of the protocol has much more bearing, especially if short-lived messages that all contain the XML documents using the same namespaces are sent on a regular basis. -- 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 30 09:40:17 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UGeHO12835 for ietf-xml-use-bks; Tue, 30 Apr 2002 09:40:17 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UGeFa12829 for ; Tue, 30 Apr 2002 09:40:16 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 0679B102DA; Tue, 30 Apr 2002 09:40:11 -0700 (PDT) Message-ID: <3CCEC8E0.4010703@textuality.com> Date: Tue, 30 Apr 2002 09:40:00 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Mealling Cc: ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Mealling wrote: >>WHile I don't disagree with the language, is there any way to put >>pressure on IETF to build some webspace for this purpose? Failing this, >>the effect is likely to be widespread use of URNs, which is not ideal >>practice for namespaces. > > Could you please either explain or point to a discussion that says why it > isn't ideal? The Namespaces Rec uses them all over the place and > specifically says: To meet the goals of the namespace REC, there is no requirement that "namespace documents" - what you get by dereferencing a namespace name, if possible - exist. But lots of people create them and they seem to be useful. Based on this observation, recently the W3C TAG took up the question and has made pretty good progress. My position paper on the issue may be found at http://www.textuality.com/tag/Issue8.html While this doesn't represent TAG consensus yet, I suspect we are going achieve consensus on something including many of these points. To summarize the case against URNs: It's good for namespace documents exist, and it's good for them to be available, and most people can't dereference URNs. -Tim From owner-ietf-xml-use Tue Apr 30 09:55:49 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UGtnK13197 for ietf-xml-use-bks; Tue, 30 Apr 2002 09:55:49 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UGtla13193 for ; Tue, 30 Apr 2002 09:55:48 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 2B0E9102DA for ; Tue, 30 Apr 2002 09:55:44 -0700 (PDT) Message-ID: <3CCECC85.8000501@textuality.com> Date: Tue, 30 Apr 2002 09:55:33 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yaron Y. Goland wrote: > P.S. It is in the sense of the previous paragraph that I think it fine to > recommend against the use of attributes in this document. The attributes > vs. element debate has occured in the general XML context. This is not the > general XML context. This is the 'use of XML in protocol messages' > context. A much more restricted world. Just as such a world is served just > fine by a single URI as the XML namespace so it is best served via > attributes not elements. Due to the long deployment times of protocols it > is necessary when extending them to ensure that it can be done in a > backwards compatible way. > > Think of HTTP where one can throw in a new header and the worst thing that > happens is that the header is ignored. Why are elements more extensible and easier to ignore than attributes? -Tim From owner-ietf-xml-use Tue Apr 30 10:12:54 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UHCsS13766 for ietf-xml-use-bks; Tue, 30 Apr 2002 10:12:54 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UHCqa13761 for ; Tue, 30 Apr 2002 10:12:52 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UHBmqB007763; Tue, 30 Apr 2002 13:11:49 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UHBlT8007762; Tue, 30 Apr 2002 13:11:47 -0400 (EDT) Date: Tue, 30 Apr 2002 13:11:47 -0400 From: Michael Mealling To: Tim Bray Cc: Michael Mealling , ietf-xml-use@imc.org, www-tag@w3.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430131147.N1904@bailey.dscga.com> Reply-To: Michael Mealling References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <3CCEC8E0.4010703@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CCEC8E0.4010703@textuality.com> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 30, 2002 at 09:40:00AM -0700, Tim Bray wrote: > Michael Mealling wrote: > >>While I don't disagree with the language, is there any way to put > >>pressure on IETF to build some webspace for this purpose? Failing this, > >>the effect is likely to be widespread use of URNs, which is not ideal > >>practice for namespaces. > > > >Could you please either explain or point to a discussion that says why it > >isn't ideal? The Namespaces Rec uses them all over the place and > >specifically says: > > To meet the goals of the namespace REC, there is no requirement that > "namespace documents" - what you get by dereferencing a namespace name, > if possible - exist. But lots of people create them and they seem to be > useful. Based on this observation, recently the W3C TAG took up the > question and has made pretty good progress. My position paper on the > issue may be found at > > http://www.textuality.com/tag/Issue8.html > > While this doesn't represent TAG consensus yet, I suspect we are going > achieve consensus on something including many of these points. > > To summarize the case against URNs: It's good for namespace documents > exist, and it's good for them to be available, and most people can't > dereference URNs. -Tim But doesn't all of that depend on the application? Let's assume that the CNRP group updated the CNRP specification and made it into a namespace. The IETF has been pretty much opposed to putting document locations like that in standards (for good reasons that some in the W3C might disagree with). The CNRP Working Group would use a URN as a way to ensure that the name _NOT_ be dereferenced through the IETF or IANA web sites but instead through some local catalog/EntityResolver. I.e. we want to use URNs specifically because they're not usually dereferenced and we have good and valid reasons for not wanting to do that. There are mechanisms for discovering information about a URN but the URN itself doesn't define it and thus create that expectation. Hmm.... looking at your document the logic used to get to the idea that URNs are bad for Namespace names is kind of circular. You assume that since a large portion of people use 'http:' scheme namespace names that those users might think they are retrievable. Since there is that assumption then we should all use 'http:' scheme names. What if I _DON'T_ want the namespace name to be resolvable by a conscious decision? Even still you also assert that namespace names aren't frequently dereferenced at run-time. So the value of saying URNs are bad is even less evident. Either they're dereferenced or they're not.... I guess for me (and many on the URI-IG Group) the question comes down to this: are URIs generic for the web or not? If they are then the TAG should make sure that the web's architecture is scheme agnostic. It might make statements about what semantics it might require of a scheme but, IMNSHO, for robustness and generality, the TAG's output shouldn't make statements about what schemes it happens to like or dislike. -MM P.S. I though the TAG was going to defer to the URI group URI related issues? At least that's they way it was represented to me.... -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 10:32:20 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UHWKP14237 for ietf-xml-use-bks; Tue, 30 Apr 2002 10:32:20 -0700 (PDT) Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UHWKa14233 for ; Tue, 30 Apr 2002 10:32:20 -0700 (PDT) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g3UHVapU010723 for ; Tue, 30 Apr 2002 10:31:36 -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.3/8.12.3) with ESMTP id g3UHTdQG013684 for ; Tue, 30 Apr 2002 10:29:40 -0700 (PDT) Received: from larrypad ([153.32.66.179]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GVE61R00.JNI for ; Tue, 30 Apr 2002 10:32:15 -0700 Reply-To: From: "Larry Masinter" To: Subject: Please set subject line on messages Date: Tue, 30 Apr 2002 10:32:04 -0700 Message-ID: <001401c1f06c$f1df6c10$b3422099@larrypad> 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, Build 10.0.3416 In-Reply-To: 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 would help for tracking issues if you would try to use subject lines on your comments. From owner-ietf-xml-use Tue Apr 30 10:44:00 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UHi0914504 for ietf-xml-use-bks; Tue, 30 Apr 2002 10:44:00 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UHhsa14498 for ; Tue, 30 Apr 2002 10:43:58 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3UHhupP014761; Tue, 30 Apr 2002 10:43:56 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id KAA18850; Tue, 30 Apr 2002 10:43:55 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Tue, 30 Apr 2002 10:43:54 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: Tim Bray cc: ietf-xml-use@imc.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt In-Reply-To: <3CCECC85.8000501@textuality.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Why are elements more extensible and easier to ignore than attributes? -Tim > I agree that attributes are just as easy to ignore as elements. The issue is extensions. As for extensions, the issue is scope. If I have an attribute "foo='bar'" and I want to add in the extension BAZ there is no way to do in the attribute. The best I can do is add another attribute that says something like "fooext='baz'". But when I want to add yet another extension I have already used fooext so now I have to introduce fooext2 and so on. Furthermore it may not always be clear which extensions goes with which attribute. For example, I may have an extension that could apply to foo or blah so what do I make of "foo='bar' blah='ick' ext='3'" To which one does ext apply? We can, of course, come up with naming conventions. Maybe "foo='bar' blah='ick' ext.foo='3'" or maybe we can come up with syntax conventions "foo='bar' blah='ick' ext='foo;3'" or maybe we can just use XML elements. bar3ick Using attributes doesn't make it impossible to make a system extensible, it just requires one to re-invent all the features already provided by XML elements. As an essentially lazy person if someone has already done all the work I would rather use it then re-invent it. Yaron From owner-ietf-xml-use Tue Apr 30 11:33:41 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIXfG15486 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:33:41 -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 g3UIXda15482 for ; Tue, 30 Apr 2002 11:33:39 -0700 (PDT) Received: (qmail 12705 invoked by uid 0); 30 Apr 2002 18:33:36 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp001-rz3) with SMTP; 30 Apr 2002 18:33:36 -0000 From: "Julian Reschke" To: Subject: draft 02, XML declarations Date: Tue, 30 Apr 2002 20:33:33 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCEC8E0.4010703@textuality.com> Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: " In general, an XML protocol element should either disallow XML declarations ("MUST NOT be used") or require one ("MUST have"). A design which allows but does not require an XML declaration leads to unreliable implementations. When in doubt, require an XML declaration." 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. From owner-ietf-xml-use Tue Apr 30 11:35:14 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIZEJ15544 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:35:14 -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 g3UIZCa15540 for ; Tue, 30 Apr 2002 11:35:13 -0700 (PDT) Received: (qmail 4097 invoked by uid 0); 30 Apr 2002 18:35:09 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp004-rz3) with SMTP; 30 Apr 2002 18:35:09 -0000 From: "Julian Reschke" To: Subject: draft 02, processing instructions Date: Tue, 30 Apr 2002 20:35:09 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCEC8E0.4010703@textuality.com> Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "...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." 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. From owner-ietf-xml-use Tue Apr 30 11:38:17 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UIcHP15588 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:38:17 -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 g3UIcFa15584 for ; Tue, 30 Apr 2002 11:38:16 -0700 (PDT) Received: (qmail 4901 invoked by uid 0); 30 Apr 2002 18:38:12 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp007-rz3) with SMTP; 30 Apr 2002 18:38:12 -0000 From: "Julian Reschke" To: Subject: draft 02, Well-Formedness Date: Tue, 30 Apr 2002 20:38:12 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCEC8E0.4010703@textuality.com> Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Given that XML requires well-formedness, XML parsers are typically intolerant of well-formedness errors. Protocol designers need to recognize this limitation and provide specific guidelines for recovery when malformed data is encountered." "typically" is misleading here. A parser that is "tolerant" isn't an XML parser at all. "Protocol designers need to recognize this limitation and provide specific guidelines for recovery when malformed data is encountered." -> I think this is misleading is well. If the supposed-to-be-XML content in the request isn't wellformed, there's no way to recover. It's just a Bad Request. If that's what the draft intends to say, it should be clarified. From owner-ietf-xml-use Tue Apr 30 11:42:17 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIgHs15695 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:42:17 -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 g3UIgFa15691 for ; Tue, 30 Apr 2002 11:42:16 -0700 (PDT) Received: (qmail 21451 invoked by uid 0); 30 Apr 2002 18:42:12 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp009-rz3) with SMTP; 30 Apr 2002 18:42:12 -0000 From: "Julian Reschke" To: Subject: draft 02, binary data Date: Tue, 30 Apr 2002 20:42:11 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCEC8E0.4010703@textuality.com> Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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). (*) Control characters except TAB, CR and LF are not allowed in XML content. From owner-ietf-xml-use Tue Apr 30 11:50:21 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIoL315868 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:50:21 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIoJa15864 for ; Tue, 30 Apr 2002 11:50:19 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id D149F102DA; Tue, 30 Apr 2002 11:50:14 -0700 (PDT) Message-ID: <3CCEE75C.9020409@textuality.com> Date: Tue, 30 Apr 2002 11:50:04 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Cc: ietf-xml-use@imc.org Subject: Re: draft 02, XML declarations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julian Reschke wrote: > " In general, an XML protocol element should either disallow XML > declarations ("MUST NOT be used") or require one ("MUST have"). A design > which allows but does not require an XML declaration leads to unreliable > implementations. When in doubt, require an XML declaration." > > 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. The issue isn't the parser, it's the serializer. At the moment, it's my belief that every serializer on the planet writes an XML decl. Another point is that in many cases someone building protocol code won't be using an off-the-shelf serializer, they'll be writing a few printf() or System.println() or whatever calls; in this case, guidance from the protocol designer as to whether or not to put in the XML decl is clearly a good thing. Summary: I see your point, but I think that the language in draft-02 is sensible and helpful and I'd like to see it stay. -Tim From owner-ietf-xml-use Tue Apr 30 11:59:10 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UIxAp16095 for ietf-xml-use-bks; Tue, 30 Apr 2002 11:59:10 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIx8a16090 for ; Tue, 30 Apr 2002 11:59:08 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 4F25F102DA for ; Tue, 30 Apr 2002 11:59:05 -0700 (PDT) Message-ID: <3CCEE96E.8090707@textuality.com> Date: Tue, 30 Apr 2002 11:58:54 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-xml-use@imc.org Subject: Re: -guidelines-02.txt: elements/attributes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yaron Y. Goland wrote: >>Why are elements more extensible and easier to ignore than attributes? -Tim > > I agree that attributes are just as easy to ignore as elements. The issue > is extensions. > > As for extensions, the issue is scope. I take your arguments, but I don't see how they apply especially to protocols as opposed to XML in the general case. I'll avoid arguing the other side of the issue, and note only that a lot of smart people have had this argument for a decade and a half and failed to reach consensus. I think that Larry's recent note here got it right: explain the differences so protocol designers get the issues, then let 'em do what they want, because they will anyhow. -Tim From owner-ietf-xml-use Tue Apr 30 12:01:02 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UJ12A16178 for ietf-xml-use-bks; Tue, 30 Apr 2002 12:01:02 -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 g3UJ10a16165 for ; Tue, 30 Apr 2002 12:01:00 -0700 (PDT) Received: (qmail 16175 invoked by uid 0); 30 Apr 2002 19:00:56 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp016-rz3) with SMTP; 30 Apr 2002 19:00:56 -0000 From: "Julian Reschke" To: Subject: RE: draft 02, XML declarations Date: Tue, 30 Apr 2002 21:00:54 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCEE75C.9020409@textuality.com> 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 Tim Bray > Sent: Tuesday, April 30, 2002 8:50 PM > To: Julian Reschke > Cc: ietf-xml-use@imc.org > Subject: Re: draft 02, XML declarations > > > > Julian Reschke wrote: > > > " In general, an XML protocol element should either disallow XML > > declarations ("MUST NOT be used") or require one ("MUST have"). A design > > which allows but does not require an XML declaration leads to unreliable > > implementations. When in doubt, require an XML declaration." > > > > 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. > > The issue isn't the parser, it's the serializer. At the moment, it's my > belief that every serializer on the planet writes an XML decl. Another > point is that in many cases someone building protocol code won't be > using an off-the-shelf serializer, they'll be writing a few printf() or > System.println() or whatever calls; in this case, guidance from the > protocol designer as to whether or not to put in the XML decl is clearly > a good thing. > > Summary: I see your point, but I think that the language in draft-02 is > sensible and helpful and I'd like to see it stay. -Tim Well. 1) I happened to write my own serializer some time ago, because the one in Xerces back then didn't do what I needed. Guess what? As it was always producing plain ASCII, it never produced an XML declaration. Until I encountered a client that relied on the presence of the XML declaration to decide whether it would make sense at all to invoke the internal XML parser. So I had to change my perfectly conformant serializer to fix a problem with a broken client. 2) The issue is with the parser as well. If I use an off-the-shelf parser, and the protocol requires or forbids the XML declaration, how am I supposed to check whether a given request conforms to this requirement? With a standard XML processor, I'll never know whether the declaration was present or not. I'm making these comments out of working experience implementing WebDAV clients and servers. Based on this experience, I still think that the current wording doesn't help at all. In particular, forbidding or requiring the declaration makes it unimplementable with an off-the-shelf parser (unless you're recommending to do the check for the XML declaration *before* passing the data stream to the parser). Julian From owner-ietf-xml-use Tue Apr 30 12:15:24 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UJFOI16543 for ietf-xml-use-bks; Tue, 30 Apr 2002 12:15:24 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UJFLa16539 for ; Tue, 30 Apr 2002 12:15:22 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 46684102DA; Tue, 30 Apr 2002 12:15:18 -0700 (PDT) Message-ID: <3CCEED3B.6080107@textuality.com> Date: Tue, 30 Apr 2002 12:15:07 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <3CCEC8E0.4010703@textuality.com> <20020430131147.N1904@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Mealling wrote: >> http://www.textuality.com/tag/Issue8.html >> >>To summarize the case against URNs: It's good for namespace documents >>exist, and it's good for them to be available, and most people can't >>dereference URNs. -Tim > > But doesn't all of that depend on the application? Let's assume that > the CNRP group updated the CNRP specification and made it into > a namespace. The IETF has been pretty much opposed to putting > document locations like that in standards (for good reasons that > some in the W3C might disagree with). The CNRP Working Group would > use a URN as a way to ensure that the name _NOT_ be dereferenced > through the IETF or IANA web sites but instead through some local > catalog/EntityResolver. So if I don't have one handy, as most people don't, I'm going to have to do some real work to track down the documentation. Why is this better? > I.e. we want to use URNs specifically because they're not usually > dereferenced and we have good and valid reasons for not wanting to do that. OK, we agree, if you explicitly don't want people to dereference the names, then using URNs is appropriate. Our experience has been that dereferencing the names to get explanatory material is very helpful, but perhaps that experience is not relevant in this domain. > Hmm.... looking at your document the logic used to get to the idea that > URNs are bad for Namespace names is kind of circular. You assume that > since a large portion of people use 'http:' scheme namespace names that > those users might think they are retrievable. Since there is that > assumption then we should all use 'http:' scheme names. It's simpler than that. People picked the http: names first, then thought they might as well put something there, and that turned out to be useful. Since it turns out to be useful, we conclude that http: names are the way to go. > What if > I _DON'T_ want the namespace name to be resolvable > by a conscious decision? Then use a URN. > Even still you also assert that namespace names aren't frequently dereferenced > at run-time. So the value of saying URNs are bad is even less evident. > Either they're dereferenced or they're not.... There are two cases in which we see them being dereferenced: (1) by a human wondering "what is this namespace about?" or "I thought I knew this stuff, what the hell is a tag?" - this doesn't happen at run-time. (2) by an application at run-time - this isn't something I care about much but the SemWeb people are all excited about it. I agree that run-time dereferencing would be really unlikely at the protocol level. > I guess for me (and many on the URI-IG Group) the question comes down to this: > are URIs generic for the web or not? URNs and what we used to call URLs are far from equivalent in their design goals and usage characteristics. Is it not reasonable to assert that for certain application classes, one side or the other is a better fit? > P.S. I though the TAG was going to defer to the URI group URI related > issues? At least that's they way it was represented to me.... It increasingly seems like *everything* is a URI-related issue. Only half kidding. -Tim From owner-ietf-xml-use Tue Apr 30 12:49:42 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UJngB17172 for ietf-xml-use-bks; Tue, 30 Apr 2002 12:49:42 -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 g3UJnea17168 for ; Tue, 30 Apr 2002 12:49:41 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01656; Tue, 30 Apr 2002 15:49:36 -0400 Date: Tue, 30 Apr 2002 21:47:06 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <982427437.20020430214706@w3.org> To: "Julian Reschke" CC: ietf-xml-use@imc.org Subject: Re: draft 02, Well-Formedness In-Reply-To: References: 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 Tuesday, April 30, 2002, 8:38:12 PM, Julian wrote: JR> JR> "Given that XML requires well-formedness, XML parsers are typically JR> intolerant of well-formedness errors. Protocol designers need to recognize JR> this limitation and provide specific guidelines for recovery when malformed JR> data is encountered." JR> "typically" is misleading here. A parser that is "tolerant" isn't an XML JR> parser at all. Yes, absolutely. I had already made a comment along these lines, so when this came up in TAG discussions we pretty much assumed that this would be fixed in this version. We did agree that any specification which allows any sort of automated recovery from XML well formedness errors is a disaster. JR> "Protocol designers need to recognize this limitation and provide specific JR> guidelines for recovery when malformed data is encountered." -> I think this JR> is misleading is well. Yes. For a start, its a feature not a limitation. JR> If the supposed-to-be-XML content in the request JR> isn't wellformed, there's no way to recover. It's just a Bad Request. If JR> that's what the draft intends to say, it should be clarified. Strongly agree. -- Chris mailto:chris@w3.org From owner-ietf-xml-use Tue Apr 30 12:57:08 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UJv8w17339 for ietf-xml-use-bks; Tue, 30 Apr 2002 12:57:08 -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 g3UJv8a17335 for ; Tue, 30 Apr 2002 12:57:08 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA04006; Tue, 30 Apr 2002 15:57:02 -0400 Date: Tue, 30 Apr 2002 21:54:32 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <752873406.20020430215432@w3.org> To: "Julian Reschke" CC: ietf-xml-use@imc.org Subject: Re: draft 02, XML declarations In-Reply-To: References: 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 Tuesday, April 30, 2002, 8:33:33 PM, Julian wrote: JR> > JR> " In general, an XML protocol element should either disallow XML JR> declarations ("MUST NOT be used") That would be very difficult to do. JR> or require one ("MUST have"). Requiring one is harmless, but one is not always needed. JR> A design which allows but does not require an XML declaration JR> leads to unreliable implementations. I don't see much evidence of that. The sole piece of evidence that i can think of is the case where an HTTP charset parameter is allowed to contain different information from, and to override, the XML encoding declaration in the XML declaration. Appart from that notable error (IMHO) its very clear - if the content uses XML 1.0, is standalone, and uses either UTF-8 or UTF-16 then it does not need an XML declaration. JR> When in doubt, require an XML JR> declaration." This latter is good advice, but it applies on a case by case basis to content not to specifications. JR> I think it's up to the XML recommendation to define when an XML declaration JR> is required and when it isn't. Yes, I agree. JR> Requiring it's presence or absence in an XML JR> application won't fly, because implementors may not be able to influence JR> what their XML parser or serializer does. So a "MUST NOT be used" may not be JR> implementable at all. Certainly. And a "must use" needlessly penalises content that did not, in fact, need it. The sole reason I can think of to say anything about this at all beyond the XML spec would be to recommend that protocols should not override parts of the XML with out of band headers, unless they make the rewiting requirement on local save explicit. -- Chris mailto:chris@w3.org From owner-ietf-xml-use Tue Apr 30 13:10:24 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UKAOP17565 for ietf-xml-use-bks; Tue, 30 Apr 2002 13:10:24 -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 g3UKAMa17561 for ; Tue, 30 Apr 2002 13:10:22 -0700 (PDT) Received: (qmail 5978 invoked by uid 0); 30 Apr 2002 20:10:19 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp013-rz3) with SMTP; 30 Apr 2002 20:10:19 -0000 From: "Julian Reschke" To: Subject: RE: draft 02, XML declarations Date: Tue, 30 Apr 2002 22:10:19 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <752873406.20020430215432@w3.org> 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 Chris Lilley > Sent: Tuesday, April 30, 2002 9:55 PM > To: Julian Reschke > Cc: ietf-xml-use@imc.org > Subject: Re: draft 02, XML declarations > > .. > > Requiring one is harmless, but one is not always needed. I don't agree. If the protocol says that the XML declaration is mandatory, a recipient of a request/response MUST reject it if it doesn't have it. If the recipient uses an off-the-shelf XML parser, how is it supposed to *know* whether there was an XML declaration? (Obviously, I agree with the rest of your comments :-) From owner-ietf-xml-use Tue Apr 30 13:16:39 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UKGdc17684 for ietf-xml-use-bks; Tue, 30 Apr 2002 13:16:39 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UKGba17680 for ; Tue, 30 Apr 2002 13:16:37 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UKFYqB008434; Tue, 30 Apr 2002 16:15:34 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UKFXTC008433; Tue, 30 Apr 2002 16:15:33 -0400 (EDT) Date: Tue, 30 Apr 2002 16:15:33 -0400 From: Michael Mealling To: Tim Bray Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430161533.P1904@bailey.dscga.com> Reply-To: Michael Mealling References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <3CCEC8E0.4010703@textuality.com> <20020430131147.N1904@bailey.dscga.com> <3CCEED3B.6080107@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CCEED3B.6080107@textuality.com> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 30, 2002 at 12:15:07PM -0700, Tim Bray wrote: > Michael Mealling wrote: > >> http://www.textuality.com/tag/Issue8.html > >>To summarize the case against URNs: It's good for namespace documents > >>exist, and it's good for them to be available, and most people can't > >>dereference URNs. -Tim > > > >But doesn't all of that depend on the application? Let's assume that > >the CNRP group updated the CNRP specification and made it into > >a namespace. The IETF has been pretty much opposed to putting > >document locations like that in standards (for good reasons that > >some in the W3C might disagree with). The CNRP Working Group would > >use a URN as a way to ensure that the name _NOT_ be dereferenced > >through the IETF or IANA web sites but instead through some local > >catalog/EntityResolver. > > So if I don't have one handy, as most people don't, I'm going to have to > do some real work to track down the documentation. Why is this better? Because it doesn't create a single point of failure for when that resource is no longer available. This probably won't be a consideration for most things but for highly used protocols it very well could be an issue. > >I.e. we want to use URNs specifically because they're not usually > >dereferenced and we have good and valid reasons for not wanting to do that. > > OK, we agree, if you explicitly don't want people to dereference the > names, then using URNs is appropriate. Our experience has been that > dereferencing the names to get explanatory material is very helpful, but > perhaps that experience is not relevant in this domain. Yes. I think saying they're always bad is the problem. Like I said, the TAG should be agnostic with respect to specific schemes but layout the pros and cons of particular scheme semantics: i.e. dereferencing is good but it can create expectations and single points of failure that may be an issue for some applications. This way people don't take this statement to just a littel farther and build parsers that assume things like all XML Namespace names start with 'http:'. > >Hmm.... looking at your document the logic used to get to the idea that > >URNs are bad for Namespace names is kind of circular. You assume that > >since a large portion of people use 'http:' scheme namespace names that > >those users might think they are retrievable. Since there is that > >assumption then we should all use 'http:' scheme names. > > It's simpler than that. People picked the http: names first, then > thought they might as well put something there, and that turned out to > be useful. Since it turns out to be useful, we conclude that http: > names are the way to go. Weeeelll, the evidence I've seen suggests that there are a _large_ number of people using URNs as namespace names instead. I think every single namespace used in MS Office uses a URN (albiet an unregistered one!) I think every web services example from IBM I've seen is using them. > > What if > >I _DON'T_ want the namespace name to be resolvable > >by a conscious decision? > > Then use a URN. Good. That's what I was after.... ;-) > >Even still you also assert that namespace names aren't frequently > >dereferenced at run-time. So the value of saying URNs are bad is even less > >evident. > >Either they're dereferenced or they're not.... > > There are two cases in which we see them being dereferenced: (1) by a > human wondering "what is this namespace about?" or "I thought I knew > this stuff, what the hell is a tag?" - this doesn't happen at > run-time. Yes. This is the most common usage I've seen. In that case using any managed namespace is probably sufficient since there will be ways of finding out about it. > (2) by an application at run-time - this isn't something I > care about much but the SemWeb people are all excited about it. I agree > that run-time dereferencing would be really unlikely at the protocol level. Yep. I don't think my CNRP client will be doing it but my semantic web utility might and in that case it will be DDDS aware so it will be able to resolve any URI (both authoritatively and contextually). > >I guess for me (and many on the URI-IG Group) the question comes down to > >this: > > are URIs generic for the web or not? > > URNs and what we used to call URLs are far from equivalent in their > design goals and usage characteristics. Is it not reasonable to assert > that for certain application classes, one side or the other is a better > fit? Yes and no. I think the best thing is to discuss the actual semantics that are desirable and leave the choice of the actual namespace up to the application designer. I.e. "It is a good thing that XML Namespace Names are dereferencable for pedagogical and support purposes but it is not required that they be so. Thus XML Namespace Names should be chosen from URI schemes that are derefereneable. But in the case where there is no need to do so then any URI scheme is valid." > >P.S. I though the TAG was going to defer to the URI group URI related > >issues? At least that's they way it was represented to me.... > > It increasingly seems like *everything* is a URI-related issue. Only > half kidding. -Tim My favorite definition for the web was one TimBL used a long time ago: "The Web is the set of 'things' that can be identified by a URI" (and that included physical objects!). So, while you're only half kidding, I actually prefer the idea. ;-) -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 13:31:54 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UKVsa18068 for ietf-xml-use-bks; Tue, 30 Apr 2002 13:31:54 -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 g3UKVqa18064 for ; Tue, 30 Apr 2002 13:31:52 -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 QAA23402; Tue, 30 Apr 2002 16:32:10 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5ZK70>; Tue, 30 Apr 2002 16:31:43 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B9E1@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Julian Reschke'" , ietf-xml-use@imc.org Subject: RE: draft 02, Well-Formedness Date: Tue, 30 Apr 2002 16:31:40 -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: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, April 30, 2002 2:38 PM > To: ietf-xml-use@imc.org > Subject: draft 02, Well-Formedness > > > > de.html#xmlwf> > > "Given that XML requires well-formedness, XML parsers are typically > intolerant of well-formedness errors. Protocol designers need > to recognize > this limitation and provide specific guidelines for recovery > when malformed > data is encountered." > > "typically" is misleading here. A parser that is "tolerant" > isn't an XML > parser at all. This is new text. I can change "XML parsers are typically intolerant" to "compliant XML parsers are intolerant". > "Protocol designers need to recognize this limitation and > provide specific > guidelines for recovery when malformed data is encountered." > -> I think this > is misleading is well. If the supposed-to-be-XML content in > the request > isn't wellformed, there's no way to recover. It's just a Bad > Request. If > that's what the draft intends to say, it should be clarified. Leaving out the IETF's "be liberal in what you accept" text from the same paragraph takes this quotation slightly out of context. Malformed XML may indeed be a Bad Request, but the best we can do in this document is to advise designers that they have to be aware that compliant XML parsers aren't liberal in what they accept, and they should be prepared to address this limitation in their design. If the word "recovery" is the one that's causing a problem for you I'll come up with something else (like maybe "behavior"), but beyond that I don't understand what you consider to be misleading. -Scott- From owner-ietf-xml-use Tue Apr 30 13:47:06 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UKl6Y18361 for ietf-xml-use-bks; Tue, 30 Apr 2002 13:47:06 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UKl5a18357 for ; Tue, 30 Apr 2002 13:47:05 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id A64C2102DA; Tue, 30 Apr 2002 13:47:01 -0700 (PDT) Message-ID: <3CCF02BA.4070905@textuality.com> Date: Tue, 30 Apr 2002 13:46:50 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lilley Cc: Julian Reschke , ietf-xml-use@imc.org Subject: Re: draft 02, Well-Formedness References: <982427437.20020430214706@w3.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Chris Lilley wrote: > We did agree that any specification which allows any sort of automated > recovery from XML well formedness errors is a disaster. > ... > JR> If the supposed-to-be-XML content in the request > JR> isn't wellformed, there's no way to recover. It's just a Bad Request. If > JR> that's what the draft intends to say, it should be clarified. > > Strongly agree. Hmm, if the protocol is based on exchanging XML messages, and one of the messages turns out not to be XML, it's reasonable to have fallback or error-handling (report? abort? retry?) behavior in a protocol. I had read the -02 draft to say that and wasn't worried. Probably all that needs to be done is to say that the error-handling behavior doesn't include trying to guess what the non-XML message was trying to say. -Tim From owner-ietf-xml-use Tue Apr 30 13:57:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UKvDv18586 for ietf-xml-use-bks; Tue, 30 Apr 2002 13:57:13 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UKvCa18582 for ; Tue, 30 Apr 2002 13:57:12 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 9024010310; Tue, 30 Apr 2002 13:57:08 -0700 (PDT) Message-ID: <3CCF0519.7000200@textuality.com> Date: Tue, 30 Apr 2002 13:56:57 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <3CCEC8E0.4010703@textuality.com> <20020430131147.N1904@bailey.dscga.com> <3CCEED3B.6080107@textuality.com> <20020430161533.P1904@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Mealling wrote: [on why-URNs?] > Because it doesn't create a single point of failure for when that > resource is no longer available. This probably won't be a consideration > for most things but for highly used protocols it very well could be > an issue. We're mostly in agreement, but for the record I've always had a hard time believing that URNs will actually be more reliable/persistent in practice; the causes of URL breakage are mostly incompetence and stupidity, and a guaranteed level of indirection may not succeed in routing around this. > Weeeelll, the evidence I've seen suggests that there are a _large_ > number of people using URNs as namespace names instead. I think every > single namespace used in MS Office uses a URN (albiet an unregistered one!) > I think every web services example from IBM I've seen is using them. Yeah, the MS Office practice is really egregious in my view. >>>P.S. I though the TAG was going to defer to the URI group URI related >>>issues? At least that's they way it was represented to me.... >> >>It increasingly seems like *everything* is a URI-related issue. Only >>half kidding. -Tim > > My favorite definition for the web was one TimBL used a long time ago: > "The Web is the set of 'things' that can be identified by a URI" (and that > included physical objects!). So, while you're only half kidding, I actually > prefer the idea. ;-) Aha! Thus we can disband the TAG and most of the W3C and the IETF HTTP work and turn all the work over to the URI group and go back to writing code and taking vacations. I *like* this approach:) -Tim From owner-ietf-xml-use Tue Apr 30 14:04:35 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UL4Zq18862 for ietf-xml-use-bks; Tue, 30 Apr 2002 14:04:35 -0700 (PDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UL4Ya18858 for ; Tue, 30 Apr 2002 14:04:34 -0700 (PDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g3UL3VqB008562; Tue, 30 Apr 2002 17:03:31 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g3UL3UYK008561; Tue, 30 Apr 2002 17:03:30 -0400 (EDT) Date: Tue, 30 Apr 2002 17:03:30 -0400 From: Michael Mealling To: Tim Bray Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Message-ID: <20020430170330.Q1904@bailey.dscga.com> Reply-To: Michael Mealling References: <3CCD8A69.2010907@textuality.com> <20020430101719.K1904@bailey.dscga.com> <3CCEC8E0.4010703@textuality.com> <20020430131147.N1904@bailey.dscga.com> <3CCEED3B.6080107@textuality.com> <20020430161533.P1904@bailey.dscga.com> <3CCF0519.7000200@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CCF0519.7000200@textuality.com> User-Agent: Mutt/1.3.22.1i Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Apr 30, 2002 at 01:56:57PM -0700, Tim Bray wrote: > Michael Mealling wrote: > [on why-URNs?] > >Because it doesn't create a single point of failure for when that > >resource is no longer available. This probably won't be a consideration > >for most things but for highly used protocols it very well could be > >an issue. > > We're mostly in agreement, but for the record I've always had a hard > time believing that URNs will actually be more reliable/persistent in > practice; the causes of URL breakage are mostly incompetence and > stupidity, and a guaranteed level of indirection may not succeed in > routing around this. Well, for the record, the point was never the level of indirection but the fact that in order to get a chunk of the namespace you have to explain how you're going to gaurantee that the names are never reassigned and that you explicitly understand what it means to be a URN. That's why RFC 2141 never even discusses resolution. http://purl.org/ doesn't tell me anything about how persistent it might be. urn:pin:1 does because the namespace _requires_ it. Hence I know that if something screwes up it wasn't my improper assumption about persistence..... > >Weeeelll, the evidence I've seen suggests that there are a _large_ > >number of people using URNs as namespace names instead. I think every > >single namespace used in MS Office uses a URN (albiet an unregistered one!) > >I think every web services example from IBM I've seen is using them. > > Yeah, the MS Office practice is really egregious in my view. IMHO, I think the usage is fine. The namespace needs to be registered but it seems to work for them.... > >>>P.S. I though the TAG was going to defer to the URI group URI related > >>>issues? At least that's they way it was represented to me.... > >> > >>It increasingly seems like *everything* is a URI-related issue. Only > >>half kidding. -Tim > > > >My favorite definition for the web was one TimBL used a long time ago: > >"The Web is the set of 'things' that can be identified by a URI" (and that > >included physical objects!). So, while you're only half kidding, I > >actually prefer the idea. ;-) > > Aha! Thus we can disband the TAG and most of the W3C and the IETF HTTP > work and turn all the work over to the URI group and go back to writing > code and taking vacations. I *like* this approach:) -Tim I said I liked it. I didn't say it was sufficient! ;-) -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-ietf-xml-use Tue Apr 30 14:25:49 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ULPnw19360 for ietf-xml-use-bks; Tue, 30 Apr 2002 14:25:49 -0700 (PDT) Received: from hq15.pcmail.ingr.com (ckpnt02.intergraph.com [63.75.137.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ULPma19354 for ; Tue, 30 Apr 2002 14:25:49 -0700 (PDT) Received: by hq15.pcmail.ingr.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 16:29:19 -0500 Message-ID: <2C61CCE8A870D211A523080009B94E430752B3C5@HQ5> From: "Bullard, Claude L (Len)" To: "'Tim Bray'" Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: What Are the Payoffs for SOAP? (WAS RE: Comments on draft-hollenb eck-ietf-xml-guidelines-02.txt) Date: Tue, 30 Apr 2002 16:25:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Not quite. If path dependency for correct choices requires correct information, you still have the responsibility to educate the educators. Then there are those nasty syntax issues. You can't ever go home or on vacation again because the supply of people to be educated is endless. :-) Would the quote be more correct if it said: "The Web is the set of *representations* that can be identified by a URI". If true, then we know what the Web is. Can someone tell me why given the URI identifies a WSDL, SOAP is a bad thing? If an information owner chooses to hide representations behind a single URI, isn't that simply a bet on the payoffs of hiding the representations? Fielding says, this is a bad bet but bases that on "unforeseen uses". So he assumes payoffs but can't enumerate all of them. The information is imperfect (second degree path dependency). The REST advocates claim a potential third degree path dependency but can't prove it exists except insofar as the benefits of common interfaces are asserted. At some point, some champion of SOAP must enumerate and defend the SOAP payoffs. Then and only then can one begin to determine if a third degree path dependency exists. len -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] > My favorite definition for the web was one TimBL used a long time ago: > "The Web is the set of 'things' that can be identified by a URI" (and that > included physical objects!). So, while you're only half kidding, I actually > prefer the idea. ;-) Aha! Thus we can disband the TAG and most of the W3C and the IETF HTTP work and turn all the work over to the URI group and go back to writing code and taking vacations. I *like* this approach:) -Tim From owner-ietf-xml-use Tue Apr 30 14:28:41 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3ULSfK19444 for ietf-xml-use-bks; Tue, 30 Apr 2002 14:28:41 -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 g3ULSea19440 for ; Tue, 30 Apr 2002 14:28:40 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA20892; Tue, 30 Apr 2002 17:28:36 -0400 Date: Tue, 30 Apr 2002 23:26:05 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <508366328.20020430232605@w3.org> To: "Julian Reschke" CC: ietf-xml-use@imc.org Subject: Re: draft 02, XML declarations In-Reply-To: References: 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 Tuesday, April 30, 2002, 10:10:19 PM, Julian wrote: >> From: owner-ietf-xml-use@mail.imc.org >> [mailto:owner-ietf-xml-use@mail.imc.org]On Behalf Of Chris Lilley >> Sent: Tuesday, April 30, 2002 9:55 PM >> To: Julian Reschke >> Cc: ietf-xml-use@imc.org >> Subject: Re: draft 02, XML declarations >> >> .. >> >> Requiring one is harmless, but one is not always needed. JR> I don't agree. I was referring to the XML Spec regarding whether one was required, and when. JR> If the protocol says that the XML declaration is mandatory, a JR> recipient of a request/response MUST reject it if it doesn't have it. Yes, clearly. So, the protocol should not do that. Unless it is going to require special XML parsers and serialisers. JR> If the JR> recipient uses an off-the-shelf XML parser, how is it supposed to *know* JR> whether there was an XML declaration? Exactly. -- Chris mailto:chris@w3.org From owner-ietf-xml-use Tue Apr 30 14:49:04 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3ULn4T19810 for ietf-xml-use-bks; Tue, 30 Apr 2002 14:49:04 -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 g3ULn3a19806 for ; Tue, 30 Apr 2002 14:49:03 -0700 (PDT) Received: from ad.kr.doubleclick.net (localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24590; Tue, 30 Apr 2002 17:49:03 -0400 Date: Tue, 30 Apr 2002 23:46:33 +0200 From: Chris Lilley X-Mailer: The Bat! (v1.60c) Personal Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1629593562.20020430234633@w3.org> To: "Hollenbeck, Scott" CC: "'Julian Reschke'" , ietf-xml-use@imc.org Subject: Re: draft 02, Well-Formedness In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B9E1@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B9E1@vsvapostal3.bkup6> 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 Tuesday, April 30, 2002, 10:31:40 PM, Scott wrote: HS> This is new text. I can change "XML parsers are typically intolerant" to HS> "compliant XML parsers are intolerant". That is an improvement. HS> Leaving out the IETF's "be liberal in what you accept" text from the same HS> paragraph takes this quotation slightly out of context. Malformed XML may HS> indeed be a Bad Request, but the best we can do in this document is to HS> advise designers that they have to be aware that compliant XML parsers HS> aren't liberal in what they accept, They are liberal. They will accept absolutely any elements and attributes you give them. HS> and they should be prepared to address HS> this limitation in their design. They won't tolerate well formedness errors at all though, and it is incorrect and misleading to describe this as a "limitation". Its a feature. Saying its a limitation encourages someone to fix the limitation. HS> If the word "recovery" is the one that's HS> causing a problem for you I'll come up with something else (like maybe HS> "behavior"), but beyond that I don't understand what you consider to be HS> misleading. -- Chris mailto:chris@w3.org From owner-ietf-xml-use Tue Apr 30 14:50:15 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3ULoFB19845 for ietf-xml-use-bks; Tue, 30 Apr 2002 14:50:15 -0700 (PDT) Received: from hq15.pcmail.ingr.com (ckpnt02.intergraph.com [63.75.137.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ULoEa19841 for ; Tue, 30 Apr 2002 14:50:14 -0700 (PDT) Received: by hq15.pcmail.ingr.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 16:53:45 -0500 Message-ID: <2C61CCE8A870D211A523080009B94E430752B3C6@HQ5> From: "Bullard, Claude L (Len)" To: "'Jeff Bone'" Cc: ietf-xml-use@imc.org, www-tag@w3.org Subject: RE: What Are the Payoffs for SOAP? (WAS RE: Comments on draft-hol lenb eck-ietf-xml-guidelines-02.txt) Date: Tue, 30 Apr 2002 16:50:05 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: They can be precisely described, but if "unforeseen", then the information needed, the payoffs, is still imperfect. Of course, one can argue predictability based on memory but proving necessity and therefore forecasting payoffs, is still unobtainable. I don't want to push this too far and clog these lists. I only want to point out that one side has claimed better payoffs for their architecture and that the other has yet to do so. I don't accept that hiding assets behind a single point of interface (a single URI) is bad for the Web. It may be bad for the selector of that architecture but without the payoffs, that is hard to decide. As long as the URI of the WSDL is a proper URI, caveat emptor unless there are other penalties or payoffs. The fear of SOAP/RPC is for some, predicated on the fear of lock-in to an inferior technology. Given REST, if this is "perfect", then this is a third degree path dependency and, IMO, the duty of the TAG is as Fielding has stated, regardless of the intentions or short term payoffs to the W3C members who support REST. He is right: that is why the TAG was formed. len -----Original Message----- From: Jeff Bone [mailto:jbone@deepfile.com] Sorry to weigh in on a nit but... non-enumerable doesn't imply "imperfect" information: there are sets (such as applications on the web) which can be discussed in very precise terms by talking about their characteristics but which cannot be enumerated. From owner-ietf-xml-use Tue Apr 30 15:53:19 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UMrJq20999 for ietf-xml-use-bks; Tue, 30 Apr 2002 15:53:19 -0700 (PDT) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UMrGa20995 for ; Tue, 30 Apr 2002 15:53:16 -0700 (PDT) Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.12.3/8.12.2) with ESMTP id g3UMrJ8p006659; Tue, 30 Apr 2002 15:53:19 -0700 (PDT) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id PAA22063; Tue, 30 Apr 2002 15:53:18 -0700 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Tue, 30 Apr 2002 15:53:18 -0700 (PDT) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: Tim Bray cc: ietf-xml-use@imc.org Subject: Re: -guidelines-02.txt: elements/attributes In-Reply-To: <3CCEE96E.8090707@textuality.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think that Larry's recent note here got it right: explain the > differences so protocol designers get the issues, then let 'em do what > they want, because they will anyhow. -Tim > Works for me. From owner-ietf-xml-use Tue Apr 30 16:51:32 2002 Received: by above.proper.com (8.11.6/8.11.3) id g3UNpWk22098 for ietf-xml-use-bks; Tue, 30 Apr 2002 16:51:32 -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 g3UNpUa22094 for ; Tue, 30 Apr 2002 16:51:30 -0700 (PDT) Received: (qmail 10855 invoked by uid 0); 30 Apr 2002 23:51:28 -0000 Received: from p3ee2475f.dip.t-dialin.net (HELO lisa) (62.226.71.95) by mail.gmx.net (mp001-rz3) with SMTP; 30 Apr 2002 23:51:28 -0000 From: "Julian Reschke" To: Subject: RE: draft 02, Well-Formedness Date: Wed, 1 May 2002 01:51: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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CCF02BA.4070905@textuality.com> 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 Tim Bray > Sent: Tuesday, April 30, 2002 10:47 PM > To: Chris Lilley > Cc: Julian Reschke; ietf-xml-use@imc.org > Subject: Re: draft 02, Well-Formedness > > > > Chris Lilley wrote: > > > We did agree that any specification which allows any sort of automated > > recovery from XML well formedness errors is a disaster. > > > ... > > JR> If the supposed-to-be-XML content in the request > > JR> isn't wellformed, there's no way to recover. It's just a > Bad Request. If > > JR> that's what the draft intends to say, it should be clarified. > > > > Strongly agree. > > Hmm, if the protocol is based on exchanging XML messages, and one of the > messages turns out not to be XML, it's reasonable to have fallback or > error-handling (report? abort? retry?) behavior in a protocol. I had > read the -02 draft to say that and wasn't worried. Probably all that > needs to be done is to say that the error-handling behavior doesn't > include trying to guess what the non-XML message was trying to say. -Tim Well, maybe I'm getting paranoid, but this is what is sounded like to me. So the draft should make clear that XML *does* draconic error reporting, that this is a feature, and that a protocol simply should define what is supposed to happen upon receipt of a malformed message (in case of WebDAV that's HTTP status 400). Julian From owner-ietf-xml-use Tue Apr 30 18:50:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g411oZO24120 for ietf-xml-use-bks; Tue, 30 Apr 2002 18:50:35 -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 g411oXa24112 for ; Tue, 30 Apr 2002 18:50:33 -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 DFFB715BF; Wed, 1 May 2002 10:50:19 +0900 (JST) Message-Id: <4.2.0.58.J.20020501085031.0286e3b8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 01 May 2002 08:52:40 +0900 To: "Julian Reschke" , From: Martin Duerst Subject: Re: draft 02, processing instructions In-Reply-To: References: <3CCEC8E0.4010703@textuality.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: I agree. By the way, as far as I remember, last time I read the doc, there was nothing on comments. There should be something similar on comments: - Ignore them on the receiving side if you get them. - Don't use them for the actual protocol, or extensions. (You might think that the second point is obvious, but sadly enough, it has been done.) Regards, Martin. At 20:35 02/04/30 +0200, Julian Reschke wrote: > > >"...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." > >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. From owner-ietf-xml-use Tue Apr 30 18:50:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g411oZQ24119 for ietf-xml-use-bks; Tue, 30 Apr 2002 18:50:35 -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 g411oXa24111 for ; Tue, 30 Apr 2002 18:50:33 -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 2740115C4; Wed, 1 May 2002 10:50:22 +0900 (JST) Message-Id: <4.2.0.58.J.20020501085258.02ba5950@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 01 May 2002 08:53:46 +0900 To: "Julian Reschke" , From: Martin Duerst Subject: Re: draft 02, binary data In-Reply-To: References: <3CCEC8E0.4010703@textuality.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 20:42 02/04/30 +0200, Julian Reschke wrote: > > > >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 (*), Yes, good point. >or preferrably suggesting a common format >for >usage in many protocols). This is supposed to become a BCP. Regards, Martin. >(*) Control characters except TAB, CR and LF are not allowed in XML content. > From owner-ietf-xml-use Wed May 1 10:45:39 2002 Received: by above.proper.com (8.11.6/8.11.3) id g41Hjdk21425 for ietf-xml-use-bks; Wed, 1 May 2002 10:45:39 -0700 (PDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41Hjca21421 for ; Wed, 1 May 2002 10:45:38 -0700 (PDT) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g41HlO19002671 for ; Wed, 1 May 2002 10:47: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.12.3/8.12.3) with ESMTP id g41HjFuE002414 for ; Wed, 1 May 2002 10:46:00 -0700 (PDT) Received: from larrypad ([153.32.29.226]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GVG1AM00.K9C; Wed, 1 May 2002 10:44:46 -0700 Reply-To: From: "Larry Masinter" To: "'Julian Reschke'" Cc: Subject: RE: draft 02, binary data Date: Wed, 1 May 2002 10:44:25 -0700 Message-ID: <001501c1f137$d58c94e0$e21d2099@larrypad> 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, Build 10.0.3416 In-Reply-To: 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 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). > > (*) Control characters except TAB, CR and LF are not allowed > in XML content. I'm not sure what else we need to say beyond Note that the XML character range does not include arbitrary "control" characters. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation. do you have a suggestion? From owner-ietf-xml-use Wed May 1 10:53:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41Hrlm21636 for ietf-xml-use-bks; Wed, 1 May 2002 10:53:47 -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 g41Hrja21625 for ; Wed, 1 May 2002 10:53:45 -0700 (PDT) Received: (qmail 27371 invoked by uid 0); 1 May 2002 17:53:40 -0000 Received: from pd950c246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp004-rz3) with SMTP; 1 May 2002 17:53:40 -0000 From: "Julian Reschke" To: Cc: Subject: RE: draft 02, binary data Date: Wed, 1 May 2002 19:53:40 +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: <001501c1f137$d58c94e0$e21d2099@larrypad> 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: > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Wednesday, May 01, 2002 7:44 PM > To: 'Julian Reschke' > Cc: ietf-xml-use@imc.org > Subject: RE: draft 02, binary data > > > > > nary > > > 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). > > > > (*) Control characters except TAB, CR and LF are not allowed > > in XML content. > > I'm not sure what else we need to say beyond > > Note that the XML character range does not include arbitrary > "control" characters. This means that strings that might be > considered "text" within an ABNF-defined protocol element may need > to > be treated as binary data within an XML representation. > > do you have a suggestion? Well, choosing a binary representation for something which "almost" always consists of allowed Unicode characters seems to be a waste of readability and size. Some alternatives were discussed on xml-dev [1], for instance text .. ... or text .. ... I think it would be a good thing that XML-based IETF protocols have a common answer to this problem. [1] From owner-ietf-xml-use Mon May 6 15:33:14 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46MXEH05718 for ietf-xml-use-bks; Mon, 6 May 2002 15:33:14 -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 g46MXDL05714 for ; Mon, 6 May 2002 15:33:13 -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 330F2D87 for ; Tue, 7 May 2002 07:33:04 +0900 (JST) Message-Id: <4.2.0.58.J.20020507055450.02fd7810@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 07 May 2002 07:32:14 +0900 To: ietf-xml-use@imc.org From: Martin Duerst Subject: Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.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: Sorry for being a bit late. Here are my comments as far as they haven't been addressed by others: > Guidelines for the Use of XML within IETF Protocols > draft-hollenbeck-ietf-xml-guidelines-02.txt >Abstract > > 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 being developed; many > have need for a representation for structured data relevant to their have need for -> have a need for ? >1. Introduction and Overview > > The Extensible Markup Language (XML) is a framework for structuring There should be a reference to XML here, probably to [8]. I guess it may have been avoided because the document assumes that XML includes XML Namespaces,... In any case, the document should clearly state what it understands by "XML", and should do so early on. >1.2 Scope > > This document is intended to give guidelines for the use of XML > content within a larger protocol. The goal is not to suggest that > XML is the "best" or "preferred" way to represent data; rather, the > goal is to lay out the context for the use XML within a protocol once > other factors point to XML as a possible data representation > solution. > > There are a number of protocol frameworks already in use or under > development which focus entirely on "XML protocol": the exclusive use > of XML as the data representation in the protocol. For example, the > World Wide Web Consortium (W3C) is developing an XML Protocol > framework [41] based on the Simple Object Access Protocol (SOAP) > [42]. The applicability of such protocols is not part of the scope > of this document. > > In addition, there are higher-level representation frameworks, based > on XML, that have been designed as carriers of certain classes of > information; for example, the Resource Description Framework (RDF) > [36] is an XML-based representation for logical assertions. This > document does not provide guidelines for the use of such frameworks. The definition is mostly in negative terms. It would be good to have some positive examples. I could imagine something like: "Examples of existing protocols that would be addressed by these guidelines if they would be newly defined include WebDAV and CNRP." It should also be said that this doc doesn't address the simple case of sending XML as a document over MIME/MIME-like protocols such as SMTP or HTTP. >2. XML Selection Considerations > o XML includes features to support internationalization and > localization. I would take out localization. Also, 'includes features' doesn't really adequately describe the fact that this is built in at the very base. > o XML is text-based, so XML fragments are easily created, edited, > and managed using common utilities. Further, being text-based > means it more readily supports incremental development, debugging, > and logging. A simple "canned" XML fragment can be embedded > within a program as a string constant, rather than constructed. rather than constructed -> rather than having to be constructed >3. XML Alternatives > Specification encoding: XML schema are themselves represented in XML, XML schema -> XML schemas (see e.g. http://www.w3.org/TR/xmlschema-0/) > and the specification itself can be written using arbitrary > characters from the language. Which language? The part after the ',' isn't clear to me at all. >The specification of representations > in other systems (ASN.1, XDR, ABNF) are generally in ASCII [27] text. "specification is" or "specifications are" > Text Encoding and character sets: the character encoding used to > represent a formal specification. XML defines a consistent character > model based on ISO 10646 [32], with a base that supports at least > UTF-8 [4] and UTF-16 [22], and allows for other encodings. While > ASN.1 and XDR may carry strings in any encoding, there is no common > mechanism for defining character encodings within them. Typically, > ABNF definitions tend to be defined in terms of octets or characters > in ASCII. "with a base that supports at least UTF-8 [4] and UTF-16 [22]" -> "and requires that XML parsers accept at least UTF-8 [4] and UTF-16 [22]" > Data Encoding: XML is based on a character model. This sentence seems to say nothing. What do you want to say? Maybe something like "XML is defined as a sequence of characters, rather than a sequence bytes." > Extensibility: XML has a rich extensibility model: XML > representations "XML represetantions" is most probably the wrong term here (and below). It suggests that XML can be represented in more than one form. > ASN.1, XDR, and BNF are described here as examples of alternatives to > XML for use in IETF protocols. There are other alternatives, but a > complete enumeration of all possible alternatives is beyond the scope > of this document. This paragraph (with slight editorial adaptions) should be at the start of this chapter, not at the end. >4. XML Use Considerations and Recommendations >4.4 Validity and Extensibility > Whether protocol definitions also require the corresponding protocol > elements be valid according to the schema depends to some degree on > the extensibility design; for example, if the protocol has its own > versioning mechanism, way of updating the schema, or pointing to a > new one. There is an 'if', but no 'then' ???? >The use of XML namespaces (Section 4.5) allows other kinds > of extensibility without compromising schema validity. > > For whatever formalism chosen, there are often additional constraints > that cannot be expressed in that formalism. These additional > requirements should be clearly called out in the specification. > Ideally, a process model might first check for well-formedness; if > OK, apply the primary formalism and, if the instances "passes", apply > the other constraints so that the entire set (or as mush is machine > processable) can be checked at the same time. mush is -> as much as is There should be some text in this section saying something like: While XML has various features that ease extensibility, it should be noted that this cannot replace careful design for extensibility for the specific protocol under consideration. >4.6 Element and Attribute Design Considerations > > XML provides much flexibility in allowing a designer to use either > elements or element attributes to carry data. Element attributes are element attributes -> attributes (more than once) (there is no such thing as an 'element attribute' in XML) > Many protocols include parameters that are selected from an > enumerated set of values. As shown in the above examples, such > enumerated values can be encoded as elements, attributes, or strings > within element values. elements, attributes, or strings within element values -> attribute values, element content, or element names >4.7 Binary Data > Protocols that need a container that can hold both structural data > and large quantities of binary data should consider carefully whether > XML is appropriate, since the Base64 and hex encodings are > inefficient. Otherwise, Other than what? >protocols should use the mechanisms of XML > Schema to represent binary data; the Base64 encoding is best for > larger quantities of data. > > Note that the XML character range does not include arbitrary > "control" characters. Change this sentence to: Note that XML doesn't allow to use C0 control characters except for CR, LF, and TAB. [C1 controls are allowed, although this is by accident according to James Clark.] >This means that strings that might be > considered "text" within an ABNF-defined protocol element may need to > be treated as binary data within an XML representation. >5. Internationalization Considerations Very glad to see this! > This section describes internationalization considerations for the > use of XML to represent data in IETF protocols. In addition to the > recommendations here, IETF policy on the use of character sets and > languages [3] also apply. > >5.1 Character Sets and Encodings: UTF-8 and UTF-16 > > IETF protocols frequently speak of the "character set" or "charset" > of a string, which is used to denote both the character repertoire > and the encoding used to represent sequences of characters as > sequences of bytes. > > XML performs all character processing in terms of the Universal XML does not perform character processing. XML syntax is defined in terms of characters from the UCS. XML processing (e.g. in specs such as XSLT) is therefore also defined in terms of the UCS. > Character Set (UCS, [32] and [34]). XML requires all XML processors > to support both the UTF-8 [4] and UTF-16 [22] encodings of UCS, > although other encodings (charsets) compatible with UCS may be > allowed. good up to here. > Protocols must allow both UTF-8 and UTF-16 (for XML compatibility). > This document recommends allowing only those encodings. I have no idea how this suddenly got in here. I have not seen anybody suggesting that protocols must allow both. XML [8] requires that *XML processors* accept both. This does not require that any protocol/application allow both. There is a strong preference in the IETF for UTF-8 (seen e.g. in RFC 2277, as well as by the fact that the RFC for UTF-16 is informational, whereas the one for UTF-8 is currently draft standard, and is being looked at for moving to full standard). It is also in conflict with section 4.1. This is all for very good reasons, in particular because of ASCII compatibility and endianness issues. > In cases > where there are strong reason to allow others, it should be required > to specify the encoding using an "encoding" attribute in the XML > declaration (see Section 4.1). > >5.2 Language Declaration > > Text encapsulated in XML can be represented in many different human > languages, and it is often useful to explicitly identify the language > used to present the text. XML version 1 This is the only place where you use 'XML version 1'. probably not needed. >defines a special attribute > in the "xml" namespace, xml:lang, that can be used to specify the > language used to represent data in an XML document. The xml:lang > attribute and the values it can assume are defined in section 2.12 of > [8]. > > It is strongly recommended that protocols representing data in a > human language mandate use of an xml:lang attribute if the XML > instance might be interpreted in language-dependent contexts. It would be nice if we could *mandate* the use of xml:lang, but I think it's not possible, because in many cases, data is comming from other places without language information (and wrong language information is definitely worse than none). Also, it should be said here that both DTDs and XML Schema (and probably the other mechanimsm) require xml:lang to be declared explicitly in order to be even allowed. >7. Security Considerations > Several security service options are available mitigate these risks. mitigate -> to mitigate > Though XML does not include any built-in security services, other > protocols and protocol layers provide services that can be used to > protect XML protocols. XML encryption [12] provides privacy services > to prevent unintended disclosure. Canonical XML [6] XML digital probably a comma missing. > signatures [7] provide integrity services to detect modification and > authentication services to confirm the identity of the data source. > Other IETF security protocols (e.g., the Transport Layer Security > (TLS) protocol [2]) are also available to protect data and service > endpoints as appropriate. Given the lack of security services in > XML, it is imperative that protocol specifications REQUIRE additional > security services to counter common threats and attacks; the specific > required services will depend on the protocol's threat model. >Normative References >Informative References Except for this distinction, I don't see ANY kind of ordering principle for references. Would be good if there were, would make things easier to find. Also, [40] should be updated to point to the newest version (April 2002). (And this is in last call, comments welcome :-). You may also want to add a reference to: Unicode in XML and other Markup Languages Unicode Technical Report #20 W3C Note 18 February 2002 http://www.w3.org/TR/unicode-xml/ and http://www.unicode.org/unicode/reports/tr20/ (this is a joint publication) Regards, Martin. From owner-ietf-xml-use Tue May 7 05:49:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47Cnlq20934 for ietf-xml-use-bks; Tue, 7 May 2002 05:49:47 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47CnjL20930 for ; Tue, 7 May 2002 05:49:45 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.11.4/8.11.4) id g47Cmv122125 for ; Tue, 7 May 2002 14:48:57 +0200 (MEST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma022117; Tue, 7 May 02 14:48:40 +0200 Received: from crf.canon.fr ([194.2.81.173]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GVQRIC00.C1E; Tue, 7 May 2002 14:47:00 +0200 Message-ID: <3CD7CD4A.5CFBFA0B@crf.canon.fr> Date: Tue, 07 May 2002 14:49:14 +0200 From: "Jean-Jacques Moreau" Organization: Canon Research Centre France X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ietf-xml-use@imc.org Subject: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g47CnkL20931 Sender: owner-ietf-xml-use@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is good stuff. Here are my comments, as far as they have not been already addressed by others. Jean-Jacques Moreau. ------------------------ > XML has evolved to be a widely-used mechanism for representing > structured data in protocol exchanges. See [39] for an > introduction to XML. Souldn’t there be also a reference to [8] ("Extensible Markup Language (XML) 1.0 (2nd ed)") ? > For example, the World Wide Web Consortium (W3C) is developing > an XML Protocol framework > [41] The status of the XMLP Abstract Model, currently a Working Draft, is uncertain; I’d remove the reference. > based on the Simple Object Access Protocol (SOAP) [42]. SOAP is no longer an acronym. > XML is text-based, so XML fragments are easily created, edited, > and managed using common utilities. The XML Infoset specification allows other encodings. The XML Infoset is not limited to the current textual representation (XML 1.0). > Binary data has to be encoded into a text-based form to be > represented in XML. Not necessarily if a binary serialization of the XML Infoset is used. Also, DIME and SOAP+Attachments are examples of a protocols that use XML and still allows binary data to be transferred with no prior encoding. > XML is verbose when compared with many other structured data > representation languages. Yes, as far as the current XML 1.0 serialization is concerned. However, other, more efficient serialization of the XML Infoset may be used instead for efficiency. > XML processing speed can be an issue in some environments. XML > processing can be slower because XML data streams may be larger > than other representations, and the use of general purpose XML > parsers will add a software layer with its own performance > costs (though these costs can be reduced through consistent use > of an optimized parser). Also see DIME for an alternative approach. > Further, processing XML requires scanning the entire XML data > stream; Not necessarily, for example when using a SAX parser (as long as the data is structured properly). > mechanisms such as XML merely add bloat [25] If this I-D is supposed to become a real RFC, I would recommend removing this reference. > Specification encoding: XML schema are themselves represented > in XML, This is the first time XML Schema [11] is being mentionned. It might be worth introducing the term earlier, for example in the introduction. > and the specification itself can be written using arbitrary > characters from the language. The meaning of ‘language” is unclear. Do you mean the “XML language”? This could also be read as the “user’s native language”. > XML Schema [11] includes mechanisms for representing some > datatypes (integer, date, array, etc.) but other binary > datatypes are encoded in Base64 [17]. The word “other” leaves the impression that anything which is not a string cannot be represented in XML, unless encoded in Base64, which is not true. For example, graphs, which are usually represented as binary structures/objects in typical programming languages, can also be represented as text in XML. > ASN.1 and XDR have rich mechanisms for encoding a wide variety > of datatypes. This is debatable. > 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 [9], though there is no > standard mechanism in XML to indicating whether or not new > extensions are mandatory to recognize. SOAP has introduced such a mechanism (“mustUnderstand”). But I agree that such a mechanism is missing in general for XML. > A design which allows but does not require an XML declaration > leads to unreliable implementations. When in doubt, require an > XML declaration. Well, it may be that what is being transported is an XML document/fragment that was produced elsewhere. The client may have no control over the producer, and may required to pass the fragment as is to the server. As stated, this requirement would prohibit this scenario. > 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"). Again, this requirement would make it impossible for a client to transport an XML document/fragment that was produced elsewhere (see above). I think this requirement should be "SHOULD not transmit” and “MUST ignore" (i.e. be liberal). It may also be worth pointing out that PIs require extra server capabilities, and muddle the processing model. > For this reason, it is recommended that protocol specifications > explicitly require XML well-formedness ("MUST be well- > formed"). Again, XML Infoset conformance is probably better than raw XML 1.0 conformance. I would suggest saying something along the lines of "MUST be a valid XML Infoset". > The IETF has a long-standing tradition of "be liberal in what > you accept" that might seem to be at odds with this > recommendation. Given that XML requires well-formedness, XML > parsers are typically intolerant of well-formedness errors. > Protocol designers need to recognize this limitation and > provide specific guidelines for recovery when malformed data is > encountered. I don’t think "well-formedness" is necessarily at odds with "being liberal in what one accepts". I read liberal in this context as allowing either a subset or a superset of the expected XML Infoset (i.e. missing or extra AIIs or EIIs). I don't read liberal as allowing an invalid Infoset. > Many protocols have successfully used the DTD mechanism for > describing validity, whether or not they insist that all XML > elements are valid SOAP has chosen to explicitely forbid DTDs. > This document recommends that, in the absence of reasons to > choose some other mechanism, protocol designs use W3C XML > Schema as the language for describing validity. ... if validity is required, which I think should be left up to protocol designers, for example to cater for resource constraint devices. Also, it may be worth pointing out in a separate section that protocol designers may wish to type data inline via "xsi:type", from XML Schema, and support XML Schema Part2: Datatypes. > In lieu of such, other permanent URIs can be used, e.g., URNs > in the IETF URN namespace (see [13] and [14]). However, in general, it is better for namespace URIs to be dereferencable and for dereferencing to return the corresponding schema. > 4.5.1 Namespaces and Attributes It should probably be pointed out somewhere that the choice of any namespace prefix is arbitrary and not semantically significant. > There can be no more than one instance of a given attribute > within a given element, ... although an attribute may contain several values, separated by [:space:]. > Attribute values can contain only simple XML data types. ... as defined per XML Schema Part 2 ? >
10.1.2.3
> “type” as used here is confusing with “xsi:type” from XML Schema. I’d recommend renaming the attribute. > Otherwise, protocols should use the mechanisms of XML Schema to > represent binary data; the Base64 encoding is best for larger > quantities of data. See above comment on DIME and SOAP+Attachment. > In some situations, is possible to incrementally process an XML Missing “it” ? > this is analogous to the process by which browsers > incrementally render HTML pages as they are received. Streaming is made easier if the message constructed are carefully structured. For example, a message might be made of a number of “blocks”, and each block might be treated independently. > XML requires all XML processors to support both the UTF-8 [4] > and UTF-16 [22] encodings of UCS. Again, this applies only to the XML 1.0 serialization of the XML Infoset. > 5.3 Other Considerations I think’s there is probably a missing section on URI, including a discussion on the recommended use of xml:base. > Some of these issues are discussed, with recommendations, in > [40]. Add a reference to IRIs ? > The "application/xml" media type is most appropriate for > general XML; It might be worth pointing out that SOAP 1.2 uses “application/soap+xml”, so that it can be recognized both by SOAP processors and generic XML processors (although the former is better). > [42] [etc] http://www.w3.org/TR/soap12-part1/ Shouldn't there be also a reference to Part 2 ? > Moreau, J. Please use "JJ.", if possible. From owner-ietf-xml-use Tue May 7 06:04:28 2002 Received: from loca