On Wednesday 08 September 2004 06:31, T. Onoma wrote:
> I'm trying to understand the debate here. Could you outline the
Well, Clark and I agree on the semantics in a basic level, but seem to
disagree on the mechanism for explaining/describing them. Which is
good, it means we are getting somewhere.
IMVHO, Clark's proposal (using !implicit-*) is confusing and arbitrary,
while using NULL is cleared and a better reflection of what is actually
> problem you face here is that, try as you may, any attempt to limit
> the transforms is going to be hackish.
Exactly. Once you present resolution as taking some tag and re-writing
it to be a different tag, the word "transform" is used, and you open
the door for a host of issues, like why can't I do other transforms, to
my own private tags, and can't I explicitly write !implicit-foo and
transform that, and why do I need to have a transform in the first
place - can't I simply load the document as it is, please?
Sure, there are possible answers. But this whole song-and-dance is
> So the _usable_ structural meaning is
> what I'll call semantic value level ONE. At that level YAML docs have
> !!map, !!seq, !!str and !!imp (or !!var if you prefer).
We call this the node's _kind_. It can be a mapping, a sequence, or a
scalar. (!!map, !!seq and !!str are specific types; not all mappings
are !!map, not all sequences are !!seq, and not all scalars are !!str).
Also note that prior to loading, some nodes have a known (explicit) tag.
E.g., a mapping might be a "!invoice". So "value level one" goes beyond
the mere node kind - for _some_ nodes anyway.
> ... actually the !!imp is pointing out the truth about
> everything in the doc: _You have to idea what it will become!_
Exactly! This is why I feel that using NULL is the simplest, correct
solution. I simply *do not know* the name of the type of "cave drawing"
that will be used for the node ("what it will become").
This makes everything simple. Obviously, if you don't know what "it will
become", before it "becomes" anything, you need to _decide_ what it
"will become". Right?
Well, we give a name to this decision: "deciding-what-it-will-become" ==
"tag resolution". This isn't an optional step (again: you *must*
"decide-what-it-will-become" before it "becomes"). This isn't a
transform: you are NOT changing "what it will become" (the tag of the
In Clark's way of explaining things, since you *pretend* you know the
tag of the node, this _is_ a transform, as you *are* changing the tag
of some nodes. So you go into a whole song-and-dance about why its OK
to change some tags and not others, and so on. Ugh, Ick, and Oy Vey :-)
Here's an analogy. You have a hospital ("application"). Whenever someone
comes in ("a node is loaded"), you check his name against your medical
histories database ("construct a native object"). People who visit the
hospital often are all listed in the database. You give them a plastic
card with a barcode ("some nodes have tags").
However, most people who come in, come in for the first time, and have
no card ("most nodes have no tag"). You don't know their name - you
have to ask them (if uncouncious, you have to look at their possesions)
to discover their name ("you must give a tag to these nodes by looking
at their content").
Clark's proposal is that we name all the people without a card
"Joe" ("we give all untagged nodes the tag "!implicit"). So, if you ask
the name in the waiting room who is there, she'll say: "I have Alice
and Joe and Joe and Joe and Joe" ("!!float and !implicit and !implicit
and !implicit and !implicit").
Now, for a person to be treated, we enter his name to the database to
look up prior history and record new history ("for a node to be loaded,
we need to decide on the native object type").
Under my approach, you say: First, find out their name. If they have a
tag, fine. If not, FIND IT OUT - ask them, look at their pockets for a
driving license, etc. Now that you have a name, use it. ("if a node has
a tag, fine; otherwise, look in its content for regexp etc. and decide
on one. Now, use the native object type associated with the tag").
Under Clark's approach, you say: If their name is "Joe", ask them what
their name is, look in their pockets for a driving license, etc. Then
RENAME each "Joe" to a new name, and then look it up in the database.
("transform all !implicit tags to something else based on the node
content. Now, use the native object type associated with the tag").
Under my approach, it makes perfect sense to say: I failed to/didn't yet
discover this person's name, I'll call him as "John Doe" ("NULL").
However, I can't look the name "John Doe" up in the database for prior
medical history. ("I failed to/didn't yet discover the node's tag, I'll
just leave it NULL. However, I can't load it into a native object").
Under Clark's approach, it is like saying: This unconcious guy has a
chart saying his name is "John Doe" ("!implicit"). Let's see if he has
a history of prior admissions... ("use the tag !implicit as if it as a
normal private tag to look up the native data type"). Oh wait, I can't.
So his name really isn't "John Doe". Or is it? Can I look him up in the
database or not? Nurse, were you here when this guy was admitted, did
he have any ID? ("are !implicit 'resolved' or are they not? is this
node !implicit or a !float waiting to be resolved? which callback gave
you that node, again - a loader callback or a parser callback?").
In my approach, you _can_ treat a "John Doe" without using any medical
history. This is a weaker form of treatment - you might misdiagnose,
etc. ("You can 'load' a NULL-tagged node to a "generic YAML node". This
is a weaker form of 'load' - you might get equality wrong, etc."). So
you take extra care when you treat him ("applications are limited in
what they can do with NULL-tagged nodes").
See? You do NOT look up in the database to see the prior history of
"John Doe" (you do not say that "the native data type for NULL nodes is
<some-type>"). Hence, "John Doe" means "I have no name", it is NOT a
name ("a NULL tag means "I have no tag", it is NOT a tag
Really, Clark's approach baffles me. I can see that its functionally
equivalent - which is good, since this means we are getting somewhere.
But for the life of me I can't see it simplifies anything. It just
Using NULL tags is the simplest, most direct way of representing the
"physics" of the issue. Some nodes have no tags, period. Here, look at
the document. See a tag? No? well, there you have it. It has no tag.
Now, if I need the node's tag, I must find it out first, right? It
because I say so, it just the way things are. There's no tag, I need
it, I must find it out. If I *don't* need it (e.g., YAML pretty
printer), I simply don't bother finding it out.
Brain-dead simple, can't get it wrong, can explain it to a first grader.
"What you see is what you get".
Magical !implicit-* tags that change what they mean for different nodes
is complicated. See, this node has an invisible !"implicit" tag. Its
invisible, that's why you can't see it, OK? Except it doesn't _really_
have this tag, because if I actually _need_ the tag, I first might want
to change it to something else. If I don't actually need the tag
(e.g., YAML pretty printer), I don't bother to change it. No, it is
*not* allowed to change any other tag, that is very different and would
be very bad. Because I say so, that's why!
Brain-numbing complicated, can't get it right, can't explain it to
people in this list without a zillion posts (and even then, I bet some
got it wrong). "What you see is what I mean".
And the worst of it all... its *unnecessary*. The semantics is _the
same_ as the much simpler alternative (using NULLs).
> I'll close with this final thought: If YAML intends to stay out of
> the business of semantics, then it must give up trying to tame
+100. Transformations can and will do anything at all, it is OK to apply
them, there's nothing in the spec to forbid them. It is just that they
are out of the scope of the YAML core spec. We must ensure that nobody
even *thinks* of the word "transformation" when he simply loads his
document. "Transform it? I dumped my object, I loaded it back - what
transformation? Magical invisible tags that disappear just before I use
them? What have you been ingesting?"
I dumped, I loaded, it is the *SAME*.