6 ms·

<star bayerName="Beta Pictoris" spectralType="A6V" mass="1.75" luminosity="8.7"> <position rightAscension="05h 47m 17.1s"

<star bayerName="Beta Pictoris" spectralType="A6V" mass="1.75" luminosity="8.7"> <position rightAscension="05h 47m 17.1s" declination="−51°03′59"" distance="63.4ly"/> <age min="20My" max="24My"/> </star> The tag-content ratio of XML is only as bad as you make it.

tacone 4y ago
Of course. The problem with that approach is that every value becomes a string with no hint about which type it should be converted to. In comparison JSON has - at least - basic types.
- __afk__ 4y ago
  There are more ways to type (at schema and inline) and more types (see the common XSD types) available OOB in XML than JSON could ever have. Then we can introduce custom types. JSON looks rather impoverished in comparison.
  - mattpallissard 4y ago
    Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality. Admittedly, XML isn't the most pleasant syntax to interact with by hand.
    - Devasta 4y ago
      XML syntax is fine so long as you're using a proper IDE. I manage a team of reporting analysts and all of them come from Business Analyst or Accountancy backgrounds; they write and maintain XSLT transforms just fine, once they spend a day or two getting used to IntelliJ IDEA.
    - crispyambulance 4y ago
      XML was a great idea. At some point in the early naughts, however, XML-abuse became rampant-- too many crappy tools, too many half-assed attempts at putting square pegs into round holes. It didn't help that XML got inextricably associated with those horrible over-complicated ws-* standards that ended up sending Russian novel-sized "hello world" information exchanges. The main idea, however, was wonderful. An information exchange format (xml itself), a way to define schemas (xsd), a transformation language (xslt), and stylesheets (xsl?). I kind of miss it.
      - dragonwriter 4y ago
        XSL (Extensible Stylesheet Language) the stylesheet part, it included XSLT (transform), XPath, and XSL-FO (XSL Format Objects). XSLT and XPath each went on to great solo careers, XSL-FO kind of fizzled when XML+XSL failed to displace HTML+CSS.
        spiralx 4y ago
        XSL:FO is great for turning into PDFs though. There's also XQuery for transformations and XSD/RelaxNG for schemas, the whole combination of XML database, WYSIWYG (via XSLT) XML editor and output transformations is very powerful, every journal we published and every site we ran at the British Medical Journal was generated that way.
      - giantrobot 4y ago
        I miss XSLT every time I see megabytes of JavaScript converting some JSON into a soup of HTML to display in browsers. A bunch of JavaScript with a bunch of overwrought "components" is serving as a very complicated templating system. A lot of really stupid JavaScript could be done fairly easily with XSLT natively inside a browser engine. An XML document can point to its own XSL(s) so get rendered to the appropriate delivery format or just used directly as data.
        phoehne 4y ago
        I don't miss it. I had several projects where it seemed like a good idea. I pushed it as a good idea. I really wanted it to work. Some developers (usually the sharper bulbs) got it. A lot of developers really struggled with it. Especially the folks who were 'front end' developers. Even in the 2000's, when everything was trying to go XML, staffing those roles was hard.
    - dragonwriter 4y ago
      > Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality. No, I'm pretty sure that if they have only used XML syntax as a data rep and not XML-associated tooling like XSD, they are quite aware that when thet say they hate XML they are talking about syntax. OTOH. I am surprised at the number of people that seem to thing “has a schema language that can be used to specify structure beyond just the basic raw language” distinguishes XML from other data representation languages. Or, more generally, the way that “if you don’t like XML, maybe your problem is you aren’t using enough of it” has become an edgy contrarian position rather than steretypical establishment enterprise consultant thing it was 15 or so years ago.
  - zozbot234 4y ago
    JSON-LD can express any RDF datatype, and some XSD types (though not all) have standardized matches in RDF.
- electroly 4y ago
  The quotes in XML don't make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. XML schemas will give you all the type information and automatic validation you can swallow. Typing in XML is far richer than in JSON. There's even a date type!
  - smitty1e 4y ago
    You mean an .xsd? JSON has .avro, I thought. It's all data. Validation logic is sold separately.
  - dragonwriter 4y ago
    > The quotes in XML don’t make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. JSON, like XML, has several schema languages, which have widely-available libraries for generating host language typings, validation, etc. > Typing in XML is far richer than in JSON. There’s even a date type! JSON Type Definition has timestamp, JSON Schema has date, date-time, time, and duration.
    - int_19h 4y ago
      The nice thing about XML being an extensible markup language is that schemas (and metadata like xsi:type) could be easily written inline, making the document fully self-contained.
      - mdaniel 4y ago
        I haven't personally tried such a stunt, but I'd bet it's possible to do that with JSON Schema, too, if the schema resolver tolerates the same self-references style in `$schema`. My experience with the tooling is "lol, yeah right" but shrug seems reasonable { "$schema": "#/$theSchema", "$theSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "MySchema", "type": "object", "properties": { "productId": { "description": "The unique identifier for a product", "type": "integer" }, "productName": { "description": "Name of the product", "type": "string" }, "price": { "description": "The price of the product", "type": "number", "exclusiveMinimum": 0 } } }, "productId": 1, "productName": "An ice sculpture", "price": 12.50 }
- stcroixx 4y ago
  You've got to learn XML and XSD first, then you'll see that's not what you're looking at at all.
- bfgoodrich 4y ago
  [dead]
Koshkin 4y ago
You mean "markup" vs. "content." At least, such was the original intent: you store what is considered data as content, and metadata of any sort as markup. In many use cases, however, this distinction is now ignored or simply non-existent. One other "abuse" of XML as a structured representation of data is to embed a "foreign" (i.e. non-XML) syntax, like in the above example of rightAscension (which is not the worst example, to be fair).
- ahepp 4y ago
  I often feel confused about when to use tags and when to use attributes. Is there principled guidance on this?
  - epalm 4y ago
    I generally try to reserve attributes for metadata. That is, data about the data contained in the tag.
  - chipsa 4y ago
    No? But I think that if you have substructure, like a position or can reasonably have multiples of the thing, it should be a tag.
  - int_19h 4y ago
    There is none. In general, the main difference is that elements are all ordered wrt each other, while attributes are not. This ought to make the choice simple, except that attributes also cannot contain nested data structures. A particularly unusual take is to ignore the difference and allow either attributes or child elements as different ways to do the same thing. This is what XAML does; e.g. this: <Button Content="Foo" /> is identical to: <Button> <Button.Content>Foo</Button.Content> </Button>
  - dwaite 4y ago
    There is for user-viewable markup-enhanced documents, like SVG and HTML - which is pretty much what you experience with SVG and HTML authorship by hand. If data should be presented to the user by a user agent that doesn't understand extensions to the markup, it should be using text nodes. If it is a modification to a subset of a block of text, such as emphasizing a word, it should be a new element. If it is a block of semantic metadata, you would structure that as a hierarchy of elements with attributes. Otherwise, it is usually an attribute on an existing element. SVG is a bit of a zany format in XML because so much of the content is points or encoded data, which get stuffed in some truly epic attributes. XML wasn't really made for pure data formats, even though shoehorning that in was the majority of the market's effort.
somat 4y ago
I think that if you are encoding data, like your example, you should not use attributes, attributes are best used when you are using xml in it's text markup role. In the text markup role tags are like functions and the attributes are parameters to the functions. but in the data encoding role the attributes are another redundant key value store and you end up with a confusing mix where some of your kv's are in the tag and some are in the attributes and it is a bit of a mess.
- kijin 4y ago
  In the parent's example, every value is in the attributes. Tags only serve as objects that contain those values, and never have "content" of their own. This style might not have been the original intent of XML, but at least it's consistent and easily readable.
  - somat 4y ago
    The parent example was remarkably consistent, far from the worst I have seen however... There is a star tag(presumably a list of star tags) each of which contains a single position tag. The star tag is is full of attributes, and the position tag is full of attributes, now you have a complicated(not that complicated, hyperbola is for arguments sake) access method where you need to do different things based on what data you want out of the structure. Why was the position tag not an attribute? What happens when you want to encode the rightAscension, and declination, they will get their own tag, in fact they probably just should have tagged everything in the first place and avoided attributes.
klysm 4y ago
I still find closing tags redundant.
chrismorgan 4y ago
If going in this direction, I’d want justification for position and age still being separate elements. Elements are clearly suitable or necessary when you want multiple values, order-sensitivity, or to contain something other than a single text value. But that’s not the case here, and I find “hierarchical structure” or “property grouping” to be weak justification. So then: <star bayerName="Beta Pictoris" spectralType="A6V" mass="1.75" luminosity="8.7" rightAscension="05h 47m 17.1s" declination="−51°03′59″" distance="63.4ly" minAge="20My" maxAge="24My"/> We are, of course, playing into the article’s second footnote here. (Also: I’m curious why you turned the original document’s ″ (U+2033 DOUBLE PRIME) into " (", U+0022 QUOTATION MARK).)
- sixbrx 4y ago
  Interesting thing about the position coordinates, is that the position really needs an "epoch" metadata attribute, like "2000" or "2050", because they are relative to the equinox which moves over the years. So maybe the fact that this kind of thing can rear its head unexpectedly might be an argument for favoring separate elements to group fields? If that new attribute were thrown in with the other attributes of "star" it looks like it qualifies the star, but it only really qualifies the coordinates.
- Devasta 4y ago
  I changed the character because I'm a dumbass who thought I was looking at a quotation mark. I don't ever see double prime at my job, so it was probably muscle memory.

tacone 4y ago

Of course. The problem with that approach is that every value becomes a string with no hint about which type it should be converted to. In comparison JSON has - at least - basic types.

__afk__ 4y ago
There are more ways to type (at schema and inline) and more types (see the common XSD types) available OOB in XML than JSON could ever have. Then we can introduce custom types. JSON looks rather impoverished in comparison.
- mattpallissard 4y ago
  Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality. Admittedly, XML isn't the most pleasant syntax to interact with by hand.
  - Devasta 4y ago
    XML syntax is fine so long as you're using a proper IDE. I manage a team of reporting analysts and all of them come from Business Analyst or Accountancy backgrounds; they write and maintain XSLT transforms just fine, once they spend a day or two getting used to IntelliJ IDEA.
  - crispyambulance 4y ago
    XML was a great idea. At some point in the early naughts, however, XML-abuse became rampant-- too many crappy tools, too many half-assed attempts at putting square pegs into round holes. It didn't help that XML got inextricably associated with those horrible over-complicated ws-* standards that ended up sending Russian novel-sized "hello world" information exchanges. The main idea, however, was wonderful. An information exchange format (xml itself), a way to define schemas (xsd), a transformation language (xslt), and stylesheets (xsl?). I kind of miss it.
    - dragonwriter 4y ago
      XSL (Extensible Stylesheet Language) the stylesheet part, it included XSLT (transform), XPath, and XSL-FO (XSL Format Objects). XSLT and XPath each went on to great solo careers, XSL-FO kind of fizzled when XML+XSL failed to displace HTML+CSS.
      - spiralx 4y ago
        XSL:FO is great for turning into PDFs though. There's also XQuery for transformations and XSD/RelaxNG for schemas, the whole combination of XML database, WYSIWYG (via XSLT) XML editor and output transformations is very powerful, every journal we published and every site we ran at the British Medical Journal was generated that way.
    - giantrobot 4y ago
      I miss XSLT every time I see megabytes of JavaScript converting some JSON into a soup of HTML to display in browsers. A bunch of JavaScript with a bunch of overwrought "components" is serving as a very complicated templating system. A lot of really stupid JavaScript could be done fairly easily with XSLT natively inside a browser engine. An XML document can point to its own XSL(s) so get rendered to the appropriate delivery format or just used directly as data.
      - phoehne 4y ago
        I don't miss it. I had several projects where it seemed like a good idea. I pushed it as a good idea. I really wanted it to work. Some developers (usually the sharper bulbs) got it. A lot of developers really struggled with it. Especially the folks who were 'front end' developers. Even in the 2000's, when everything was trying to go XML, staffing those roles was hard.
  - dragonwriter 4y ago
    > Many people "love yaml" and "hate XML" but never dealt with XSD, so they don't even realize what they're talking about syntax instead of functionality. No, I'm pretty sure that if they have only used XML syntax as a data rep and not XML-associated tooling like XSD, they are quite aware that when thet say they hate XML they are talking about syntax. OTOH. I am surprised at the number of people that seem to thing “has a schema language that can be used to specify structure beyond just the basic raw language” distinguishes XML from other data representation languages. Or, more generally, the way that “if you don’t like XML, maybe your problem is you aren’t using enough of it” has become an edgy contrarian position rather than steretypical establishment enterprise consultant thing it was 15 or so years ago.
- zozbot234 4y ago
  JSON-LD can express any RDF datatype, and some XSD types (though not all) have standardized matches in RDF.
electroly 4y ago
The quotes in XML don't make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. XML schemas will give you all the type information and automatic validation you can swallow. Typing in XML is far richer than in JSON. There's even a date type!
- smitty1e 4y ago
  You mean an .xsd? JSON has .avro, I thought. It's all data. Validation logic is sold separately.
- dragonwriter 4y ago
  > The quotes in XML don’t make it a string; in the XML schema you can specify the type (and so much more). JSON has a lot of benefits but it absolutely loses this particular comparison. JSON, like XML, has several schema languages, which have widely-available libraries for generating host language typings, validation, etc. > Typing in XML is far richer than in JSON. There’s even a date type! JSON Type Definition has timestamp, JSON Schema has date, date-time, time, and duration.
  - int_19h 4y ago
    The nice thing about XML being an extensible markup language is that schemas (and metadata like xsi:type) could be easily written inline, making the document fully self-contained.
    - mdaniel 4y ago
      I haven't personally tried such a stunt, but I'd bet it's possible to do that with JSON Schema, too, if the schema resolver tolerates the same self-references style in `$schema`. My experience with the tooling is "lol, yeah right" but shrug seems reasonable { "$schema": "#/$theSchema", "$theSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "MySchema", "type": "object", "properties": { "productId": { "description": "The unique identifier for a product", "type": "integer" }, "productName": { "description": "Name of the product", "type": "string" }, "price": { "description": "The price of the product", "type": "number", "exclusiveMinimum": 0 } } }, "productId": 1, "productName": "An ice sculpture", "price": 12.50 }
stcroixx 4y ago
You've got to learn XML and XSD first, then you'll see that's not what you're looking at at all.
bfgoodrich 4y ago
[dead]

Koshkin 4y ago

You mean "markup" vs. "content." At least, such was the original intent: you store what is considered data as content, and metadata of any sort as markup. In many use cases, however, this distinction is now ignored or simply non-existent. One other "abuse" of XML as a structured representation of data is to embed a "foreign" (i.e. non-XML) syntax, like in the above example of rightAscension (which is not the worst example, to be fair).

ahepp 4y ago
I often feel confused about when to use tags and when to use attributes. Is there principled guidance on this?
- epalm 4y ago
  I generally try to reserve attributes for metadata. That is, data about the data contained in the tag.
- chipsa 4y ago
  No? But I think that if you have substructure, like a position or can reasonably have multiples of the thing, it should be a tag.
- int_19h 4y ago
  There is none. In general, the main difference is that elements are all ordered wrt each other, while attributes are not. This ought to make the choice simple, except that attributes also cannot contain nested data structures. A particularly unusual take is to ignore the difference and allow either attributes or child elements as different ways to do the same thing. This is what XAML does; e.g. this: <Button Content="Foo" /> is identical to: <Button> <Button.Content>Foo</Button.Content> </Button>
- dwaite 4y ago
  There is for user-viewable markup-enhanced documents, like SVG and HTML - which is pretty much what you experience with SVG and HTML authorship by hand. If data should be presented to the user by a user agent that doesn't understand extensions to the markup, it should be using text nodes. If it is a modification to a subset of a block of text, such as emphasizing a word, it should be a new element. If it is a block of semantic metadata, you would structure that as a hierarchy of elements with attributes. Otherwise, it is usually an attribute on an existing element. SVG is a bit of a zany format in XML because so much of the content is points or encoded data, which get stuffed in some truly epic attributes. XML wasn't really made for pure data formats, even though shoehorning that in was the majority of the market's effort.

somat 4y ago

I think that if you are encoding data, like your example, you should not use attributes, attributes are best used when you are using xml in it's text markup role. In the text markup role tags are like functions and the attributes are parameters to the functions. but in the data encoding role the attributes are another redundant key value store and you end up with a confusing mix where some of your kv's are in the tag and some are in the attributes and it is a bit of a mess.

kijin 4y ago
In the parent's example, every value is in the attributes. Tags only serve as objects that contain those values, and never have "content" of their own. This style might not have been the original intent of XML, but at least it's consistent and easily readable.
- somat 4y ago
  The parent example was remarkably consistent, far from the worst I have seen however... There is a star tag(presumably a list of star tags) each of which contains a single position tag. The star tag is is full of attributes, and the position tag is full of attributes, now you have a complicated(not that complicated, hyperbola is for arguments sake) access method where you need to do different things based on what data you want out of the structure. Why was the position tag not an attribute? What happens when you want to encode the rightAscension, and declination, they will get their own tag, in fact they probably just should have tagged everything in the first place and avoided attributes.

klysm 4y ago

I still find closing tags redundant.

chrismorgan 4y ago

If going in this direction, I’d want justification for position and age still being separate elements. Elements are clearly suitable or necessary when you want multiple values, order-sensitivity, or to contain something other than a single text value. But that’s not the case here, and I find “hierarchical structure” or “property grouping” to be weak justification. So then: <star bayerName="Beta Pictoris" spectralType="A6V" mass="1.75" luminosity="8.7" rightAscension="05h 47m 17.1s" declination="−51°03′59″" distance="63.4ly" minAge="20My" maxAge="24My"/> We are, of course, playing into the article’s second footnote here. (Also: I’m curious why you turned the original document’s ″ (U+2033 DOUBLE PRIME) into " (", U+0022 QUOTATION MARK).)

sixbrx 4y ago
Interesting thing about the position coordinates, is that the position really needs an "epoch" metadata attribute, like "2000" or "2050", because they are relative to the equinox which moves over the years. So maybe the fact that this kind of thing can rear its head unexpectedly might be an argument for favoring separate elements to group fields? If that new attribute were thrown in with the other attributes of "star" it looks like it qualifies the star, but it only really qualifies the coordinates.
Devasta 4y ago
I changed the character because I'm a dumbass who thought I was looking at a quotation mark. I don't ever see double prime at my job, so it was probably muscle memory.