Re: [Yaml-core] Brian's YACs

[Brian I. <in...@tt...>]

 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