7 ms·

Q. I'm designing my first DTD. Should I use elements or attributes to store data? A. Of course. What else would you use? I giggled.

tannhaeuser 9y ago
If you find yourself torturing your head about whether to use elements or attributes, then you're attempting to use a markup language as a general-purpose data representation format, something it wasn't designed for. SGML and XML are for text, optionally marked up with tags/elements. Attributes are for data about element presentation, and not intended to be displayed directly. It's as simple as that.
- vbezhenar 9y ago
  99% of XML applications are not for text. Take SVG as an example.
  - DaiPlusPlus 9y ago
    SVG was a mistake, but we're stuck with it. Does SVG offer any advantages over, say, EMF/WMF? I know a strong advantage of WMF is that the file format translates 1:1 into GDI calls, which makes it very fast - but I don't see EMF files rendered with anti-aliasing or complex gradients. What about PDF or PostScript?
    - porfirium 9y ago
      >I know a strong advantage of WMF is that the file format translates 1:1 into GDI calls S... strong advantage?
      - DaiPlusPlus 9y ago
        Simplicity of implementation. GDI's drawing primitives exist in practically all other drawing APIs so translating it to Cairo, OpenGL, or Direct2D should be trivial.
        chris_wot 9y ago
        Hardly. You are coupling the Windows GDI to an image format. It’s horrible to parse, and reliant on Windows quirks. It’s really not that great.
    - Samis2001 9y ago
      If you're talking standards, then platform-specific advantages mean precisely nothing.
    - vesinisa 9y ago
      SVG would actually be great if it wasn't such a feature creep. Filters, masks, scripts and animations are supported only by some renderers, often inconsistenly. This does not seem to stop SVG generators producing documents using these features, often unnecessarily. Good SVG can even be human-readable and -editable. I've actually fixed simple broken SVGs with vim and a pocket calculator. PostScript is great but as a binary format not very modern, where text-based formats seem preferred. I had to look up WMF and dumping calls to Microsoft API as an 'open' standards does not sound too exciting, either.
      - fanf2 9y ago
        Postscript is a text format :-) Its disadvantage is that it is a full on programming language, not declarative, so it isn't friendly to editing tools.
        vesinisa 9y ago
        You are right on both counts! I seem to have mixed it with PDF. Sadly, programming is coming to SVG as well with more and more renderers supporting JavaScript. Which might be great for some use cases, but again even further disperses the field of possible generator/feature/renderer combinations that might (will) fail.
    - int_19h 9y ago
      EMF+ has GDI+ primitives in it, which do allow for anti-aliasing and gradients.
    - chris_wot 9y ago
      Oh dear god no. Trying to parse EMF+ is a bit of a nightmare, and it’s not just 1:1 GDI calls, there are dual EMF/EMF+ files, it’s stack based (I suppose not so bad), with klydge after kludge (especially around text)... we use it because we have to.
  - tannhaeuser 9y ago
    True, but SVG's saving grace is that it's designed to be used embedded in HTML (or in XHTML back then). But it doesn't make a lot of sense otherwise. Eg. take SVG2's switch to represent drawing order in a z-index-like property, as opposed to SVG's original "painter model" where drawing order is determined by document order. Basically, SVG doesn't make any use of distinguished markup features such as element content (text elements being the only exception) and document order. Usage of XML in business data and non-text document formats OTOH is an accident IMHO, but is still the most robust format for data exchange and archival in long-term commitment scenarios we've come up with so far, and I don't see that changing anytime soon because there aren't that many open standards being developed anymore.
  - zeveb 9y ago
    Then 99% of XML applications are using it improperly. I can live with that estimate.
- greenhouse_gas 9y ago
  >SGML and XML are for text I'd say anything which can be nested. For example, XML makes sense for a layout engine: Arbitrary amounts of buttons can fit inside a layout? Make it a child. Text in a button? If only one and can't have children tags? Make it an attribute. Else -> Make a child.
- xelxebar 9y ago
  I'm confused. SGML/XML is capable of representing arbitrary tree structures (with metadata attached to the nodes), is it not? Somewhat of a tangent, but I like the name of the alegraic structure for binary trees: magma [0]. [0] https://en.m.wikipedia.org/wiki/Magma_(algebra) https://en.m.wikipedia.org/wiki/Magma_(algebra)
  - dozzie 9y ago
    > I'm confused. SGML/XML is capable of representing arbitrary tree structures (with metadata attached to the nodes), is it not? So is ASN.1, but nobody in their right mind would use ASN.1 as a markup language. The sole fact that it is possible to cram the structure into the format doesn't mean it's a good idea.
    - xelxebar 9y ago
      Wait. A tree is just nested tags, right? I feel like I'm missing something. Here I'm thinking of the correspondence between trees and strings of nested parentheses. So, strings like (a (b c) d) (e f) carry a tree structure, and any (non-associative) multiplication is just a fold operation over a tree. In this case it's like we tag each set of prentheses with a name/operation, so naively XML would seem to naturally represent this kind of thing. I have little actually experience using XML directly though, so am genuinely curious as to what so terrible or "crammy" about my ideas here.
      - fusiongyro 9y ago
        There's a lot of weird ideas floating around in the comments on this link. I don't think you are on the wrong track. There is some mismatch between what XML was designed for and the problems XML is good at solving. It was most certainly designed to be easy for humans to read and write manually. In practice, it is a great interchange format, by which I mean the specific idea of different parties writing XML for exchange between each other, because it can be validated mechanically. There is a large and powerful ecosystem of software that has sprung up around it which simply isn't there for s-exps or JSON. Elsewhere on here, marcoperaza points out that it is kind of against hacker ethic. That's true. But enterprise software often involves multiple separate organizations having to agree on what a document can contain, and XML is great for that, and that use case tends to be more valuable in industry than whether it is the tersest, most flexible or readable format.
- FigmentEngine 9y ago
  this is a sweeping statement, and not true. for example, i often use xml documents with no text - for example <contraindications> <pregnancy/> </contraindications> and really the rule of thumb about attributes vs elements is more about if you are going to need chikdren of item - easier to extend elements with child nodes..
  - JetSpiegel 9y ago
    Might as well use YAML or TOML in that case. Same use case and you are not limited to ASCII strings for identifiers.
    - fusiongyro 9y ago
      You aren't limited to ASCII for XML either.
      - jwilk 9y ago
        Right. Almost all characters are permitted in names, except those which either are or reasonably could be used as delimiters. The intention is to be inclusive rather than exclusive, so that writing systems not yet encoded in Unicode can be used in XML names Source: https://www.w3.org/TR/REC-xml/#sec-common-syn https://www.w3.org/TR/REC-xml/#sec-common-syn
weinzierl 9y ago
I don't know about SGML, but in XML attributes are subject to (mandatory) Attribute-Value Normalization whereas white space normalization for elements can be disabled if you have control over the parser. Both (elements and attributes) are unsuitable to store arbitrary data in a straight forward manner. If you absolutely must, you should know about normalization, XML-whitespace handling and CDATA.
- zaphar 9y ago
  And you, are why the parent poster giggled.
  - weinzierl 9y ago
    Enlighten me. We both said XML is not for data storage, no?
marvy 9y ago
This made me giggle: Q. What's so great about ISO standardization? A. It is often said that one of the advantages of SGML over some other, proprietary, generic markup scheme is that "nobody owns the standard". While this is not strictly true, the ISO's pricing policy certainly has helped to keep the number of people who do own a copy of the Standard at an absolute minimum. [ Ed. note: I'm not exactly sure why this is seen as an advantage, it's just something people say. ]

tannhaeuser 9y ago

If you find yourself torturing your head about whether to use elements or attributes, then you're attempting to use a markup language as a general-purpose data representation format, something it wasn't designed for. SGML and XML are for text, optionally marked up with tags/elements. Attributes are for data about element presentation, and not intended to be displayed directly. It's as simple as that.

vbezhenar 9y ago
99% of XML applications are not for text. Take SVG as an example.
- DaiPlusPlus 9y ago
  SVG was a mistake, but we're stuck with it. Does SVG offer any advantages over, say, EMF/WMF? I know a strong advantage of WMF is that the file format translates 1:1 into GDI calls, which makes it very fast - but I don't see EMF files rendered with anti-aliasing or complex gradients. What about PDF or PostScript?
  - porfirium 9y ago
    >I know a strong advantage of WMF is that the file format translates 1:1 into GDI calls S... strong advantage?
    - DaiPlusPlus 9y ago
      Simplicity of implementation. GDI's drawing primitives exist in practically all other drawing APIs so translating it to Cairo, OpenGL, or Direct2D should be trivial.
      - chris_wot 9y ago
        Hardly. You are coupling the Windows GDI to an image format. It’s horrible to parse, and reliant on Windows quirks. It’s really not that great.
  - Samis2001 9y ago
    If you're talking standards, then platform-specific advantages mean precisely nothing.
  - vesinisa 9y ago
    SVG would actually be great if it wasn't such a feature creep. Filters, masks, scripts and animations are supported only by some renderers, often inconsistenly. This does not seem to stop SVG generators producing documents using these features, often unnecessarily. Good SVG can even be human-readable and -editable. I've actually fixed simple broken SVGs with vim and a pocket calculator. PostScript is great but as a binary format not very modern, where text-based formats seem preferred. I had to look up WMF and dumping calls to Microsoft API as an 'open' standards does not sound too exciting, either.
    - fanf2 9y ago
      Postscript is a text format :-) Its disadvantage is that it is a full on programming language, not declarative, so it isn't friendly to editing tools.
      - vesinisa 9y ago
        You are right on both counts! I seem to have mixed it with PDF. Sadly, programming is coming to SVG as well with more and more renderers supporting JavaScript. Which might be great for some use cases, but again even further disperses the field of possible generator/feature/renderer combinations that might (will) fail.
  - int_19h 9y ago
    EMF+ has GDI+ primitives in it, which do allow for anti-aliasing and gradients.
  - chris_wot 9y ago
    Oh dear god no. Trying to parse EMF+ is a bit of a nightmare, and it’s not just 1:1 GDI calls, there are dual EMF/EMF+ files, it’s stack based (I suppose not so bad), with klydge after kludge (especially around text)... we use it because we have to.
- tannhaeuser 9y ago
  True, but SVG's saving grace is that it's designed to be used embedded in HTML (or in XHTML back then). But it doesn't make a lot of sense otherwise. Eg. take SVG2's switch to represent drawing order in a z-index-like property, as opposed to SVG's original "painter model" where drawing order is determined by document order. Basically, SVG doesn't make any use of distinguished markup features such as element content (text elements being the only exception) and document order. Usage of XML in business data and non-text document formats OTOH is an accident IMHO, but is still the most robust format for data exchange and archival in long-term commitment scenarios we've come up with so far, and I don't see that changing anytime soon because there aren't that many open standards being developed anymore.
- zeveb 9y ago
  Then 99% of XML applications are using it improperly. I can live with that estimate.
greenhouse_gas 9y ago
>SGML and XML are for text I'd say anything which can be nested. For example, XML makes sense for a layout engine: Arbitrary amounts of buttons can fit inside a layout? Make it a child. Text in a button? If only one and can't have children tags? Make it an attribute. Else -> Make a child.
xelxebar 9y ago
I'm confused. SGML/XML is capable of representing arbitrary tree structures (with metadata attached to the nodes), is it not? Somewhat of a tangent, but I like the name of the alegraic structure for binary trees: magma [0]. [0] https://en.m.wikipedia.org/wiki/Magma_(algebra) https://en.m.wikipedia.org/wiki/Magma_(algebra)
- dozzie 9y ago
  > I'm confused. SGML/XML is capable of representing arbitrary tree structures (with metadata attached to the nodes), is it not? So is ASN.1, but nobody in their right mind would use ASN.1 as a markup language. The sole fact that it is possible to cram the structure into the format doesn't mean it's a good idea.
  - xelxebar 9y ago
    Wait. A tree is just nested tags, right? I feel like I'm missing something. Here I'm thinking of the correspondence between trees and strings of nested parentheses. So, strings like (a (b c) d) (e f) carry a tree structure, and any (non-associative) multiplication is just a fold operation over a tree. In this case it's like we tag each set of prentheses with a name/operation, so naively XML would seem to naturally represent this kind of thing. I have little actually experience using XML directly though, so am genuinely curious as to what so terrible or "crammy" about my ideas here.
    - fusiongyro 9y ago
      There's a lot of weird ideas floating around in the comments on this link. I don't think you are on the wrong track. There is some mismatch between what XML was designed for and the problems XML is good at solving. It was most certainly designed to be easy for humans to read and write manually. In practice, it is a great interchange format, by which I mean the specific idea of different parties writing XML for exchange between each other, because it can be validated mechanically. There is a large and powerful ecosystem of software that has sprung up around it which simply isn't there for s-exps or JSON. Elsewhere on here, marcoperaza points out that it is kind of against hacker ethic. That's true. But enterprise software often involves multiple separate organizations having to agree on what a document can contain, and XML is great for that, and that use case tends to be more valuable in industry than whether it is the tersest, most flexible or readable format.
FigmentEngine 9y ago
this is a sweeping statement, and not true. for example, i often use xml documents with no text - for example <contraindications> <pregnancy/> </contraindications> and really the rule of thumb about attributes vs elements is more about if you are going to need chikdren of item - easier to extend elements with child nodes..
- JetSpiegel 9y ago
  Might as well use YAML or TOML in that case. Same use case and you are not limited to ASCII strings for identifiers.
  - fusiongyro 9y ago
    You aren't limited to ASCII for XML either.
    - jwilk 9y ago
      Right. Almost all characters are permitted in names, except those which either are or reasonably could be used as delimiters. The intention is to be inclusive rather than exclusive, so that writing systems not yet encoded in Unicode can be used in XML names Source: https://www.w3.org/TR/REC-xml/#sec-common-syn https://www.w3.org/TR/REC-xml/#sec-common-syn

weinzierl 9y ago

I don't know about SGML, but in XML attributes are subject to (mandatory) Attribute-Value Normalization whereas white space normalization for elements can be disabled if you have control over the parser. Both (elements and attributes) are unsuitable to store arbitrary data in a straight forward manner. If you absolutely must, you should know about normalization, XML-whitespace handling and CDATA.

zaphar 9y ago
And you, are why the parent poster giggled.
- weinzierl 9y ago
  Enlighten me. We both said XML is not for data storage, no?

marvy 9y ago

This made me giggle: Q. What's so great about ISO standardization? A. It is often said that one of the advantages of SGML over some other, proprietary, generic markup scheme is that "nobody owns the standard". While this is not strictly true, the ISO's pricing policy certainly has helped to keep the number of people who do own a copy of the Standard at an absolute minimum. [ Ed. note: I'm not exactly sure why this is seen as an advantage, it's just something people say. ]