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

On Mon, Jun 14, 2010 at 1:51 PM, William Spitzak <[email protected]> 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?
>

Yes.


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

Thanks!

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

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

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core