From: Oren Ben-K. <or...@ri...> - 2001-10-26 08:12:52
|
(Someone should solve the timezone difference problem some day :-) OK, let's see what's settled and what's open: > 0. Let's get rid of '@' and '%' as my original proposal. We all agree here. > 1. Please don't use ':' instead of ' ' to separate "descriptors". We all agree here. > 2. We can use ':' instead of '\' as the next-line scalar indicator. It seems you guys want this. OK. So we all agree here. There was a sub-issue raised about where the descriptors go - before or after this ':'. I think we all agree that before: key: !descriptor : next line value Likewise for any other indicator: key: !descriptor | block value Right? > 3. Let's keep '~' as an implicit type - not a descriptor. Likewise for > '*<anchor>'. We all agree here. > 4. We can add in-line block values (I've no strong opinion). We all agree NOT to have them. > 5. Let's use '-' instead of ':' for list entries (unless someone feels > strongly against it). This is the current agreement, but it isn't "firm". > 6. Let's have explicit type names available for text as well as map and > list. We all agree here. > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. It seems we agree to skip the "<type>!" shorthand. As for specifying the exact semantics of "relative types", are you *certain* we want to get into it right now? I wouldn't mind one but just to keep the current wording: reverse DNS and IANA based names are reserved for their owners, single-word names are private, anything else unspecified (yet). At most add wording saying that names starting with '.' or '/' are reserved. If you do want to get into is, see below for some ideas :-) > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong > opinion). It seems we all agree '@' would have been best, except for the fact it makes it impossible to use @ for indicating lists (if we need it). Again, I think using '[' as an indicator is a bad idea (that's too useful a character to waste on being an indicator). We also can't use an unannotated number - that's rather confusing. So this seems to be open for now... let's think some more on this. > 9. We can restrict unquoted keys to one line. We all agree on this. > 10. There's no need for a magical empty map/list descriptor beyond the > explicit map/list type name. This is still open. My proposal: There seems to be a need in Perl to be able to "bless" an empty list or an empty list. Hmmm. Would the following do: blessed-empty-list: !perl-class-name - blessed-empty-map: !perl-class-name Reasoning: a map-based perl class is defined as an explicit YAML type. This type can accept as a valid value a map with a certain set of keys, OR a text string (the empty one). A list-based perl class is also defined as an explicit YAML type; this type can accept as a valid value a list with certain set of entries, OR a text string (containing a single '-'). If you don't like '' and '-', you can replace them with any other non-indicator string; for all I care, it can be the strings "empty-map" and "empty-list". The point is that there's no need to have these strings be indicators. It is just an explicitly typed scalar, which is deserialized into the appropriate native data structure - a blessed map or list as the case may be. > 11. Let's have an *optional* central registry for implicit types. We seem to agree on this; Clark and I will agree on appropriate wording. > 12. There's no need to be able to serialize the ! and & keys. Yes. This doesn't preclude "encoding" as I called it, or any alternative way to properly round-trip unknown types. > 13. We can have multiple line breaks indicate a top-level list. It seems we now agree on using '----' as seperator instead - however, unlike the previous time we had them, multiple instances do not indicate "empty chunks", they are simply ignored. Right? I can live with that. I disagree that a top-level string is interpreted as a scalar, I think it should be a key: ---- "this is a quoted key" :: "not a value" ---- : "This is a quoted value" ---- : "So is this one" ---- | This is a block value ---- This is an unquoted value ---- : So is this one ---- - This is a list entry ---- this is : a key ---- OK? Note that this clear distinction is only possible because the next-line-scalar indicator isn't identical to the list-entry indicator. So if the list-entry-indicator goes back to ':', we'll have to return the next-scalar indicator to '\'. > 14. Let's reconsider using tabs for indentation. We all agree here to use them. > 15. Let's not have a special in-line key/value pair syntax for '#'. We all agree here. > 16. Let's consider having throw-away comments and other filters as > "transfer encoding". We all agree here; Brian is free to use them, as long as this functionality is explicitly enabled. A wording in the draft that such behavior is acceptable, but that these comments aren't part of YAML, may be in order. > 17. Let's not have a next-line form for the quoted > scalar, so that the multi-line scalar is simpler. We all agree to allow next-line quoted scalars. Right? :-) > 18. Let's allow for multi-line scalars to begin on > the first line and extend to further lines. (Except for blocks). That was always the intent. We all agree here. > 19. Let's consider changing the term 'list' to 'array' in all YAML > documentation. Open issue. Is that's due to the array/tuple distinction: > 20) Reserve '=' for implicit tuple serialization. Reserve !tuple as > well. I'm against it. I agree with Clark that 'tuple' is just an explicit type, and does not require a new list entry indicator. This is for two reasons: - He's the Python head here, and this is Python oriented. - Each language (Java, Perl and Python) has some data types which are hard to do in YAML. For Java, it is structured keys. For Perl, it is deep references. For Python, it is tuples. After much debate, we discovered it is possible to keep YAML simple and manage to represent such values anyway, at some verbosity cost. I think the same reasoning holds here. I see no problem with writing: tuple: !org.yaml.tuple - First slot - Second slot Like "ref" for Perl, "tuple" is a prime candidate for a shorthand name (whatever mechanism we come up with eventually). > 21) I think the type indicator should immediately follow the colon or > dash, even when the value is classed or anchored. I though the syntax was: ('-' | <key> <lwsp>* ':' ) # List entry or key ( <lwsp>+ <descriptor> )* # Descriptors <lwsp>+ ( <indicator>? <eol> # One of (none)<eol>, :<eol>, |<eol>, or |-<eol> | <in-line-value> ) # One of "double", 'single' or un-quoted Any problem with this? > 23) Class names are case-sensitive. I think we all agree on this. Isn't that the case in most languages anyway? OK, that leaves one big issue - the relative type names. I'm starting to regret I ever mentioned it :-) At any rate, let's see what we want to gain from this: - The ability to write reasonably short names. - Especially for org.yaml.* types (rank has its privilege etc.) - Allow private types. - Don't mess the information model. - Make it readable (as little magic as possible). The only know way to do this is to somehow establish the concept of a "type conetxt", which is associated with the natural scoping rules of the document. In XML this is done via xmlns="...". That would map in YAML to something like: key: !any-type ^type-context sub-key: !<indicator, say '.'>type-in-sub-context Think of '^type-context' as a directive to the parser on how to convert "relative types" into "absolute types". Essentially it specifies a prefix to be added to the type name before the application even sees it. The emitter is free to generate type-context directives to make the output look "better"; this is at the same level as deciding to emit a certain scalar as a block to make it look better. There's no "type context" in the information model. Another way to do this is to overload the type declaration. This is built on the observation that in many cases, the type context is shared between the 'key' and the 'sub-key' above. In YAML this may look like: key: !some.absolute.type # establishes some.absolute.* context sub-key: !.other-type # uses that context. Again, this is done at the parser/emitter level, NOT in the information model. Now, note that either way this means that you can't cut-and-paste safely without ensuring you get the appropriate "type name context" as well. In-memory this isn't much of a problem because we tend to rely on the language's built-in type system, but it is an issue when doing text-based operations or when handling unknown types. That's a big minus - many a battle was fought in SML-DEV over this point. *Assuming* this is acceptable: 1. Shoule we use an explict context-setting directive or to overload the type declaration we already have. There are pros and cons here both ways. For example, using an explicit "type context here" makes it easier to detect it when doing cut & paste, and it allows attaching a type context to differently-typed node. For example: list-of-invoices: !com.company1.type ^com.company2. - !.invoice ... This was raised as an issue in SML-DEV. There's little actual experience with this sort of applications, however, so it is unknown whether this is a concern or not. The down side is that any explicit context-setting mechanism requires lookahead in the emitter (to intelligenty choose the context). Also, it is additional explicit magic (as opposed to additional implicit magic :-) 2. Assuming we overload the type declaration, how do we know what part of it is the "context"? The easiest way would be to just strip the last word: context: !some.absolute.type # context is 'some.absolute.' sub: !.another # type is 'some.absolute.another another: !..type # type is 'some.type' because '..' is "up"? But one may also explicitly annotate it: context: !some!.absolute.type # context is 'some.*' another: !.type # type is 'some.type' This allows to establish a context for an untyped node: context: !some.absolute.! # This node is untyped! sub !.type # The type is 'some.absolute.type' 3. As for a special shorthand for 'org.yaml.*', we can use, say '!' for that: sub: !!.tuple # org.yaml.tuple 4. Private types: Simply don't start with '.'. 5. When using IANA based types the reasonable syntax would have been '/' for indicating a relative type, not '.'. Perhaps the best way would be to be agnostic to this (assuming explicit declaration of the context): context: !context-prefix!this-node-type(optional) relative: !!gets-the-context-prefix absolute: !does-not-get-the-prefix yaml: !^yaml-type Where ^ would be any character unlikely to appear in types. In short, this is messy, on the order of any other tough question we faced so far. Do we want to go there now? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-10-26 14:16:21
|
Clark C . Evans wrote: > | > 8. We can add a '^<index>' descriptor for sparse lists (I've no > | > strong opinion). > ... > Right. This one is still open. But note: It's a new feature. Yes. > | > 10. There's no need for a magical empty map/list descriptor > | > beyond the > | > explicit map/list type name. > | > | This is still open. My proposal: > | ... > | blessed-empty-list: !perl-class-name - > | blessed-empty-map: !perl-class-name > > I don't think this will work, beacuse it will make - an > indicator in this context. No, it is just a particulat scalar value. Not an indicator. This *would* be allowed: > not-allowed: !money -23.38 > | The point is that there's no need to have these strings be indicators. > | It is > | just an explicitly typed scalar, which is deserialized into the > | appropriate > | native data structure - a blessed map or list as the case may be. > > Your point is... that the class will know what it's storage > requirement is. This works as long as the class is supported > by the given operational environment, right? Not at all. A Perl parser seeing an unknown type can look at the scalar, if its empty bless an empty map, if its '-' bless an empty list, and otherwise do whatever it does with unknown-type scalars. Which does not make '-' an indicator. It doesn't even make '' and '-' members of an implicit type, since the node is explicitly typed here. What *wouldn't* work is a non-map explicit type which has "" as a valid value, or a non-list explicit type which has "-" as a valid value. In a Perl system *which doesn't know the type*, they will be interpreted as blessed-empty-map and blessed-empty-list. I don't think this is a real problem. > | > 13. We can have multiple line breaks indicate a top-level list. > > But I did have an idea... and it seems a bit simpler > since we can use the "map" grammer... Interesting, but see my other post with a new idea about these and comments. I think being able to "grow into" MIME is an important feature. > | > 19. Let's consider changing the term 'list' to 'array' in all YAML > | > documentation. > | > | Open issue. Is that's due to the array/tuple distinction? > > Hmm. Let's compromise and call it a "sequence"... Fine with me. > | > 20) Reserve '=' for implicit tuple serialization. Reserve !tuple as > | > well. > | > | I'm against it... > | tuple: !org.yaml.tuple > | - First slot > | - Second slot > | > | Like "ref" for Perl, "tuple" is a prime candidate for a shorthand name > | (whatever mechanism we come up with eventually). > > Yep. OK then. > | OK, that leaves one big issue - the relative type names. > | I'm starting to regret I ever mentioned it :-) > | ... this is done at the parser/emitter level, NOT in the > | information model. > > Right. Good. > I think an implicit mechanism is probably the best > in this case. From Don Park's experience, he often > quotes that most data comes in islands. And the container of the island had a name with the right prefix? At any rate, I can live with it, I'm just pointing out it is a mine field and that we don't want to fully settle it. > Also, we could just use the implicit model, and > if it doesn't work add the explicit one (which > would override the implicit mechanism) later, > if we found it was absolutely needed. In this > way we don't overly complicate the system up-front. Sounds reasonable. So what's the current state, I'm losing track here: absolute: !dns.based.absolute relative: !.type # == dns.absolute.type private: !has-no-dot yaml: !!map Or is it: private: !!has-explamantion yaml: !has-no-dot I prefer the former, I think. '!!' seems more "important" somehow, I don't want to glorify private types :-) > Let's not worry about anything *but* DNS based names. Does that mean we should take out the wording about reserving type names starting with a IANA type names? Being able to write: arrow: !image/gif [=base64=] Is rather neat, I'd like to keep that. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-10-26 14:36:55
|
On Fri, Oct 26, 2001 at 04:17:17PM +0200, Oren Ben-Kiki wrote: | > Also, we could just use the implicit model, and | > if it doesn't work add the explicit one (which | > would override the implicit mechanism) later, | > if we found it was absolutely needed. In this | > way we don't overly complicate the system up-front. | | Sounds reasonable. So what's the current state, I'm losing track here: | | absolute: !dns.based.absolute | relative: !.type # == dns.absolute.type | private: !has-no-dot | yaml: !!map | | Or is it: | | private: !!has-explamantion | yaml: !has-no-dot | | I prefer the former, I think. '!!' seems more "important" | somehow, I don't want to glorify private types :-) It's not glorification as much as it is control of the class mechanism. For example, below you want to expand the reserved types to IANA. We can't do that if "private: !has-no-dot", however, we can do this later on if "private: !!whatever". So, I strongly back Brian's suggestion. It scales better. | > Let's not worry about anything *but* DNS based names. | | Does that mean we should take out the wording about reserving type names | starting with a IANA type names? Being able to write: | | arrow: !image/gif [=base64=] This brings up the "multi-typing" problem again. arrow:: !image/gif !base64 =base64= Clark P.S. BTW... to enter a real tab (not just spaces) in Emacs under Mutt I have to type in "CTRL+Q TAB" Quite irritating, but I'm going to survive. |
From: Brian I. <in...@tt...> - 2001-10-26 17:34:14
|
On 26/10/01 10:47 -0400, Clark C . Evans wrote: > P.S. BTW... to enter a real tab (not just spaces) > in Emacs under Mutt I have to type in > "CTRL+Q TAB" Quite irritating, but I'm > going to survive. Try meta+i (meta is 'alt' or 'escape') BTW, I also use mutt, but with vi. (But I program with emacs :) |
From: Clark C . E. <cc...@cl...> - 2001-10-26 13:34:06
|
| > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. | | It seems we agree to skip the "<type>!" shorthand. As for specifying the | exact semantics of "relative types", are you *certain* we want to get into | it right now? I wouldn't mind one but just to keep the current wording: | reverse DNS and IANA based names are reserved for their owners, single-word | names are private, anything else unspecified (yet). At most add wording | saying that names starting with '.' or '/' are reserved. I think that brian wanted to keep a short-hand so that !map meant !org.yaml.map ; he agreed that !!Data:Dumper could be a private area... | > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong | > opinion). | | It seems we all agree '@' would have been best, except for the fact it makes | it impossible to use @ for indicating lists (if we need it). Again, I think | using '[' as an indicator is a bad idea (that's too useful a character to | waste on being an indicator). We also can't use an unannotated number - | that's rather confusing. Right. This one is still open. But note: It's a new feature. | > 10. There's no need for a magical empty map/list descriptor beyond the | > explicit map/list type name. | | This is still open. My proposal: | | There seems to be a need in Perl to be able to "bless" an empty list or an | empty list. Hmmm. Would the following do: | | blessed-empty-list: !perl-class-name - | blessed-empty-map: !perl-class-name I don't think this will work, beacuse it will make - an indicator in this context. not-allowed: !money -23.38 | Reasoning: a map-based perl class is defined as an explicit YAML type. This | type can accept as a valid value a map with a certain set of keys, OR a text | string (the empty one). | | A list-based perl class is also defined as an explicit YAML type; this type | can accept as a valid value a list with certain set of entries, OR a text | string (containing a single '-'). | | If you don't like '' and '-', you can replace them with any other | non-indicator string; for all I care, it can be the strings "empty-map" and | "empty-list". | | The point is that there's no need to have these strings be indicators. It is | just an explicitly typed scalar, which is deserialized into the appropriate | native data structure - a blessed map or list as the case may be. Your point is... that the class will know what it's storage requirement is. This works as long as the class is supported by the given operational environment, right? | > 13. We can have multiple line breaks indicate a top-level list. | | It seems we now agree on using '----' as seperator instead - however, unlike | the previous time we had them, multiple instances do not indicate "empty | chunks", they are simply ignored. Right? I can live with that. I think that's right. If one wants a blank node, we can always use.. ---- ~ ---- | I disagree that a top-level string is interpreted as a scalar, | I think it should be a key: | | ---- | "this is a | quoted key" :: | "not a value" | ---- | : | "This is a quoted value" | ---- | : "So is this one" | ---- | | | This is a block value | ---- | This is an unquoted value | ---- | : | So is this one | ---- | - This is a list entry | ---- | this is : a key | ---- | | OK? | | Note that this clear distinction is only possible because the | next-line-scalar indicator isn't identical to the list-entry indicator. So | if the list-entry-indicator goes back to ':', we'll have to return the | next-scalar indicator to '\'. This is OK. I'm not too concerned with the details here. ... But I did have an idea... and it seems a bit simpler since we can use the "map" grammer... ---: "this is a quoted value" ---: This is an unquoted value --- this: is a map --- - this is a list ---| This is a block value It starts indented one tab. ---|- This is a block value with a chomp | > 19. Let's consider changing the term 'list' to 'array' in all YAML | > documentation. | | Open issue. Is that's due to the array/tuple distinction? Hmm. Let's compromise and call it a "sequence" this would be a good mathematical term that usually isn't bothered with specific implementation assumptions. Array usually assumes quick access, quick appending, and slow insertion. List (as in linked) usually implies slower random access, but fast insertion at any point. YAML does not imply either of these... thus sequence may be nicer. | > 20) Reserve '=' for implicit tuple serialization. Reserve !tuple as | > well. | | I'm against it. I agree with Clark that 'tuple' is just an explicit type, | and does not require a new list entry indicator. <chomp/> | | tuple: !org.yaml.tuple | - First slot | - Second slot | | Like "ref" for Perl, "tuple" is a prime candidate for a shorthand name | (whatever mechanism we come up with eventually). Yep. | OK, that leaves one big issue - the relative type names. I'm starting to | regret I ever mentioned it :-) At any rate, let's see what we want to gain | from this: | | - The ability to write reasonably short names. | - Especially for org.yaml.* types (rank has its privilege etc.) | - Allow private types. | - Don't mess the information model. | - Make it readable (as little magic as possible). | | The only know way to do this is to somehow establish the concept of a "type | conetxt", which is associated with the natural scoping rules of the | document. In XML this is done via xmlns="...". That would map in YAML to | something like: | | key: !any-type ^type-context | sub-key: !<indicator, say '.'>type-in-sub-context (note: I like ^ for the sub-context indicator) | Think of '^type-context' as a directive to the parser on how to convert | "relative types" into "absolute types". Essentially it specifies a prefix to | be added to the type name before the application even sees it. The emitter | is free to generate type-context directives to make the output look | "better"; this is at the same level as deciding to emit a certain scalar as | a block to make it look better. There's no "type context" in the information | model. | | Another way to do this is to overload the type declaration. This is built on | the observation that in many cases, the type context is shared between the | 'key' and the 'sub-key' above. In YAML this may look like: | | key: !some.absolute.type # establishes some.absolute.* context | sub-key: !.other-type # uses that context. | | Again, this is done at the parser/emitter level, NOT in the information | model. Right. | Now, note that either way this means that you can't cut-and-paste safely | without ensuring you get the appropriate "type name context" as well. | In-memory this isn't much of a problem because we tend to rely on the | language's built-in type system, but it is an issue when doing text-based | operations or when handling unknown types. That's a big minus - many a | battle was fought in SML-DEV over this point. Right. But such conversations came down to two: (a) automated systems won't have a problem (b) human systems can grok the complexity (c) if a human isn't sure, they can be explicit | *Assuming* this is acceptable: | | 1. Shoule we use an explict context-setting directive or to overload the | type declaration we already have. There are pros and cons here both ways. | For example, using an explicit "type context here" makes it easier to detect | it when doing cut & paste, and it allows attaching a type context to | differently-typed node. For example: | | list-of-invoices: !com.company1.type ^com.company2. | - !.invoice | ... | | This was raised as an issue in SML-DEV. There's little actual experience | with this sort of applications, however, so it is unknown whether this is a | concern or not. | | The down side is that any explicit context-setting mechanism requires | lookahead in the emitter (to intelligenty choose the context). Also, it is | additional explicit magic (as opposed to additional implicit magic :-) I think an implicit mechanism is probably the best in this case. From Don Park's experience, he often quotes that most data comes in islands. Also, we could just use the implicit model, and if it doesn't work add the explicit one (which would override the implicit mechanism) later, if we found it was absolutely needed. In this way we don't overly complicate the system up-front. | 2. Assuming we overload the type declaration, how do we know what part of it | is the "context"? The easiest way would be to just strip the last word: | | context: !some.absolute.type # context is 'some.absolute.' | sub: !.another # type is 'some.absolute.another | another: !..type # type is 'some.type' because '..' is "up"? | | But one may also explicitly annotate it: | | context: !some!.absolute.type # context is 'some.*' | another: !.type # type is 'some.type' | | This allows to establish a context for an untyped node: | | context: !some.absolute.! # This node is untyped! | sub !.type # The type is 'some.absolute.type' I don't like either of these mechanisms to get at the "grantparent" context. The ! in the middle, or the ".." gives me a headache. I would vote for the initial system only handling the "leaf". In otherwords, the simplest form. This should catch 90% of the needs. The other 10% (or much less) can just be verbose. That said, if we found the 10% to be distrubing, we could add the explicit suggestion in point #1 above without disturbing our first pass (the simplest version) | 3. As for a special shorthand for 'org.yaml.*', we can use, say '!' for | that: | | sub: !!.tuple # org.yaml.tuple | | 4. Private types: Simply don't start with '.'. I'd rather stick with Brian's suggestion. !!Private type !yaml-type | 5. When using IANA based types the reasonable syntax would have been '/' for | indicating a relative type, not '.'. Perhaps the best way would be to be | agnostic to this (assuming explicit declaration of the context): | | context: !context-prefix!this-node-type(optional) | relative: !!gets-the-context-prefix | absolute: !does-not-get-the-prefix | yaml: !^yaml-type IMHO, too complicated. Let's not worry about anything *but* DNS based names. Best, Clark |
From: Brian I. <in...@tt...> - 2001-10-26 15:46:10
|
On 26/10/01 10:13 +0200, Oren Ben-Kiki wrote: > (Someone should solve the timezone difference problem some day :-) No Kidding > > 2. We can use ':' instead of '\' as the next-line scalar indicator. > > It seems you guys want this. OK. So we all agree here. There was a sub-issue > raised about where the descriptors go - before or after this ':'. I think we > all agree that before: Actually, I now want them after. Clark concurs. > > key: !descriptor : > next line value key:: !descriptor next line value > > Likewise for any other indicator: > > key: !descriptor | > block value key:| !descriptor block value > > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. > > It seems we agree to skip the "<type>!" shorthand. As for specifying the > exact semantics of "relative types", are you *certain* we want to get into > it right now? I wouldn't mind one but just to keep the current wording: > reverse DNS and IANA based names are reserved for their owners, single-word > names are private, anything else unspecified (yet). At most add wording > saying that names starting with '.' or '/' are reserved. > > If you do want to get into is, see below for some ideas :-) I'd like !foo to mean !org.yaml.foo > > 10. There's no need for a magical empty map/list descriptor beyond the > > explicit map/list type name. > > This is still open. My proposal: > > There seems to be a need in Perl to be able to "bless" an empty list or an > empty list. Hmmm. Would the following do: > > blessed-empty-list: !perl-class-name - > blessed-empty-map: !perl-class-name Cool idea. But I'd like to keep working on it. > > 13. We can have multiple line breaks indicate a top-level list. > > It seems we now agree on using '----' as seperator instead - however, unlike > the previous time we had them, multiple instances do not indicate "empty > chunks", they are simply ignored. Right? I can live with that. It's '---' not '----'. > I disagree that a top-level string is interpreted as a scalar, I think it > should be a key: OK > ---- > "this is a > quoted key" :: > "not a value" > ---- > : > "This is a quoted value" > ---- > : "So is this one" > ---- > | > This is a block value > ---- > This is an unquoted value Please no. It cut's us off too much. Comments etc will be harder. And it adds too many rules as to what needs quoting. An actual '---' scalar for example. > ---- > : > So is this one > ---- > - This is a list entry > ---- > this is : a key > ---- > > OK? As noted. > Note that this clear distinction is only possible because the > next-line-scalar indicator isn't identical to the list-entry indicator. So > if the list-entry-indicator goes back to ':', we'll have to return the > next-scalar indicator to '\'. Not true. :: A list item : Another list item > > > 14. Let's reconsider using tabs for indentation. > > We all agree here to use them. Then start using them :) > > 19. Let's consider changing the term 'list' to 'array' in all YAML > > documentation. > > Open issue. Is that's due to the array/tuple distinction: I like array. It's really what we are serializing in almost every language I can think of. I don't like sequence. No need to get so generic. > > 21) I think the type indicator should immediately follow the colon or > > dash, even when the value is classed or anchored. > > I though the syntax was: > > ('-' | <key> <lwsp>* ':' ) # List entry or key > ( <lwsp>+ <descriptor> )* # Descriptors > <lwsp>+ > ( <indicator>? <eol> # One of (none)<eol>, :<eol>, |<eol>, or |-<eol> > | <in-line-value> ) # One of "double", 'single' or un-quoted > > Any problem with this? This grammar was conceived by me when ':' was the separator instead of ' '. Now I think the type indicator should come immediately. It looks more consistent to me. > > 22) Classes Simple: Explicit: !org.camel.foo Reserved: !foo # means !org.yaml.foo Private: !!my.class # means I don't have to explain Drop Relative classes. We can always do them later based on user input. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-10-26 16:22:36
|
On Fri, Oct 26, 2001 at 08:45:58AM -0700, Brian Ingerson wrote: | > There was a sub-issue raised about where the descriptors | > go - before or after this ':'. I think we all agree that before: | | Actually, I now want them after. Clark concurs. Yep. | I'd like !foo to mean !org.yaml.foo +1 | It's '---' not '----'. Ok. | > > 14. Let's reconsider using tabs for indentation. | > | > We all agree here to use them. | | Then start using them :) I am... and they stay unless you and Oren decide otherwise. | > > 22) Classes | | Simple: | | Explicit: !org.camel.foo | Reserved: !foo # means !org.yaml.foo | Private: !!my.class # means I don't have to explain | | Drop Relative classes. We can always do them later | based on user input. Great. Clark |