YAML Ain't Markup Language

On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote:
| Some real world feedback.
|
| >>  Do you know about YAML, on CPAN?
| >
| > Yes, but I rejected it due to its alpha status
|
| > unneeded complexity

Perhaps for simple configuration and/or log files
we are too complex.  However, people are using XML
for log and configuration files; and XML is more 
complex than YAML.

| > and because it relies on whitespace indentation to represent
| > structure. Imagine what happens if people start editing the files and
| > use tabs with different presets?.

1.  I think our tab policy now is pretty good, as the above problem
    with people using tabs with different presets is explicitly
    covered.  We need to cover this in the FAQ and modify the spec
    so that it is clearly articulated way-up-front.

2.  There are people who like tabs, for example:
    http://www.scottsweeney.com/projects/slip
    I think indented vs tagged is just a religious item
    like vi vs emacs.  Of course, there is only one
    right answer... *smile*

3.  We could (should?) devise another non-tab based syntax
    that has the same information model.  In this way all of
    our tools can work regardless of which religion they want.
    We could even allow for multi-line [] thingys...*sigh*

Hmm.  I guess the deciding fact will be lots of good 
implementations.  Many people I know think XML is ugly
till they started to use it day in and day out.  

Best,

Clark

Clark C . Evans [05/04/02 22:02 -0500]:
> Perhaps for simple configuration and/or log files
> we are too complex.  However, people are using XML
> for log and configuration files; and XML is more 
> complex than YAML.

[Warning: rant]

I use YAML a lot at work, and the only (real) complaint I have is that the
YAML spec didn't make it a requirement for the #YAML:xxx tag to change with
each release of the spec, before we settle down to an approved 1.0 status. I
still have a bunch of old files lying around that look like this:

   --- #YAML:1.0 %
   foo: bar
   baz: com

This claims that it's a 1.0 document, because the spec was called 1.0 last
year in September, as it is today. But September-01's YAML is different from
April-02's YAML. How different? Different enough.

IMHO, YAML parsers of today should croak on #YAML:1.0, and we shouldn't be
encouraging people to use that. We should be encouraging people to use
whatever spec numbering system we're using:

   --- #YAML:10mar2002
   foo: bar
   baz: com

When we declare the spec frozen (really frozen) we should endorse a version
number.

> Many people I know think XML is ugly till they started to use it day
> in and day out.

Let's be fair: XML is pretty as long as you _make_ it so. Machine-generated
XML tends to look awful. YAML looks nice because it has to:

   <?xml version="1.0"?>
   <package name="YAML" version="0.30" publisher="CPAN">
      <author name="INGY" />
      <tarball location="authors/id/I/IN/INGY/YAML-0.30.tar.gz" />
      <modules>
         <module name="YAML" version="0.30" />
      </modules>
      <scripts>
         <script name="ysh" version="" />
      </scripts>
      <license type="Perl" from="YAML.pod">
         This module is free software. You may use, redistribute, and/or
         modify this module under the same terms as Perl itself.
      </license>
   </package>

   --- #YAML:1.0 !activestate.com/PPM/package_description
   name: YAML
   version: '0.30'
   publisher: CPAN
   author: INGY
   tarball:
      location: authors/id/I/IN/INGY/YAML-0.30.tar.gz
   modules:
      - name: YAML
        version: '0.30'
   scripts:
      - name: ysh
        version: ""
   license:
      type: Perl
      from: YAML.pod
      content: ]
        This module is free software. You may use, redistribute, and/or
	modify this module under the same terms as Perl itself.

Both of those look reasonable to me. Of course, what comes out of
XML-producing systems often looks like this:

   <?xml version="1.0"?><package name="YAML" version="0.30"
   publisher="CPAN"><author name="INGY"/><tarball
   location="authors/id/I/IN/INGY/YAML-0.30.tar.gz"/><modules><module
   name="YAML" version="0.30"/></modules><scripts><script name="ysh"
   version=""/></scripts><license type="Perl" from="YAML.pod">This module is
   free software. You may use, redistribute, and/or modify this module under
   the same terms as Perl itself.</license></package>

Whereas YAML-producing systems look just as nice as the human-typed version.
Leading me to my belief that XML is really a binary protocol. If you can't
read it, it isn't text. (I can't wait for YAML-RPC to take off. A colleague
of mine showed me an example of it working, but there are only two clients in
the world :)

Later,
Neil

On Fri, Apr 05, 2002 at 07:56:38PM -0800, Neil Watkiss wrote:
| I use YAML a lot at work, and the only (real) complaint I have is that the
| YAML spec didn't make it a requirement for the #YAML:xxx tag to change with
| each release of the spec, before we settle down to an approved 1.0 status. 

Yes, this has been a problem.  My apologies.  I think we are very
close to a final version, do we want to call it 1.1?

| When we declare the spec frozen (really frozen) we should endorse 
| a version number.


| Let's be fair: XML is pretty as long as you _make_ it so.

Unfortunately, pretty printing is not simple in XML.  These
two documents below have a very different DOM representation
   <root><hello>world!</hello></root>
and
   <root>
       <hello>world!</hello>
   </root>
The latter has introduced two additional text nodes
and thus root has 3 children instead of one.  This is why
the "machine produced" XML always looks awful.  If it 
pretty-printed the XML, it would be changing the DOM 
structure of the document.

| Leading me to my belief that XML is really a binary protocol. If you can't
| read it, it isn't text. (I can't wait for YAML-RPC to take off. A colleague
| of mine showed me an example of it working, but there are only two clients in
| the world :)

;) Clark

On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote:
| Some real world feedback.

I've added a FAQ item to our website.


   1.  What happens to YAML when people edit the files and use tabs
with different presets?

      By default, a YAML parser rejects streams using tabs for
indentation. For those which must use tabs, an explicit declaration,
#TAB:N, is provided which can be used to inform the YAML parser of
tab policy. If tabs are used, we cannot solve the case where a YAML
file created and marked with #TAB:8 (vi) is edited with an editor
using #TAB:4 (visual studio), however, we think that the road sign
should provide adiquate warning. Further, the default form for YAML
printers is to always use spaces for greatest interoperability.

Clark C . Evans [06/04/02 11:31 -0500]:
> Unfortunately, pretty printing is not simple in XML.  These
> two documents below have a very different DOM representation
>    <root><hello>world!</hello></root>
> and
>    <root>
>        <hello>world!</hello>
>    </root>
> The latter has introduced two additional text nodes
> and thus root has 3 children instead of one.  This is why
> the "machine produced" XML always looks awful.  If it 
> pretty-printed the XML, it would be changing the DOM 
> structure of the document.

Crap like that is why I don't use DOM or SAX to access XML documents.
XML::Simple parses both of those streams like this:

   $VAR1 = {
             'root' => {
                         'hello' => 'world'
                       }
           };

Later,
Neil

On 05/04/02 22:02 -0500, Clark C . Evans wrote:
> On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote:
> | Some real world feedback.
> |
> | >>  Do you know about YAML, on CPAN?
> | >
> | > Yes, but I rejected it due to its alpha status
> |
> | > unneeded complexity
> 
> Perhaps for simple configuration and/or log files
> we are too complex.  However, people are using XML
> for log and configuration files; and XML is more 
> complex than YAML.
> 
> | > and because it relies on whitespace indentation to represent
> | > structure. Imagine what happens if people start editing the files and
> | > use tabs with different presets?.
> 
> 1.  I think our tab policy now is pretty good, as the above problem
>     with people using tabs with different presets is explicitly
>     covered.  We need to cover this in the FAQ and modify the spec
>     so that it is clearly articulated way-up-front.

+1 +1

> 
> 2.  There are people who like tabs, for example:
>     http://www.scottsweeney.com/projects/slip
>     I think indented vs tagged is just a religious item
>     like vi vs emacs.  Of course, there is only one
>     right answer... *smile*

:) +1

> 
> 3.  We could (should?) devise another non-tab based syntax
>     that has the same information model.  In this way all of
>     our tools can work regardless of which religion they want.
>     We could even allow for multi-line [] thingys...*sigh*

-1 I think we're elegantly covered. No changes needed. Just good error
meassages and documentation.

> 
> Hmm.  I guess the deciding fact will be lots of good 
> implementations.  Many people I know think XML is ugly
> till they started to use it day in and day out.  

+1 

Cheers, Brian