From: Antoine A. <aa...@gm...> - 2014-07-22 22:05:53
|
According to the YAML 1.1 spec <http://yaml.org/spec/1.1/#l-first-document>, If the document specifies no directives, it is parsed using the same > settings as the previous document. > However, the YAML 1.2 spec <http://yaml.org/spec/1.2/spec.html#id2800132> states that 9.1. Documents <http://yaml.org/spec/1.2/spec.html#id2800132> > A YAML character stream may contain several documents. Each document is > completely independent from the rest. > and makes no mention of inheriting directives from the previous document. This change might cause subtle bugs when using a 1.2 processor on a stream that was designed assuming version 1.1. Am I correctly interpreting the specs? In the initial paragraphs of version 1.2, it is said that The primary objective of this revision is to bring YAML into compliance > with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most > practical applications - this is a minor revision. > This makes me wonder if this change was intentional, or if was an overlook. Can someone clarify? Thanks, Antoine Aubry |
From: Oren Ben-K. <or...@be...> - 2014-07-22 22:33:31
|
Well... that's why it says "YAML 1.2 is compatible with 1.1 for *most* practical applications - this is a minor revision.". Directives were/are pretty rarely used in practice. There are other subtle incompatibility issues, due to the requirement of being 100% compatible with JSON. On Wed, Jul 23, 2014 at 1:05 AM, Antoine Aubry <aa...@gm...> wrote: > According to the YAML 1.1 spec > <http://yaml.org/spec/1.1/#l-first-document>, > > If the document specifies no directives, it is parsed using the same >> settings as the previous document. >> > > However, the YAML 1.2 spec <http://yaml.org/spec/1.2/spec.html#id2800132> > states that > > 9.1. Documents <http://yaml.org/spec/1.2/spec.html#id2800132> >> A YAML character stream may contain several documents. Each document is >> completely independent from the rest. >> > > and makes no mention of inheriting directives from the previous document. > This change might cause subtle bugs when using a 1.2 processor on a stream > that was designed assuming version 1.1. Am I correctly interpreting the > specs? > > In the initial paragraphs of version 1.2, it is said that > > The primary objective of this revision is to bring YAML into compliance >> with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most >> practical applications - this is a minor revision. >> > > This makes me wonder if this change was intentional, or if was an > overlook. Can someone clarify? > > Thanks, > > Antoine Aubry > > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Antoine A. <aa...@gm...> - 2014-07-23 11:41:01
|
Ok, thanks for the clarification. On 22 July 2014 23:33, Oren Ben-Kiki <or...@be...> wrote: > Well... that's why it says "YAML 1.2 is compatible with 1.1 for *most* > practical applications - this is a minor revision.". Directives were/are > pretty rarely used in practice. There are other subtle incompatibility > issues, due to the requirement of being 100% compatible with JSON. > > > On Wed, Jul 23, 2014 at 1:05 AM, Antoine Aubry <aa...@gm...> wrote: > >> According to the YAML 1.1 spec >> <http://yaml.org/spec/1.1/#l-first-document>, >> >> If the document specifies no directives, it is parsed using the same >>> settings as the previous document. >>> >> >> However, the YAML 1.2 spec <http://yaml.org/spec/1.2/spec.html#id2800132> >> states that >> >> 9.1. Documents <http://yaml.org/spec/1.2/spec.html#id2800132> >>> A YAML character stream may contain several documents. Each document is >>> completely independent from the rest. >>> >> >> and makes no mention of inheriting directives from the previous document. >> This change might cause subtle bugs when using a 1.2 processor on a stream >> that was designed assuming version 1.1. Am I correctly interpreting the >> specs? >> >> In the initial paragraphs of version 1.2, it is said that >> >> The primary objective of this revision is to bring YAML into compliance >>> with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most >>> practical applications - this is a minor revision. >>> >> >> This makes me wonder if this change was intentional, or if was an >> overlook. Can someone clarify? >> >> Thanks, >> >> Antoine Aubry >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Yaml-core mailing list >> Yam...@li... >> https://lists.sourceforge.net/lists/listinfo/yaml-core >> >> > |
From: Trans <tra...@gm...> - 2014-07-23 15:40:05
|
Considering that there is only one official directive `%YAML`, the distinction might not really matter. I would expect that all documents in a stream to be the same YAML version. If there is a chance they might not be, I would advise that the generator be modified to normalize them so they are. It might not be a bad idea to make that a rule. |
From: Oren Ben-K. <or...@be...> - 2014-07-23 16:12:42
|
There are also the %TAG directives. On Wed, Jul 23, 2014 at 6:39 PM, Trans <tra...@gm...> wrote: > Considering that there is only one official directive `%YAML`, the > distinction might not really matter. I would expect that all documents in a > stream to be the same YAML version. If there is a chance they might not be, > I would advise that the generator be modified to normalize them so they are. > > It might not be a bad idea to make that a rule. > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Trans <tra...@gm...> - 2014-07-23 15:43:27
|
Duh. right. So in 1.2 they apply per-document and not per-stream? |
From: Oren Ben-K. <or...@be...> - 2014-07-23 16:13:01
|
Yes. It is a trade off. The decision was to make it safe to concatenate streams/documents (we also did work on the document markers to make it more robust). On Wed, Jul 23, 2014 at 6:43 PM, Trans <tra...@gm...> wrote: > Duh. right. > > So in 1.2 they apply per-document and not per-stream? > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Ingy d. N. <in...@in...> - 2014-07-23 17:22:54
|
FWIW, I think the "use case" of randomly concatenating YAML files, and trying to ensure they still make sense, is totally bogus. I think we should have called BS on it a long time ago. Nobody would ever expect a syntax to work that way. It's like concatenating 2 arbitrary Python files. All bets are off. The fact that we use this use case to back up language decisions, is a bad smell. ... While I'm here, I should mention that directives themselves seem to be a bad smell. First off, there are only 2 of them, which makes it feel kludgy, I feel like I've written about this here: https://github.com/yaml/YAML2/wiki but I can't see it at the moment. I'll add something later... I think we could lose the directives in a YAML 2.0. YAML documents have never stood on their own. They need an outside context to give them any meaning. There are a couple general contexts (schemas) that are well understood: 1. Be like JSON, as much as possible by default. 2. Whatever the Load/Dump of a framework decides is best for a language. As long as the loader roundtrips what the dump dumps, YAML is safe within that language/yaml-framework. The general point though (and this goes over the heads of 99.9% of YAML users) is that (without context/schema) any YAML stream can mean *anything*. ie the YAML {foo: bar} could (conceivably) load the same as the JSON [1, 2, 3]. So given that, the TAG directive, seems like it could be moved elsewhere (just like all the other context), and YAML directive could too. I can't recall ever seeing a YAML directive in the wild. On Wed, Jul 23, 2014 at 9:12 AM, Oren Ben-Kiki <or...@be...> wrote: > Yes. It is a trade off. The decision was to make it safe to concatenate > streams/documents (we also did work on the document markers to make it more > robust). > > > On Wed, Jul 23, 2014 at 6:43 PM, Trans <tra...@gm...> wrote: > >> Duh. right. >> >> So in 1.2 they apply per-document and not per-stream? >> >> >> >> ------------------------------------------------------------------------------ >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Yaml-core mailing list >> Yam...@li... >> https://lists.sourceforge.net/lists/listinfo/yaml-core >> >> > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Oren Ben-K. <or...@be...> - 2014-07-23 18:25:10
|
I concatenate YAML files together all the time, but I don't do it randomly :-) Agreed %TAG isn't really used. Most usage of YAML are in the context of a single application, where tags aren't very useful. If you take out the requirement that the YAML file has "semantics" beyond the specific application that reads it, then it is possible to simplify the spec, but there are also dangers in that approach. On Wed, Jul 23, 2014 at 8:22 PM, Ingy dot Net <in...@in...> wrote: > FWIW, I think the "use case" of randomly concatenating YAML files, and > trying to ensure they still make sense, is totally bogus. I think we should > have called BS on it a long time ago. > > Nobody would ever expect a syntax to work that way. It's like > concatenating 2 arbitrary Python files. All bets are off. > > The fact that we use this use case to back up language decisions, is a bad > smell. > > ... > > While I'm here, I should mention that directives themselves seem to be a > bad smell. First off, there are only 2 of them, which makes it feel kludgy, > I feel like I've written about this here: > https://github.com/yaml/YAML2/wiki but I can't see it at the moment. I'll > add something later... > > I think we could lose the directives in a YAML 2.0. YAML documents have > never stood on their own. They need an outside context to give them any > meaning. There are a couple general contexts (schemas) that are well > understood: > > 1. Be like JSON, as much as possible by default. > 2. Whatever the Load/Dump of a framework decides is best for a > language. As long as the loader roundtrips what the dump dumps, YAML is > safe within that language/yaml-framework. > > The general point though (and this goes over the heads of 99.9% of YAML > users) is that (without context/schema) any YAML stream can mean > *anything*. ie the YAML {foo: bar} could (conceivably) load the same as the > JSON [1, 2, 3]. > > So given that, the TAG directive, seems like it could be moved elsewhere > (just like all the other context), and YAML directive could too. I can't > recall ever seeing a YAML directive in the wild. > |
From: Roy B. (Dossier) <roy...@do...> - 2014-07-23 20:32:19
|
Having written and maintained (= rewritten) a handful of domain model constructors (Java) by hand, I'd find a schema-based domain class generator useful. That schema, in turn, could probably be kept simple if the nodes have their tags (resolved or explicit). So I'd vote against the idea of getting rid of the tags ;) Regards, Roy > On 23. juli 2014, at 20:25, Oren Ben-Kiki <or...@be...> wrote: > > I concatenate YAML files together all the time, but I don't do it randomly :-) > > Agreed %TAG isn't really used. Most usage of YAML are in the context of a single application, where tags aren't very useful. If you take out the requirement that the YAML file has "semantics" beyond the specific application that reads it, then it is possible to simplify the spec, but there are also dangers in that approach. > >> On Wed, Jul 23, 2014 at 8:22 PM, Ingy dot Net <in...@in...> wrote: >> FWIW, I think the "use case" of randomly concatenating YAML files, and trying to ensure they still make sense, is totally bogus. I think we should have called BS on it a long time ago. >> >> Nobody would ever expect a syntax to work that way. It's like concatenating 2 arbitrary Python files. All bets are off. >> >> The fact that we use this use case to back up language decisions, is a bad smell. >> >> ... >> >> While I'm here, I should mention that directives themselves seem to be a bad smell. First off, there are only 2 of them, which makes it feel kludgy, I feel like I've written about this here: https://github.com/yaml/YAML2/wiki but I can't see it at the moment. I'll add something later... >> >> I think we could lose the directives in a YAML 2.0. YAML documents have never stood on their own. They need an outside context to give them any meaning. There are a couple general contexts (schemas) that are well understood: >> Be like JSON, as much as possible by default. >> Whatever the Load/Dump of a framework decides is best for a language. As long as the loader roundtrips what the dump dumps, YAML is safe within that language/yaml-framework. >> The general point though (and this goes over the heads of 99.9% of YAML users) is that (without context/schema) any YAML stream can mean *anything*. ie the YAML {foo: bar} could (conceivably) load the same as the JSON [1, 2, 3]. >> So given that, the TAG directive, seems like it could be moved elsewhere (just like all the other context), and YAML directive could too. I can't recall ever seeing a YAML directive in the wild. >> > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Trans <tra...@gm...> - 2014-07-23 21:46:49
|
I suppose the %YAML tag could be done away with if context is always the defining factor. When there is a question then it would be up to the "protocol" to specify. That might be as simple as a file extension, e.g. `.yaml12` or part of a handshake before data transmission. Yet these approaches feel a bit haphazard, where as the directive feels reliable, albeit I'm not sure there is a parser out there that can handle both 1.1 and 1.2 documents (except is so far as they are compatible). Perhaps directives "smell" b/c they have never really been embraced? I certainly can imagine things like a %SCHEMA directive. Another might be a digital %SIGNATURE directive. And so on. But even so, I get the same gut feeling that they're not quite right. So, perhaps the smell is just that these directives aren't in YAML format. Could the specification be generalize such that all documents are streams, and then directives are just a preceding YAML "header" document with a `!!directives` type? Hmm.. of course that assumes the type of the directive document it known ... well the other directives wouldn't have that problem. |
From: Trans <tra...@gm...> - 2014-07-23 21:47:15
|
https://gist.github.com/trans/c28a41353d76a7b78bef |
From: Ingy d. N. <in...@in...> - 2014-07-25 22:36:05
|
Sorry, for the late reply. Just returned from OSCON. Thank you Roy for weighing in. When I have talked about removing the TAG directives on IRC, it has been the Java people who have said that they are really needed. I came up with almost the same solution that trans did: put the info in a leading inline document. This is very extensible, and can be used for all types of added functionality. I had the idea that instead of !!directives document you would have !!tags, !!schema, !!meta (version etc), !!formatting (how to dump), !!translation (how to load; merge etc) etc. You could also merge these into one leading sequence doc of type !!yaml (where each sequence entry is one of the above). This would take directives right out of the language, making the YAML format simpler overall, and allow new external ideas to be played with in a safe way before being adopted as yaml.org types. I've always thought that schema documents should sit relative to their content docs, but didn't think of putting them inline into the stream. YAML has this (multidoc) advantage over JSON. Let's use it. ... Ingy On Wed, Jul 23, 2014 at 2:47 PM, Trans <tra...@gm...> wrote: > https://gist.github.com/trans/c28a41353d76a7b78bef > > > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Trans <tra...@gm...> - 2014-07-26 19:27:22
|
Something like https://gist.github.com/trans/c28a41353d76a7b78bef ? |
From: Oren Ben-K. <or...@be...> - 2014-07-26 19:55:41
|
I like the notion of simply converting the directives to a previous document in the stream. Presumably this prefix document will remain in effect until a different such document appears? We can do a lot of bike-shedding on the syntax of such document, but the simplest thing is something like trans1.yaml. This probably needs to be tagged !!directives instead of !!directive but that's very minor. On Sat, Jul 26, 2014 at 10:27 PM, Trans <tra...@gm...> wrote: > Something like https://gist.github.com/trans/c28a41353d76a7b78bef ? > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Ingy d. N. <in...@in...> - 2014-07-27 01:26:10
|
Commented on https://gist.github.com/trans/c28a41353d76a7b78bef Basically we have a set of concerns that can effect the usage/processing of a YAML stream; version, tag-expansion, schema, emitter/formatter rules, etc. Each of these concerns can be expressed in YAML and can live in a separate document that is somehow associated with the YAML to be processed. The association can be a separate relative file, and in-stream YAML document, internal to the YAML framework logic or something else. The inline association is nice for things like tags, but things like schemas likely want to be external and reusable. We have the following tags (at a minimum) that we can add to the yaml.org,2002 base: - !!yaml - !!schema - !!format I prefer a more generic name like 'yaml' or 'meta' for the top level info. 'directive' is a noun that usually describes single line syntax things like '#include'. I also don't like using plural, which is a foreign concept to many languages, when singular conveys the same meaning. I'm guessing that zero or one !!yaml documents at the beginning of a stream is all that is needed in practice. Something like: https://gist.github.com/ingydotnet/c5e17136d85c30e32b14 Cheers, Ingy |
From: Zenaan H. <ze...@fr...> - 2014-07-27 04:30:30
|
On 7/27/14, Ingy dot Net <in...@in...> wrote: > '#include'. I also don't like using plural, which is a foreign concept to > many languages, when singular conveys the same meaning. Would the plural of yaml be yiml or yamls or what? |
From: Oren Ben-K. <or...@be...> - 2014-07-27 04:57:22
|
!!meta is good. Dances around the plurality issue, is properly generic, and conveys the correct semantics (meta data describing the following documents). On Sun, Jul 27, 2014 at 7:30 AM, Zenaan Harkness <ze...@fr...> wrote: > On 7/27/14, Ingy dot Net <in...@in...> wrote: > > '#include'. I also don't like using plural, which is a foreign concept to > > many languages, when singular conveys the same meaning. > > Would the plural of yaml be yiml or yamls or what? > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Zenaan H. <ze...@fr...> - 2014-07-27 05:15:44
|
On 7/27/14, Oren Ben-Kiki <or...@be...> wrote: > On Sun, Jul 27, 2014 at 7:30 AM, Zenaan Harkness <ze...@fr...> wrote: >> On 7/27/14, Ingy dot Net <in...@in...> wrote: >> > '#include'. I also don't like using plural, which is a foreign concept >> > to >> > many languages, when singular conveys the same meaning. >> >> Would the plural of yaml be yiml or yamls or what? > !!meta is good. Dances around the plurality issue, is properly generic, and > conveys the correct semantics (meta data describing the following > documents). !!metaConfigurationSnippet_NonOperative_FileSegment_OptionalCharacteristic and !!metaConfigurationSnippet_NonOperative_FileSegment_NonOptionalCharacteristic perhaps? :) An ACK on "!!meta". It's also just slightly more concise than my suggestions above, which is a bonus. So could bonii be the plural of bonus? Best Zenaan >> _______________________________________________ >> Yaml-core mailing list >> Yam...@li... >> https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Trans <tra...@gm...> - 2014-07-28 00:38:50
|
One minor point about the use of a directive(s) tag, where `!!directive`, `!!directives` or `!!yaml`, what if `!!` has been redefined by a prior directive? P.S. Could someone please fix the mailing list to respond to the mailing list? I am sick and tired of sending my responses to individuals rather than the list. I try to remember but inevitably some get by me. This message is a case in point. I sent to to Zazaan yesterday. |
From: Oren Ben-K. <or...@be...> - 2014-07-28 07:32:49
|
!!meta is just a shorthand way of specifying a full URI. The full URI is what sets the semantics. If someone overrides !! so the resulting URI is different, well then, the document will have the semantics specified by that different URI. On Mon, Jul 28, 2014 at 3:38 AM, Trans <tra...@gm...> wrote: > One minor point about the use of a directive(s) tag, where `!!directive`, > `!!directives` or `!!yaml`, what if `!!` has been redefined by a prior > directive? > > > P.S. Could someone please fix the mailing list to respond to the mailing > list? I am sick and tired of sending my responses to individuals rather > than the list. I try to remember but inevitably some get by me. This > message is a case in point. I sent to to Zazaan yesterday. > > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Ingy d. N. <in...@in...> - 2014-07-28 11:04:42
|
Well put, Oren! On Mon, Jul 28, 2014 at 12:32 AM, Oren Ben-Kiki <or...@be...> wrote: > !!meta is just a shorthand way of specifying a full URI. The full URI is > what sets the semantics. If someone overrides !! so the resulting URI is > different, well then, the document will have the semantics specified by > that different URI. > > > On Mon, Jul 28, 2014 at 3:38 AM, Trans <tra...@gm...> wrote: > >> One minor point about the use of a directive(s) tag, where `!!directive`, >> `!!directives` or `!!yaml`, what if `!!` has been redefined by a prior >> directive? >> >> >> P.S. Could someone please fix the mailing list to respond to the mailing >> list? I am sick and tired of sending my responses to individuals rather >> than the list. I try to remember but inevitably some get by me. This >> message is a case in point. I sent to to Zazaan yesterday. >> >> >> >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> Yaml-core mailing list >> Yam...@li... >> https://lists.sourceforge.net/lists/listinfo/yaml-core >> >> > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > > |
From: Trans <tra...@gm...> - 2014-07-29 15:34:08
|
Did it again! Sigh. ---------- Forwarded message ---------- From: Trans <tra...@gm...> Date: Mon, Jul 28, 2014 at 10:50 AM Subject: Re: [Yaml-core] Fwd: Breaking change between YAML 1.1 and 1.2 with multiple documents To: Oren Ben-Kiki <or...@be...> On Mon, Jul 28, 2014 at 3:32 AM, Oren Ben-Kiki <or...@be...> wrote: > !!meta is just a shorthand way of specifying a full URI. The full URI is > what sets the semantics. If someone overrides !! so the resulting URI is > different, well then, the document will have the semantics specified by > that different URI. > Sweet. +1 for !!meta ! |
From: Trans <tra...@gm...> - 2014-07-29 15:37:40
|
Was thinking about how this would effect the specification. It occurred to me that it might require some adjustment to terminology b/c every YAML document would also be stream, even if it contained only one document --hence the terminology problem. i.e. "a YAML document is a stream of YAML documents". That would be confusing. |
From: Alexey Z. <ind...@gm...> - 2014-07-31 10:24:02
Attachments:
signature.asc
|
On 29 Jul 2014, at 19:37, Trans <tra...@gm...> wrote: > Was thinking about how this would effect the specification. It occurred to me that it might require some adjustment to terminology b/c every YAML document would also be stream, even if it contained only one document --hence the terminology problem. i.e. "a YAML document is a stream of YAML documents". That would be confusing. something like: "YAML file has to be interpreted as a Stream of YAML Documents" -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc |