Clark C. Evans wrote:
> On Fri, Sep 03, 2004 at 04:57:33AM +0100, David Hopwood wrote:
> | If there is a policy of restricting new names in the
> | repository to, say, [a-zA-Z0-9_]+, then people can choose to use
> | private names that do not match that regexp without any risk that
> | they will be confusable with future repository-defined tags.
> | (This is useful despite the fact that there is nothing preventing
> | collisions between two private names in general.)
> Perfect. Great suggestion.
Although not needed with pass #7 or #8, where the names of private and
YAML tags are disjoint.
> On Fri, Sep 03, 2004 at 10:14:22AM +0300, Oren Ben-Kiki wrote:
> | - %NS: -1. There's nothing special about the "default" tag, it doesn't
> | carry any special semantics that need to be reported to the loader.
> | All %TAG prefixes, including the "default" one, are 100% syntactical
> | trickery, nothing more, nothing else. As David said:
> | > Does %NS identify the type of the document? Surely, the full tag name of
> | > the root node does that.
> | - One doc, one namespace: -10. It just doesn't work when you start to mix
> | "schemas". See the GraphicTimesheet example.
> I can't agree with Oren more. In particular, I don't want the Parser
> sending any 'namespace' information to the Loader. Each application
> can configure the loader as it feels fit. This %TAG mechanism is just
> syntax sugar... to make YAML a bit more sweet.
+2. If there is "namespace" information that matters to the loader, then it
is by definition semantic content as opposed to presentation -- so where
does it go in the representation/serialization models? There is currently
no place for it there (and complicating the models in order to add it would
By the same argument, whether an implicit-tagged scalar is written in
quoted style is also semantic content, and so there must be different
implicit tags for plain and quoted scalars. IIUC, these are both currently
reported by parsers as the empty string :-(
One option would be to define these as equivalent to private tags named
"plain" or "quoted" (i.e. !plain or !quoted in #8). For example:
would be equivalent to
- !plain 42
- !quoted "foo"
If a default %TAG is in effect then these would get expanded just as normal.
So the loader would have all the information that T. Onoma wants it to have,
if I understand his argument correctly.
Going back to some comments on pass #7 that I didn't get around to:
> On Friday 03 September 2004 04:53 am, Oren Ben-Kiki wrote:
> | - Use "!" instead of "^". Yes, "!" is a URI character. Still,
> | there's no ambiguity, as long as the "default" %TAG _must_ have
> | a "!" at the end. And its worth it (see below).
You could always write ! as %21 if you really wanted to refer to an
URI with a ! in it (this works because ! is not in RFC2396[bis]
> | - Tags starting with '!' (as in !!foo) are "private". If a default
> | %TAG namespace is defined, they use that.
> | - Tags starting with "scheme:" are global (as in "!http://whatever").
> | They are passed on as is.
> | - Tags starting with "prefix!" require a %TAG (as in "!prefix!suffix").
> | They are cooked using the prefix.
> | - All other tags are automatically given the prefix "tag:yaml.org,2004:"
> | (as in "!int").
> Nice proposal, but it doesn't have wings:
Humbug. #7 is an improvement on #8 IMHO. It avoids making an inadequately
motivated and incompatible change to the current convention in which
!int is a YAML tag, and !!private a private tag.
> On Fri, Sep 03, 2004 at 11:00:43AM +0300, Oren Ben-Kiki wrote:
> | Strictly speaking, _all_ references to "URI" in the spec need to be
> | replaced with "URI reference". Thanks for catching that.
> We should say up front, that when we say URI we mean an absolute URI
> reference; "URI reference" by itself is not sufficient..
No, the spec should say "absolute URI reference" in each case, not
redefine URI up-front.
> | - Other than "cooking", no other processing is done to tag characters.
> | Specifically, no form of escaping is applied by the YAML processor.
\-escaping in tags shouldn't be any different from \-escaping anywhere
else in a YAML document. It is not needed in tags, so it would be reasonable
to discourage it there, but not to forbid it.
David Hopwood <david.nospam.hopwood@...>