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

On Mon, Jun 14, 2010 at 7:42 PM, William Spitzak <[email protected]> wrote:

>
>
> Ingy dot Net wrote:
>
>     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?
>>
>
> It seems ok. Certainly whether a string is quoted or not is used by YAML
> parsers to determine type, but that is only when the tag is missing. I think
> if there is a tag then it is ok if the value is always quoted. It does mean
> that you cannot add more keywords than JSON supports as unquoted constants
> to YAML but I don't think that is being allowed anyway?
>

Right. The serialization needs to be 100% JSON.


>
>  We need to support a top level '%TAG' and '%JSYNC' syntax:
>>
>> %YAML 1.2
>> %TAG ! tag:xyz.com <http://xyz.com>,2010:
>> %TAG !abc! tag:abc.net <http://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 <http://xyz.com>,2010:\nTAG !abc!
>> tag:abc.net <http://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 <http://xyz.com>,2010:\n%TAG !abc! tag:
>> abc.net <http://abc.net>,2010:\n!thing",
>>  ["!abc!widget", 2, 4]
>> ]
>>
>
> I would put each '%' into it's own item.
>
> I think of YAML, if you include the "---" dividers, as having a top-level
> list naturally. So perhaps the conversion of YAML to JSON is to turn it
> always into a list. Back-conversion will turn that top-level list into ---
> divided items.


Interesting thoughts. Let's let it brew for a while.


>
>  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.
>>
>
> Okay we have the following list, imho:
>
> DEFINATELY NEED QUOTING:
>  !, #, %, &, *
>
> MAY NEED QUOTING:
>  @ (reserved for future use by YAML)
>  space (I'm not sure why)
>

because space sorts before '!'. The first printable chars are:

     <space> ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @

I was thinking it would be nice if the JSYNCisms key sorted above the normal
keys.


>  " and ' (also used by YAML at the start of values)
>

" will always be \"

It is required to be valid JSON.


>
> NOT QUOTED:
>  +, -, 0-9 (for numbers)
>  A-Z, a-z, _ (valid identifiers in most languages)
>  All Unicode > 0x7f (match the letters, no UTF-8 decoding needed)
>  / and \ (for . and .. filenames)
>  "nothing": a string of only periods is unchanged (for . and .. filenames)
>

Agreed.


>
> UNKNOWN (but I would say not quoted):
>  C0 control characters such as newline
>  $, (, ), comma, -, :, ;, <, =, >, ?, [, ], ^, `, {, |, }, ~
>
>
>
>
>
>
>> 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