From: Oren Ben-K. <or...@ri...> - 2001-12-28 15:47:12
|
Clark C . Evans wrote: > indentation: \ > I'd use flexible indentation for everything > but a block scalar. In this case, I'd assume > one space indentation and use |4 and ||4 Why restrict the other next-line scalars not to have leading spaces? If we allow |4 and ||4 we might as well allow \4 and \\4. It would make block less of a special case. > tabs: > - \ > Unix style tabs only (moves to nearest > column divisible by eight). +1 > - \ > A yaml parser must issue a warning if spaces/tabs > are mixed in a single 'indent'. In other words, > at the start of the line, " \t" would issue a > warning since the four spaces could be omitted. "Must" or "should"? At any rate, I agree this is a suspicious use of tabs. +.5 :-) > - \ > The yaml parser should also warn if tabs and spaces > are used inconsistently (aka Python style). This > will help save people who edit a document having > tabs where they have tab expansion set at 4. *shudder* :-) +1 > domain: \ > I like the domain idea, however, I think that it should > be an absolute URL ("http","ftp") pointing to a YAML schema. So call it 'SCHEMA' then. And I certainly do *not* want to put that into the YAML:1.0 spec! > Yes, we don't have YAML schema yet, but this won't take us > too long as we can alter RELAX NG for our purposes. For > YAML schema "boostrap" we can say that a blank YAML document > (comments excepted) allows any content. Thus, the domain can > point to a human readable (via comments) description of the > YAML format for now. Later on, when YSCHEMA is introduced > people can use this right away. So SCHEMA would point to a machine readable format and DESCRIPTION to a human readable one? At any rate... Leave this out of the 1.0 spec please. It is a can of worms we'll have to deal with - *eventually*. *We still don't have a final spec*. Let's concentrate on finishing it... > comments: \ > I'm in favor of any comment proposal that keeps the > current information model; that is, the parser reports > comments as a single text block attached to each pair. > That said, this forbids things that would attach a comment > to a map key or a map value directly... or would not > allow adjacent comments to be concatinated for reporting > with a new line separator. I see no problem with that... I think Brian's point was about being very lenient about how comments are indented, not about adding them in new places. I've no problem with letting them have arbitrary indentation... > blank-lines: \ > I'm perfectly OK with making trailing new lines in > a folded or escaped scalar not-significant, there by > allowing greater freedom here. As for the block > scalar, I think those trailing spaces should > remain significant. This would make block a special case. BTW, note that a single '#' at the start of a line is enough to cause the termination of any multi-line leaf (once we allow comments to have arbitrary indentation: a: b: c: \ this is a multi-line text value. # d: \ this is another one. For simple values we don't even need that: a: b: c: simple value d: another one Is this good enough? If it is I'd rather keep things as they are. If not, I'm willing to be convinced that trailing blank lines be trimmed from folded/escaped leafs... I guess... > I'd rather not introduce any > magical directives to enable this. Amen. > transfer-of-string-to-sequence: \ > Dead on arrival. Seriously, an application can do > this on it's own. We are not preventing them from > doing a simple "split" on the string. I don't follow. Do you suggest that the application have its own data type '!split' so that: this: a b c Would become a series of 3 elements? We've explicitly forbidden that so that YPATH would work. As far as YAML is concerned the above would be a leaf/scalar and if at a future date the document were to be modified to be: this: - a - b - c Then YAML would treat it as a whole different beast. I don't think that's what Brian had in mind. If I got his reasoning right, he'd want: this: [| a b c |] To be exactly the same data as the above explicit series form. > The added > complexity and inconsistency isn't worth the small > advantage. That may be. The example above doesn't lose much readability by being written as: this: [ a, b, c ] I don't know whether Brian can show us with a use case where the new [| ... |] form (or any other explicitly annotated form he can come up with) is useful enough to be justified. Until he does I tend to agree with you that is isn't. > path-type: \ I have no problem with a path or a IP address type; > although we should probably get our type-repository > going. That we should. > As for any hint that "date" comes out of the > spec... well, if it does, then so does "int", "binary", > "float", etc. Dates/Times are even more 'core' data > types than float or binary! I disagree. I see a difference between data types supported by the language itself (such as int) and a data type which is only supported by convention or a library (such as a date). str/int/float/bin are supported at the language level. The other types are not. > So... I'm all for > bootstrapping the type repository with "int", "binary", > "float", "date", "time", etc. I'll go with that if that's what it takes to keep 'path' out of the core spec :-) But I'd still rather keep str/int/float/bin in the spec. > canonical: \ > The definition of canonical should allow for > streaming content and should be easily usable > via "e-mail"... thus the canonical scalar should > be escaped, and all in-line short-hands made > explicit. I'm even thinking that key: value > pairs should always be in ?key\n:value style. That's very different from what I had in mind ("shortest possible form"). Luckily we don't have to decide on this right now, as it doesn't impact the spec. So, we need to discuss the following: - Indentation. It seems we all like flexible indentation and |4 ||4. However, do we do \4 and \\4 as well? (I'd rather we did). - Do we add DOMAIN/BASE_URI/SCHEMA *in YAML:1.0*? (I'd rather we don't). - Comments/blank lines: do we ignore trailing blank lines in \ and \\ values? - Types: We seem to agree that 'path' or 'ip' belong in a type repository. We need to agree what other types go there as well. (I'd rather keep str/int/float/bin in the spec itself). Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-12-29 21:12:06
|
Clark C . Evans wrote: > | Why restrict the other next-line scalars not to have leading spaces? > > In the folded scalars, I can't think of a use case for leading > spaces. If there is one, then escaped scalar could be used > (\x20). Given that the folded scalar will be a large percentage > of the next-line scalars... I don't see a reason why the number > of indented spaces needs to be specified. Hmmm. Basically you are saying that all next-line leaf styles other than block are trimmed in a particular way - no leading spaces or trailing blank lines. They may have leading blank lines or trailing white spaces, however... Which seems rather arbitrary to me. At least in the case of the leading spaces it seems to me that given we allow |4, allowing \4 costs us nothing and is more consistent. From your latest it seems you concur... So, can we agree on allowing the indent level number being allowed in all the next-line leaf types? As for the trailing blank lines, I asked whether the following is acceptable: > | a: > | b: > | c: \ > | this is a multi-line > | text value. > | # > | d: \ > | this is another one. It seems both Clark and myself aren't certian about this. If it is acceptable, the only change we need to make is comment indentation (which we want to do anyway). All next-line leaf styles remain consistent. I rather like this for another reason. While I don't get around to actual coding I am running the implementation architecture through my mind, and trimming trailing blank lines would be a pain. That's because they require potentially unbound lookahead. If I am processing the following: this: a: \ b <1,000,000 blank lines> c Only when I see 'c' do I know whether I need to report these 1,000,000 blank lines as "text content" or to throw them away as comments. For a streaming API, this isn't a nice dillema to face. AFAIK we don't have any other gotchas like this - we used to and got rid of them. I really rather not re-introduce one. So if the above solution (using '#') is *at all* reasonable, I *much* rather stick to it. If allowing insignificant blank lines is *that* important, I'd consider disallowing them altogether in next-line leaf values, rather than introduce unbound lookahead into a YAML system. This issue is tied to comment indentation, and thinking of implementation (and productions) made me notice some point about that as well. It is trivial to allow a comment to be less indented than what is in the spec today, without causing any ambiguities. But allowing it to be *more* indented is a problem (due to potential ambiguities). So my initial idea was to keep the spec as it is, with a minor change saying a throwaway_comment(n) is indented using indent(m<=n) instead of indent(n). There's an important case where this limiting, however: map: key: \ value #key: value another: The current rules say that the comment must be indented at the same level as the 'another' key. Which means that it can't be where it is, even though it doesn't cause any ambiguity. So we have to delve a bit deeper. What I suggest we do is say that comments can be indented any way at all, *BUT*, comments aren't allowed inside next-line leaf values (this is what the wording says today anyway). That is, the BNF would be ambiguous, but the next-line leaf value productions would be marked as greedy to cancel the ambiguity. That would allow the above without wreaking hell on the BNF productions. > | > domain: \ > | > I like the domain idea, however, I think that it should > | > be an absolute URL ("http","ftp") pointing to a YAML schema. > | > | So call it 'SCHEMA' then. And I certainly do *not* want to put > | that into the YAML:1.0 spec! > > I was proposing that we do a minimal "boostrap" definition > of YAML SCHEMA: > > 1. An empty schema document means that any structure > is allowed. > 2. Comments are allowed and are not significant > with respect to rule #1 above. > ... > | So SCHEMA would point to a machine readable format and DESCRIPTION > | to a human readable one? At any rate... Leave this out of the 1.0 > | spec please. It > | is a can of worms we'll have to deal with - *eventually*. > > Hunh? It wouldn't contain a description to a human readable one... it > would contain a text file of comments. That's all. No can of worms > here. And when we do introduce some machine readable schema format(s), how would they relate to this? Would there be one directive for "file of text comments" and one for "machine readable schema"? Could I have both, then? Would there be just one URL directive and some way of telling whether the schema is "a text of comments" or "machine readable"? Would we end up adding a SCHEMA-TYPE directive instead? Would we rue the day we used 'SCHEMA' for something which isn't machine-readable? This *is* a can of worms. *I don't want to get into it*. It will hold us back from *getting a spec out the door*, something we were on the verge of doing... and we still *can* do if we don't get tempted by the dark side of the force :-) It is enough that white space, our old nemessis, has raised its ugly head again. Let's leave schemas for another day... > | I don't follow. Do you suggest that the application have > | its own data type '!split' > > No. I'm just suggesting for configuration files, > (that are only read-in), there is nothing saying > that a given field can't be a string and if the > application want's to split it into sub-strings > based on a separator this can be application > specific, and out-of-scope for YAML. We can't > specify everything... it's enough of an edge > case that I'd let it slip through the cracks. I agree. However, we don't want to encourage this practice because it reduces the usefulness of YAML processing tools when applied to these files. > | this: [| a b c |] > | this: [ a, b, c ] > > I like the second better... ;) So do I :-) I guess it would be a matter of educating people that [ a, b, c ] is "the right thing to do", even if it does cost a few extra characters. Like you said, we can't specify *everything*... But we can point out that YAML provides a reasonable way to handle reasonable use cases, in-line lists included; and the benefits of doing it "the right way". > | > As for any hint that "date" comes out of the > | > spec... well, if it does, then so does "int", "binary", > | > "float", etc. Dates/Times are even more 'core' data > | > types than float or binary! > | > | I disagree. I see a difference between data types supported by the > | language > | itself (such as int) and a data type which is only supported by > | convention > | or a library (such as a date). str/int/float/bin are supported at the > | language level. The other types are not. > > What language? Each language supports different stuff. Take the > DBASE III language for instance, it has five data types: Character, > Date, Numeric, Logical, and Memo -- no Integer, no Float. In REXX > you only have scalars and mappings (arrays are mappings using > integer keys). You give me a data type, and I'll find a language > where it either isn't supported, or is supported via a "libary". OK :-) > Let's have "seq", "map" and "str" in the core spec and > delegate all other types to the repository. Fine. Let's rename the section to "Core" instead of "Common", then. "These are the types that a YAML system *must* provide". I'd also keep the structured keys there, to explain the encoding idiom. I think that should be 'core', as it describes how any YAML system "should" handle unknown types. [Canonical format] > | > explicit. I'm even thinking that key: value > | > pairs should always be in ?key\n:value style. > | > | That's very different from what I had in mind ("shortest possible > | form"). > > Yep. I figured! Well, as I said, we don't need to agree on this - all we need to agree on is that it isn't in the spec :-) So, let's see, what is between us and a spec: - Decide about trimming blank lines, which seems the only open issue right now. Either abandon the notion or start a thread on how to do it without making YAML streaming a pain. - Add the |4 \4 indentation (with a tab moving to the next 8 position, with a warning if not starting at one). YAC and spec... - Relax restrictions on comments indentation as described above. YAC and spec again... - Move all types except !map !seq !str and !structured outside the spec. YAC, spec and create a common type library HTML file... - Find the time to do all the above. We sould probably split the work... who does what, when? All this is keeping me away from doing any implementation... Sigh. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-29 21:55:50
|
| So we have to delve a bit deeper. What I suggest we do is say that comments | can be indented any way at all, *BUT*, comments aren't allowed inside | next-line leaf values (this is what the wording says today anyway). That is, | the BNF would be ambiguous, but the next-line leaf value productions would | be marked as greedy to cancel the ambiguity. That would allow the above | without wreaking hell on the BNF productions. Ok. We should clearly note that comment indentation is not in the syntax model; and adjacent comments are merged with a line separator between them. | > I was proposing that we do a minimal "boostrap" definition | > of YAML SCHEMA: | > | > 1. An empty schema document means that any structure | > is allowed. | > 2. Comments are allowed and are not significant | > with respect to rule #1 above. | > ... | > | So SCHEMA would point to a machine readable format and DESCRIPTION | > | to a human readable one? At any rate... Leave this out of the 1.0 | > | spec please. It | > | is a can of worms we'll have to deal with - *eventually*. | > | > Hunh? It wouldn't contain a description to a human readable one... it | > would contain a text file of comments. That's all. No can of worms | > here. | | And when we do introduce some machine readable schema format(s), | how would they relate to this? Think of the above proposal as SCHEMA 0.1 (a file having only comments). When SCHEMA 1.0 comes out, it can be used immediately. | Would there be just one URL directive and some way of telling whether the | schema is "a text of comments" or "machine readable"? Would we end up adding | a SCHEMA-TYPE directive instead? Would we rue the day we used 'SCHEMA' for | something which isn't machine-readable? No additional directives. We only put one constraint on SCHEMA 1.0, that is, a blank schema allows any content. That's all. No worms. If a processor becomes schema aware, it just dereferences the schema and reads it. If it finds a SCHEMA 0.1 (just a file with comments) then the schema allows anything... no schema restrictions. | > | this: [| a b c |] | > | this: [ a, b, c ] | > | > I like the second better... ;) | | So do I :-) I guess it would be a matter of educating people that [ a, b, c | ] is "the right thing to do", even if it does cost a few extra characters. | Like you said, we can't specify *everything*... But we can point out that | YAML provides a reasonable way to handle reasonable use cases, in-line lists | included; and the benefits of doing it "the right way". Ok. So pending Brian's ok, this YAC would be rejected? | > Let's have "seq", "map" and "str" in the core spec and | > delegate all other types to the repository. | | Fine. Let's rename the section to "Core" instead of "Common", then. "These | are the types that a YAML system *must* provide". I'd also keep the | structured keys there, to explain the encoding idiom. I think that should be | 'core', as it describes how any YAML system "should" handle unknown types. Ok. | - Decide about trimming blank lines, which seems the only open issue right | now. Either abandon the notion or start a thread on how to do it without | making YAML streaming a pain. I'm for using a single comment marker, #, to introduce blank lines. Also, blank lines aren't a problem with in-line scalars. | - Add the |4 \4 indentation (with a tab moving to the next 8 position, with | a warning if not starting at one). YAC and spec... Right. | - Relax restrictions on comments indentation as described above. | YAC and spec again... Right. The wording should be set so that all comments are concatinated and then attached to the closest following pair. | - Move all types except !map !seq !str and !structured outside the spec. | YAC, spec and create a common type library HTML file... Right. Labor division indeed. ;) Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-30 09:17:30
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | So we have to delve a bit deeper. What I suggest we do is > | say that comments > | can be indented any way at all, *BUT*, comments aren't > | allowed inside > | next-line leaf values (this is what the wording says today > | anyway). That is, > | the BNF would be ambiguous, but the next-line leaf value > | productions would > | be marked as greedy to cancel the ambiguity. That would > | allow the above > | without wreaking hell on the BNF productions. > > Ok. We should clearly note that comment indentation is > not in the syntax model; and adjacent comments are merged > with a line separator between them. There's another wart I only notioced later. The following is illegal: --- map: key: value #key: value <EOF> We only allow comments *before* something... and this comment isn't "before" anything. We could relax the productions (and the syntax model) to say that comments are allowed at the end of a document, but that would cause an ambiguity: # before 1st doc --- map: key: value # before 2nd doc or after 1st one? # We could take indentation into account, # so this would be 'before 2nd' and the above # would be 'after 1st'... Yuck. --- map: key: value # after 2nd doc <EOF> Of course we could fix the productions so it would be OK to have a comment after the YAML *stream*... That would not raise ambiguities. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-12-30 09:26:19
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | > | this: [| a b c |] > | > | this: [ a, b, c ] > | > > | > I like the second better... ;) > | > | So do I :-) ... > > Ok. So pending Brian's ok, this YAC would be rejected? +1 > | - Decide about trimming blank lines, which seems the only > | open issue right > | now. Either abandon the notion or start a thread on how to > | do it without > | making YAML streaming a pain. > > I'm for using a single comment marker, #, to introduce blank lines. +1 > Also, blank lines aren't a problem with in-line scalars. ? Do you mean: map: key: value key1: value We could allow that, sure... > | - Add the |4 \4 indentation (with a tab moving to the next > | 8 position, with > | a warning if not starting at one). YAC and spec... > > Right. OK then. > | - Relax restrictions on comments indentation as described above. > | YAC and spec again... > > Right. The wording should be set so that all comments are > concatinated and then attached to the closest following pair. With the additional wart I pointed out - we'll need a comment at the end of the stream... > | - Move all types except !map !seq !str and !structured > | outside the spec. > | YAC, spec and create a common type library HTML file... > > Right. Done. > Labor division indeed. ;) Well, *someone* needs to do the work... :-) Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-28 16:36:09
|
| Why restrict the other next-line scalars not to have leading spaces? In the folded scalars, I can't think of a use case for leading spaces. If there is one, then escaped scalar could be used (\x20). Given that the folded scalar will be a large percentage of the next-line scalars... I don't see a reason why the number of indented spaces needs to be specified. | > domain: \ | > I like the domain idea, however, I think that it should | > be an absolute URL ("http","ftp") pointing to a YAML schema. | | So call it 'SCHEMA' then. And I certainly do *not* want to put | that into the YAML:1.0 spec! I was proposing that we do a minimal "boostrap" definition of YAML SCHEMA: 1. An empty schema document means that any structure is allowed. 2. Comments are allowed and are not significant with respect to rule #1 above. # # somedocument.yaml # --- SCHEMA:http:\\clarkevans.com\my-schema.yaml \ This is the content of the document. ... # my-schema.yaml # # This is the minimal schema document, it is totally # blank... it is only a text file with human-readable # comments. When the YSCHEMA comes along, it may be # modified to have YAML SCHEMA instructions. | So SCHEMA would point to a machine readable format and DESCRIPTION to a | human readable one? At any rate... Leave this out of the 1.0 spec please. It | is a can of worms we'll have to deal with - *eventually*. Hunh? It wouldn't contain a description to a human readable one... it would contain a text file of comments. That's all. No can of worms here. | > blank-lines: \ | > I'm perfectly OK with making trailing new lines in | > a folded or escaped scalar not-significant, there by | > allowing greater freedom here. As for the block | > scalar, I think those trailing spaces should | > remain significant. | | This would make block a special case. Once again, I don't see the problem of making a block different than folded. It has different rules. | a: | b: | c: \ | this is a multi-line | text value. | # | d: \ | this is another one. Right. Once can always use blank comments for blank lines. Is this acceptable? | > transfer-of-string-to-sequence: \ | > Dead on arrival. Seriously, an application can do | > this on it's own. We are not preventing them from | > doing a simple "split" on the string. | | I don't follow. Do you suggest that the application have | its own data type '!split' No. I'm just suggesting for configuration files, (that are only read-in), there is nothing saying that a given field can't be a string and if the application want's to split it into sub-strings based on a separator this can be application specific, and out-of-scope for YAML. We can't specify everything... it's enough of an edge case that I'd let it slip through the cracks. | this: [| a b c |] | this: [ a, b, c ] I like the second better... ;) | > As for any hint that "date" comes out of the | > spec... well, if it does, then so does "int", "binary", | > "float", etc. Dates/Times are even more 'core' data | > types than float or binary! | | I disagree. I see a difference between data types supported by the language | itself (such as int) and a data type which is only supported by convention | or a library (such as a date). str/int/float/bin are supported at the | language level. The other types are not. What language? Each language supports different stuff. Take the DBASE III language for instance, it has five data types: Character, Date, Numeric, Logical, and Memo -- no Integer, no Float. In REXX you only have scalars and mappings (arrays are mappings using integer keys). You give me a data type, and I'll find a language where it either isn't supported, or is supported via a "libary". | > So... I'm all for | > bootstrapping the type repository with "int", "binary", | > "float", "date", "time", etc. | | I'll go with that if that's what it takes to keep 'path' out of the core | spec :-) But I'd still rather keep str/int/float/bin in the spec. Let's have "seq", "map" and "str" in the core spec and delegate all other types to the repository. | > explicit. I'm even thinking that key: value | > pairs should always be in ?key\n:value style. | | That's very different from what I had in mind ("shortest possible | form"). Yep. I figured! Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2001-12-30 18:19:44
|
I'm in South Carolina with little access to bandwidth. I'll reply on Sunday. (Looks good though :) Cheers, Brian On 28/12/01 11:50 -0500, Clark C . Evans wrote: > | Why restrict the other next-line scalars not to have leading spaces? > > In the folded scalars, I can't think of a use case for leading > spaces. If there is one, then escaped scalar could be used > (\x20). Given that the folded scalar will be a large percentage > of the next-line scalars... I don't see a reason why the number > of indented spaces needs to be specified. > > | > domain: \ > | > I like the domain idea, however, I think that it should > | > be an absolute URL ("http","ftp") pointing to a YAML schema. > | > | So call it 'SCHEMA' then. And I certainly do *not* want to put > | that into the YAML:1.0 spec! > > I was proposing that we do a minimal "boostrap" definition > of YAML SCHEMA: > > 1. An empty schema document means that any structure > is allowed. > 2. Comments are allowed and are not significant > with respect to rule #1 above. > > # > # somedocument.yaml > # > --- SCHEMA:http:\\clarkevans.com\my-schema.yaml \ > This is the content of the document. > ... > > # my-schema.yaml > # > # This is the minimal schema document, it is totally > # blank... it is only a text file with human-readable > # comments. When the YSCHEMA comes along, it may be > # modified to have YAML SCHEMA instructions. > > | So SCHEMA would point to a machine readable format and DESCRIPTION to a > | human readable one? At any rate... Leave this out of the 1.0 spec please. It > | is a can of worms we'll have to deal with - *eventually*. > > Hunh? It wouldn't contain a description to a human readable one... it > would contain a text file of comments. That's all. No can of worms here. > > > | > blank-lines: \ > | > I'm perfectly OK with making trailing new lines in > | > a folded or escaped scalar not-significant, there by > | > allowing greater freedom here. As for the block > | > scalar, I think those trailing spaces should > | > remain significant. > | > | This would make block a special case. > > Once again, I don't see the problem of making a block > different than folded. It has different rules. > > | a: > | b: > | c: \ > | this is a multi-line > | text value. > | # > | d: \ > | this is another one. > > Right. Once can always use blank comments > for blank lines. Is this acceptable? > > | > transfer-of-string-to-sequence: \ > | > Dead on arrival. Seriously, an application can do > | > this on it's own. We are not preventing them from > | > doing a simple "split" on the string. > | > | I don't follow. Do you suggest that the application have > | its own data type '!split' > > No. I'm just suggesting for configuration files, > (that are only read-in), there is nothing saying > that a given field can't be a string and if the > application want's to split it into sub-strings > based on a separator this can be application > specific, and out-of-scope for YAML. We can't > specify everything... it's enough of an edge > case that I'd let it slip through the cracks. > > | this: [| a b c |] > | this: [ a, b, c ] > > I like the second better... ;) > > | > As for any hint that "date" comes out of the > | > spec... well, if it does, then so does "int", "binary", > | > "float", etc. Dates/Times are even more 'core' data > | > types than float or binary! > | > | I disagree. I see a difference between data types supported by the language > | itself (such as int) and a data type which is only supported by convention > | or a library (such as a date). str/int/float/bin are supported at the > | language level. The other types are not. > > What language? Each language supports different stuff. Take the > DBASE III language for instance, it has five data types: Character, > Date, Numeric, Logical, and Memo -- no Integer, no Float. In REXX > you only have scalars and mappings (arrays are mappings using > integer keys). You give me a data type, and I'll find a language > where it either isn't supported, or is supported via a "libary". > > | > So... I'm all for > | > bootstrapping the type repository with "int", "binary", > | > "float", "date", "time", etc. > | > | I'll go with that if that's what it takes to keep 'path' out of the core > | spec :-) But I'd still rather keep str/int/float/bin in the spec. > > Let's have "seq", "map" and "str" in the core spec and > delegate all other types to the repository. > > | > explicit. I'm even thinking that key: value > | > pairs should always be in ?key\n:value style. > | > | That's very different from what I had in mind ("shortest possible > | form"). > > Yep. I figured! > > Clark > > -- > Clark C. Evans Axista, Inc. > http://www.axista.com 800.926.5525 > XCOLLA Collaborative Project Management Software > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |