Re: Next YAML: drop equality definition

On 3/10/16, Osamu TAKEUCHI <[email protected]> wrote:
>> 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?

Such as application/ layer 4 "application" with application specific
schema, and schema-blind middleware, and in this case, "If these
schemas differ on assigning identity then you cause all sort of sticky
issues."

> It sounds really strange for me.

Exactly because it is likely to cause problem.

Either
 - use default YAML schema (previous emails) and then a "schema blind"
"YAML middleware" processor might make sense, but who knows - this is
up to developers of YAML middleware and or 'end user' applications,
 - or use application specific schema, and you are very unlikely to be
able to mix in "schema blind" YAML middleware.

I think we all agree on these basics.

> IMO, any document can not stand without a valid schema.

If we say "schema less document" is actually YAML document relying on
"default schema" (with scalars working as users expect them etc), then
I agree with you.

I like the "default schema" where "schema less" YAML documents work as
I expect them to. I use YAML mainly with human (me) generated YAML
files, and if the default schema were to change to require "scalars
have identity" then the first thing I would require of any YAML tool I
use, is that it support the "old style" schema.

> A schema-blind application must not apply any
> possibly-wrong schema to any document. Namely, it can

I think part of the problem is that we sort of lack a real world
example of a practical for regular use "schema blind" tool. I think
the examples of scalars needing identity have so far been a bit
contrived - if '!not_float 3.14159' must have separate identity / be
not equal to '!not_float 3.14159', that to my eyes looks like a
decidedly application specific schema. I am still struggling to
comprehend how that could be useful, even though I can certainly
accept that it's possible it might be useful in some situation to
someone.

> 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.

If an application requires such behaviour ("schema"), then it, of
course, could not rely upon the default schema. This sounds sensible,
yes?


>> 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?

How is that relevant to the discussion?

Some languages will have layer 3/4 YAML constructors to support
"arbitary" custom tags/ schemas - other languages might be a bit
limited some how, although if such languages exist, then I think that
language would be not very popular - we have relatively high "minimum
standards" these days... I don't think BrainFuck is going to be at the
top of the list for YAML implementations, although apparently BF -is-
turing complete...

>> 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_.

I am not a YAML library implementer/ programmer. That said, I think
your question is too theoretical - if an application requires that any
YAML middleware preserve scalar identity, then that application is
naturally going to have to be pretty specific about which "YAML
middleware" is allowed to be used in its processing chains.

In a decade or more, I have not seen the doors of this mailing list
being broken down with questions such as "why is my YAML middleware
not correctly processing my YAML communication channel between my YAML
endpoints?"
(Hint: we've never, ever, seen such a question.)

Even a well-grounded "real world hypothetical" would move the
discussion onwards at this point. But we don't even have a "real world
hypothetical", let alone a real world problem.


>> 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 about scalar identity give generic tools the
>>ability to do more than they could do 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?

Common sense and "default expectation" - Linus Torvalds has a similar
saying about kernel to user land interfaces, where POSIX has
occasionally been allowed to be violated by linux, or a bug has been
solved in one out of a number of ways, because of historical precedent
and or user expectation.

Scalars having identity breaks the expectations of the man with the
editor. And if me editing a particular YAML document, do depend on
scalar identity, I expect that that would require awareness of the
schema for this document (which presumably I have, since I am manually
editing the document).

This is actually an example which favours the default expectation of
users, which is, that scalar identity is not preserved, strings can be
internet, etc.

If a particular YAML "middleware" that I, the man with the editor, am
using, let's say a YAML pretty printer, unexpectedly preserves scalar
identiy, then I'll tell the dang pretty printer where to go.

If I am programming some transactional multi layered software, and
some middleware layer needs to work in a particular way (preserving
identiy, or not preserving identiy), I'm simply going to make sure the
YAML tool I use supports the mode of operation that I require.

I think you might be trying to solve a non existent problem?

>> 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.

This sounds intuitive to me.

> If the benefit is larger than the labor, I will accept
> the restriction.

For starters, your !!not_float example seems artificial to me - like
trying to solve a non existing problem. Changing an "intuitive to
humans" aspect of the current YAML spec (/ default schema), in order
to solve a non real world problem, would be a step backwards for YAML.

> 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.

Map and OrderedMap are well defined (mathematically) concepts. YAML
supports both, map by default schema, any other type of map by
alternate schema/ tags. Any middleware will only ever be employed in a
processing pipeline where it makes sense to use that. There is no real
world problem that has knocked on the door.

> 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.

My goal has been trying to understand YAML on a deeper/ more precise
level, so thank you for entertaining my slow understanding. My
examples were put to help me understand your question, so I could
understand YAML better - I am not trying to discard a restriction of
YAML.

Perhaps the question is: should the 'default schema' "hash map
concept" be !omap or !map? As long as I know which the default schema
is, I personally don't have attachment either way.

In my initial tests of beginning to rewrite my little "learning YAML
with Java beans" project without tags, all strings are "cookies" and
all numbers are "values" - i.e. they have no identity, and if they
did, that would be a problem for me - I would be immediately asking
around for a library supporting "old/ original YAML" schema.

For me, where say a string has to have identity, that would be because
it represents a class name (Java bean name) - and of course, every
other appearance of that exact sequence of characters (e.g. "T e s t B
e a n" (without the spaces)), represents exactly the same entity/
thing/ field/ class/ bean! A sane hypothetical where the opposite
needs to be true, completely eludes me.


>> 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.

Au contraire! I support a "super strict" order, so YAML design
decisions are consistent over the years. This has been the case - one
of the really nice things about YAML. Now we have "-layers-, onion
boy" (with apologies to Shrek), so I'm even happier. Design
consistency in YAML is truly awesome. And the order of design
priorities is very appealing to me personally. Did I mention I like
YAML?

> We always have to optimize the balance of conflicting
> ways to the goals.

Of course, when a convincing argument can be put that a chosen order
of priorities, or to pick a random example, rules applying in a
particular logical layer of the system, ought be changed, then that
makes for a great discussion.

> 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.

I disagree. Every tag can be transformed into a two element list,
where the first element is the tag, and the second element is the node
content that was tagged. Or instead of a two element list, think a two
element map, e.g.:
-
  tag: omap
  content:
    blah
    blah

> If we give up YAML, the next choice will indeed be XML.

Nope. The next choice will be YAML 2. Then the next choice will be
JSON 1. Then the next choice will be JSON 2. Then the next choice will
be native serialization in your language of choice. Then custom binary
serialization. Then a continually permutating algorithmic mixing
stream, just for laughs. There are infinite alternatives to XML and if
worse comes to worst, I suggest hard transcoding your data into COBOL
statements and serializing those in Base63.

Nowhere would one willingly choose XML.

Hell, I'd choose HTML if I was ordered to use XML on a project, just
to make sure the next guy who touches that code knows that the
serialization format has to be changed.

Manager: "Z, did you finish that, what's it called again? Yeah, the
XML serialization?"

Me: "Sure did! And it's Netscape 3.1 compatible too." <snigger>HTML<snigger>

Manager: <used to work at Best Buy, does not understand>"Oh, cool!
That's just great! I knew I'd finish on time, and I'll tell marketing
our new name too, 'NewScope compatible' - has a great ring to it.
Great ring! Good job Z, you'll go places you know. Go places in this
world!"


> 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.

Should be easy. Anything's more enjoyable than XML... whoops, there I
go again...
:)

------------------------------------------------------------------------------
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