[
Lists Home |
Date Index |
Thread Index
]
I had a discussion with an eXtreme Programmer recently, wherein he pointed out his utter disdain for things XMLish, and pointed to YAML as his idea of a Far Far Better Thing.
Further discussion revealed quite clearly that his intended applications were all very focussed on data serialization. I'd be prepared to cede the point, having seen plenty of abusive XML in that area, but...
First, I've never liked working with COBOL's fixed positioning, and YAML smacks too much of it. For working with a Wiki, it is fine, because you aren't working with code or data. The stated goals of YAML could ostensibly be used to write this objection off, but we all know that initial goals have a way of being extended by the users of a technology.
Second, YAML confuses many XML-based technologies with XML itself. The various justifications and contrasts to XML in the spec and supporting articles are hyperbolic with respect to XML itself, though no doubt there are justifiable criticisms one might make individually to specific technologies and approaches for specific tasks (SOAP, DOM...).
Third, YAML deliberately conflates its underlying processing and storage models with its syntax. This is explained as a simplification, and contrasted to XML. However, I see no reason why an XML technology cannot be proposed which implements similar primitives. Indeed, I see as a strength of XML, the refactoring and separation of syntax from the data processing and information models which YAML implies is a weakness.
This last argument is a very old one. YAML does appear to hold value for data serialization. But a little nagging feeling inside tells me that there is a myopic viewpoint at play.
- Mitch
Simon St.Laurent wrote:
> Years ago, discussion of simplified XML left this list for SML-DEV.
> There were a lot of fruitful conversations on SML-DEV, some of which
> have come back here, others of which have gone elsewhere. YAML seems to
> have found its own community, and evolved quite a spec:
>
> http://yaml.org/spec/
>
> Like XML, YAML is built on Unicode text, but its creators have
> explicitly set different priorities:
>
>
>>YAML Ain't Markup Language, abbreviated YAML, is both a human-readable
>>data serialization format and processing model. This text describes
>>the class of data objects called YAML document streams and partially
>>describes the behavior of computer programs that process them.
>>
>>YAML document streams encode in a textual form the native data
>>constructs of modern scripting languages. Strings, arrays, hashes, and
>>other user-defined data types are supported. A YAML document stream
>>consists of a sequence of characters, some of which are considered part
>>of the document's content, and others that are used to indicate
>>document structure.
>
>
> Human readability and editing are still important, but information
> structures come from the programming domain, without a notion of humans
> adding metadata to documents. At the same time, its type system
> (http://yaml.org/spec/#.Type-Families) is very different from W3C XML
> Schema.
>
> The differences in structures and approach are made explicit in a brief
> section on YAML's relation to XML:
>
>
>>Newcomers to YAML often search for its correlation to the eXtensible
>>Markup Language (XML). While the two languages may actually compete in
>>several application domains, there is no direct correlation between
>>them. YAML is primarily a data serialization language. XML is often
>>used for various types of data serialization but that is not its
>>fundamental design goal.
>>
>>There are many differences between YAML and XML. XML was designed to
>>be backwards compatible with Standard Generalized Markup Language
>>(SGML) and thus had many design constraints placed on it that YAML
>>does not share. Also XML, inheriting SGML's legacy, is designed to
>>support structured documents, where YAML is more closely targeted at
>>messaging and native data structures. Where XML is a pioneer in many
>>domains, YAML is the result of many lessons from the XML community.
>>
>>The YAML and XML information models are starkly different. In XML, the
>>primary construct is an attributed tree, where each element has an
>>ordered, named list of children and an unordered mapping of names to
>>strings. In YAML, the primary constructs are sequence (natively stored
>>as an array), mapping (natively stored as a hash) and scalar values
>>(string, integer, floating point). This difference is critical since
>>YAML's model is directly supported by native data structures in most
>>modern programming languages, where XML's model requires mapping
>>conventions, or an alternative programming component (e.g. a document
>>object model).
>>
>>It should be mentioned that there are ongoing efforts to define
>>standard XML/YAML mappings. This generally requires that a subset of
>>each language be used.
>
>
> For developers looking for data serialization approaches that are more
> amenable to their existing structures than XML, YAML seems worth a much
> closer look. It seems to me to combine XML's structured text foundation
> and ASN.1's programming orientation, perhaps giving programmers the best
> of both worlds.
>
> Kendall Clark explored YAML last year:
> http://www.xml.com/pub/a/2002/07/24/yaml.html
>
> For more of the history of SML-DEV and YAML, see Leigh Dodds' piece at:
> http://www.xml.com/pub/a/2001/08/01/simpler.html
>
>
|
