From: Clark C . E. <cc...@cl...> - 2001-12-07 17:58:58
|
I think this can't be done unless each transfer method also provides a way to get at a canonical string representation for scalar values.... so perhaps I'm wrong about an equality operator. |
From: Clark C . E. <cc...@cl...> - 2001-12-08 03:34:00
|
There are two options for the generic model: 1. Each scalar provides a canonical representation for the given value 2. Each scalar provides: a. Any old representation b. An equality operator c. A hash code And then I'm still not sure that (2) works. So. I'm very sorry for pushing for an equality operator in the generic model. I'm fixing this. Best, Clark P.S. Almost done. |
From: Clark C . E. <cc...@cl...> - 2001-12-08 05:25:36
|
On Fri, Dec 07, 2001 at 10:46:49PM -0500, Clark C . Evans wrote: | There are two options for the generic model: | | 1. Each scalar provides a canonical | representation for the given value | | 2. Each scalar provides: | | a. Any old representation | b. An equality operator | c. A hash code | | And then I'm still not sure that (2) works. Ok. After writing this out and seeing that the canonical requirement is as complicated as I thought, I'm going back... Ok. I may be trying to do too many things at once here and not properly delegating. I *do* need to support some sort of node-equality or the mapping construct becomes meaningless. This can be supported by dictating that the transfer method either have an equality operator or provide canonical forms. The latter is far more powerful (and thus restrictive). That said, I was leaning towards requiring any old representation (to serialize) and an equality operator. The problem I ran into was the YAML signatures, and I implicitly assumed that you should be able to carry out a YAML signature based on the information in the YAML generic model. I'm not certain that this is a requirement. A similar requirement occurs for YPATH... YPATH can be implmented on top of the generic model; as long as you strip out all kinds of useful type specific operators. If you note that XPATH model defined numbers, strings, etc. and then defines operators on those types. So. This makes me think that YPATH will be a model layered over the generic model which provides the various operators on the different data types. Thus, if YPATH needs a bigger model than the generic model; should digital signatures? After all, XML signatures are implemented over the XML canonical form. I'm slightly worried about this if you can't tell... XML got into it's problem when two "layered" models had a conflict at a very low level (namespaces+xpath). Thus the XML canonical form is kinda messy. I know that I'm not wize enough to garuentee that we can make the right choice... *sigh* So. I ask.... can we layer canonical form? If YES, Then the info model should stick with the equality operator. If NO, Then we _really_ must dig deeply into canonical forms and work out the ramifications. I'm suggesting that we pretend that we can layer... and continue. But this issue must be addressed before this spec can go to 1.0 ... or we risk having all kinds of processor incompatibility problems. Of course... by having a nice standard C implemention "libyaml" we can probably mitigate most compatibility issues. ALSO, note that this doesn't impact at all the "simple" use of YAML dumping/loading from native data types. It's primary impact is with generic processing.... SUMMARY: I'm going to forget canonical, but put it on our to-do list; and then sick with the equality operator. Best, Clark |