X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Delivered-To: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with SMTP id k8csp91916lbn; Mon, 11 Jun 2012 12:58:33 -0700 (PDT) Received: by 10.68.193.226 with SMTP id hr2mr29378560pbc.155.1339444713105; Mon, 11 Jun 2012 12:58:33 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org. [2001:1890:123a::1:1e]) by mx.google.com with ESMTP id sp1si11847005pbc.170.2012.06.11.12.58.32; Mon, 11 Jun 2012 12:58:33 -0700 (PDT) Received-SPF: fail (google.com: domain of abnf-discuss-bounces@ietf.org does not designate 2001:1890:123a::1:1e as permitted sender) client-ip=2001:1890:123a::1:1e; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of abnf-discuss-bounces@ietf.org does not designate 2001:1890:123a::1:1e as permitted sender) smtp.mail=abnf-discuss-bounces@ietf.org; dkim=pass (test mode) header.i=@ietf.org Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1987B11E809B; Mon, 11 Jun 2012 12:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1339444712; bh=WTEACDSqjG7lH4HPqCXGOu+xB10QVojAsKsY/pEuYWo=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=HlWee19P11vOH9d4mMGqVPTdQaYISmNO3O3goNkH6UVrzVaWOXQx3Xwwg0M0oSumG ujAwnBB9ICVjpkSbXI8eXRf3jUB7vd/Cxrg3gGDaqTc/lkPAiIkoYyN6NlYdy8PLO7 ddhuWG6mdW8XyK19BBV6Gax9XTYsOCjxHY64merw= X-Original-To: abnf-discuss@ietfa.amsl.com Delivered-To: abnf-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5009221F85CD for ; Mon, 11 Jun 2012 12:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61bYKitOtuyI for ; Mon, 11 Jun 2012 12:56:42 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D395D21F859E for ; Mon, 11 Jun 2012 12:56:41 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2721209wib.13 for ; Mon, 11 Jun 2012 12:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=J1PBcBGkL6OsyVe3hnSSmIbcjXyX6bes5UwqvU0Ysto=; b=lLVbrBeVqprKxLuozubrWHtLflWS4ly3DzCCJkSH/ZWMXroS8xxIt8Pq+9csvkaaMH AUZx5DYnN0t9G6hQryWeH+4YBev3KO38zp7inl2gMC8FV2HuQ+O8TTYQeNGXSWM9kiIm m0VMF80ew0DUmTqEDVwbalJul1iOB2hN/5yBA9ckIyv2xSpkmFhcLa7y7qdwr/VepHQZ bXFxp+H/zCdQYTTNgE+KVkqVJ6Ih3PRxlsYsM9mOkF+egt47rfLXgmLUu81Jb7d0wYCk x9EaZS0EiK7LAlGIH3rDN64w0HxACf45yZ3pfsn5yBpBaE0vEE8jd0TFrrMIL8rbEcPD Qn6Q== Received: by 10.216.142.146 with SMTP id i18mr7407333wej.74.1339444600940; Mon, 11 Jun 2012 12:56:40 -0700 (PDT) Received: from [10.0.2.197] (host86-164-41-179.range86-164.btcentralplus.com. [86.164.41.179]) by mx.google.com with ESMTPS id gb9sm516694wib.8.2012.06.11.12.56.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 12:56:40 -0700 (PDT) From: Paul Moore Date: Mon, 11 Jun 2012 20:56:38 +0100 Message-Id: <2CCD27F5-B8D5-4C51-A830-54E6E2676029@lineone.net> To: abnf-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [abnf-discuss] Unordered lists with specific cardinality X-BeenThere: abnf-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8171314804639137650==" Sender: abnf-discuss-bounces@ietf.org Errors-To: abnf-discuss-bounces@ietf.org --===============8171314804639137650== Content-Type: multipart/alternative; boundary=Apple-Mail-127-360145334 --Apple-Mail-127-360145334 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, Background I'm documenting a vendor specific media type = (application/vnd.whosebill+json) which I intend to publish as an = Informational RFC. However, I'm having some trouble with the handling = of unordered lists in ABNF. Broadly, from my research it would appear that this has been a = long-standing problem, and authors have typically used one of two = approaches: Approach A - Specific cardinality, unordered nature in prose In this approach, authors document the list as an ordered rule, *and* = annotate the list to communicate the unordered nature: myobject =3D begin-object members end-object members =3D member-a [separator member-b] separator member-c ; the ordering of the members is unimportant begin-object =3D %x7B ; "{" end-object =3D %x7D ; "}" separator =3D %x2C ; "," Pros: Cardinality is ABNF specific (as 'member-b'). Cons: Ordering has to *fixed* by prose. Example: RFC 2045 (MIME Format) - MIME Header Fields which states "The = ordering of the header fields implied by this BNF definition should be = ignored" or, Approach B - Specific unordered nature, cardinality in prose=20 In this approach, authors document the list as a selection of = alternatives, and annotate the cardinality of each member in prose myobject =3D begin-object member *( separator member ) end-object member =3D member-a / member-b ; required / member-c begin-object =3D %x7B ; "{" end-object =3D %x7D ; "}" separator =3D %x2C ; "," Pros: Unordered nature is implicit through the combination of optional = alternative values. Cons: Cardinality concerns are reduced to prose. Example: RFC 5988 (Web Linking) - Link grammar. There is some = discussion about this specific approach in a rejected erratum of the = same RFC, where Mark Nottingham notes "The proposed ABNF makes ordering = significant, which is NOT specified or intended. ABNF can never capture = all of the constraints on syntax; that's why we have prose." =20 Problem My (limited) research implies that ABNF cannot precisely articulate = unordered lists with specific cardinality; authors are left with a = choice as to which aspect to handle in prose. There is some discussion about the problem by Chris Newman here, and = Chris advocates a more formulated arrangement of the cardinality in = prose approach here. Additionally, from examination of the earlier ABNF drafts (RFC 2234) I = see there was some discussion of a 'list rule' (#rule) and latterly a = 'set group' with similar intent, but none of these proposals made it to the = final versions. I also stumbled across a thread which implicated that use of the 'list = rule' / 'set group' proposals would cause ambiguities in ABNF, and = therefore were not pursued. I appreciate that syntax features must be = carefully designed so as not to introduce ambiguity, but I'm not a lexer = / parser specialist, and so would like to get a view of whether this is = something that could be considered for a latter revision of ABNF? Questions 1. Is my understanding that ABNF is unable to articulate unordered lists = with specific cardinality correct, or am I missing something? 2. Would introducing functionality to allow such lists fundamentally = introduce ambiguity into the ABNF syntax? Many thanks for your time Paul= --Apple-Mail-127-360145334 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
myobject =3D = begin-object members end-object
members  =3D = member-a [separator member-b] separator member-c
      =    ; the ordering of the members is = unimportant
begin-object =3D %x7B ; = "{"
end-object   =3D %x7D ; "}"
separator   =  =3D %x2C ; ","

Pros: Cardinality = is ABNF specific (as 'member-b').
Cons: Ordering has to *fixed* by = prose.
Example: RFC 2045 (MIME Format) - MIME Header = Fields which states "The ordering of the header fields = implied by this BNF definition should be = ignored"

or,

Appr= oach B - Specific unordered nature, cardinality in = prose 

In this approach, authors = document the list as a selection of alternatives, and annotate = the cardinality of each member in = prose

myobject =3D = begin-object member *( separator member ) = end-object
member   =3D member-a
      =    / member-b ; required
      =    / member-c
begin-object =3D %x7B = ; "{"
end-object   =3D = %x7D ; "}"
separator   =  =3D %x2C ; = ","

Pros: Unordered = nature is implicit through the combination of optional alternative = values.
Cons: Cardinality concerns are reduced to = prose.
Example: RFC 5988 (Web Linking) - Link grammar. =  There is some discussion about this specific approach in a rejected = erratum of the same RFC, where Mark Nottingham notes "The = proposed ABNF makes ordering significant, which is NOT specified or = intended. ABNF can never capture all of the constraints on syntax; = that's why we have = prose."
 
Problem

=
My (limited) research implies that ABNF cannot precisely articulate = unordered lists with specific cardinality; authors are left with a = choice as to which aspect to handle in = prose.

There is some discussion about the = problem by Chris Newman here,= and Chris advocates a more formulated arrangement of the = cardinality in prose approach here.

Additionally, from examination of = the earlier ABNF drafts (RFC 2234) I see there was some discussion = of a 'list rule' (#rule) and latterly a 'set
group' with similar = intent, but none of these proposals made it to the final = versions.

I also stumbled across a thread which = implicated that use of the 'list rule' / 'set group' proposals would = cause ambiguities in ABNF, and therefore were not  pursued.  I = appreciate that syntax features must be carefully designed so as not to = introduce ambiguity, but I'm not a lexer / parser specialist, and so = would like to get a view of whether this is something that could be = considered for a latter revision of = ABNF?

Questions

1. Is my understanding that ABNF is unable to = articulate unordered lists with specific cardinality correct, = or am I missing something?

2. Would introducing = functionality to allow such lists fundamentally introduce ambiguity into = the ABNF = syntax?


Many thanks = for your time

Paul
= --Apple-Mail-127-360145334-- --===============8171314804639137650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ abnf-discuss mailing list abnf-discuss@ietf.org https://www.ietf.org/mailman/listinfo/abnf-discuss --===============8171314804639137650==--