9 ms·

You've misunderstood his point with that example. He knows it's ambiguous, but he's telling you that it's an undesirable distinction to make.

lisper 11y ago
OK, but then he's wrong about that. <input type=button/> does not mean the same thing as <input><type>button</type></input>. No matter how you slice it, Erik is wrong here. His translation is lossy, and a lossy translation is bad because it can't be applied bidirectionally.
- evacchi 11y ago
  I believe his point was that what you are losing there does not really carry any extra information
  - lisper 11y ago
    Yes, I know that was his point. My claim is that he was wrong. The distinction does carry extra information. See my other comments in this thread for specific examples.
    - latiera 11y ago
      I think it's safe to say at this point that it is you who are dead wrong and not Erik.
- brandonbloom 11y ago
  Again, you're missing the point. He's saying that those two things shouldn't be different. He's clearly well aware that they are different. His very first sentence is: As long as we think aloud in alternative syntaxes, I actually prefer to break the _incredibly_ stupid syntactic-only separation of elements and attribute values. His entire post is a hypothetical in which you 1) need a structured markup language and 2) are willing to break compatibility with XML.
  - lisper 11y ago
    No, I understand what he is saying. My claim is that he is wrong. They should be different. There's a significant and useful difference between data and metadata, and hence there's a significant and useful difference between tags and attributes, and if you throw out that distinction you lose useful functionality, and specifically you lose the ability to distinguish between, e.g.: <input type=button/> and <input><type>button</type></input> Tags compose in different ways than attributes, that difference reflects a real aspect of the structure of the problem, and hence it's useful.
    - brandonbloom 11y ago
      But it's not a difference between metadata and data. It's a difference between structural representations. Either or both representations can be used to encode data or metadata, but that separation comes from the interpretation of the markup.
      - lisper 11y ago
        Yes. But the two structures at issue are: ((foo baz bar) bing) and (foo (baz bar) bing) The only difference is in the location of a single paren. But latter representation (Erik's) loses information whereas the former does not. All else being equal, and absent a compelling argument why the lost information has no value, it is better not to lose information.
        brandonbloom 11y ago
        1) There's no information to be lost. He's not talking about encoding XML, he's talking about general design criteria for a cleanroom markup language design. I don't understand why this point is hard to get. 2) The idea that it's "better not to lose information" is totally nonsensical because the value of information is contextual. For example, the ascii encoding of this message useful omits the subtleties of my awful handwriting, although you're right: it would be better to preserve the information present in the deep pencil strokes, indicating my frustrating with this thread.
- ICWiener 11y ago
  Erik Naggum even answererd the question about ambiguity himself in the same thread: https://groups.google.com/d/msg/comp.lang.lisp/8eUxiibm_zA/iPcOQlj00UsJ https://groups.google.com/d/msg/comp.lang.lisp/8eUxiibm_zA/i...
  - lisper 11y ago
    The essence of his response: "Whether bar is an attribute or a sub-element of foo is irrelevant to processing them." I disagree. Elements and attributes compose in different ways, and I think this distinction is useful and hence relevant. I think it is self-evident that: <input type=button/> and <input><type>button</type></input> mean different things, and that it is legitimate to try to express either of these things, and so distinguishing between these two different things is useful. In particular, the latter representation implies that: <input>foo</input> <type>bar</type> might mean something. The former representation makes it explicit that the type attribute is intended to be inextricably bound to the input tag. I think that's useful information.
    - ICWiener 11y ago
      Did you just summarize thousands of sentences in a single one? Neither <input type=button/> nor <input><type>button</type></input> does mean anything without a spec of your language, and trying to infer that <input>foo</input> or <type>bar</type> is valid is only due to some pre-conception about the underlying semantics you gave to your data (you chose familiar tag names, after all). If I gave you a sample XML file from work, you'd have a very hard time knowing whether one attribute/element is or isn't optional (or bound) to an element. You'd need a schema/meta-model or even an informal spec. With attributes/elements, you have two ways of defining data where only one is necessary: (input (type button)). The closet example I can think of is for example, if you had a lisp that is not homoiconic but had two different syntaxes for lists at its core: [] and (), without a simple way to abstract over them. Then your data format would be cumbersome to use with no added benefit: whether or not a []-list means something different than a ()-list depends on the specification of your data.
      - 11y ago

lisper 11y ago

OK, but then he's wrong about that. <input type=button/> does not mean the same thing as <input><type>button</type></input>. No matter how you slice it, Erik is wrong here. His translation is lossy, and a lossy translation is bad because it can't be applied bidirectionally.

evacchi 11y ago
I believe his point was that what you are losing there does not really carry any extra information
- lisper 11y ago
  Yes, I know that was his point. My claim is that he was wrong. The distinction does carry extra information. See my other comments in this thread for specific examples.
  - latiera 11y ago
    I think it's safe to say at this point that it is you who are dead wrong and not Erik.
brandonbloom 11y ago
Again, you're missing the point. He's saying that those two things shouldn't be different. He's clearly well aware that they are different. His very first sentence is: As long as we think aloud in alternative syntaxes, I actually prefer to break the _incredibly_ stupid syntactic-only separation of elements and attribute values. His entire post is a hypothetical in which you 1) need a structured markup language and 2) are willing to break compatibility with XML.
- lisper 11y ago
  No, I understand what he is saying. My claim is that he is wrong. They should be different. There's a significant and useful difference between data and metadata, and hence there's a significant and useful difference between tags and attributes, and if you throw out that distinction you lose useful functionality, and specifically you lose the ability to distinguish between, e.g.: <input type=button/> and <input><type>button</type></input> Tags compose in different ways than attributes, that difference reflects a real aspect of the structure of the problem, and hence it's useful.
  - brandonbloom 11y ago
    But it's not a difference between metadata and data. It's a difference between structural representations. Either or both representations can be used to encode data or metadata, but that separation comes from the interpretation of the markup.
    - lisper 11y ago
      Yes. But the two structures at issue are: ((foo baz bar) bing) and (foo (baz bar) bing) The only difference is in the location of a single paren. But latter representation (Erik's) loses information whereas the former does not. All else being equal, and absent a compelling argument why the lost information has no value, it is better not to lose information.
      - brandonbloom 11y ago
        1) There's no information to be lost. He's not talking about encoding XML, he's talking about general design criteria for a cleanroom markup language design. I don't understand why this point is hard to get. 2) The idea that it's "better not to lose information" is totally nonsensical because the value of information is contextual. For example, the ascii encoding of this message useful omits the subtleties of my awful handwriting, although you're right: it would be better to preserve the information present in the deep pencil strokes, indicating my frustrating with this thread.
ICWiener 11y ago
Erik Naggum even answererd the question about ambiguity himself in the same thread: https://groups.google.com/d/msg/comp.lang.lisp/8eUxiibm_zA/iPcOQlj00UsJ https://groups.google.com/d/msg/comp.lang.lisp/8eUxiibm_zA/i...
- lisper 11y ago
  The essence of his response: "Whether bar is an attribute or a sub-element of foo is irrelevant to processing them." I disagree. Elements and attributes compose in different ways, and I think this distinction is useful and hence relevant. I think it is self-evident that: <input type=button/> and <input><type>button</type></input> mean different things, and that it is legitimate to try to express either of these things, and so distinguishing between these two different things is useful. In particular, the latter representation implies that: <input>foo</input> <type>bar</type> might mean something. The former representation makes it explicit that the type attribute is intended to be inextricably bound to the input tag. I think that's useful information.
  - ICWiener 11y ago
    Did you just summarize thousands of sentences in a single one? Neither <input type=button/> nor <input><type>button</type></input> does mean anything without a spec of your language, and trying to infer that <input>foo</input> or <type>bar</type> is valid is only due to some pre-conception about the underlying semantics you gave to your data (you chose familiar tag names, after all). If I gave you a sample XML file from work, you'd have a very hard time knowing whether one attribute/element is or isn't optional (or bound) to an element. You'd need a schema/meta-model or even an informal spec. With attributes/elements, you have two ways of defining data where only one is necessary: (input (type button)). The closet example I can think of is for example, if you had a lisp that is not homoiconic but had two different syntaxes for lists at its core: [] and (), without a simple way to abstract over them. Then your data format would be cumbersome to use with no added benefit: whether or not a []-list means something different than a ()-list depends on the specification of your data.
    - 11y ago