From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A5A5C63 for ; Fri, 23 Sep 2016 13:13:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BF23F5 for ; Fri, 23 Sep 2016 13:13:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 7E3B0242B2 for ; Fri, 23 Sep 2016 15:13:12 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org Date: Fri, 23 Sep 2016 15:13:10 +0200 Message-ID: <2344192.PKYylsbkSL@kiwi> In-Reply-To: <20160923115550.GB17871@nex> References: <2232258.WNiT0kZN2f@kiwi> <20160923115550.GB17871@nex> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 23 Sep 2016 13:21:05 +0000 Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 13:13:17 -0000 On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev wrote: > Not sure if the comparison to XML and HTML holds: the lack of closing > tags makes the meaning of individual tokens ambiguous, like I pointed > out before. The use of segments gives at most two levels of nesting, > so any relationship among tokens in the same segment has to rely on > their relative position, which could result in ambiguities, like > whether a tag refers to a single input or the transaction as a whole. Practically all tagged formats make ordering a requirement, so indeed this is relevant, and not unique. For instance if you write;
Some line
Another line
3rd line
you can get a good idea of how ordering is relevant. You can reuse any item many times. Whenever there is a possible confusion the specification specifically explains which order to use. I'm not sure what you mean with the idea this; > The use of segments gives at most two levels of nesting It looks like you assume there is some opening and closing tags, since otherwise there would be no nesting. Such tags are not intended, nor documented. > so any relationship among tokens in the same segment has to rely on > their relative position, which could result in ambiguities, like > whether a tag refers to a single input or the transaction as a whole. I quoted parts of the spec in your previous email stating the same thing, but I'll repeat here. Any place that has any sort of possibility to be ambiguous is specified specifically to have an order. This makes writing and parsing easier. Since you wrote two emails now with the same issue, and I addressed it twice, I would urge you to write out some examples which may be confusing and if you find that the spec is indeed missing requirements then please share it with us. I did this some time ago and it helps understanding the ideas by having actual explicit examples. I am not aware of any sort of ambiguities that the spec allows. Cheers!