From: Ingy d. N. <in...@in...> - 2010-04-30 08:09:24
|
Greetings from Taiwan, I just wrote this up: http://www.jsync.org/ I'm interested to know what y'all think. Cheers, Ingy |
From: Brad B. <bm...@ma...> - 2010-04-30 10:54:17
|
I, for one, would welcome this. Forgive me for spotting trivia, but the lines below don't seem to match. Is that just a typo, or is there something significant I'm missing. "notes": ".!!! Awesome !!!", "notes": ".... add note here ...", notes: '!!! Awesome !!!' notes: ... add note here ... Regards, Brad On Fri, Apr 30, 2010 at 3:43 AM, Ingy dot Net <in...@in...> wrote: > Greetings from Taiwan, > > I just wrote this up: http://www.jsync.org/ > > I'm interested to know what y'all think. > > Cheers, Ingy > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Trans <tra...@gm...> - 2010-04-30 15:07:21
|
On Apr 30, 3:43 am, Ingy dot Net <i...@ingy.net> wrote: > Greetings from Taiwan, > > I just wrote this up:http://www.jsync.org/ > > I'm interested to know what y'all think. Very coo and potentially useful. Is it 100% YAML <-> JSYNC ? |
From: Ingy d. N. <in...@in...> - 2010-04-30 18:12:36
|
On Fri, Apr 30, 2010 at 11:07 PM, Trans <tra...@gm...> wrote: > > > On Apr 30, 3:43 am, Ingy dot Net <i...@ingy.net> wrote: > > Greetings from Taiwan, > > > > I just wrote this up:http://www.jsync.org/ > > > > I'm interested to know what y'all think. > > Very coo and potentially useful. Is it 100% YAML <-> JSYNC ? > > That's the goal. > > ------------------------------------------------------------------------------ > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: William S. <sp...@rh...> - 2010-04-30 16:22:08
|
Brad Baxter wrote: > I, for one, would welcome this. > > Forgive me for spotting trivia, but the lines > below don't seem to match. Is that just a typo, > or is there something significant I'm missing. > > "notes": ".!!! Awesome !!!", > "notes": ".... add note here ...", > > notes: '!!! Awesome !!!' > notes: ... add note here ... He is using a leading dot to quote the next character. Otherwise it would be impossible to make a tag that starts with '!' or '&'. I'm not sure this is the best choice, as numbers can start with a dot. This is not in official JSON syntax, however, because they must start with a zero and are never quoted while strings always are, but there are plenty of semi-JSON syntaxes that do not follow these rules and this would be a serious incompatibility with them. I think another punctuation mark should be used. '!' can't work as YAML tags can start with '!!'. But I think '&' works because a YAML address cannot start with '&&', right? Other change I would make is unify the syntax between lists and maps. Instead of "!":"record" in the map, I would use "!record":null. If there is both a tag and address I would use "!record":"&address". > Greetings from Taiwan, > > I just wrote this up: http://www.jsync.org/ > > I'm interested to know what y'all think. > > Cheers, Ingy |
From: William S. <sp...@rh...> - 2010-04-30 16:32:53
|
How are complex mapping keys supported? Only simple way I can see is to disobey JSON syntax and allow maps and lists as the keys. A complex way is to invent a few new addresses. Then the following: {{foo:bar} : value} turns into: {"&generatedA" : {"foo":"bar"}, "*generatedA" : "value" } where "generatedA" is an address produced by the from-YAML converter. Big problem with this is that it will not round-trip convert to the identity. > <mailto:in...@in...>> wrote: > > Greetings from Taiwan, > > I just wrote this up: http://www.jsync.org/ > > I'm interested to know what y'all think. > > Cheers, Ingy |
From: Ingy d. N. <in...@in...> - 2010-04-30 18:55:19
|
On Sat, May 1, 2010 at 12:32 AM, William Spitzak <sp...@rh...> wrote: > How are complex mapping keys supported? > I left this out of the front page example because it is the least important, and might make the example too muddy for the front page. My initial idea was to add an extra mapping to the start of the doc that contained the complex keys (all with anchors) and then reference them below. That would definitely work, but maybe there's a better way. Something like this { "%": [ ["&1", 3, 5], ["&2", 1, 6] ] }, "*1": "aaa", "*2": "bbb" } is: --- [3, 5]: aaa [1, 6]: bbb ... % is a new addition. I also want to add support for YAML's "%TAG" and "%JSYNC" (version). Only simple way I can see is to disobey JSON syntax and allow maps and lists > as the keys. > Plausible but I'm against the idea since I want it to be pure JSON at the parser/emitter level. Implementing JSYNC is just putting a simple constructor and representer over a JSON implementation. > A complex way is to invent a few new addresses. Then the following: > > {{foo:bar} : value} > > turns into: > > {"&generatedA" : {"foo":"bar"}, > "*generatedA" : "value" > } > > where "generatedA" is an address produced by the from-YAML converter. Big > problem with this is that it will not round-trip convert to the identity. > > > <mailto:in...@in...>> wrote: >> >> Greetings from Taiwan, >> >> I just wrote this up: http://www.jsync.org/ >> >> I'm interested to know what y'all think. >> >> Cheers, Ingy >> > |
From: Ingy d. N. <in...@in...> - 2010-04-30 18:36:39
|
On Sat, May 1, 2010 at 12:21 AM, William Spitzak <sp...@rh...> wrote: > > > Brad Baxter wrote: > >> I, for one, would welcome this. >> >> Forgive me for spotting trivia, but the lines >> below don't seem to match. Is that just a typo, >> or is there something significant I'm missing. >> >> "notes": ".!!! Awesome !!!", >> "notes": ".... add note here ...", >> >> notes: '!!! Awesome !!!' >> notes: ... add note here ... >> > > He is using a leading dot to quote the next character. Otherwise it would > be impossible to make a tag that starts with '!' or '&'. > > Correct. I chose a leading period as the escape character. The first '.' of any string is removed. '\' doesn't work for obvious reasons. I chose '.' because it is small and not unsightly, but readability isn't a major design goal. I also chose '.' because it sorts after '!', '&' and '*'. It will be recommended that JSYNC emitters emit mapping keys in sort order. Types will always sort to the top, unless the key begins with a space. In that case the emitter is recommended to put a '.' in front of the space, to make it sort lower. The first ascii printables are: ! " # $ % & ' ( ) * + , - . / 0 1 I'd like all special chars to be before '0'. I'd like the escape char to sort last, or at least after the '&'. That leaves us with ' + , - . or /. I still like . the best. Note that the escape char is the leading char, *after* extra syntax is removed. [ "!type .&content" ] is: --- !type '&content' I'm not sure this is the best choice, as numbers can start with a dot. This > is not in official JSON syntax, however, because they must start with a zero > and are never quoted while strings always are, but there are plenty of > semi-JSON syntaxes that do not follow these rules and this would be a > serious incompatibility with them. > Can you elucidate with an example? I don't follow the logic. > I think another punctuation mark should be used. '!' can't work as YAML > tags can start with '!!'. But I think '&' works because a YAML address > cannot start with '&&', right? > > Other change I would make is unify the syntax between lists and maps. > Instead of "!":"record" in the map, I would use "!record":null. If there is > both a tag and address I would use "!record":"&address". I was thinking of: "!": "!record" as a possibility. The "!record":"&address" is pretty clever. I'll sleep on it. > > Greetings from Taiwan, >> >> I just wrote this up: http://www.jsync.org/ >> >> I'm interested to know what y'all think. >> >> Cheers, Ingy >> > |
From: William S. <sp...@rh...> - 2010-05-01 02:11:13
|
Ingy dot Net wrote: > I'm not sure this is the best choice, as numbers can start with a > dot. This is not in official JSON syntax, however, because they must > start with a zero and are never quoted while strings always are, but > there are plenty of semi-JSON syntaxes that do not follow these > rules and this would be a serious incompatibility with them. > > > Can you elucidate with an example? I don't follow the logic. libyaml does not provide any obvious api to determine if a scalar was quoted. Using it to read these files and decide if leading periods should be stripped would require you to peek into the "events" to determine if they were quoted, making it impossible to use the higher level structured api. Also I suspect it was not intended that you be able to look at the quoting of events and this is a side effect of using the same structure for output as input. |
From: Ingy d. N. <in...@in...> - 2010-05-01 08:36:32
|
Oh, heh. I was not even considering using libyaml for any of this, but I guess that's a good idea. I was just considering using the existing plethora of JSON parser/emitters, and adding a consistent API layer over them. The main point of JSYNC is simple, cross language, plain text serialization. Human friendly, human editable is not a concern. Therefore I expect that only JSYNC emitters will write JSYNC (not people). I don't see this as a big deal, even using libyaml. But I will consider it, and see how it plays out in the early adoption cycle. Thanks, for reviewing what I've written so far. Hopefully I will have a spec and JavaScript and Python initial implementation done by the end of May. Cheers, Ingy On Sat, May 1, 2010 at 8:45 AM, William Spitzak <sp...@rh...> wrote: > Ingy dot Net wrote: > > I'm not sure this is the best choice, as numbers can start with a >> dot. This is not in official JSON syntax, however, because they must >> start with a zero and are never quoted while strings always are, but >> there are plenty of semi-JSON syntaxes that do not follow these >> rules and this would be a serious incompatibility with them. >> >> >> Can you elucidate with an example? I don't follow the logic. >> > > libyaml does not provide any obvious api to determine if a scalar was > quoted. Using it to read these files and decide if leading periods should be > stripped would require you to peek into the "events" to determine if they > were quoted, making it impossible to use the higher level structured api. > Also I suspect it was not intended that you be able to look at the quoting > of events and this is a side effect of using the same structure for output > as input. > |
From: Brad B. <bm...@ma...> - 2010-05-01 12:39:46
|
On Fri, Apr 30, 2010 at 2:36 PM, Ingy dot Net <in...@in...> wrote: > > On Sat, May 1, 2010 at 12:21 AM, William Spitzak <sp...@rh...> wrote: >> >> Brad Baxter wrote: >>> >>> I, for one, would welcome this. >>> >>> Forgive me for spotting trivia, but the lines >>> below don't seem to match. Is that just a typo, >>> or is there something significant I'm missing. >>> >>> "notes": ".!!! Awesome !!!", >>> "notes": ".... add note here ...", >>> >>> notes: '!!! Awesome !!!' >>> notes: ... add note here ... >> >> He is using a leading dot to quote the next character. Otherwise it would >> be impossible to make a tag that starts with '!' or '&'. >> I suspect my understanding is shallow and logic flawed, but I'm not sure why the string would need escaping if yaml would understand it. For example, the above ought to be just "notes": "'!!! Awesome !!!'", "notes": "... add note here ...", because yaml would understand them, and ... > Note that the escape char is the leading char, *after* extra syntax is > removed. > > [ "!type .&content" ] > > is: > > --- !type '&content' ... the above could be [ "!type '&content'" ] I suppose this could also work [ "!type \"&content\"" ] but I'm not sure it would ever be needed if JSON's character notations (vs. YAML's double-quoted ones) are sufficient. As an escape mechanism, I would find single quotes much easier to spot. See original caveat. :-) -- Brad |
From: Ingy d. N. <in...@in...> - 2010-05-01 17:50:14
|
On Sat, May 1, 2010 at 8:39 PM, Brad Baxter <bm...@ma...> wrote: > On Fri, Apr 30, 2010 at 2:36 PM, Ingy dot Net <in...@in...> wrote: > > > > On Sat, May 1, 2010 at 12:21 AM, William Spitzak <sp...@rh...> > wrote: > >> > >> Brad Baxter wrote: > >>> > >>> I, for one, would welcome this. > >>> > >>> Forgive me for spotting trivia, but the lines > >>> below don't seem to match. Is that just a typo, > >>> or is there something significant I'm missing. > >>> > >>> "notes": ".!!! Awesome !!!", > >>> "notes": ".... add note here ...", > >>> > >>> notes: '!!! Awesome !!!' > >>> notes: ... add note here ... > >> > >> He is using a leading dot to quote the next character. Otherwise it > would > >> be impossible to make a tag that starts with '!' or '&'. > >> > > I suspect my understanding is shallow and logic flawed, but > I'm not sure why the string would need escaping if yaml would > understand it. > > For example, the above ought to be just > > "notes": "'!!! Awesome !!!'", > "notes": "... add note here ...", > The base encoding is not yaml, it's json. I need to repurpose strings that begin with a ! & or *. So in the rare case that an actual json string begins with one of those, I need to escape it. I do that by putting a '.' in front. Then I make the rule that in JSYNC, a '.' at the start of a string is removed. Therefore I need to encode the string '...' as "....". That's a simple rule. I could make things more complicated by saying I only remove a leading '.' if it comes before a ! & or *, but that seems a little too precious to me. Make sense? > because yaml would understand them, and ... > > > Note that the escape char is the leading char, *after* extra syntax is > > removed. > > > > [ "!type .&content" ] > > > > is: > > > > --- !type '&content' > > ... the above could be > > [ "!type '&content'" ] > > I suppose this could also work > > [ "!type \"&content\"" ] > > but I'm not sure it would ever be needed if > JSON's character notations (vs. YAML's > double-quoted ones) are sufficient. > Single quotes are an option, but I would only add them at the start, like in "'!!!" and "!type '&content". Hmm, I don't like the ' next to ". Very hard to read. ".!!!" and "!type .&content" read better. > > As an escape mechanism, I would find > single quotes much easier to spot. > > See original caveat. :-) > > -- > Brad > |
From: William S. <sp...@rh...> - 2010-05-03 17:08:36
|
Ingy dot Net wrote: > The base encoding is not yaml, it's json. I need to repurpose strings > that begin with a ! & or *. So in the rare case that an actual json > string begins with one of those, I need to escape it. I do that by > putting a '.' in front. Then I make the rule that in JSYNC, a '.' at the > start of a string is removed. Therefore I need to encode the string > '...' as "....". That's a simple rule. I could make things more > complicated by saying I only remove a leading '.' if it comes before a ! > & or *, but that seems a little too precious to me. Making the '.' do quoting if only in front of a character that needs quoting makes sense, and would fix the problem I am worried about with numbers, since ".1" would be unchanged. It does mean the set of characters to quote has to be defined, but it looks like "&*.@" might be enough. |