3 ms·

My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it's not obvious whic

My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. You can also use multiple child tags and it's not obvious whether you should mix multiple kinds or not. The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. You can have style guidelines, but other data formats don't really need that to answer those questions. More flexible is not always better, especially in languages.

thesuperbigfrog 6y ago
>> XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. >> The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. Either approach is valid. Having a choice about how to structure the data is not a bad thing. My preferred approach is to use attributes for simple key-value pairs that are mainly used to select structured data found in child tags. If you have configuration data that is stored as XML, you could use attibutes to mark where the contained structured data should be used. For example: 1) language localization data could be stored stored in XML with attributes describing the language or locale; 2) build configuration settings might be stored in XML with attributes describing the target platform or CPU architecture. For more formalized data formats, create an XML Schema that defines what the XML data should look like and then you can easily validate that the XML data is structured correctly and even generate parsers or XML to programming language bindings.
- SiempreViernes 6y ago
  > Either approach is valid. Having a choice about how to structure the data is not a bad thing. I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. In another sense, xml gives no options: your data is going to live in a string.
  - thesuperbigfrog 6y ago
    >> I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. A clear structure can be defined with an XML Schema Definition (XSD) document: https://en.wikipedia.org/wiki/XML_Schema_(W3C) https://en.wikipedia.org/wiki/XML_Schema_(W3C) An XML Schema Definition defines the structure and allowable content for a given XML document and allows XML data to be programmatically validated to ensure it adheres to the specified format and content. >> In another sense, xml gives no options: your data is going to live in a string. This is true. XML is inherently text-based. There are options for binary data formats depending on your needs.
arethuza 6y ago
"it's not obvious which one to use" Perhaps this explains one system I saw that included entire encoded XML documents as attributes in other documents. On the plus side this embedding only went one level deep.
- MereInterest 6y ago
  Now I'm curious. Is that Microsoft Office with embedded documents (e.g. a powerpoint presentation with a word document embedded)? I've never looked at how the pptx format contains the docx format internally.
  - SahAssar 6y ago
    I've seen it in XML-based docs showing example XML responses. Then somebody tried to document the doc-generating-tool and I think we all know how that went.
HelloNurse 6y ago
Child elements are different from attributes because elements can be structured (with attributes, other elements etc.) and repeated within the same parent element. On the down side, elements are a little more verbose and whitespace needs some attention. This restricts attributes to zero or one unstructured values, which is more than a "style guideline".
sergeykish 6y ago
It is questionable even in markup. Attribute restrictions (unique, can't be structured) gave rise to minilanguages class="foo bar" lang="en-US" style="margin:0;padding:0" XSLT blows away promise of structured data with XPath and functions like concat in attributes. And it is a special case in DOM and XSLT making it much harder to manipulate. Meanwhile <script> and <style> content hidden by default.
- chrismorgan 6y ago
  > Meanwhile <script> and <style> content hidden by default. This is a fun thing that most people don’t realise. You can totally do this in CSS: head, title, script, style { display: block; } And bam, your document title and the contents of any inline scripts and stylesheets are now visible on the page.
Mikhail_Edoshin 6y ago
There's no ambiguity at all. Attributes are what fields are to a record; basically everything goes into attributes. Child elements are other records and are used when either there's more than one or their order is important or they also appear as children of other elements. Text is only used when there is actual content for humans that XML delineates; when XML is used as "application/xml" :) data there should be no text (unless parts of your data are such text).
- afiori 6y ago
  More than "fields to a record" the difference between attributes and elements is that attributes cannot be nested. So in a sense if you are trying to write JSON in XML all base values should be in attributes.

thesuperbigfrog 6y ago

>> XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. >> The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. Either approach is valid. Having a choice about how to structure the data is not a bad thing. My preferred approach is to use attributes for simple key-value pairs that are mainly used to select structured data found in child tags. If you have configuration data that is stored as XML, you could use attibutes to mark where the contained structured data should be used. For example: 1) language localization data could be stored stored in XML with attributes describing the language or locale; 2) build configuration settings might be stored in XML with attributes describing the target platform or CPU architecture. For more formalized data formats, create an XML Schema that defines what the XML data should look like and then you can easily validate that the XML data is structured correctly and even generate parsers or XML to programming language bindings.

SiempreViernes 6y ago
> Either approach is valid. Having a choice about how to structure the data is not a bad thing. I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. In another sense, xml gives no options: your data is going to live in a string.
- thesuperbigfrog 6y ago
  >> I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. A clear structure can be defined with an XML Schema Definition (XSD) document: https://en.wikipedia.org/wiki/XML_Schema_(W3C) https://en.wikipedia.org/wiki/XML_Schema_(W3C) An XML Schema Definition defines the structure and allowable content for a given XML document and allows XML data to be programmatically validated to ensure it adheres to the specified format and content. >> In another sense, xml gives no options: your data is going to live in a string. This is true. XML is inherently text-based. There are options for binary data formats depending on your needs.

arethuza 6y ago

"it's not obvious which one to use" Perhaps this explains one system I saw that included entire encoded XML documents as attributes in other documents. On the plus side this embedding only went one level deep.

MereInterest 6y ago
Now I'm curious. Is that Microsoft Office with embedded documents (e.g. a powerpoint presentation with a word document embedded)? I've never looked at how the pptx format contains the docx format internally.
- SahAssar 6y ago
  I've seen it in XML-based docs showing example XML responses. Then somebody tried to document the doc-generating-tool and I think we all know how that went.

HelloNurse 6y ago

Child elements are different from attributes because elements can be structured (with attributes, other elements etc.) and repeated within the same parent element. On the down side, elements are a little more verbose and whitespace needs some attention. This restricts attributes to zero or one unstructured values, which is more than a "style guideline".

sergeykish 6y ago

It is questionable even in markup. Attribute restrictions (unique, can't be structured) gave rise to minilanguages class="foo bar" lang="en-US" style="margin:0;padding:0" XSLT blows away promise of structured data with XPath and functions like concat in attributes. And it is a special case in DOM and XSLT making it much harder to manipulate. Meanwhile <script> and <style> content hidden by default.

chrismorgan 6y ago
> Meanwhile <script> and <style> content hidden by default. This is a fun thing that most people don’t realise. You can totally do this in CSS: head, title, script, style { display: block; } And bam, your document title and the contents of any inline scripts and stylesheets are now visible on the page.

Mikhail_Edoshin 6y ago

There's no ambiguity at all. Attributes are what fields are to a record; basically everything goes into attributes. Child elements are other records and are used when either there's more than one or their order is important or they also appear as children of other elements. Text is only used when there is actual content for humans that XML delineates; when XML is used as "application/xml" :) data there should be no text (unless parts of your data are such text).

afiori 6y ago
More than "fields to a record" the difference between attributes and elements is that attributes cannot be nested. So in a sense if you are trying to write JSON in XML all base values should be in attributes.