From: Clark C . E. <cc...@cl...> - 2002-08-11 22:16:12
|
Neil, thank you for your time focusing on this... I'm sorry it has you distracted from libyaml. ;( On Sun, Aug 11, 2002 at 01:19:12PM -0700, Neil Watkiss wrote: | Clark C . Evans [11/08/02 14:07 -0400]: | > (#Unballenced key :-() : Is an edge case, but it works just fine. | | Unbalanced key :-) : Works. (#): | Unbalanced key :-) : Works. "#Unbalanced" : Works. "" : Works. Foo (and bar) and baz : Works. | I'm seeing some problems with parens, unless we extend their semantics. The | problem is that keys can be *any* data. They can be binary, number or | arbitrary string. The point of the comment key... if we even want to keep it... was to provide a simple way for people to "annotate" a node with information that applications should in general, ignore. That's it. It was never intended to comment out "arbitrary" keys, this is why we have the throwaway syntax. I think our "special" keys are probably quite useful, I use the '=' key in my data as I have older processes now that are working on new data. It's very neat trick, but it requires a way for the applicaiton to express if a given node is expecte to be a scalar. Thus far we don't have a general mechanism to do this... but I think schema will provide this expression and at this point the "=" key will be very useful. So... I don't want to dump it. As for the comment key, I've yet to use it. And Oren's current use cases are quite far from anything I can possibly imagine someone really wanting to do. So, we can either dump them, or they can comply with a syntax mechanism that other implicits use... cuz they haven't proved enough value to merit their own indicator and semantics. After some thought, I'd like to migrate the "special" keys over to use the parenthesized forms. I say this beacuse I think that we may want to introduce a few more special keys in the future, and if we make it clear in the spec that more special keys (or other short-cuts) may be added via the (parenthesis) then they can code for this eventuality and not choke on new special keys or implicit types that we dream up later. So, I'd like to use (=) for the "equals" special key. This leaves (#) for the comment special key. We started to allow other "differentiators" to follow the //, //a //b so that a given node can have more than one comment. As far as I'm concerned this ability doesn't need to extend to anywhere near a full set of characters. Limiting furture implicits so that they do not contain new lines and do not contain a parenthesis is probably a good idea, and an escaping mechanism is not needed. This is for very limited useage... not a general mechanism. So. I see two options on the table: (a) we adopt (#...) for comment keys or (b) we drop comment keys. In either case, it looks like we need to explicitly specify that current and future parenthesized implicits will never contain a ) or a new line. Hopefully this will make it easy. | The point is, this is all pretty silly. We want these things: | | 1. People can easily comment out keys "non destructively". | | People tend not to push the boundaries that much. This will probably | mean people putting (#<whatever>) around single-word <whatever>s. Not | too hard. | | 2. YAML processes can insert comments at various stages to aid in | debugging. | | Processes stress the boundaries a lot. They may want to comment out | structured keys, for example. Or keys that don't have matched parens. (#err304): | !!type this: is the offending key-value pair | Proposal: | | Use transfers, or formats, or something. Hear me out. | | "To tag a key/value pair as non-destructively commented out, give the key a | !special|comment transfer". | | We can still introduce a (#shorthand) for simple keys. | | That's really it. This runs into its own complications if the key already had | a transfer. I don't know how to solve that. Yes. This is a very simple issue, and we are indeed making a mountain out of it. However, the core proposal is: We re-frame the special keys so that they use the (parenthesized) forms so that implementers can handle them in a generic way even when they don't recognize or support a given implicit. As such, we probably need to limit what is in the parenthesis in a resonable way so that it is easy for implementers to handle. Best, Clark |