On Mon, Jun 14, 2010 at 1:51 PM, William Spitzak <spitzak@rhythm.com> wrote:
Ingy dot Net wrote:

Since neither tags nor anchors can contain a space char, you can parse them out by matching from the start to the next space. Trivial.

My concern was if the value started with a space, '&', or '!'. I guess the rule can be that exactly one space is used up. And/or that one of the alternative syntaxes must be used in these cases.

I like that exact solution best. The other option is escaping:

"!foo . s p a c y "
Also this does mean that the %XX encoding is left as-is in the tags & anchors, although libyaml and perhaps other libraries remove this before the string is returned.

Yep. Spaces in tags is pretty insane anyway.
{"&": "anchor", ...}

This is equivalent to YAML '&anchor {...}', not '{&anchor ...}', correct?

["&anchor", ...]

I think this is what influenced my proposal, though I read it wrong. This is I believe equivalent to YAML '&anchor [...]', right? (not '&anchor ...' which is what I thought).

   ["&anchor1", "foo"],
   ["&anchor2 foo"],
   ["&anchor3 ", "foo"],

- &anchor1
  - foo
- &anchor2 foo
- - &anchor3 ''  #anchor on empty string
  - foo

It is not clear how you add a tag or anchor to a non-quoted object such as a number, however. Perhaps it is ok if quotes are required, or maybe I'm missing something.

This is an interesting question. My take is that tagging is only applied to strings. Since each and every tag is resolved by a function, it seems a fair assumption to make.

I realize that there is a distinction in YAML betwixt:

- !foo "3"
- !foo 3

But I don't see a constructor making use of that distinction.

What do you think?

          # YAML: <key>: <value>
          "&A": <key>,
          "*A": <value>

This is a fantastic method. Way better than my proposal. I will fully adopt it for the forthcoming JSYNC specification. Thank you.

Thanks! Yes I was pretty happy with this, after messing with a bunch of nested lists and things it suddenly occurred to me.

It took Clark, Oren and me about 4 years of "occurring" and arguing over ideas, to come up with YAML. Hopefully this will be much quicker.

Speaking of this, there is still an important missing piece in JSYNC. Maybe you can have another stroke of brilliance...

We need to support a top level '%TAG' and '%JSYNC' syntax:

%YAML 1.2
%TAG ! tag:xyz.com,2010:
%TAG !abc! tag:abc.net,2010:
--- !thing
this: !abc!widget [2, 4]

Here is my strawman...

There are two kinds of top level in JSYNC: map and sequence. Map seems easier:

  "%": "JSYNC 1.0\nTAG ! tag:xyz.com,2010:\nTAG !abc! tag:abc.net,2010:",
  "!": "thing",
  "this": ["!abc!widget", 2, 4]

Here is a similar doc as a top level sequence:

  "%JSYNC 1.0\n%TAG ! tag:xyz.com,2010:\n%TAG !abc! tag:abc.net,2010:\n!thing",
  ["!abc!widget", 2, 4]

Whereas ! and & parse to a space or EOS, % parses to newline or EOS.

Another concern is whether to support a top level scalar in JSYNC?

   All string values that start with 1 or more '.' characters followed
   by any one of '&*!@' have a single '.' removed to get the actual value:

          ".!foo" -> "!foo"
          "...!foo" -> "..!foo"
          ".1" -> ".1" # NOTE NO CHANGE!
          "..." -> "..." # AGAIN NO CHANGE!

I have agreed with this logic, since you mentioned it. My only worry is that it doesn't future-proof well. You might want to escape other leading sigils.

I agree, though I only added '@' because that is the only punctuation mark that YAML reserves for future use (unless I read the spec wrong). I think it would make sense to add more punctuation. Some strings that I think should work and not be mangled are ".1", ".cshrc", "./blah", "..\\blah", ".", "..", and "...".

Good starting list. I would want to escape <SPACE>, !, #, $, %, & because then you could tell a JSON encoder to sort mapping keys (if the option is available) and always get the JSYNC fields at the top of the mapping. Not only is this better visually; it might be _necessary_ if we wanted to do streaming JSYNC libraries.

As an aside, I think there is about a year of time where you can declare new technology like JSYNC to be alpha, and subject to non-backwards-compatible change. I personally think it is healthy, and avoids things like mandatory tabs in Makefiles!

> I have updated the http://jsync.org example to reflect this.

This is great and if this question comes up again people should be directed to this web site. Name & syntax are chosen.


The next steps are to write up a syntax spec, then an API spec, then create an implementation or two, then write an implementation guide.

Cheers, Ingy