Ah, there's nothing like home cooking in a Spanish-descent Jewish family
on new years (and Passover). I'm stuffed as a turkey with so many
delicious things I can't even begin to list them. And, I have a perfect
alibi for sitting the last brain storm out :-)
To the issue. I have one main point before responding to specific
issues. There have been so many proposals I can't keep track (remind me
of the sald types... by I digress). I think that the last week shows
that we can't make any progress by simply throwing proposals up in the
air and hoping to hit some magical spot everyone will like. We can keep
at it for months getting nowhere.
IMVHO, we should focus on the requirements rather than the proposed
solutions. We have worked out a short list of requirements:
R1: Cooking is a simple, table-less syntactical-only operation.
R2: A YAML schema does not transform one private/global/yaml tag to
another.
R1 + R2 got us the the original !, !! proposal. Brian then added:
R3: Private tags should not have to use !!.
R1+R2+R3 got us survey item #1. People weren't happy; it turned out that
there is another requirement:
R4: Quoted scalars are Unicode strings.
This got us to survey item #4. #4 has a single advantage going for it:
It is the simplest, cleanest proposal we know of that satisfies *all*
of R1 - R4.
People are still unhappy with #4. To me, this says that people have some
yet-unphrased requirement(s) that are not being addressed. Instead of
getting lost in a maze of twisty little proposals, all different, could
you please put your finger on what's wrong with survey item #4 and
phrase it as a requirement?
Then, and only then, it would make sense to see what the simplest
proposal would be to satisfy the new requirement R5 _in addition_ to R1
- R4. I'm very tired of reading proposals that happily violate some
R1/R2/R3/R4, in order to solve some implicit problem which only clear
to the proposal's author.
Tim was the only one who posted along these lines. He defined two
properties of a YAML schema:
"Property I" seems to be, basically, R1 + R2.
"Property S" is less clear to me. Since this is the one Tim feels isn't
provided by survey item #4, I'd be very interested in him rephrasing
it.
I'll now try to deduce what the missing requirement R5 is. I'm trying to
reverse-engineer around 60 messages here while full of a similar number
of different dishes, so I'll probably get it wrong... At any rate, it
seems to be:
R5(?): Quoted scalars should not have a "concrete" type.
On the off chance that this is a fair description of what bothers
people, before we move on to try to create a #143 proposal, I'd like to
try to reconcile this with survey item #4. I'll make three points:
1. When people write "123a", they expect it to be a "characters string".
If someone here feels that it EVER makes sense for "123a" to be loaded
into anything else than a "characters string", please speak up. AFAIR
nobody ever suggested even one example saying: well, in this and that
case, it makes more sense for "123q" to mean something other than a
string, so using tag:yaml.org,2002:str for it prevents me from doing
what I want.
Note that YAML's design goal #1 is being human readable. So, show me an
example where it is more readable to have "123q" be anything than a
simple string. I don't care much for saying "sure, its always best for
it to be a string, but I want my options open". YAGNI. Show me ONE
plausible use case, first.
2. Now, let's look at R4 again. It says: quoted scalars are Unicode
strings. Now, a Unicode string is a concrete type. It carries with it a
certain semantics baggage. Saying quoted strings should not have a
"concrete" type seems to directly contradict R4.
So, it may be that people who want R5 don't really want R4. They want:
R4.1: quoted scalars mean something else than plain scalars.
Quick show of hands: who is for R4, and who is for R4.1? What is your
use case?
3. Yes, tag:yaml.org,2002:str is a concrete *TAG*. It is NOT a concrete
native data TYPE. Each application is free to load strings into
whatever native data type (or, sa Brian calls it, "cave drawing") it
wants. Again: we are talking about the INTENT of whoever is writing the
document, NOT the details of how this intent is processed by a given
system. Operationally. you may run atoi on your strings in your
application, and divide each integer node by its indentation level -
FINE. But a "YAML schema" (INTENT of a YAML document) can't say that
'!!str 23' should be put through atoi, and that '!!int 23' nodes should
be divided by the indentation level.
So much for defending survey item #4. Now for some "previously prepared
fallback positions" :-)
Suppose that "everyone" votes for R4.1 instead of R4. This inevitably
brings us to the "plain flag". Nodes without a tag have no tag (== each
YAML schema is free to specify a different INTENT for such nodes). But,
these nodes know whether they were plain or not (== each YAML schema is
allowed to assign a different INTENT to a node with " than to anode
without a ").
The simplest thing to do in this case is something along the lines of
survey item #3 (and about a dozen mutations thereof). Define *two* "I
have no tag" values, one for non-plain scalars, one for all other
untagged nodes. These two values can be called QNULL and NULL, % and @,
or ~foo and ++bar!@# - that's a secondary, minor issue, which can be
settled very quickly if we agree to adopt R4.1 instead of R4.
Personally I'll go with " and ! (think about it).
Either way, problem solved. So, bottom line, please answer the following
quick survey (one bit answers only :-):
- Are you for R4 or R4.1 + R5?
- Do you have an example of why R4.1 is useful in any way?
- Do you have an R6 in mind?
Sorry for the long post, but I had to read 60 of yours! ;-)
Have fun,
Oren Ben-Kiki
|