From: Clark C . Evans <cce@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.
P.S. Almost done.
From: Clark C . Evans <cce@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?
Then the info model should stick with
the equality operator.
Then we _really_ must dig deeply into
canonical forms and work out the
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
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
I'm going to forget canonical, but put it
on our to-do list; and then sick with
the equality operator.
Get latest updates about Open Source Projects, Conferences and News.