Re: Yayson (proposal for a YAML presentation embedded within JSON for browser clients)

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.

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.

> {"&": "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).

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.

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

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

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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo