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 |