From: Clark C . E. <cc...@cl...> - 2001-11-09 21:52:23
|
Ok. We had an IRC chat today with Brian Oren and myself to address outstanding issues. We resolved: 1. Adoption of one space for indentation (for now) 2. No in-line blocks (this was a whim proposal) 3. Back-tick to start private implicit types, all other implicit types are registered and part of the formal YAML spec (appendix) 4. On separators... a) Top level separators will not have single-line content. b) The version format doesn't have an indicator, thus looks like... --- YAML:1.0 c) Two adjacent separators are an error. (See #11) In later versions, this may be extended into a more general mechanism to allow for "document level attributes" as described by point #11 in Brian's last post. 5. Implicit types a) We implicitly agreed that address line such-as: 328 Wittigin's way should be a !text item and should not be an implicit scalar. b) We resolved that implicit types may contain whitespace. However, we also agreed not to reserve any implicit types which do allow whitespace for now. In this way we can further limit implict types down the road to a single token. c) We implicitly agreed that Date, Time, and DateTime will make it in as an implicit type, following a single token format limited ISO 8601 as described in http://www.w3.org/TR/NOTE-datetime with slight modifications (no partial dates). d) See #3 6. Base64 a) We agreed that !base64 is an explicit type. And for now we've agreed to include a preceding [= and trailing ] on base64 values. b) We did not discuss, but implicitly agreed to "no next/multi-line implicits" (clark) I think with the new \- style, we may want to revisit this. c) We agreed to explore using !type!pipeline over the next few weeks. Specifically examining round-trip issues. If this is workable, we'd like to include pipeline in 1.0; if not we can drop it for 1.0 7. The reference implicit type a) We've implicitly agreed to stick with * 8. Flow scalar starting with a quote... a) We've agreed to introduce a new style, denoted by \- which explicitly denotes a flow (and not quoted) next-line scalar. Note: This would allow implict types to appear in the next line scalar... this impact was not discussed. But... I think it's good. 9. An empty stream is a valid series of zero documents. agreed. 10. Empty strings must be explicit in top level scalars (small error fix). Examples: --- \ "" --- \ ~ 11. Brian's #11 issue. We forbid adjacent separators to allow this in the future; but not now. 12. Brian's use of the ~ null value for a key in sparse lists was adopted. I think that's it. No new issues were raised. Clark |
From: Brian I. <in...@tt...> - 2001-11-09 22:32:54
|
On 09/11/01 17:04 -0500, Clark C . Evans wrote: > 4. On separators... > > a) Top level separators will not have > single-line content. > > b) The version format doesn't have an > indicator, thus looks like... > > --- YAML:1.0 > > c) Two adjacent separators are an error. (See #11) > > In later versions, this may be extended > into a more general mechanism to allow > for "document level attributes" as described > by point #11 in Brian's last post. Hmmm. How do we do 3 empty maps in a row? --- !map --- !map --- !map I think we can scratch 10 and 11 and still be able to do multi-line separators in the future. New rule: The last separator in a multi-line separator must contain an indicator or separator or be followed by actual data. --- VERSION:1.0 --- !map --- VERSION:1.0 another: map --- VERSION:1.0 !map --- \ --- - foo The above is 3 maps, a scalar and a seq. That should do it. Oren, what this means to you is simply that each separator must either: - end with an indicator - end with an explicit type - be followed by a map or seq line (after any throwaways) Then we'll be covered for the future. > 6. Base64 > > a) We agreed that !base64 is an explicit type. > And for now we've agreed to include a > preceding [= and trailing ] on base64 values. Oren, please explain where the '[=' syntax comes from. > a) We've agreed to introduce a new style, > denoted by \- which explicitly denotes > a flow (and not quoted) next-line scalar. It should be noted in the spec that this is only needed when the scalar begins with a single or double quote character. > 10. Empty strings must be explicit in top level > scalars (small error fix). Examples: > > --- \ > "" > --- \ > ~ I don't really need this any more. > 11. Brian's #11 issue. We forbid adjacent separators > to allow this in the future; but not now. Not needed, given ammendment to #4. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-11-09 22:49:41
|
On Fri, Nov 09, 2001 at 02:32:45PM -0800, Brian Ingerson wrote: | | Hmmm. How do we do 3 empty maps in a row? | | --- !map | --- !map | --- !map Yep. The wording isn't explicit, but what was intended was banning two adjacent --- items that didn't have an explicit type and/or indicator. | New rule: The last separator in a multi-line separator must contain | an indicator or separator or be followed by actual data. | | --- VERSION:1.0 | --- !map | --- VERSION:1.0 | another: map | --- VERSION:1.0 !map | --- \ | --- | - foo Following is how I interpreted the current agremeent. The first, third separators above above would be errors, since it had a separator lacking content, explicit type, or indicator. --- YAML:1.0 !map --- YAML:1.0 another: map --- YAML:1.0 !map --- YAML:1.0 \ --- - foo | Oren, what this means to you is simply that each separator must either: | - end with an indicator | - end with an explicit type | - be followed by a map or seq line (after any throwaways) Right. Exactly. So your example above would be an error now (reserved for possible later usage). | > 6. Base64 | > | > a) We agreed that !base64 is an explicit type. | > And for now we've agreed to include a | > preceding [= and trailing ] on base64 values. | | Oren, please explain where the '[=' syntax comes from. | | > a) We've agreed to introduce a new style, | > denoted by \- which explicitly denotes | > a flow (and not quoted) next-line scalar. | | It should be noted in the spec that this is only needed when | the scalar begins with a single or double quote character. We may want to consider letting implicit scalars work with the next line scalar... that would be consistent with allowing implicit scalars as keys (and probably make the productions easier). Best, Clark |