6 ms·

> A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements muc

by wtbob 10y ago

> A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements much less verbose, and reduces the need for attributes. Then just change '<tagname>' to '(tagname,' and '</>' to ')' and you'll have S-expressions. Consider this: (feed (version 1) (title "Example Feed") (link http://example.org/) (updated "2003-12-13T18:30:02Z") (author (name "John Doe")) (id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6) (entry (title "Atom-Powered Robots Run Amok") (link http://example.org/2003/12/13/atom03) (id urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a) (updated "2003-12-13T18:30:02Z") (summary "Some text."))) That is a canonical S-expression (for a Scheme or Common Lisp reader, just quote the URIs too) version of: <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements. And compare to your proposed version: <feed> <title>Example Feed</> <link>http://example.org/</> <updated>2003-12-13T18:30:02Z</> <author> <name>John Doe</> </> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</> <entry> <title>Atom-Powered Robots Run Amok</> <link>http://example.org/2003/12/13/atom03</> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</> <updated>2003-12-13T18:30:02Z</> <summary>Some text.</> </> </> I think it's pretty clear which is the most readable and elegant.

JoshTriplett 10y ago
If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version. Also put the author and name tags on the same line, as you did with the S-expressions: <feed> <title>Example Feed</> <link>http://example.org/</> <updated>2003-12-13T18:30:02Z</> <author><name>John Doe</></> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</> <entry> <title>Atom-Powered Robots Run Amok</> <link>http://example.org/2003/12/13/atom03</> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</> <updated>2003-12-13T18:30:02Z</> <summary>Some text.</> </> </> That said, I like S-expressions too, and I wish more parsers and tools existed for them, such as schemas, query tools, and simple transformation tools.
- wtbob 10y ago
  > If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version. When I pasted it in from https://validator.w3.org/feed/docs/atom.html#sampleFeed https://validator.w3.org/feed/docs/atom.html#sampleFeed I guess I lost the indents. No idea why: they are clearly there in the original.
erlehmann_ 10y ago
The second and third examples do not have namespaces. How would you include an HTML summary, for example?
- wtbob 10y ago
  > The second and third examples do not have namespaces. > How would you include an HTML summary, for example? As a text attribute, honestly — which would be necessary in XML as well (you could embed XHTML in XML, but not HTML). And in the general case, embedding one variant of XML inside another, rather than embedding a character-encoded variant of XML inside another, doesn't seem all that useful. How often do transforms need to reach all the way in like that? I guess it's cool if it's possible, which is why I like S-expressions all the way down. But I don't think it's all that useful, as opposed to neat.
  - erlehmann_ 10y ago
    > How often do transforms need to reach all the way in like that? In my experience, almost every time XSLT is used on real-world documents, those are documents with multiple namespaces. XSLT stylesheets themselves are also documents that have multiple namespaces. Example: Atom feeds often contain XHTML content. It is a common problem with RSS that it does not specify if the content of an element is HTML or plain text. I have found that arguments that doubt a feature is necassary from people who can not imagine use cases are almost invariably wrong, while arguments that doubt a feature is necessary from people who list use cases and why they think those are better solved otherwise or even left unsolved are often right. Your post seems like an example of the former; would you say that complex real-world content with namespaces could sway you in favor of them?
    - lmm 10y ago
      I would be convinced if I saw real-world examples where having namespaces gave an advantage over not having namespaces. I can see the value in specifying whether the content of a given node is XHTML or text. I can at least theoretically see value in allowing nesting XHTML without a layer of escaping. I can't see any non-theoretical way in which namespaces are necessary to accomplish these things.
j4_james 10y ago
> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements. I think the distinction here is that the one is an identifier which is not intended to be dereferencable, and the other is a link to a resource which has to be retrievable. In the good old days the id would most likely have been a URN and the link a URL, but that distinction was being discouraged in favour of the more general URI term at the time the Atom spec was developed. [1] So while they're syntactically both URIs (well technically IRIs), they're functionally quite different. It may be debatable whether that's a good enough reason for the one to be an element value and the other an attribute value, but I don't think that decision was obviously wrong. [1] https://tools.ietf.org/html/rfc3986#section-1.1.3 https://tools.ietf.org/html/rfc3986#section-1.1.3

by wtbob 10y ago

JoshTriplett 10y ago

If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version. Also put the author and name tags on the same line, as you did with the S-expressions: <feed> <title>Example Feed</> <link>http://example.org/</> <updated>2003-12-13T18:30:02Z</> <author><name>John Doe</></> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</> <entry> <title>Atom-Powered Robots Run Amok</> <link>http://example.org/2003/12/13/atom03</> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</> <updated>2003-12-13T18:30:02Z</> <summary>Some text.</> </> </> That said, I like S-expressions too, and I wish more parsers and tools existed for them, such as schemas, query tools, and simple transformation tools.

wtbob 10y ago
> If you're going to compare the two fairly, include appropriate indentation for both, not just the S-expression version. When I pasted it in from https://validator.w3.org/feed/docs/atom.html#sampleFeed https://validator.w3.org/feed/docs/atom.html#sampleFeed I guess I lost the indents. No idea why: they are clearly there in the original.

erlehmann_ 10y ago

The second and third examples do not have namespaces. How would you include an HTML summary, for example?

wtbob 10y ago
> The second and third examples do not have namespaces. > How would you include an HTML summary, for example? As a text attribute, honestly — which would be necessary in XML as well (you could embed XHTML in XML, but not HTML). And in the general case, embedding one variant of XML inside another, rather than embedding a character-encoded variant of XML inside another, doesn't seem all that useful. How often do transforms need to reach all the way in like that? I guess it's cool if it's possible, which is why I like S-expressions all the way down. But I don't think it's all that useful, as opposed to neat.
- erlehmann_ 10y ago
  > How often do transforms need to reach all the way in like that? In my experience, almost every time XSLT is used on real-world documents, those are documents with multiple namespaces. XSLT stylesheets themselves are also documents that have multiple namespaces. Example: Atom feeds often contain XHTML content. It is a common problem with RSS that it does not specify if the content of an element is HTML or plain text. I have found that arguments that doubt a feature is necassary from people who can not imagine use cases are almost invariably wrong, while arguments that doubt a feature is necessary from people who list use cases and why they think those are better solved otherwise or even left unsolved are often right. Your post seems like an example of the former; would you say that complex real-world content with namespaces could sway you in favor of them?
  - lmm 10y ago
    I would be convinced if I saw real-world examples where having namespaces gave an advantage over not having namespaces. I can see the value in specifying whether the content of a given node is XHTML or text. I can at least theoretically see value in allowing nesting XHTML without a layer of escaping. I can't see any non-theoretical way in which namespaces are necessary to accomplish these things.

j4_james 10y ago

> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements. I think the distinction here is that the one is an identifier which is not intended to be dereferencable, and the other is a link to a resource which has to be retrievable. In the good old days the id would most likely have been a URN and the link a URL, but that distinction was being discouraged in favour of the more general URI term at the time the Atom spec was developed. [1] So while they're syntactically both URIs (well technically IRIs), they're functionally quite different. It may be debatable whether that's a good enough reason for the one to be an element value and the other an attribute value, but I don't think that decision was obviously wrong. [1] https://tools.ietf.org/html/rfc3986#section-1.1.3 https://tools.ietf.org/html/rfc3986#section-1.1.3