From: Brian I. <in...@tt...> - 2002-09-06 08:34:13
|
I've been going over the spec word for word. You'll see a lot of posts from me in the next few days. The first thing I want to address is a concern from Section 3 Information Models. The spec talks about a process called a Viewer that "presents this native structure in a YAML-compatible way". The inferred reasoning is that a Loader would turn an event stream into a Native binding, and then a viewer would turn that into a Graph model or Uniform view; whatever you want to call it. Something that YPATH etc, could operate on. I think that's a bit backwards. I think that a Loader could definitely create a Generic view directly from an event stream without ever going all the way to Native. I also think that logically you always go through the generic model *before* getting to the native model. In order to get to Native, you often need to interact with the application class code. You need to call a registered classes' from_yaml() method, or whatever to create a native node. In my mind, what you pass that method is a generic node, that the application *transfers* into a Native node. That's the way YAML.pm works. For anything node that has an explicit transfer, I create a generic node (using the YAML::Node module) and pass it to a yaml_load() method (my name for from_yaml). You end up with an API like this: native_node = ApplicationClass.yaml_load(generic_node) generic_node = ApplicationClass.yaml_dump(native_node) Now I don't create a generic node for plain strings, integers, hashes and arrays only as an optimization (perhaps premature ;). I certainly could. And I could also just load an entire graph of only generic (YAML::Node) nodes. This is what my YPATH implementation would work on. --- So I see the diagram as being more like: SYNTAX <--> SERIAL <--> GENERIC <--> NATIVE Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-09-06 18:31:24
|
On Fri, Sep 06, 2002 at 01:34:08AM -0700, Brian Ingerson wrote: | I want to address is a concern from Section 3 Information Models. The whole model section needs yet another wording pass to make it more articulate; hopefully it doesn't need to be changed. | The spec talks about a process called a Viewer that "presents this native | structure in a YAML-compatible way". The inferred reasoning is that a Loader | would turn an event stream into a Native binding, and then a viewer would | turn that into a Graph model or Uniform view; whatever you want to call it. | Something that YPATH etc, could operate on. Right. | I think that's a bit backwards. I think that a Loader could definitely create | a Generic view directly from an event stream without ever going all the way | to Native. The loader could create a Native view which was exactly equivalent to the Generic model so that the "view" is a no-op. This is explicitly supported by the model as written and covered in our earlier discussion. | I also think that logically you always go through the generic model *before* | getting to the native model. In order to get to Native, you often need to | interact with the application class code. You need to call a registered | classes' from_yaml() method, or whatever to create a native node. In my mind, | what you pass that method is a generic node, that the application *transfers* | into a Native node. Hmm. I think Oren and I were considering that the native representation would be built before resolving aliases, and thus would be created from the Serial model; hence the diagram. Of course there isn't much difference beween the Serial and the Generic node, other than the Serial node is a single-pass sequential interface. | That's the way YAML.pm works. For anything node that has an explicit | transfer, I create a generic node (using the YAML::Node module) and pass it | to a yaml_load() method (my name for from_yaml). You end up with an API like | this: | | native_node = ApplicationClass.yaml_load(generic_node) | generic_node = ApplicationClass.yaml_dump(native_node) | | Now I don't create a generic node for plain strings, integers, hashes and | arrays only as an optimization (perhaps premature ;). I certainly could. And | I could also just load an entire graph of only generic (YAML::Node) nodes. | This is what my YPATH implementation would work on. Nods. | So I see the diagram as being more like: | | SYNTAX <--> SERIAL <--> GENERIC <--> NATIVE Hmm. In the previous paragraph you seem to be saying... SYNTAX <--> SERIAL <--> NATIVE <-> GENERIC (optionally) No? The GENERIC part only comes into play when you want to use YPATH or other generic tools on an in-memory representation not having aliases. Best, Clark |
From: Brian I. <in...@tt...> - 2002-09-07 06:29:57
|
On 06/09/02 18:32 +0000, Clark C . Evans wrote: > On Fri, Sep 06, 2002 at 01:34:08AM -0700, Brian Ingerson wrote: > | I want to address is a concern from Section 3 Information Models. > > The whole model section needs yet another wording pass to make > it more articulate; hopefully it doesn't need to be changed. FWIW I read the entire model section again today. It made my head hurt. I can barely understand the point(s) of its intention. Actually I can't understand it at all. Previously I've thought "Oh this is just Clark's area to be pedantic", but if I can't make heads or tails of it, perhaps we're not really on the same page. So enough whining from me. I'd really like to work with you on making this more useful. Let me know how I can help. > > | The spec talks about a process called a Viewer that "presents this native > | structure in a YAML-compatible way". The inferred reasoning is that a Loader > | would turn an event stream into a Native binding, and then a viewer would > | turn that into a Graph model or Uniform view; whatever you want to call it. > | Something that YPATH etc, could operate on. > > Right. > > | I think that's a bit backwards. I think that a Loader could definitely create > | a Generic view directly from an event stream without ever going all the way > | to Native. > > The loader could create a Native view which was exactly equivalent > to the Generic model so that the "view" is a no-op. This is explicitly > supported by the model as written and covered in our earlier discussion. A native view can only be created when: A) There are no application specific transfers involved or B) The loader can call into Application registered transfers One simple way to think conceptually about how a Loader would create the Native view is this: 1) The loader turns the event stream into a generic set of nodes with real aliases. 2) The loader calls the application registered transfer for each node that has a special transfer method URI, and replaces the original node with the new "native" one. > > | I also think that logically you always go through the generic model *before* > | getting to the native model. In order to get to Native, you often need to > | interact with the application class code. You need to call a registered > | classes' from_yaml() method, or whatever to create a native node. In my mind, > | what you pass that method is a generic node, that the application *transfers* > | into a Native node. > > Hmm. I think Oren and I were considering that the native > representation would be built before resolving aliases, and > thus would be created from the Serial model; hence the diagram. > Of course there isn't much difference beween the Serial and > the Generic node, other than the Serial node is a single-pass > sequential interface. This makes very little sense to me. > > | That's the way YAML.pm works. For anything node that has an explicit > | transfer, I create a generic node (using the YAML::Node module) and pass it > | to a yaml_load() method (my name for from_yaml). You end up with an API like > | this: > | > | native_node = ApplicationClass.yaml_load(generic_node) > | generic_node = ApplicationClass.yaml_dump(native_node) > | > | Now I don't create a generic node for plain strings, integers, hashes and > | arrays only as an optimization (perhaps premature ;). I certainly could. And > | I could also just load an entire graph of only generic (YAML::Node) nodes. > | This is what my YPATH implementation would work on. > > Nods. > > | So I see the diagram as being more like: > | > | SYNTAX <--> SERIAL <--> GENERIC <--> NATIVE > > Hmm. In the previous paragraph you seem to be saying... > > SYNTAX <--> SERIAL <--> NATIVE <-> GENERIC (optionally) > > No? No! That's what *you* seem to be saying :) It's very interesting that the spec lists the models as: - Native - Generic - Serial - Syntax And implies that that's how they flow. Well I totally agree for N->Y. So don't you see the obvious symetry of going Y->N? It's: - Syntax - Serial - Generic - Native > The GENERIC part only comes into play when you want > to use YPATH or other generic tools on an in-memory > representation not having aliases. I can see that you see it that way. But it's perfectly reasonable to conceptually think of the generic model always be created in full before the native. Most loaders will not deal fully with the serial and generic levels, but that does not mean that they are not there conceptually. It's much easier IMO to view YNY as: Syntax->Serial->Generic->Native->Generic->Serial->Syntax regardless of what optimizations your implementation might make. Cheers, Brian |
From: Ned K. <ne...@bi...> - 2002-09-07 14:42:22
|
On Friday 06 September 2002 11:29 pm, Brian Ingerson wrote: > It's much easier > IMO to view YNY as: > > Syntax->Serial->Generic->Native->Generic->Serial->Syntax > > regardless of what optimizations your implementation might make. I'll pitch in here... I agree with Ingy. It makes sense to me to defer potentially "lossy" or=20 non-round-trippable conversions as long as possible. If there are notations in YAML that may not be expressed in a native=20 binding (and there may be, depending on the binding), then=20 transforms, YPATH, etc. should happen at the richest, most accurate=20 stage. With the above flow, this is at the "Generic" level. This also allows for multiple Generic->Native translations; a trivial=20 (perhaps default?) one would be to convert all scalars to strings. --=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
From: Clark C . E. <cc...@cl...> - 2002-09-07 15:00:45
|
On Sat, Sep 07, 2002 at 07:41:47AM -0700, Ned Konz wrote: | On Friday 06 September 2002 11:29 pm, Brian Ingerson wrote: | > It's much easier | > IMO to view YNY as: | > | > Syntax->Serial->Generic->Native->Generic->Serial->Syntax | > | > regardless of what optimizations your implementation might make. | | I'll pitch in here... | | I agree with Ingy. Well, the information model has been hacked several times, its probably again time for a nice refactor. I think we all agree it needs alot of improvement. Let's have at it! As for the Native model, it was put in to help clarify, I'm not certain that it helps; perhaps it should just come back out giving us our three model system again: Syntax Serial Generic In any case, I like Rolf's word "type identifier" or type-id rather than type-family. This more accurately reflects the intent of the construct. | If there are notations in YAML that may not be expressed in a native | binding (and there may be, depending on the binding), then | transforms, YPATH, etc. should happen at the richest, most accurate | stage. Right. I think that the info model should probably talk about a "native binding" but I'm not sure it is something we can provide a model for... no? Best, Clark |
From: Brian I. <in...@tt...> - 2002-09-07 15:44:45
|
On 07/09/02 15:02 +0000, Clark C . Evans wrote: > On Sat, Sep 07, 2002 at 07:41:47AM -0700, Ned Konz wrote: > | On Friday 06 September 2002 11:29 pm, Brian Ingerson wrote: > | > It's much easier > | > IMO to view YNY as: > | > > | > Syntax->Serial->Generic->Native->Generic->Serial->Syntax > | > > | > regardless of what optimizations your implementation might make. > | > | I'll pitch in here... > | > | I agree with Ingy. > > Well, the information model has been hacked several times, > its probably again time for a nice refactor. I think we all > agree it needs alot of improvement. Let's have at it! > > As for the Native model, it was put in to help clarify, > I'm not certain that it helps; perhaps it should just > come back out giving us our three model system again: +1 Maybe that was the main source of my headache. We really can't put any restraints on the Native representation. All we can say is that it should preserve all of the information of the Generic model for round tripping purposes. We *could* talk a lot about the "best" ways of doing this, but I don't think we have to. It will be obvious. If we just concentrate on solidifying the Generic model (which we must for YPATH) then we don't need to say much at all about the Native except that: - it exists - it is the most natural representation for the particular language - it should preserve as much information from the Generic model as possible - it can be skipped altogether for YPATH purposes > Syntax Serial Generic > > In any case, I like Rolf's word "type identifier" or type-id > rather than type-family. This more accurately reflects the > intent of the construct. If we are talking about the Type URI, I really like the notion of it being a "transfer method". It indicates which "application method" must be invoked to carry the node from Generic to Native. Of course the "application method" might reside either in the Loader or the user application, depending on the URI's domain. Wow. That's it. The URI is an abstract name for a method(). Hmm. At least that's one aspect of it. It's also a unique "type identifier" (where have I seen that before :) for YPATH. Cool. We're both right! > | If there are notations in YAML that may not be expressed in a native > | binding (and there may be, depending on the binding), then > | transforms, YPATH, etc. should happen at the richest, most accurate > | stage. > > Right. I think that the info model should probably talk > about a "native binding" but I'm not sure it is something > we can provide a model for... no? Correct. Here is a look at the lossy-ness of information as it travels through the models. With the typical parser/loader, somethings like comments actually are lossy, while other things like Anchor/Alias are partial lossy (lose the names but not the relationships), and still others are "tradey": trade the property for another property, which can be traded back on the way out. Type Identifier is "tradey". Some special parsers might preserve *all* information. A YAML editor would need such a parser. That's outside the scope of this email. Information Attributes: DC: Data Content NK: Node Kind TI: Type Identifier AA: Anchor/Alias names KO: Mapping Key Order NS: Node Style IN: Indentation TA: Throwaway Comments Information Models: Syntax: [DC, NK, TI, KO, AA, NS, IN, TA] Serial: [DC, NK, TI, KO, AA] Generic: [DC, NK, TI, KO] Native: [DC] I think we need to make at least NK and TI be tradey between Generic and Native. Put another way, the Native model must roundtrip these properties. KO need not be preserved in Native. Many of you might say that KO doesn't belong in Generic. I say why not! Generic YAML processors could be so much more powerful if we held onto this information up until the Native Model. I see no reason to throw it away unnecessarily. That means that if we skip the Native model, YAML processes could YNY roundtrip key-order! How cool is that? (rhetorical) Also some languages (like PHP I believe) actually preserve key order in their hashes natively. Good for them. Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2002-09-07 20:41:30
|
On Sat, Sep 07, 2002 at 08:44:37AM -0700, Brian Ingerson wrote: | Maybe that was the main source of my headache. We really can't put any | restraints on the Native representation. All we can say is that it should | preserve all of the information of the Generic model for round tripping | purposes. We *could* talk a lot about the "best" ways of doing this, but I | don't think we have to. It will be obvious. If we just concentrate on | solidifying the Generic model (which we must for YPATH) then we don't need to | say much at all about the Native except that: | | - it exists | - it is the most natural representation for the particular language | - it should preserve as much information from the Generic model as possible | - it can be skipped altogether for YPATH purposes Sure. | Information Attributes: | DC: Data Content | NK: Node Kind | TI: Type Identifier | AA: Anchor/Alias names | KO: Mapping Key Order | NS: Node Style | IN: Indentation | TA: Throwaway Comments | | Information Models: | Syntax: [DC, NK, TI, KO, AA, NS, IN, TA] | Serial: [DC, NK, TI, KO, AA] | Generic: [DC, NK, TI, KO] | Native: [DC] I differ in one primary way, KO should be a serial property and not a generic property (this is what the current spec says as well) Also, I think that Native should be removed from this list of models. As its caused more confusion than helped. It's not as much as a model as it is a particular system which happens to support (perhaps with some assistance) the generic model. | Many of you might say that KO doesn't belong in Generic. I say why not! | Generic YAML processors could be so much more powerful if we held onto this | information up until the Native Model. I see no reason to throw it away | unnecessarily. That means that if we skip the Native model, YAML processes | could YNY roundtrip key-order! How cool is that? (rhetorical) The generic model is a way of viewing a native binding. Certainly there may be a "YAML Native Binding" as a "C" library in libyaml, but this is a different issue. Since most native bindings don't support key order; it can't be in the generic model. Also, from a formal standpoint having the key order in the generic model causes all kinds of complexity that just isn't required. I'd rather have our collections be plain-ole-mathematical functions. Let's keep key order down in the serial/syntax model, please? There is nothing saying that we can't have yaml tools which operate at these levels as well; but I'd like to keep the generic model a bit more simple than this. | Also some languages (like PHP I believe) actually preserve key order in their | hashes natively. Good for them. Yes, I guess it does. Python and Perl don't. Clark |
From: <ir...@ms...> - 2002-09-07 21:00:45
|
On Sat, Sep 07, 2002 at 08:43:08PM +0000, Clark C. Evans wrote: > Since most native bindings don't support > key order; it can't be in the generic model. Also, from a formal > standpoint having the key order in the generic model causes all > kinds of complexity that just isn't required. I'd rather have our > collections be plain-ole-mathematical functions. Many applications will have a preferred key order they impose on the data, no matter which order it comes in from the .yml file. Others won't give a rip what order the elements are in. And for those apps that really, really want to know what order the keys were in in the .yml file, we can provide "something else" that tells that. Since a dictionary can be represented as a list of pairs, why not have an entry method that parses them that way? Parse everything else normally but convert dictionaries to lists of pairs. Then the user gets the key order and can make their own dictionary. That would also allow them to do advanced processing of duplicate keys. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Clark C. E. <cc...@cl...> - 2002-09-08 02:05:20
|
On Sat, Sep 07, 2002 at 02:00:40PM -0700, Mike Orr wrote: | On Sat, Sep 07, 2002 at 08:43:08PM +0000, Clark C. Evans wrote: | > Since most native bindings don't support | > key order; it can't be in the generic model. Also, from a formal | > standpoint having the key order in the generic model causes all | > kinds of complexity that just isn't required. I'd rather have our | > collections be plain-ole-mathematical functions. | | Many applications will have a preferred key order they impose on the | data, no matter which order it comes in from the .yml file. Others | won't give a rip what order the elements are in. And for those apps | that really, really want to know what order the keys were in in the .yml | file, we can provide "something else" that tells that. Yes. | Since a dictionary can be represented as a list of pairs, why not have | an entry method that parses them that way? Parse everything else normally | but convert dictionaries to lists of pairs. Then the user gets the key | order and can make their own dictionary. That would also allow them to | do advanced processing of duplicate keys. Exactly. This is the serial model (the parser output) you are referring to. The topic is what the generic model will require -- a native binding may preserve key order but it should be required to to allow generic YAML tools to operate on it (ypath, schema validation, graph transformation etc.) This stuff is the generic model. Best, Clark |
From: Steve H. <sh...@zi...> - 2002-09-08 17:04:36
|
----- Original Message ----- From: "Mike Orr" <ir...@ms...> > Many applications will have a preferred key order they impose on the > data, no matter which order it comes in from the .yml file. Others > won't give a rip what order the elements are in. And for those apps > that really, really want to know what order the keys were in in the .yml > file, we can provide "something else" that tells that. Since a > dictionary can be represented as a list of pairs, why not have an entry > method that parses them that way? Parse everything else normally but > convert dictionaries to lists of pairs. Then the user gets the key > order and can make their own dictionary. That would also allow them to > do advanced processing of duplicate keys. > I envision something this. class OrderedHash: def set(key, value): # puts new key/value pair into an ordered hash class HashFactory: def new(): return OrderedHash() parser = yaml.Parser() parser.setHashFactory(HashFactory) for doc in parser.load(): # do whatever Cheers, Steve |
From: Clark C. E. <cc...@cl...> - 2002-09-08 17:16:38
|
On Sun, Sep 08, 2002 at 01:03:48PM -0400, Steve Howell wrote: | ----- Original Message ----- | From: "Mike Orr" <ir...@ms...> | > Many applications will have a preferred key order they impose on the | > data, no matter which order it comes in from the .yml file. Others | > won't give a rip what order the elements are in. And for those apps | > that really, really want to know what order the keys were in in the .yml | > file, we can provide "something else" that tells that. Since a | > dictionary can be represented as a list of pairs, why not have an entry | > method that parses them that way? Parse everything else normally but | > convert dictionaries to lists of pairs. Then the user gets the key | > order and can make their own dictionary. That would also allow them to | > do advanced processing of duplicate keys. | > | | I envision something this. | | class OrderedHash: | def set(key, value): | # puts new key/value pair into an ordered hash | | class HashFactory: | def new(): | return OrderedHash() | | parser = yaml.Parser() | parser.setHashFactory(HashFactory) | for doc in parser.load(): | # do whatever | I beg of you. Please don't do this. Wait for syntax-model schema mechanism which can be used by the emitter. Just beacuse the syntax will allow it doesn't mean it should be in the model. You could also use duplicate keys as well. Doing this will throw all hope for generic tools out-the-window (or greatly complicate them). I don't want to _subset_ YAML to have a meaningful transformation language. Trust me. When we get around to developing ypath and transform/query languages you will clearly see why this is a VERY BAD idea. To rule this stuff out is *exactly* why there is an information model included in the specification. Yes, you are right, perhaps a few users may _want_ to have an ordered hash. However, I'm fully willing to tell those users to go somewhere else. Somewhere there has to be a line between what is YAML and what isn't. Just beacuse it may look like YAML doesn't mean it is. Best, Clark |
From: Tom S. <tra...@tr...> - 2002-09-08 17:32:16
|
On Sun, 2002-09-08 at 11:18, Clark C. Evans wrote: > Yes, you are right, perhaps a few users may _want_ to have an ordered > hash. However, I'm fully willing to tell those users to go somewhere else. > Somewhere there has to be a line between what is YAML and what isn't. > Just beacuse it may look like YAML doesn't mean it is. > ordered hashs are certainly useful. using ruby, i have come across a number of times when i wish i had one, and thus have been pushing for a a new class much like PHPs. but at any rate, i'd don't see why yaml can't have this. is it really that much of a difficulty? the conception is really nothing more than the combination of a sequence and a mapping into one entity: - A - B - C and one: A two: B three: C perhaps: -one: A -two: B -three: C certainly ypath wouldn't have a problem dealing with this. not as for duplicate keys, well that i can do without. -- tom sawyer, aka transami tra...@tr... |
From: Clark C. E. <cc...@cl...> - 2002-09-08 17:56:13
|
On Sun, Sep 08, 2002 at 11:42:48AM -0600, Tom Sawyer wrote: | On Sun, 2002-09-08 at 11:18, Clark C. Evans wrote: | > Yes, you are right, perhaps a few users may _want_ to have an ordered | > hash. However, I'm fully willing to tell those users to go somewhere else. | > Somewhere there has to be a line between what is YAML and what isn't. | > Just beacuse it may look like YAML doesn't mean it is. | > | | ordered hashs are certainly useful. using ruby, i have come across a | number of times when i wish i had one, and thus have been pushing for a | a new class much like PHPs. but at any rate, i'd don't see why yaml | can't have this. is it really that much of a difficulty? the conception | is really nothing more than the combination of a sequence and a mapping | into one entity: | | - A | - B | - C | | and | | one: A | two: B | three: C Right. But as soon as you combine them, you end up with an object which is no longer a "mathematical function" and thus you complicate just about everything in a transformation language. I don't mind considering this down the road in a year or two; but I'd like to have ypath and a yaml transformation language worked out so that we can be absolutely sure that it won't cause problems. | perhaps: | | -one: A | -two: B | -three: C Yes, this is great (and the reson for the short-hand notation). At the core of YAML we've chosen the map/list construct as our pillar. This is one pillar that I don't want to consider moving. | certainly ypath wouldn't have a problem dealing with this. Actually it would complicate ypath signficiantly. If key order is signficant then YPATH should have a way to ask for the Nth key. Thus /0 means what? Right now it would be the value for the key "0". If it didn't mean that, then we'd have to find some other way to match a key with a value of "0"; alternatively we'd have to find a YPATH expression to match the Nth key; and if it differed from the way to access the first item in the list we'd have an inconsistency. Thus, no matter which choice you pick it is inconsistent. This is just the start of the problems. It is much worse complication for schema and transforms. That said, I have no problem with an "emitter directive" which gives the key ordering and which scalar styles to use, etc. This would be a very very welcome development and I encourage someone to do this in a way that can be copied by all implementations. But please, please don't build naitve objects from information which isn't in the generic model. This violates the specification and will cause lots of headaches if implementations get in the habit of routinely violating the spec whenever they feel like it. Thanks! Clark |
From: Steve H. <sh...@zi...> - 2002-09-08 17:34:17
|
----- Original Message ----- From: "Clark C. Evans" <cc...@cl...> > On Sun, Sep 08, 2002 at 01:03:48PM -0400, Steve Howell wrote: > | ----- Original Message ----- > | From: "Mike Orr" <ir...@ms...> > | > Many applications will have a preferred key order they impose on the > | > data, no matter which order it comes in from the .yml file. Others > | > won't give a rip what order the elements are in. And for those apps > | > that really, really want to know what order the keys were in in the .yml > | > file, we can provide "something else" that tells that. Since a > | > dictionary can be represented as a list of pairs, why not have an entry > | > method that parses them that way? Parse everything else normally but > | > convert dictionaries to lists of pairs. Then the user gets the key > | > order and can make their own dictionary. That would also allow them to > | > do advanced processing of duplicate keys. > | > > | > | I envision something this. > | > | class OrderedHash: > | def set(key, value): > | # puts new key/value pair into an ordered hash > | > | class HashFactory: > | def new(): > | return OrderedHash() > | > | parser = yaml.Parser() > | parser.setHashFactory(HashFactory) > | for doc in parser.load(): > | # do whatever > | > > I beg of you. Please don't do this. Wait for syntax-model schema > mechanism which can be used by the emitter. Just beacuse the syntax > will allow it doesn't mean it should be in the model. You could also > use duplicate keys as well. Doing this will throw all hope for > generic tools out-the-window (or greatly complicate them). I don't > want to _subset_ YAML to have a meaningful transformation language. > > Trust me. When we get around to developing ypath and transform/query > languages you will clearly see why this is a VERY BAD idea. To rule > this stuff out is *exactly* why there is an information model included > in the specification. > > Yes, you are right, perhaps a few users may _want_ to have an ordered > hash. However, I'm fully willing to tell those users to go somewhere else. > Somewhere there has to be a line between what is YAML and what isn't. > Just beacuse it may look like YAML doesn't mean it is. Clark, you really need to chill out. Nobody's goldfish is gonna die if I provide this *optional* method. It's low on my list of priorities, so you don't have to worry about it now, but Mike's idea really resonated with thoughts that I've had as a YAML user. When users like Mike and I present you ideas for YAML, please give them serious consideration, and please do not make statements like "tell those users to go somewhere else," or shout "VERY BAD idea" at us. You're gonna scare people. Seriously. Cheers, Steve |
From: Clark C. E. <cc...@cl...> - 2002-09-08 18:53:58
|
| Clark, you really need to chill out. Yes. I do apologise. I'm very irked lately beacuse in the last week two aspects of the generic model (core of yaml) are being questioned: a) type-family as optional (now it is mandatory) b) exclusion of key order (it is only in the serial model) Not that these arn't good questions. In particular Oren's change may be the best approach; although we need to arm-wresle out the differences between making the change or not. Mostly what is irking me is that its clear that you and perhaps other implementers either haven't read the information model section of the spec or haven't not understood it. ==> In either case it is a failure on my part and I'm struggling how to make it inviting... in the mean time I feel as if the ground under (implementations) is shifting and this makes me uneasy. | Nobody's goldfish is gonna die if I provide this *optional* method. This is where we differ. No body is going to die if _why doesn't throw an error when he finds duplicate keys in his loader. In fact, he may load everythign into a named-list for better XML compatibility. You are right. No one will die. But at that point the use of YAML is in violation of the specification. And that is where I get concerned and really stressed out. | It's low on my list of priorities, so you don't have to worry about | it now, but Mike's idea really resonated with thoughts that I've had | as a YAML user. We definatly need a way to specify key order for the emitter. Ideally it would be a standard way driven from a schema or something like that. But I'm asking you to please not do stuff that violates the specification. And I think that this is a serious enough request to bark a bit. | When users like Mike and I present you ideas for YAML, please give them | serious consideration, and please do not make statements like "tell those | users to go somewhere else," or shout "VERY BAD idea" at us. You're gonna | scare people. Seriously. Ok. I can do that. However, would you promise to read the specification and if something isn't crystal clear ask or make a suggested change so that it is clear? Orr's question is very good, and it should be clearly explained and put into a FAQ. There is a fork in the road yaml-core will come to very shortly, that is one where the spec is finished and everything isn't subject to question/change. That conversion has to happen soon or people like Neil won't be able to proceed without fear of the carpet pulled out from under him. Also we will have to do this soon or higher-level tools will be forever in the "future". I thought that "last call" was going to be very close to that milestone... and although I don't mind changes; I'd rather us not reconsider the whole of YAML. YAML will never be perfect. But at some point it does have to be "done". I'm irked beacuse I want to move on to other stuff, ypath, transformation, etc. And I'm very tired of re-considering YAML to get it even closer to perfection before we have had a chance to build higher-level tools, etc. Answering questions is one thing. Proposed changes to a spec that is in last call is something else entirely. Best, Clark |
From: Steve H. <sh...@zi...> - 2002-09-08 20:53:18
|
----- Original Message ----- From: "Clark C. Evans" <cc...@cl...> > | Clark, you really need to chill out. > > Yes. I do apologise. I'm very irked lately beacuse in the last week > two aspects of the generic model (core of yaml) are being questioned: > > a) type-family as optional (now it is mandatory) > b) exclusion of key order (it is only in the serial model) > > Not that these arn't good questions. In particular Oren's change > may be the best approach; although we need to arm-wresle out the > differences between making the change or not. > > Mostly what is irking me is that its clear that you and perhaps > other implementers either haven't read the information model section > of the spec or haven't not understood it. ==> In either case it is > a failure on my part and I'm struggling how to make it inviting... in > the mean time I feel as if the ground under (implementations) is > shifting and this makes me uneasy. > > | Nobody's goldfish is gonna die if I provide this *optional* method. > > This is where we differ. No body is going to die if _why doesn't > throw an error when he finds duplicate keys in his loader. In fact, > he may load everythign into a named-list for better XML compatibility. > You are right. No one will die. But at that point the use of YAML > is in violation of the specification. And that is where I get concerned > and really stressed out. > > | It's low on my list of priorities, so you don't have to worry about > | it now, but Mike's idea really resonated with thoughts that I've had > | as a YAML user. > > We definatly need a way to specify key order for the emitter. Ideally > it would be a standard way driven from a schema or something like that. > But I'm asking you to please not do stuff that violates the specification. > And I think that this is a serious enough request to bark a bit. > > | When users like Mike and I present you ideas for YAML, please give them > | serious consideration, and please do not make statements like "tell those > | users to go somewhere else," or shout "VERY BAD idea" at us. You're gonna > | scare people. Seriously. > > Ok. I can do that. However, would you promise to read the specification > and if something isn't crystal clear ask or make a suggested change so > that it is clear? Orr's question is very good, and it should be > clearly explained and put into a FAQ. > > There is a fork in the road yaml-core will come to very shortly, that > is one where the spec is finished and everything isn't subject to > question/change. That conversion has to happen soon or people like > Neil won't be able to proceed without fear of the carpet pulled out > from under him. Also we will have to do this soon or higher-level > tools will be forever in the "future". I thought that "last call" > was going to be very close to that milestone... and although I don't > mind changes; I'd rather us not reconsider the whole of YAML. > > YAML will never be perfect. But at some point it does have > to be "done". I'm irked beacuse I want to move on to other > stuff, ypath, transformation, etc. And I'm very tired of > re-considering YAML to get it even closer to perfection before > we have had a chance to build higher-level tools, etc. > > Answering questions is one thing. Proposed changes to a spec > that is in last call is something else entirely. > Clark, the chapter in the spec that deals with the data models dissatisfies me for only one reason. It lacks conciseness. Cheers, Steve |
From: <ir...@ms...> - 2002-09-08 23:40:50
|
I tried to read the spec again yesterday, but again it made my head spin. I don't have a background in tokenizer/parser theory so I can't say which parts are necessary and which are not. I just noticed a lot of words like "syntax", "serial", "native", "generic", "parser", "loader", "dumper", "emitter", "type family", "kind", "graph", "transfer", "taguri" that are too much to assimilate all at once. It leaves me with the feeling -- and this is what I told Steve -- "Does YAML really need a spec that's 73 pages long?" If it does, maybe it's not a "simple" replacement for XML, and maybe it's not the tool for small jobs. Now, Python's grammar and parser module (AST objects) also make my head spin for the same reason. But fortunately they take up only one small corner of the documentation and don't prevent me from *using* Python. They do prevent me from using the parser module to write a program that lists all a program's dependencies (imports), a project I've tried to do on and off for years but have always given up on. (Yes, I could do a text search for "import" but I want to use Python's real parser.) But that's just one insignificant application, not something that prevents me from using Python. XML on the other hand requires you to learn the gory details of DTDs, namespaces, XSLT, etc, in order to do anything more than the simplest file. You can't even use most public DTDs with a pretty intricate knowledge, much less add a couple private tags to them, and the whole thing gives you a sense of "Why does this have to be so complicated? Why do I have to specify so many details just because some huge corporation needs them for their documents?" YAML has a large gap between the quick reference on the site (and the other tutorials) and the spec. The tutorials get you started but then what? For instance, the date format. Four formats, but no explanation about what it's supposed to be used for, what it's not supposed to be used for, and why it doesn't handle certain less-precise formats users would commonly want. I realize YAML is a new and rapidly-changing project and that this will come. Still, these are the kinds of problems users face. The gap can eventually be filled by a big users' guide so that most people don't have to look at the spec, -or- by simplifying the spec so it can double as a users' guide. For instance, do we need five quoting styles for strings (bare, '', "", |, > )? Or 3+ styles for single- and multi-line mappings? I wasn't here when each style was adopted, and maybe they are all necessary for significant problem domains, but it's worth considering whether any can be dropped. That would shorten the spec and the quickref, and perhaps make YAML more accessible. At the least, it would make the Perl/Python/Ruby implementors' job easier, not having to code so many special cases. Note that I'm not saying we need to do something about strings and mappings in particular; I'm just using them as examples. I like Oren's direction in his big message today. Supporting schema-blind and schema-specific usages equally seems wise, and I like the idea of banishing type conversions to the smallest portion of code possible. > | Nobody's goldfish is gonna die if I provide this *optional* method. > > This is where we differ. No body is going to die if _why doesn't > throw an error when he finds duplicate keys in his loader. It's possible for the loader to have a default recommended mode that does whatever, -and- provide options like "extract mappings as pairs", "all values are strings", or anything we find a significant constituency for in the future. The options make certain uses of YAML possible *without* detracting from the core/recommended usage. (Now, maybe Oren's schema proposal will handle all the situations these options would, we'll see.) Perhaps some comparisions between YAML and Cheetah would be helpful. I'm a developer for Cheetah, a string template system for Python (www.cheetahtemplate.org). I don't work on the parser code (can you guess why?), but I do other coding and also wrote the users' guide and developers' guide. 1) We want Cheetah to be the template system of choice for the widest variety of tasks. Its primary purpose is for Webware servlets, and we won't add anything that detracts from that. But we've added features needed by CGI scripts, Python source generators, Java source generators, and shell scripts running templates as standalone commands. We don't add features one person needs. But we add features that make Cheetah suitable for an entire class of applications it wasn't before. Anyway, I see YAML as being able to fulfill a similar role in the data-storage/data-exchange realm. Certain core uses, but also flexible for other uses on the side. 2) Rather than working from a written grammar and spec, Cheetah's design was based on a spec inside somebody's head. Then the users' guide was written, and I'm now writing an EBNF grammar based on the users' guide. Not a suitable approach for an interoperational project like YAML, but it's interesting that the two grew in almost opposite directions. 3) YAML is in rapid change now anticipating a 1.0 spec freeze. Cheetah was in rapid change last summer and then entered a long beta while we slowly decided whether we're all comfortable with the current spec. Since there haven't been any requests for backward-incompatible changes for several months (except one), we're pretty confident about entering a final beta as soon as a few small tasks are completed. There are plenty of requests after that, but they are all behind-the-scenes work or adding optional features, not things that would change the spec. It's like popping popcorn, or at least that's been our experience. Eventually the popping slows down and you can freeze the spec, confident most people are comfortable with it. And if you end up in a stalemate argument, the BDFL says this is the way it's gonna be, and the dissenters either take it or leave it. But usually the best design emerges on its own. Thanks to Brian, Clark and Oren for putting all this work into what might turn out to be a lifesaver for XML refugees. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Clark C. E. <cc...@cl...> - 2002-09-09 01:40:16
|
On Sun, Sep 08, 2002 at 04:40:47PM -0700, Mike Orr wrote: | I tried to read the spec again yesterday, but again it made my head | spin. I don't have a background in tokenizer/parser theory Well, in the next few weeks let's fix it. I could use your and Steve's help as people to bounce it off. To get started, reference my last post. Perhaps this needs to be somehow worked into the spec so that the intent is clear. I think Oren and I implicitly share some of this intent (from XML land) | XML on the other hand requires you to learn the gory details of DTDs, | namespaces, XSLT, etc, in order to do anything more than the simplest | file. You can't even use most public DTDs with a pretty intricate | knowledge, much less add a couple private tags to them, and the | whole thing gives you a sense of "Why does this have to be so | complicated? Why do I have to specify so many details just because | some huge corporation needs them for their documents?" I agree here. What brought Oren and I together was SML-DEV where the goal was to "simplify XML". The product is really the YAML information model... or an earlier version of it. It found a syntax about a year later when we hooked up with Brian. YAML's info model is very very simple compared to XML's. Its simpler beacuse we've distinguished beween the syntax and the graph model. | YAML has a large gap between the quick reference on the site | (and the other tutorials) and the spec. The tutorials get you started | but then what? For instance, the date format. Four formats, but | no explanation about what it's supposed to be used for, what it's | not supposed to be used for, and why it doesn't handle certain | less-precise formats users would commonly want. I realize YAML | is a new and rapidly-changing project and that this will come. | Still, these are the kinds of problems users face. I could convince you or someone else to write a tutorial? It's something we desperately need and I'd rather focus my energies on the spec and on helping out with the implementations. | For instance, do we need five quoting styles for strings (bare, | '', "", |, > )? Or 3+ styles for single- and multi-line mappings? Most of this stuff has rationales and yes, it'd be cool to put this stuff in the spec (so it can be regurgitated in a user guide). With our re-thinking implicit types, we may be able to drop the single quoted form; but I'm not sure. | That would shorten the spec and the quickref, and perhaps make YAML | more accessible. At the least, it would make the Perl/Python/Ruby | implementors' job easier, not having to code so many special cases. Ideally these will be implemented once in Neil's libyaml, the Python binding then works primarly from the serial model w/o having to deal with all of the styles and syntax level issues. | I like Oren's direction in his big message today. Supporting | schema-blind and schema-specific usages equally seems wise, and I | like the idea of banishing type conversions to the smallest portion | of code possible. I can see where he is coming from, but I'd like to have things that need not be application/bindinging specific shared by all implementations. And the implicit detection for scalars I think could (should?) fit into that category. | > This is where we differ. No body is going to die if _why doesn't | > throw an error when he finds duplicate keys in his loader. | | It's possible for the loader to have a default recommended mode that | does whatever, -and- provide options like "extract mappings as pairs", | "all values are strings", or anything we find a significant | constituency for in the future. The options make certain uses of YAML | possible *without* detracting from the core/recommended usage. This one is a tough call. Certainly some playing is good, but "extensions" by different implementations, as well intentioned as they may be, have a funny way of colliding and making a big mess of things.... | Perhaps some comparisions between YAML and Cheetah would be helpful. The big difference is that YAML has more than one implementation and we use the SPEC to communicate a shared understanding. | I'm a developer for Cheetah, a string template system for Python | (www.cheetahtemplate.org). I don't work on the parser code (can you | guess why?), but I do other coding and also wrote the users' guide | and developers' guide. Yes, I know. You've helped me on the Webware list more than once. | I see YAML as being able to fulfill a similar role | in the data-storage/data-exchange realm. Certain core uses, but | also flexible for other uses on the side. Right. But its important that those other uses don't cause changes that make schemas/transforms/ypaths and other stuffs like that harder than it need be. | 2) Rather than working from a written grammar and spec, Cheetah's | design was based on a spec inside somebody's head. Then the users' | guide was written, and I'm now writing an EBNF grammar based on the | users' guide. Not a suitable approach for an interoperational | project like YAML, but it's interesting that the two grew in almost | opposite directions. Actually, we've had a pretty cool feedback loop between the spec and the implementation for some time. Oren has been the lead spec guy, Brian was the lead implementation guy and I was the cheerleader (doing a bit of both) | 3) YAML is in rapid change now anticipating a 1.0 spec freeze. Cheetah | was in rapid change last summer and then entered a long beta while we | slowly decided whether we're all comfortable with the current spec. YAML improves in jumps which come through a "insight" that we just didn't see... blind sided us even. We've had many of these fellas. The recent type one has been brewing for some time... it'll take a wee bit to settle down; but this has a good chance of being the last core item. The info model has kept pace with the syntax, they in effect have informed each other. Those who may have been focusing on the syntax may have not see the info model changes, but they have progressed... | Thanks to Brian, Clark and Oren for putting all this work into what | might turn out to be a lifesaver for XML refugees. We are working hard on it. Thank you for all of your valueable feedback. Best, Clark |
From: Steve H. <sh...@zi...> - 2002-09-09 02:11:55
|
----- Original Message ----- From: "Clark C. Evans" <cc...@cl...> > On Sun, Sep 08, 2002 at 04:40:47PM -0700, Mike Orr wrote: > | I tried to read the spec again yesterday, but again it made my head > | spin. I don't have a background in tokenizer/parser theory > > Well, in the next few weeks let's fix it. I could use your > and Steve's help as people to bounce it off. To get started, > reference my last post. Perhaps this needs to be somehow > worked into the spec so that the intent is clear. I think > Oren and I implicitly share some of this intent (from XML land) > Clark, Mike, Brian, and I are trying to help you make the spec better, but there's not much we can do if you don't listen. We're smart folks too, you know. I like the idea of incorporating your recent emails into a more permanent document, although we are running out of room in the spec. Please see the Wiki pages that I have created from Clark's recent emails: http://wiki.yaml.org/yamlwiki/RecentChanges Thanks to Brian for his message earlier today reminding us that the Wiki can be a valuable tool. I think we do underutilize it. Cheers, Steve |
From: <ir...@ms...> - 2002-09-09 06:08:24
|
On Mon, Sep 09, 2002 at 01:42:00AM +0000, Clark C. Evans wrote: > On Sun, Sep 08, 2002 at 04:40:47PM -0700, Mike Orr wrote: > | I tried to read the spec again yesterday, but again it made my head > | spin. I don't have a background in tokenizer/parser theory > > Well, in the next few weeks let's fix it. I could use your > and Steve's help as people to bounce it off. I'm certainly willing to help. > To get started, reference my last post. Which last post? I'll take your IRC summary today and your "what is the YAML model anyway?" as starting points. Steve is right, the latter document is definitely the kind of thing we need and should go in the docs somewhere. How are you using the word "graph"? When Tim Berners-Lee was trying to convince the Python team to have a graph object, he described something like a dictionary but with triples instead of pairs, so that two parts together would form the key (e.g., section + specific item => value). Is that what you mean by a graph, in the sense of renaming the generic level to the graph level? Where are the two keys? > I could convince you or someone else to write a tutorial? Actually, I had already started a PyYAML tutorial before this types brou-ha-ha started. I can at least work out what a YAML tutorial needs to include and provide an outline. One of the sneaky advantages of writing tutorials is that you get to force people to answer all your stupid questions because you can just say, "It's not just for me, it's for the tutorial," haha. :) > | For instance, do we need five quoting styles for strings (bare, > | '', "", |, > )? Or 3+ styles for single- and multi-line mappings? > > Most of this stuff has rationales and yes, it'd be cool to > put this stuff in the spec (so it can be regurgitated in > a user guide). As an aside, it occurred to me that backslash escapes may be a good thing to handle by a #DIRECTIVE. Leave the default off following the policy of least surprise, but let it be turned on on a document-wide basis. Most users won't know what a backslash escape is and will never miss it. Those who do prob'ly don't want it just in one value but throughout the document. Doing this would eliminate the need for double-quoted strings and the corollary need to quote a " inside them. Just a thought. Then if we get rid of single-quoted strings... :) > Yes, I know. You've helped me on the Webware list more than once. I did?? I didn't recognize your name. Anyway, spec readability. I'll print out your two e-mails and read them over tomorrow. I have only an hour a day of free time during the week, between 8 and 10pm (UTC-0700, Seattle). Where are you? -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Brian I. <in...@tt...> - 2002-09-09 05:47:58
|
On 08/09/02 16:40 -0700, Mike Orr wrote: > I tried to read the spec again yesterday, but again it made my head > spin. I don't have a background in tokenizer/parser theory so I > can't say which parts are necessary and which are not. I just noticed > a lot of words like "syntax", "serial", "native", "generic", > "parser", "loader", "dumper", "emitter", "type family", "kind", > "graph", "transfer", "taguri" that are too much to assimilate all > at once. It leaves me with the feeling -- and this is what I told Steve > -- "Does YAML really need a spec that's 73 pages long?" If it does, > maybe it's not a "simple" replacement for XML, and maybe it's not the > tool for small jobs. The spec is long because YAML is a tool for big complicated jobs. But it is also the tool for small jobs. We're working hard to make it both. The spec is not where users should go to learn YAML. (Perhaps the tutorial section belongs outside of it.) The spec is where the stuff that implementors of YAML processors can get their information. And yes, it's heavy. It could be made a lot better, but probably not a lot shorter. Spec length is orthongonal to usefullness in the small. Look at Perl. It's parser grammar is so complicated that a spec can't even be written for it. And yet it's most time proven useful domain is in small to medium hacks. Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2002-09-08 19:29:45
|
On Sun, Sep 08, 2002 at 01:33:38PM -0400, Steve Howell wrote: | > Trust me. When we get around to developing ypath and transform/query | > languages you will clearly see why this is a VERY BAD idea. To rule | > this stuff out is *exactly* why there is an information model included | > in the specification. | > | > Yes, you are right, perhaps a few users may _want_ to have an ordered | > hash. However, I'm fully willing to tell those users to go somewhere else. | > Somewhere there has to be a line between what is YAML and what isn't. | > Just beacuse it may look like YAML doesn't mean it is. | | Clark, you really need to chill out. Nobody's goldfish is gonna die if I | provide this *optional* method. It's low on my list of priorities, so | you don't have to worry about it now, but Mike's idea really resonated | with thoughts that I've had as a YAML user. I think my reply here wasn't clear. I'm not opposed to people serializing the order within a map using YAML; what I am opposed is using YAML in a way that violates the spec to do so. Basically, just beacuse the syntax orderes the keys doesn't mean that this ordering can/should be used. this: !my-ordered-map - is: one - way: to - represent: an - ordered: mapping Other option includes using an external "syntax schema" which specifies the key ordering. What would not be acceptable is to serialize this as... this: is: one way: to represent: an ordered: mapping Beacuse treating the order here as signifcant will cause problems between implementations which don't. Best, Clark |
From: Steve H. <sh...@zi...> - 2002-09-08 16:44:44
|
Brian wrote: > > Also some languages (like PHP I believe) actually preserve key order in their > hashes natively. Good for them. > Yes indeed. The hash-with-key-order is such a useful data structure. Although Perl and Python don't do it by default, they both have decent language facilities for rolling your own. I rolled my own in Python, just as a spike, and it's not too hard. We should probably think about putting supporting code for these data structures into our YAML distributions. |
From: Brian I. <in...@tt...> - 2002-09-08 21:21:22
|
On 08/09/02 12:44 -0400, Steve Howell wrote: > Brian wrote: > > > > Also some languages (like PHP I believe) actually preserve key order in their > > hashes natively. Good for them. > > > > Yes indeed. The hash-with-key-order is such a useful data structure. Although > Perl and Python don't do it by default, they both have decent language > facilities for rolling your own. I rolled my own in Python, just as a spike, > and it's not too hard. We should probably think about putting supporting code > for these data structures into our YAML distributions. There is a little script that ships with YAML.pm called phone2yaml. It takes a tab separated phone export file from a palm pilot and turns it into nicely formatted YAML. The hash keys are in the same order as they are in the palm pilot. This makes the file very human readable which is how I use it. I genereally do a context grep for a string in the file. Like 2 lines before and 10 lines after 'Howell'. And I get back what my palm pilot would have told me. The point is that I have an interface for injecting key order into any node. I do this using a shadow but in Ruby/Python I could probably just inject the info right into the dictionary. When I do the YAML dump, YAML.pm respects the key order in the shadow. Now for the kicker. I consider the shadow node to be my 'Generic View'. Given that, I could actually *Load* the document using these special generic nodes (which are objects) rather than just native Perl hashes. If I dump the same generic nodes, then it is a given that I will have just preserved key order in a YNY roundtrip. Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2002-09-08 23:44:20
|
On Sun, Sep 08, 2002 at 02:21:08PM -0700, Brian Ingerson wrote: | The point is that I have an interface for injecting key order into any node. | I do this using a shadow but in Ruby/Python I could probably just inject the | info right into the dictionary. When I do the YAML dump, YAML.pm respects the | key order in the shadow. And this is great feature for enhancing readabilty of YAML output, ideally we could have a manner in which the scalar style, comments to be added, and other syntax-model level things could be added. | Now for the kicker. I consider the shadow node to be my 'Generic View'. No. The generic model is an abstraction of our "ideal" target language which we've defined as including Python and Perl for hard-core references. If Python and Perl don't support the structure out-of-the-box, then it's not in the generic model. | Given that, I could actually *Load* the document using these | special generic nodes (which are objects) rather than just | native Perl hashes. If I dump the same generic nodes, then | it is a given that I will have just preserved key order | in a YNY roundtrip And this is nice. But this equivalent to having an XML DOM. You've added requirements beyond YAML. ... One thing which I think is probably a mistake we made is that if a language _doesn't_ know how to handle a particular data type is shouldn't be required to round-trip the type identifier; it should be permitted to issue an error but load the file anyway. I think the round-tripping type-family requirement is being mis-understood.. perhaps it shouldn't even have been a requirement. Hmm. Best, Clark |