📅 Original date posted:2016-09-23
📝 Original message: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;
<div> Some line </br>Another line</br>3rd line</div>
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!
Tom [ARCHIVE] /
npub1h3…8z4k5
2023-06-07 17:53:30
in reply to nevent1q…nsfl
Author Public Key
npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5Published at
2023-06-07 17:53:30Event JSON
{
"id": "2ec54b32bc1d1a168c2eb0f1e876facdb11ef17e77dea87d7a96e1689ef2dd55",
"pubkey": "bc4b5c3c366f36f93aa3e261f5c7832ecb85137537baf5e8f00a4321e85f0477",
"created_at": 1686160410,
"kind": 1,
"tags": [
[
"e",
"1a569d98e0e6ce5c9d61181fddad681419ffdb691b73a42ccb4919035df06596",
"",
"root"
],
[
"e",
"e2540028b3df02484e12fd0d57840370186d2d475281529b1322adf420769344",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2016-09-23\n📝 Original message:On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev \nwrote: \n\u003e Not sure if the comparison to XML and HTML holds: the lack of closing\n\u003e tags makes the meaning of individual tokens ambiguous, like I pointed\n\u003e out before. The use of segments gives at most two levels of nesting,\n\u003e so any relationship among tokens in the same segment has to rely on\n\u003e their relative position, which could result in ambiguities, like\n\u003e whether a tag refers to a single input or the transaction as a whole.\n\n\nPractically all tagged formats make ordering a requirement, so indeed this \nis relevant, and not unique.\n\nFor instance if you write;\n \u003cdiv\u003e Some line \u003c/br\u003eAnother line\u003c/br\u003e3rd line\u003c/div\u003e\nyou can get a good idea of how ordering is relevant. You can reuse any item \nmany times.\n\nWhenever there is a possible confusion the specification specifically \nexplains which order to use.\n\nI'm not sure what you mean with the idea this;\n\n\u003e The use of segments gives at most two levels of nesting\n\nIt looks like you assume there is some opening and closing tags, since \notherwise there would be no nesting.\nSuch tags are not intended, nor documented.\n\n\u003e so any relationship among tokens in the same segment has to rely on\n\u003e their relative position, which could result in ambiguities, like\n\u003e whether a tag refers to a single input or the transaction as a whole.\n\nI quoted parts of the spec in your previous email stating the same thing, \nbut I'll repeat here.\nAny place that has any sort of possibility to be ambiguous is specified \nspecifically to have an order. This makes writing and parsing easier.\n\nSince you wrote two emails now with the same issue, and I addressed it \ntwice, I would urge you to write out some examples which may be confusing \nand if you find that the spec is indeed missing requirements then please \nshare it with us. I did this some time ago and it helps understanding the \nideas by having actual explicit examples. I am not aware of any sort of \nambiguities that the spec allows.\n\nCheers!",
"sig": "c5b95e552062d33ed5afd71b85f9847826b00243bfe8c9528ffbcfe6a9fb0157e8812ae71eb085c38e7a13d28f15909bb76efee442e7a1dd69793ca5045841d1"
}