[Yaml-core] RE: YAML: a few questions.

[Oren Ben-K. <or...@ri...>]

Mathieu Bouchard [mailto:ma...@sy...] wrote:
> I'm in the process of (re-)designing my own little 
> serialization language I call LGRAM. I've been
> recommended a look at YAML. So here I am and here
> is my first round of questions. Please excuse any
> misinterpretations of the spec I may have done (and
> please correct them)

Welcome aboard! I'm replying to these in YAML-CORE rather than SML-DEV,
that's a better place for discussing the YAML spec.

> 1. How is an arbitrary object encoded? For example, what would be the
> YAML equivalent of calling "bless" on a Perl variable, and/or calling
> Foo->new(...); ? would org.yaml.indicator handle that ?

I'm not certain exactly what you are asking. If the question is "how
would the serialization of an arbitrary Perl object look like in a YAML
file", then assuming this object is contained in some map I expect it
would look something like:

key: !perl-class-name
    member: value
    another: value
    ...

"perl-class-name" may be either the exact Perl name for the class or
some alias for it (assuming the YAML system in question maps between
these aliases to Perl classes). Using such aliases is useful in case
you want to exchange data with non-Perl systems (e.g., Python).

> 2. The spec omits:
> rangeless integers (bigints),
> explicit booleans (true,false),
> complex,

Sigh. Yes.

> symbols,

What are these?

> ratios, fixed-point in non-10**npowers,

Aren't these two the same?

> timezones by their posix-name,
> shifttimes that are not whole hours;

Dates are such a pain, aren't they? The date type should be fixed
according to some "standard". POSIX may be good enough. We should
look into this.

> how do you draw the line between what goes in "suggested types" and 
> what doesn't?

Good question. There is some difference of opinion here. I'd rather
stick with the basic set of types directly supported by (most)
languages - int, float, text and binary, and move all other types out
of the core spec and into something like a org.yaml recommended types
list. Such a list would be much more "open ended" then a list contained
in a "core spec". Clark however feels that the list of types we added
in the core spec is "universal enough" to warrant listing there.
Perhaps your questions will convince him that it is best to separate
this list out after all :-)

> is there a distinction between the list in the spec and (a 
> possibly longer list of) org.yaml types?

In some sense there isn't because every application is free to use
whatever set of types which suits it. In another sense there is because
you'd expect the set of types listed in the core spec to be universally
supported. It may make sense to require that every YAML system will
support a certain list of types ("support" as in "will round-trip them
without warnings"), and only list these "required" types in the core spec
(again, a reasonable list would be int, float, binary and text). That
would create a clear distinction between "core" types and "recommended"
ones.

We'll just have to wait for Clark to return to action to resolve this.

> 3. Why is every indentation level four spaces instead of a 
> single ascii 9 (tab) character? (using single tabs allows for
> easy per-editor customisation of indentation appearance)

Hmmm. We have been through several iterations on the indentation issue.
The only objection I have to it is that printers universally expand tabs
to 8 character positions. That's too much; printing a YAML file would be
rather problematic (unless you use landscape layout :-). The "expand"
UNIX utility would help but it isn't universally available (e.g.,
in Windows).

On the other hand, I like the thought that you can, when editing a YAML
file, control the way the indentation looks while using a fixed text
representation. That's neat.

So, it is a tradeoff - is the flexibility gain worth the  difficulty in
printing? Good question. Another TBD for when Clark returns.

> 4. Why is it acceptable that $a='foo';foreach(1..$n){$a=[$a]};$a, when
> serialized, is required to take O($n**2) bytes ?

It is a problem, yes. But I don't see it as a "show stopper". It is rather
rare; the actual cost (in character count) isn't *that* high; and I see no
way to avoid it short of using a completely different scheme. We'll just
have to live with it. Thanks for pointing this out - I wasn't aware of it
before.

> 5. Why are type-specifiers limited to single identifiers?

Actually a type can contain any printable characters. It can't contain
white space and control characters. I'm not aware of any language for
which this poses a problem. Besides, it is good practice to use "universal"
aliases for types in a YAML file rather then language-specific type names
(though these have their place as well).

> 6. Is this only a spec for passing data, or there are plans 
> to specify how remote procedure calls shall be done, how procedure 
> interfaces shall be described, etc. ?

Such things are obviously out of scope for the core spec. They are
examples of domains where YAML may be successfully used. Tempting as
it may be to define such specs from scratch, perhaps it would be better
to start with a YAML-isation of existing XML-based specs such as XML-RPC
and SOAP. Of course the YAML format would be much nicer:

<?XML VERSION="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value>
                <i4>33</i4>
            </value>
        </param>
        <param>
            <value>
                <i4>39</i4>
            </value>
        </param>
    </params>
</methodCall>
<methodResponse>
    <fault>
        <value>
            <struct>
                <member>
                    <name>faultCode</name>
                    <value>
                        <int>4</int>
                    </value>
                </member>
                <member>
                     <name>faultString</name>
                     <value>
                         <string>Can't call "getStateName" because there are
too many parameters.</string>
                     </value>
                </member>
            </struct>
        </value>
    </fault>
</methodResponse>

Would become:

methodCall:
    methodName: examples.getStateName
    params:
        : !i4 33
        : !i4 39
methodResponse:
    fault:
        faultCode: 4
        faultString: Can't call "getStateName" because there are too many
parameters.

Isn't that much neater? Of course the above aggressively uses YAML features
to reduce the need for nested elements, at the cost of making its schema
unpredictable. A fixed-schema representation would include all these pesky
"value" and "name" explicit nodes. Either way you could easily tailor a
YAML front-end to an XML-RPC (or SOAP) system, which is more practical then
inventing a whole new protocol.

Have fun,

    Oren Ben-Kiki