From: Clark C. E. <cc...@cl...> - 2004-09-10 23:36:25
|
On Fri, Sep 10, 2004 at 07:03:43PM -0400, trans. (T. Onoma) wrote: | So the question is simply this: what information appropriately belongs to | the representation? My assertion is the scalar style (the forms of quoting, | folding, literalizing) is rightfully a part of the representation. And that | the source of the trouble with the plain-scalar exception, among others, is | the fact that this has been artificially extracted from the notion. | | - no special distinction between scalars (to each its own style; | it is what it is.) | - no special tags (e.g. ?whatever) There are two separate issues involved here: - Should my application be able to request that a particular node is styled in a particular manner? Yes. You should be able to do this via some sort of style sheet which associates YPath expressions, REGEX with a requested style. This is all part of the Presentation Syntax Model and we encourage you to do it. - Should my application differentiate between different nodes based on the style it was provided? No. Styles are presentation level detail, and subject to change depending upon how the human who made the file feels that particular day. You've put forth this position that "style" should be available for the program to direct it's processing, but you've yet to provide a good use-case for this. I admit, there are tempting reasons, which is why we have the plain scalar hack. However, those tempting reasons are very limited in nature and do not extend far. In _most_ cases, your application will have a set of expections for particular scalar values depending upon where it is located in the document, let me call this the "schema". If you are expecting an integer or a boolean, and you get a string -- the answer is simple, convert it to a integer, boolean, or what not. In fact, in this common case, even if you did have integers, dates, or what-not, they are going to be restricted to a particular range or by some other criteria. So any resonable application will require some sort of 'validation' layer. Just put your conversions there, and be done with it. So, this common case, which uses context, just isn't an issue. The remaining cases for distinguishing between a plain and a quoted styled scalar (for example) would be in applications where either a string or an integer are required, but both are allowed in a given file. In the great majority of these cases, the use of the item (semantics) will also tell you which data type you need, so, do a cast late in the game -- no biggee. In the other cases, it isn't that much of a burden to simply apply a regular expression to your input and guess; or, just require the user to be explicit and mark their values with a !!str or such thing. I can only think of one use case for the remaining item, and that is serialization. There are two versions of this remaining case, 'debug printing' and 'serialize-for-reload'. In the debug printing case, you don't need to reload the data, so it is perfectly OK to discard type information on the way out, perhaps an emitter can provide this feature. For the serialize-for-reload, integers arn't the only thing you will have to type. In fact, just about everything in the file will have a !tag and having !!int isn't so bad -- in fact, it is comforting, since you _know_ that some other process 2-3 years down the road won't accidently mistake your integer for a string. So. My summary is. There are two cases for distinguishing between integers and strings (the common "quoted" vs unquoted rationale). - if you application knows about what its expecting, then you don't need style to determine type, your schema will tell you - otherwise, if your application hasn't the foggiest idea of what to expect, everything should be explicit. Like I said in another thread. I've been using YAML for 2 years now, and I've never, ever, needed implict typing (although I do use explicit typing). The times when I've used it, it has bitten me in the arse. Therefore, I weigh an not only against what you propose, but also, against plain scalar vs quoted scalar distinction. Cheers! Clark P.S. So much for disappearing for the night... ;( |