Re: [Yaml-core] Viewers and the Graph Model

[Clark C. E. <cc...@cl...>]

On Sun, Sep 08, 2002 at 11:42:48AM -0600, Tom Sawyer wrote:
| On Sun, 2002-09-08 at 11:18, Clark C. Evans wrote:
| > Yes, you are right, perhaps a few users may _want_ to have an ordered
| > hash.  However, I'm fully willing to tell those users to go somewhere else.
| > Somewhere there has to be a line between what is YAML and what isn't.
| > Just beacuse it may look like YAML doesn't mean it is.
| > 
| 
| ordered hashs are certainly useful. using ruby, i have come across a
| number of times when i wish i had one, and thus have been pushing for a
| a new class much like PHPs. but at any rate, i'd don't see why yaml
| can't have this. is it really that much of a difficulty? the conception
| is really nothing more than the combination of a sequence and a mapping
| into one entity:
| 
|   - A
|   - B
|   - C
| 
| and
| 
|   one: A
|   two: B
|   three: C

Right.  But as soon as you combine them, you end up with an object
which is no longer a "mathematical function" and thus you complicate
just about everything in a transformation language.  I don't mind
considering this down the road in a year or two; but I'd like to have
ypath and a yaml transformation language worked out so that we can
be absolutely sure that it won't cause problems.

| perhaps:
| 
|   -one: A
|   -two: B
|   -three: C

Yes, this is great (and the reson for the short-hand notation).
At the core of YAML we've chosen the map/list construct as our
pillar.   This is one pillar that I don't want to consider moving.

| certainly ypath wouldn't have a problem dealing with this.

Actually it would complicate ypath signficiantly.   If key order
is signficant then YPATH should have a way to ask for the Nth key.
Thus /0 means what?  Right now it would be the value for the 
key "0".  If it didn't mean that, then we'd have to find some 
other way to match a key with a value of "0"; alternatively we'd
have to find a YPATH expression to match the Nth key; and if it
differed from the way to access the first item in the list we'd
have an inconsistency.   Thus, no matter which choice you pick
it is inconsistent.   This is just the start of the problems.
It is much worse complication for schema and transforms.

That said, I have no problem with an "emitter directive" which
gives the key ordering and which scalar styles to use, etc.  This
would be a very very welcome development and I encourage someone
to do this in a way that can be copied by all implementations.

But please, please don't build naitve objects from information
which isn't in the generic model.  This violates the specification
and will cause lots of headaches if implementations get in the
habit of routinely violating the spec whenever they feel like it.

Thanks!

Clark