Re: Next YAML: drop equality definition

Thanks, Oren,

>     I want to know the reason why non-preservation of
>scalar identity is allowed in the spec.
>
> The design goals for YAML are, in decreasing priority:
>
> 1. YAML is easily readable by humans.
>
> Having scalars-with-identity is not what humans expect.
>Humans _tend_ to  perceive scalars as "just values" and
>collections as"something with identity".

I see your point and I agree with it for some degree.

But, at the same time, I also expect implicit/explicit
schema should help people largely to read a document.
Namely, if some scalar nodes really need identities,
the meaning of those nodes are almost always obvious
from the content and purpose of the document, at least
for its users. In contrast, it may not be obvious for
machines.

Another point is about the purpose of each document.
If a document is with full of implicit custom tags,
it will not be readable or editable to everybody and
also not meant to be. Probably it is only expected
that it is only written and read by a specific
application. But, it is still much more readable in
YAML than in XML. I don't think people need hyper
readability on a YAML document with many custom tags.

On the other hand, if we remove all the tag feature
from YAML, any YAML document will be easy to read
and edit for everyonebut we do not want to do it.

We have to optimize the balance between readability
and functionality, and maybe simplicity of the spec.


> 2. YAML data is portable between programming languages.
>
> Different applications can apply a different schema to
>the same document.If these schemas differ on assigning
>identity then you cause all sort ofsticky issues.

What do you mean by "can"? Could you give us any example
where different applications _can_ apply a different
schema to the same document? It sounds really strange
for me.

IMO, any document can not stand without a valid schema.
A schema-blind application must not apply any
possibly-wrong schema to any document. Namely, it can
merely build partial representation graph and can not do
any more. If it go any further, it will very easily break
documents even without the identity issue, as partially
shown by my previous example with !!float tags.


> 3. YAML matches the native data structures
><http://www.yaml.org/spec/1.2/spec.html#native data structure//>
>ofagile languages.

I agree that YAML nodes with standard tags match the
native data structures of agile languages pretty well.
But what about nodes with custom tags? How do they
matches the native data structures and how we can make
of the matching? Coud you show us some example use cases?

> Which tend to make scalars immutable. Even Ruby is
> starting to see the error of its ways here so it is
> moving to make at least some strings be immutable
>(literals, "frozen", etc.).

I repeat, I do not want to keep identities of !!str
nodes. If you are confident that the data indeed do not
need identity preservation, you can discard identities.

My question is what we will gain by being allowed to
discard identities of nodes _with possibly unknown tags_.


> 4. YAML has a consistent model to support generic tools.
> that you
> I guess the question is, how strong is that consistent
>model?What does it _allow_ generic tools to do? The
>rules aboutscalaridentity give generic tools the
>ability to do morethan they coulddo if scalar identity
> had to be preserved.Note that a human with  a text
>editor can also be a generic,schema-blind tool.

Ok, this seems a good example. So, what is additionally
allowed to the guy with a text editor by being allowed not
to preserve scalar identity? I don't see much more than
aliasing and unaliasing the seemingly-equal nodes. Do you
see any more? If they are the only things it allows, I
don't see much importance on it.

In addition, I don't want any guy who is unaware of the
schema to edit my YAML documents. When people want to read
or edit YAML documents, they are almost always aware of
the proper schema of the target document. When and why do
you read and edit a YAML document without the knowledge of
its schema?


> 5. YAML supports one-pass processing.
>
> That's irrelevant to the topic at hand. I think.

I agree.


> 6. YAML is expressive and extensible.
>
> You could argue that not preserving scalar identity
>requiresa morecumbersome expression of some native
>data (e.g. wrappinga scalarin a collection "just
>because" you want to ensure itsidentity ispreserved -
>similarly to having to use an !!omapinstead of the
>cleaner map syntax for PHP dictionaries).
>"Everything" still _can_be expressed, though.

If the benefit is larger than the labor, I will accept
the restriction. For !!omap issue, I am about neutral.
I see it can prevent people unintentionally breaking a
YAML document by swapping the key order. I evaluate this
happens much more easily than someone aliases or unaliases
unexpected nodes.

On the other hand, if we see much more useful use cases
by allowing users to store key-order-aware hash or
key-duplication-unaware objects in mapping nodes, I
would be convinced to discard that restriction as Zanaan
is trying to.


> 7. YAML is easy to implement and use.
>
> I don't see it applies here. At any rate, being the
>lastgoal,it tends to lose out - which is the main
>issue peoplehave with YAML.

I agree.


> So... it seems to be a reasonable decision given our
>goals.
>
> One of the reason we explicitly listed the goals,
>_in order_,was to break ties when different goals
>pushed us in differentdirections. Order the goals
>differently, and you'll get adifferent spec. I think
>you would end up with JSON if youorderedthem in a
>different way. Or even, god help us, XML ;-)

I strongly agree with this statement and seemingly
the order itself is nice, too. But as I commented on
the first item, the order can not be super strict.
We always have to optimize the balance of conflicting
ways to the goals.

Another point is, I feel that most of the YAML documents
in your mind are those that can be stored in JSON but
those in my mind are not always. YAML documents with
full of custom tags are not easily stored in JSON.
If we give up YAML, the next choice will indeed be XML.
Actually, my library is build to replace XML serializer
that is provided by C#. Since we want YAML to be able
to serialize both kinds of documents, we have to think
the best balance.

Best,
Osamu Takeuchi



------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140