From: Clark C . E. <cc...@cl...> - 2001-11-12 15:12:43
|
On Mon, Nov 12, 2001 at 04:30:14PM +0200, Oren Ben-Kiki wrote: | I agree with everything you say about using the same YPATH syntax and same | API for maps and sequences. I don't see that forces us to merge them at the | information model level. If you merge them at the API level, then I argue that you are using "Beta" information model since you are treating them both in a similar manner with a lower level abstraction, aka a Branch. | As for considering map and list to mere "styles" I'm against it. No. I consider them to be a combination of both: (a) a Syntax, and (b) a Class. The "native" representation of the "list" and "map" class should be up to the language at hand. In a PostgreSQL relational database, for instance, I would choose to treat maps and lists identically... as Relations. As for the syntax, I see these as our two core "styles". Each style implying a different class if it is not given otherwise. For example, take Brian's sparse list... --- !list 0: one 5: five | It basically says "everything is a map". It isn't. No it doesn't. It's a "branch" as distinct from a "scalar". That the "branch" needs to be "typed" (aka given a Class) for it to work well in Python, Perl, etc. is a separable issue. In PostgreSQL it will be implemented with a table given particular domain constraints. | Sequences have different semantics then maps. For example, | a sequence always has entry 4 if it has entry 5. A map doesn't. | A sequence can only have integer keys. Right. These are constraints of the "org.yaml.Map" and "org.yaml.List" classes, the *default* classes for each of the map and list syntax. | Styles are appropriate when thinking of *text* scalars - different | way to represent *the same thing*, which is a sequence of Unicode | characters. Style is a bad word to apply to differing concepts | like sequence and map (and definitely a table). Ok. Think "syntax with default class" instead of style. For example, how do these two differ? --- !list 0: one 1: two --- !list - one - two If we are to merge the APIs, as you said above, they must have an *identical* information model. Right? | Again, I fully agree with the API and YPATH syntax points you raise. Let's focus on YPATH. Either we must have a different YPATH to match maps and lists... or we must have the same information model for both. You can't have it both ways... it would be inconsistent. | I just don't see what they have to do with the information model. | The spec explicitly says you can have whatever API you want as long | as it preserve the information model, and a unified API with an | 'isSeq' method certainly does. It's got everything to do with the information model. | I think we are splitting hairs, and Brian is tearing his in despair by now | (or probably even just skipping these posts altogether :-). Let's let it go | and focus on the last remaining issue - scalar styles (I think that's the | last one, right?). Brian, do you want to make a distinction between the example map and list above? This is a important question. Are they *different* ... or are they the *same* If they are different, we must treat them differently in the API and the language embedding; or we violate the information model. If they are the same, then our informaiton model which makes this distinction must be fixed. It's not a trivial issue. The information model says what things are important. Best, Clark |