From: <ti...@ds...> - 2004-02-19 21:23:29
|
> --- > : value # Null key > ? Key1 # Null value > ? Key2 > : Hmmm > ... what happened to [ ~, null, Nil ] ? I think explicitly written null could only enhance readability. perhaps it could be required at least in keys? I find --- ~ : value ? Key1 ? Key2 ~ : Hmmm ... much more easy to read and not at all ambiguous. kventin p.s. I use YAML in both ruby and perl and it 'greatly enhanced my productivity' I dare to say. (seriously, YAML is _the_ ini/config/dump format for scripting for me) |
From: <ti...@ds...> - 2004-02-23 10:19:49
|
I realized null key might be also written --- ? : value of nothing ... correct? but it is IMHO still less clear than explicitly written null. on the other hand - when will null keys be really used? AFAIK only python allows None to be key; perl5 doesn't allow anything but strings, ruby and lua do allow anything - but null, i don't know about others. so, python would see None, but everybody else would see something other as it's own null (perhaps !yaml/null or just !python/None ?) and would have to cope with it. am i missing something? kventin |
From: Zenaan H. <ze...@fr...> - 2004-02-23 11:01:20
|
On Mon, 2004-02-23 at 21:09, Bra=F2o Tich=FD wrote: > I realized null key might be also written > --- > ? : value of nothing > ... > correct? > but it is IMHO still less clear than explicitly written null. > on the other hand - when will null keys be really used? > AFAIK only python allows None to be key; > perl5 doesn't allow anything but strings, ruby and lua do allow anything = - > but null, i don't know about others. > so, python would see None, but everybody else would see something other a= s > it's own null (perhaps !yaml/null or just !python/None ?) > and would have to cope with it. > am i missing something? Should it be defined as empty string, or is that somehow different to null? If so, how would empty string be specified in above example? ta zen |
From: Zenaan H. <ze...@fr...> - 2004-02-23 11:06:37
|
On Mon, 2004-02-23 at 21:49, Zenaan Harkness wrote: > On Mon, 2004-02-23 at 21:09, Bra=F2o Tich=FD wrote: > > I realized null key might be also written > > --- > > ? : value of nothing > > ... > > correct? > > but it is IMHO still less clear than explicitly written null. > > on the other hand - when will null keys be really used? > > AFAIK only python allows None to be key; > > perl5 doesn't allow anything but strings, ruby and lua do allow anythin= g - > > but null, i don't know about others. > > so, python would see None, but everybody else would see something other= as > > it's own null (perhaps !yaml/null or just !python/None ?) > > and would have to cope with it. > > am i missing something? >=20 > Should it be defined as empty string, or is that somehow different to nul= l? >=20 > If so, how would empty string be specified in above example? In fact, to me the above kind of looks like a string of a single space. But would that be introducing exceptions to otherwise generic rules? On that line of thinking - the ideal way in my mind is a single rule that has sensible conclusions for such cases as above. Similar in kind to the C++ STL convention of having ranges defined as two iterators (/pointers), such that the first points to the beginning of the range, and the second point to the one-past-the-end of the range. Such a convention proves to make the library's design much simpler overall, and making use of it, and customizing the library with algorithms - a whole bunch of corner cases just disappeared. Now for YAML? ... cheers zen |
From: <ti...@ds...> - 2004-02-23 12:50:01
|
----- Original Message -----=20 From: "Zenaan Harkness" <ze...@fr...> To: <yam...@li...> Sent: Monday, February 23, 2004 11:55 AM Subject: Re: [Yaml-core] RE: Proposed Changes to YAML by example > On Mon, 2004-02-23 at 21:49, Zenaan Harkness wrote: > > On Mon, 2004-02-23 at 21:09, Bra=F2o Tich=FD wrote: > > > I realized null key might be also written > > > --- > > > ? : value of nothing > > > ... > > > correct? > > > but it is IMHO still less clear than explicitly written null. > > > on the other hand - when will null keys be really used? > > > AFAIK only python allows None to be key; > > > perl5 doesn't allow anything but strings, ruby and lua do allow anything - > > > but null, i don't know about others. > > > so, python would see None, but everybody else would see something other as > > > it's own null (perhaps !yaml/null or just !python/None ?) > > > and would have to cope with it. > > > am i missing something? > > > > Should it be defined as empty string, or is that somehow different to null? > > > > If so, how would empty string be specified in above example? --- '' : value of an empty string ... > > In fact, to me the above kind of looks like a string of a single space. no, that would be --- ' ' : value of a space ... (or some kind of escape: \x20, "\ ") > But would that be introducing exceptions to otherwise generic rules? > maybe to some rules regarding white space. all following documents should be equivalent (what word is used in yaml lingo?) --- abcd: 1 --- abcd : 1 --- abcd : 1 ... |
From: <in...@tt...> - 2004-02-23 20:01:50
|
On 23/02/04 11:09 +0100, Bra?o Tich? wrote: > I realized null key might be also written > --- > ? : value of nothing > ... > correct? This actually is invalid YAML. When the explicit key indicator '?' is used, the ':' must be on a separate line and in the same column. --- ? : value of nothing ... > but it is IMHO still less clear than explicitly written null. > on the other hand - when will null keys be really used? > AFAIK only python allows None to be key; > perl5 doesn't allow anything but strings, ruby and lua do allow anything - > but null, i don't know about others. > so, python would see None, but everybody else would see something other as > it's own null (perhaps !yaml/null or just !python/None ?) > and would have to cope with it. > am i missing something? The answer you are seeking is a little bit tricky, but is key to understanding the essence of YAML. An empty string is not really a null per se. It is an empty "scalar" that also has an empty "tag". YAML's type repository encourages this combination to be loaded into memory as a Python None or a Ruby null or a Perl undef. But (in the absence of a schema) a YAML loader can load it as anything. In fact, loaders are also encouraged to load all untagged scalars as strings. So how can they be encouraged to do both? It depends on how the application using YAML would like empty values served up. In other words, if there is no "schema" or "contract", two different loaders will probably load the same document in different ways. And this is perfectly OK. It all depends on the application that is using YAML. On the specific use case. You cannot take a random YAML document from Perl, pass it through Ruby, and expect it (beyond a shadow of a doubt) to come back intact. *Unless* there is a schema associated with the document. Or unless the classes in Perl and in Python have been designed to work with each other. Which is really a different form of a "schema" or "contract". Hope this helps. Cheers, Brian |
From: <ti...@ds...> - 2004-02-24 08:41:43
|
> > --- > > ? : value of nothing > > ... > > correct? > > This actually is invalid YAML. When the explicit key indicator '?' is > used, the ':' must be on a separate line and in the same column. > > --- > ? > : value of nothing > ... > oh, right, i missed this one. > The answer you are seeking is a little bit tricky, but is key to > understanding the essence of YAML. An empty string is not really a null > per se. It is an empty "scalar" that also has an empty "tag". YAML's > type repository encourages this combination to be loaded into memory as > a Python None or a Ruby null or a Perl undef. But (in the absence of a > schema) a YAML loader can load it as anything. In fact, loaders are > also encouraged to load all untagged scalars as strings. So how can they > be encouraged to do both? It depends on how the application using YAML > would like empty values served up. > > In other words, if there is no "schema" or "contract", two different > loaders will probably load the same document in different ways. And this > is perfectly OK. It all depends on the application that is using YAML. > On the specific use case. > > You cannot take a random YAML document from Perl, pass it through Ruby, > and expect it (beyond a shadow of a doubt) to come back intact. *Unless* > there is a schema associated with the document. Or unless the classes in > Perl and in Python have been designed to work with each other. Which is > really a different form of a "schema" or "contract". > > Hope this helps. > yes, this helps a lot. thank you. i found several schema proposals at http://yaml.freepan.org/index.cgi?SchemaProposals, but is there any plans to have standard way to attach schema to document? or is this again application specific? > Cheers, Brian > kventin (who like yaml more every day) |
From: <in...@tt...> - 2004-02-24 22:57:37
|
On 24/02/04 09:39 +0100, Brano Tich? wrote: > > > --- > > > ? : value of nothing > > > ... > > > correct? > > > > This actually is invalid YAML. When the explicit key indicator '?' is > > used, the ':' must be on a separate line and in the same column. > > > > --- > > ? > > : value of nothing > > ... > > > > oh, right, i missed this one. > > > The answer you are seeking is a little bit tricky, but is key to > > understanding the essence of YAML. An empty string is not really a null > > per se. It is an empty "scalar" that also has an empty "tag". YAML's > > type repository encourages this combination to be loaded into memory as > > a Python None or a Ruby null or a Perl undef. But (in the absence of a > > schema) a YAML loader can load it as anything. In fact, loaders are > > also encouraged to load all untagged scalars as strings. So how can they > > be encouraged to do both? It depends on how the application using YAML > > would like empty values served up. > > > > In other words, if there is no "schema" or "contract", two different > > loaders will probably load the same document in different ways. And this > > is perfectly OK. It all depends on the application that is using YAML. > > On the specific use case. > > > > You cannot take a random YAML document from Perl, pass it through Ruby, > > and expect it (beyond a shadow of a doubt) to come back intact. *Unless* > > there is a schema associated with the document. Or unless the classes in > > Perl and in Python have been designed to work with each other. Which is > > really a different form of a "schema" or "contract". > > > > Hope this helps. > > > > yes, this helps a lot. thank you. > i found several schema proposals at > http://yaml.freepan.org/index.cgi?SchemaProposals, > but is there any plans to have standard way to attach schema to document? > or is this again application specific? There will most likely be conventions that arise, and that YAML-core endorses. Take a sample document: --- !ingy.net,2004/floozle date: 1/2/2004 name: Duck Soup It is possible that a schema document could live at http://ingy.net/floozle/ Or perhaps an index lives there that points to a schema location. I'm sure Clark and Oren have ideas on how this might work. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-25 09:02:32
|
Brian wrote: > > > In other words, if there is no "schema" or "contract",=20 > > > two different=20 > > > loaders will probably load the same document in different=20 > > > ways. And=20 > > > this is perfectly OK. It all depends on the application that is=20 > > > using YAML. On the specific use case. So far, so good, but: > > > You cannot take a random YAML document from Perl, pass it through=20 > > > Ruby, and expect it (beyond a shadow of a doubt) to come back=20 > > > intact. I *do* expect to be able to load a YAML document from Perl into Ruby and re-emit it "intact", regardless of the schema. That's the whole point of the "information model" - it defines what information must be preserved for the result to be "the same" as the input. It doesn't matter that the Ruby loader uses a different "cave drawing" than the Perl loader to represent each node. If the Ruby loader emits a "different" document, than it isn't really working properly. For example, if I write a YAML pretty-printer in Ruby, it would be very bad if it changed the document semantics. > > > *Unless* there is a schema associated with the=20 > > > document. Or=20 > > > unless the classes in Perl and in Python have been=20 > > > designed to work=20 > > > with each other. Which is really a different form of a=20 > > > "schema" or "contract". A schema helps in two ways. First, if the Ruby loader fails to preserve all the information required by the YAML spec, but the specific schema doesn't ever use the lost information (e.g., never uses implicit typing), then the application is still "valid YAML", even though the loader isn't. I expect this to be rather rare, though. Second, and more importantly, you must agree on a schema/contract in advance if you want a YAML document generated by Perl to load into "meaningful" Ruby - that is, into "compatible" classes with "the same" semantics. In fact this holds when transferring a document between any two different processing systems. Brano Tich=FD asked: > > i found several schema proposals at=20 > > http://yaml.freepan.org/index.cgi?SchemaProposals, > > but is there any plans to have standard way to attach schema to=20 > > document? or is this again application specific? Yes and no. Like Brian said: > There will most likely be conventions that arise, and that=20 > YAML-core endorses. >=20 > Take a sample document: >=20 > --- !ingy.net,2004/floozle > date: 1/2/2004 > name: Duck Soup The !ingy.net,2004/floozle tag is the standard YAML way to associate a schema with the document. However, all the YAML gives you is a URI - globally unique identifier - for the schema. It does not specify the mechanism by which you convert this URI into whatever concrete form you expect the schema to take. This is intentional. There is a range of concrete forms the schema may take - human-readable documents, various declarative languages for verification, and even code libraries that may be loaded dynamically for processing the document. Similarly, there is a range of mechanisms that may be used to locate the concrete schema - using protocols such as http or ftp, accessing a database, and so on. Inevitably, different applications running in different systems will have different choices of the format and mechanism. It may even be that the same application may use multiple mechanisms simultaneously (e.g., fetching separate "verification schema" and "loading schema"). That's why the schema tag is a UR*I*, rather than a UR*L* - it merely *identifies* the schema, it does not *locate* it. > I'm sure Clark and Oren have ideas on how this might work. I have a lot of ideas on how schema location may work, but I firmly believe it is outside the scope of the YAML standard itself. Have fun, Oren Ben-Kiki |
From: <in...@tt...> - 2004-02-25 16:46:10
|
On 25/02/04 11:00 +0200, Oren Ben-Kiki wrote: > Brian wrote: > > > > In other words, if there is no "schema" or "contract",=20 > > > > two different=20 > > > > loaders will probably load the same document in different=20 > > > > ways. And=20 > > > > this is perfectly OK. It all depends on the application that is=20 > > > > using YAML. On the specific use case. >=20 > So far, so good, but: >=20 > > > > You cannot take a random YAML document from Perl, pass it through= =20 > > > > Ruby, and expect it (beyond a shadow of a doubt) to come back=20 > > > > intact. >=20 > I *do* expect to be able to load a YAML document from Perl into Ruby and > re-emit it "intact", regardless of the schema. That's the whole point of > the "information model" - it defines what information must be preserved > for the result to be "the same" as the input. I agree with you in principle. My point was more along the lines of a practical scenario. If you pass empty keys around between implementations without explicit typing or some kind of schema, you are basically playing "fast and loose" with YAML, and shouldn't be surprised if your empty keys turn into empty strings along the way. ie If you have the following document: --- : foo bar: baz And load it into memory using a stock no-frills Perl loader, I would expect the key to load as a string (since Perl only uses strings for keys). And it might get dumped as: --- '': foo bar: baz And that's ok really because it was the most right thing to do. Perl shouldn't jump through hoops to preserve every pedantic semantic (heh), since there isn't a shred of schema assistance attached. > It doesn't matter that the Ruby loader uses a different "cave drawing" > than the Perl loader to represent each node. If the Ruby loader emits a > "different" document, than it isn't really working properly. For > example, if I write a YAML pretty-printer in Ruby, it would be very bad > if it changed the document semantics. Of course it would. I agree with this and everything else below. >=20 > > > > *Unless* there is a schema associated with the=20 > > > > document. Or=20 > > > > unless the classes in Perl and in Python have been=20 > > > > designed to work=20 > > > > with each other. Which is really a different form of a=20 > > > > "schema" or "contract". >=20 > A schema helps in two ways. First, if the Ruby loader fails to preserve > all the information required by the YAML spec, but the specific schema > doesn't ever use the lost information (e.g., never uses implicit > typing), then the application is still "valid YAML", even though the > loader isn't. I expect this to be rather rare, though. >=20 > Second, and more importantly, you must agree on a schema/contract in > advance if you want a YAML document generated by Perl to load into > "meaningful" Ruby - that is, into "compatible" classes with "the same" > semantics. In fact this holds when transferring a document between any > two different processing systems. >=20 > Brano Tich=FD asked: > > > i found several schema proposals at=20 > > > http://yaml.freepan.org/index.cgi?SchemaProposals, > > > but is there any plans to have standard way to attach schema to=20 > > > document? or is this again application specific? >=20 > Yes and no. Like Brian said: >=20 > > There will most likely be conventions that arise, and that=20 > > YAML-core endorses. > >=20 > > Take a sample document: > >=20 > > --- !ingy.net,2004/floozle > > date: 1/2/2004 > > name: Duck Soup >=20 > The !ingy.net,2004/floozle tag is the standard YAML way to associate a > schema with the document. However, all the YAML gives you is a URI - > globally unique identifier - for the schema. It does not specify the > mechanism by which you convert this URI into whatever concrete form you > expect the schema to take. >=20 > This is intentional. There is a range of concrete forms the schema may > take - human-readable documents, various declarative languages for > verification, and even code libraries that may be loaded dynamically for > processing the document. Similarly, there is a range of mechanisms that > may be used to locate the concrete schema - using protocols such as http > or ftp, accessing a database, and so on. Inevitably, different > applications running in different systems will have different choices of > the format and mechanism. It may even be that the same application may > use multiple mechanisms simultaneously (e.g., fetching separate > "verification schema" and "loading schema"). >=20 > That's why the schema tag is a UR*I*, rather than a UR*L* - it merely > *identifies* the schema, it does not *locate* it. >=20 > > I'm sure Clark and Oren have ideas on how this might work. >=20 > I have a lot of ideas on how schema location may work, but I firmly > believe it is outside the scope of the YAML standard itself. >=20 > Have fun, >=20 > Oren Ben-Kiki >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@be...> - 2004-02-25 22:22:01
|
Brian wrote: > I agree with you in principle. My point was more along the > lines of a practical scenario. If you pass empty keys around > between implementations without explicit typing or some kind > of schema, you are basically playing "fast and loose" with > YAML, and shouldn't be surprised if your empty keys turn into > empty strings along the way. I would not be playing "fast and loose" with YAML, it would be the loader that does that. It is the same thing as if it has changed the following document: --- false: 12 ... Into this one: --- "false": "12" ... > And that's ok really because it was the most right thing to > do. Perl shouldn't jump through hoops to preserve every > pedantic semantic (heh), since there isn't a shred of schema > assistance attached. Well... Granted that it wouldn't break things _often_. I'd still like to see at least a "pedantic" flag that would require the Perl loader to fully preserve the "full" YAML semantics, regardless of a schema. Whether or not this flag would be "on" by default, well, I guess that depends on how much it would cost the application to use it. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-02-26 04:16:37
|
This isn't so cut and dry. The distinction between 'plain' and 'quoted' scalars isn't in the YAML Representation, so it need not be preserved. Correct? On Thu, Feb 26, 2004 at 12:19:52AM +0200, Oren Ben-Kiki wrote: | I would not be playing "fast and loose" with YAML, it would be the | loader that does that. It is the same thing as if it has changed the | following document: | | --- | false: 12 | ... | | Into this one: | --- | "false": "12" | ... I don't see the problem. This is all schema specific stuff, I mean, wart handling specific (*grins*) -- its the price we pay for not wanting two types of scalars. Unless, well, unless we want to make the wart a bit more offical and add an additional "kind", giving us: MAP, SEQ, PLAIN SCALAR, NON-PLAN SCALAR. And then, due to the tag implies kind association, one can't use both !int "23" and 23. It's a wart. We can't have it both ways. Either it is significant and we must maintain the distinction (not a good option), or it is not signficant and if someone uses it to 'indicate' something then, well, they risk having that distinction lost. Best, Clark |
From: Oren Ben-K. <or...@be...> - 2004-02-26 10:10:14
|
Clark C. Evans wrote: > This isn't so cut and dry. The distinction between 'plain' > and 'quoted' scalars isn't in the YAML Representation, so it > need not be preserved. Correct? Nope. We have made the rule that the input to the tag resolution process, for a scalar node, is exactly: - The path leading to it; - The content of the scalar; - Whether it was in the plain style. It follows that this information (and only this information) must be preserved in order to keep the document "intact". > I don't see the problem. This is all schema specific stuff, Yes and No. If you know the schema, you can tell that "foo" and foo are the same and you may safely switch between them, but "12" and 12 are not the same and you must never switch between them. So, when the schema is known, there is no wart. If you don't know the schema, your only safe bet is to keep everything that was plain as plain. That's what a "compliant valid YAML processor" _must_ do. Yes, it is a wart, but only "generic" YAML tools need to deal with it. > Unless, well, unless we want > to make the wart a bit more official and add an additional > "kind", giving us: MAP, SEQ, PLAIN SCALAR, NON-PLAN SCALAR. Never. "Kind" != "Input for tag resolution". First, the "Input for tag resolution" includes the path to the node. Second, trying to unify these two concepts is unnatural and leads to much ugliness: > And then, due to the tag implies kind association, one can't > use both !int "23" and 23. It's a wart. Exactly. Hence, we must accept that "Kind" != "Input to tag resolution". Now, since obviously "Information that must be preserved" == "Input to tag resolution", we are left with the inevitable conclusion "Information that must be preserved" includes "Whether a scalar was plain or not". > We can't have it both ways. > Either it is significant It is. > and we must maintain the distinction We must (only when the schema is not known!). > (not a good option), Not good, perhaps, but better than anything else we came up with. > or it is not significant and > if someone uses it to 'indicate' something then, well, they > risk having that distinction lost. Much worse. If the distinction between plain and non-plain is not significant, then: - either an untagged quoted "12" would be an integer; - or an untagged, unquoted 12 would be a string; - or we'd have to explicitly tag all integers. All are unacceptable. Yes, requiring a (generic) YAML processor to maintain the distinction between "foo" and foo is a wart. The reason for this wart is the very context-dependent way that people read documents. If we were going after elegant syntax rather than human readability (and all its warts), we'd just be using S-expressions anyway :-) Luckily, in practice, this wart has very little effect on the implementation. Consider Perl as an example: Most applications that load documents are at least "implicitly" schema aware. Hence, when I read/write a document in Perl, it makes perfect sense to assume (by default anyway) that the document's schema is "compatible" with Perl - even if I don't completely know the schema. So, by default, YAML.pm will only use numbers and strings as implicit tags - note this applies for both input and output. YAML.pm must also allow me to specify my own tag resolution. For example, if I want all dates to load into some internal My::Timestamp class, and everything else to be loaded as strings (including an unquoted 12 - my schema has no numbers!), I should be able to ask YAML.pm to do that somehow. Again, note this applies to output as well. Now, if I want to write a generic YAML tool - say, a YAML "query" program that extracts a chunk of YAML out of a document and emits it as a separate document - I *must* preserve the distinction between plain and non-plain scalars. A trivial way to do it is to replace the parser's default tag resolution mechanism with one that loads all untagged plain scalars as "My::PlainUntagged", and dumps all such objects (and only such objects) as plain scalars. But that's just a special use case of the general "let me roll my own tag resolution" mechanism which YAML.pm must provide anyway. So, in practice, YAML.pm can just forget about plain vs. non-plain after it resolved the implicit tags. By default, on both input and output, it can assume that numbers are strings are the only implicit tags. It must also allow the application to override this default with a schema-specific set of tags. This all seems very reasonable - not a wart in sight. Have fun, Oren Ben-Kiki |
From: <in...@tt...> - 2004-02-26 19:10:13
|
On 26/02/04 12:07 +0200, Oren Ben-Kiki wrote: > Clark C. Evans wrote: > Luckily, in practice, this wart has very little effect on the > implementation. Consider Perl as an example: > > Most applications that load documents are at least "implicitly" schema > aware. Hence, when I read/write a document in Perl, it makes perfect > sense to assume (by default anyway) that the document's schema is > "compatible" with Perl - even if I don't completely know the schema. So, > by default, YAML.pm will only use numbers and strings as implicit tags - > note this applies for both input and output. > > YAML.pm must also allow me to specify my own tag resolution. For > example, if I want all dates to load into some internal My::Timestamp > class, and everything else to be loaded as strings (including an > unquoted 12 - my schema has no numbers!), I should be able to ask > YAML.pm to do that somehow. Again, note this applies to output as well. > > Now, if I want to write a generic YAML tool - say, a YAML "query" > program that extracts a chunk of YAML out of a document and emits it as > a separate document - I *must* preserve the distinction between plain > and non-plain scalars. A trivial way to do it is to replace the parser's > default tag resolution mechanism with one that loads all untagged plain > scalars as "My::PlainUntagged", and dumps all such objects (and only > such objects) as plain scalars. But that's just a special use case of > the general "let me roll my own tag resolution" mechanism which YAML.pm > must provide anyway. > > So, in practice, YAML.pm can just forget about plain vs. non-plain after > it resolved the implicit tags. By default, on both input and output, it > can assume that numbers are strings are the only implicit tags. It must > also allow the application to override this default with a > schema-specific set of tags. This all seems very reasonable - not a wart > in sight. Good recap Oren. Let me just make some clarification on YAML.pm behaviour. First of all, in Perl there really is no distinction between strings and numbers. Internally scalars are stored as char*, int, and double; but users of the language never really know about it. Scalars are dynamically cast on demand. In fact, it is non-trivial (deep magic) to tell whether a scalar of '12' is being stored as a char* or int. So the default behaviour of YAML.pm (the new upcoming one) will be to load everything as a string. ie No tag resolution (other than defaulting to !str). Beyond that, users will be able to specify classes that affect type resolution. For example if a use just says: use YAML; use YAML::int; They will get integer tag resolution. Not that this would really be useful in a pure Perl application. Now in Python, using a string as a number would raise an exception. So there is this problem. If Python passes Perl this: --- int: 12 string: '13' And Perl has integer resolution turned on, it will still dump the loaded document like this: --- int: 12 string: 13 Which when passed back to Python will blow up. That's because the Perl dumper doesn't know anything about integer types, and it can't guess either. Even the deep magic won't help because a scalar may have been cast before the dump. The only way out is to turn on a shadowing feature that keeps track of plain vs nonplain. This wouldn't really work though if the scalar value was changed and the shadow lost. It seems that the Perl application would have to have code that kept the python schema intact. ie The programmer would have to know the schema and write it up in Perl code. So there's no magic bullet for cross language sharing. Schemas will indeed be important in this use case. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-27 23:05:20
|
Brian wrote: > So the default behavior of YAML.pm (the new upcoming one) > will be to load everything as a string. ie No tag resolution > (other than defaulting to !str). OK. > Beyond that, users will be able to specify classes that > affect type resolution. For example if a use just says: > > use YAML; > use YAML::int; > > They will get integer tag resolution. Not that this would > really be useful in a pure Perl application. But it would (should) be useful for round-tripping... See below. > Now in Python, using a string as a number would raise an exception. > > So there is this problem. If Python passes Perl this: > > --- > int: 12 > string: '13' > > And Perl has integer resolution turned on, it will still dump > the loaded document like this: > > --- > int: 12 > string: 13 -1. IMVHO, if a user of YAML.pm chooses to "use YAML::int", this should affect both input *and* output. That is to say, it should cause YAML.pm to not emit in the plain style anything that would be misinterpreted as an integer (and, of course, it should emit all integers as plain scalars). Otherwise, YAML.pm isn't consistent with *itself* - doing either YNY or NYN round-tripping will fail. > The only way out is to turn on a shadowing feature that keeps > track of plain vs nonplain. This wouldn't really work though > if the scalar value was changed and the shadow lost. Isn't this exactly what "use YAML::int" does? Somehow marking some nodes as "integers" while others are "just strings"? Understandably, if the program modifies the data, it is also its responsibility to modify this shadowing/meta-data. If you want to mess with a cave drawing, you have use charcoal and get your hands dirty :-) > It seems that the Perl application would have to have code > that kept the python schema intact. ie The programmer would > have to know the schema and write it up in Perl code. It doesn't have to be a specific schema, actually. You might allow for something like "use YAML::Common" which would load "common" types - integer, float, Boolean, date... > So there's no magic bullet for cross language sharing. > Schemas will indeed be important in this use case. Having a "common" set of types would do wonders for cross-language compatibility. Of course you'd also have to allow an easy way for an application to construct and manipulate such "cave drawings" directly, in addition for allowing them to be loaded from and dumped to YAML. Have fun, Oren Ben-Kiki |
From: <in...@tt...> - 2004-02-28 03:15:33
|
On 28/02/04 01:01 +0200, Oren Ben-Kiki wrote: > Brian wrote: > > So the default behavior of YAML.pm (the new upcoming one) > > will be to load everything as a string. ie No tag resolution > > (other than defaulting to !str). > > OK. > > > Beyond that, users will be able to specify classes that > > affect type resolution. For example if a use just says: > > > > use YAML; > > use YAML::int; > > > > They will get integer tag resolution. Not that this would > > really be useful in a pure Perl application. > > But it would (should) be useful for round-tripping... See below. But the YAML::int class *can't* do automatic integer preservation... See below. > > Now in Python, using a string as a number would raise an exception. > > > > So there is this problem. If Python passes Perl this: > > > > --- > > int: 12 > > string: '13' > > > > And Perl has integer resolution turned on, it will still dump > > the loaded document like this: > > > > --- > > int: 12 > > string: 13 > > -1. IMVHO, if a user of YAML.pm chooses to "use YAML::int", this should > affect both input *and* output. That is to say, it should cause YAML.pm > to not emit in the plain style anything that would be misinterpreted as > an integer (and, of course, it should emit all integers as plain > scalars). Otherwise, YAML.pm isn't consistent with *itself* - doing > either YNY or NYN round-tripping will fail. Yes -1. It sucks but I'm stuck. YAML::int should quote numeric strings, and leave integers plain on a dump. But it just can't tell on it's own. Not practically. Perl has no concept of string, integer, and float. Everything is just a scalar. And a scalar just does the right thing. Except in our case. It doesn't know it's type. So: use YAML; use YAML::int; print Dump {int => 12, str => '13'}; Produces: --- int: 12 str: 13 To get the right thing, you'd need to do: use YAML; use YAML::int; use YAML::str; $map = {int => 12, str => '13'}; YAML::int->tag($map->{int}); YAML::str->tag($map->{str}); print Dump $map; Producing: --- int: 12 str: '13' Now that is ghastly. Basically it would do the appropriate shadowing for you. Now, there *are* ways of introspecting the state of a scalar, but it requires that I write YAML::int in C. I know, Perl sucks here. But maybe this is the right thing to do. Then I can do something like this: use YAML; use YAML::int; $map = {int => 12, str => '13'}; print Dump $map; and get: --- int: 12 str: '13' As long as I don't use $map->{str} in numeric context, or $map->{int} in string context all would be ok. Otherwise I'd need to call ->tag() on the values to ensure proper dumping. Sigh. This seems like a fragile way to do things, but it is explainable. I also hate to introduce C but I can figure that part out. (The C is easy; keeping it from hindering YAML.pm adoption is harder). > > The only way out is to turn on a shadowing feature that keeps > > track of plain vs nonplain. This wouldn't really work though > > if the scalar value was changed and the shadow lost. > > Isn't this exactly what "use YAML::int" does? Somehow marking some nodes > as "integers" while others are "just strings"? The intent of YAML::int wasn't to do any implicit marking. That doesn't really make sense since the native data might not even be coming in from YAML. The loader can definitely have a mode that shadows everything, although that would be overkill for most situations. Integers are the tough ones. Things like dates are easy because they exist in memory as date objects. ie They have a definite type. > Understandably, if the program modifies the data, it is also its > responsibility to modify this shadowing/meta-data. If you want to mess > with a cave drawing, you have use charcoal and get your hands dirty :-) > > > It seems that the Perl application would have to have code > > that kept the python schema intact. ie The programmer would > > have to know the schema and write it up in Perl code. > > It doesn't have to be a specific schema, actually. You might allow for > something like "use YAML::Common" which would load "common" types - > integer, float, Boolean, date... > > > So there's no magic bullet for cross language sharing. > > Schemas will indeed be important in this use case. > > Having a "common" set of types would do wonders for cross-language > compatibility. Of course you'd also have to allow an easy way for an > application to construct and manipulate such "cave drawings" directly, > in addition for allowing them to be loaded from and dumped to YAML. It all comes down to specific use cases. The programmer must be aware of what she is trying to accomplish, and use the right settings. There is no perfect setting that always does the right thing. Hopefully I will be able to keep the easy use cases easy and the hard use cases possible. But then again I'm a Perl programmer :) Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-28 11:14:42
|
Brian wrote: > To get the right thing, you'd need to do: > > use YAML; > use YAML::int; > use YAML::str; > $map = {int => 12, str => '13'}; > YAML::int->tag($map->{int}); > YAML::str->tag($map->{str}); > print Dump $map; > > Producing: > > --- > int: 12 > str: '13' Two questions. First: If I load the above document, using YAML::int, doesn't YAML::int call "YAML::int->tag" automatically for all the integer nodes created by "Load"? I thought that was the whole point of using it. If it doesn't do that, what _does_ it do? Second: If I use YAML::int, doesn't YAML.pm call "YAML::str->tag" for all the plain scalars that were _not_ integers? Or, alternatively, just implicitly assume on output that all scalars that are not "Something->tag"-ed are strings? It seems to me that the answer for both questions should be "yes". The semantics I suggest are: Case 0: If I don't use YAML::int or anything like that, then the parser implicitly assumes Perl semantics. All implicit scalars are loaded and dumped as strings, no tags are necessary, etc. If I load and dump the above document in this mode, '13' will be converted to 13, and that's OK. Case 1: If I use YAML::int and similar modules, then on loading the parser invokes "YAML::int->tag" for all integer nodes it creates. On output, it emits integers as plain scalars. Scalars that are _not_ shadow-tagged, and that could be misinterpreted as integers, are quoted; otherwise they may be emitted as plain. So '13' will remain quoted but 'foo' may lose its quotes. Programmatically case 0 and case 1 are just one case, where there's a list of implicit types that's empty in case 0 and non-empty in case 1. Case 2: If I use YAML::int and similar modules, but also YAML::str, then on loading the parser shadow-tags *all* scalar nodes, using either "YAML::int->tag" or "YAML::str->tag". On output, the parser complains if it encounters a node that is not explicitly shadow-tagged. It emits integers as plain scalars, and quotes all strings that would be mistaken for integers. Programmatically case 2 is almost the same as case 1 except for a additional "Croak" calls here and there verifying that all scalar nodes are properly tagged. > Now that is ghastly. What is "ghastly" is creating a document (or a value) with a non-Perl schema from scratch, or performing "major" modifications (that change the type) on a node within such a document. These require explicitly tagging the scalar nodes (in case 1, just the non-str nodes, in case 2, all the nodes). So you can't "trivially" write a non-Perl schema from a Perl program. Hardly a surprise. Read-only operations are always trivial (using case 0, or possibly case 1 if you are interested in the non-Perl schema distinctions). So is safe round-tripping. Just "use YAML::plain". It behaves like YAML::int, but unlike it, YAML::plain matches every value. Given the semantics of case 1 or case 2 above, emitting the loaded document will preserve the plain vs. non-plain status of each scalar node. This allows you to trivially write a YAML pretty printer in Perl and be 100% certain that no matter what the original schema is, the semantics will be preserved. > Sigh. This seems like a fragile way to do things, but it is > explainable. I also hate to introduce C but I can figure that > part out. (The C is easy; keeping it from hindering YAML.pm > adoption is harder). I don't see that using C will solve the problem, because it goes beyond integers (and floats). It also affects *any* type that anyone may ever decide to use as an implicit type (Booleans, prices, whatever). The only safe solution is something along the lines I described above. Which doesn't require C at all. > It all comes down to specific use cases. The programmer must > be aware of what she is trying to accomplish, and use the > right settings. There is no perfect setting that always does > the right thing. +1 on that. > Hopefully I will be able to keep the easy use cases easy and > the hard use cases possible. But then again I'm a Perl programmer :) The 3 "settings" I suggest above should do just that: Case 0 is the "Perl Native" schema case, which should be the most common (for Perl programmers, that is). It is as easy as it gets - just "use YAML.pm" and ignore shadows and tags. As you pointed out, any implicit type that is implemented as an object (e.g. dates) should work fine in this case. Case 1 is the "Lazy non-Perl" case, which should be less common. It minimizes the pain (you only tag implicit non-str types that aren't implemented as objects). For read-only applications, there's no pain at all. Using YAML::plain, it allows you to trivially implement generic YAML tools such as Y-Pretty-Print. Case 3 is the "Strict non-Perl" case, which would be the least common. It incurs the most pain (tagging all scalars), and would only be used by people doing things like schema processing that want to ensure no untagged nodes slip through the cracks of heavy structural transformations and so on. There's no C required, it satisfies the YAML spec requirements, and it basically requires only a single implementation mechanism (with a few conditional Croaks for the strict people). Have fun, Oren Ben-Kiki |
From: <in...@tt...> - 2004-02-28 18:44:18
|
On 28/02/04 13:10 +0200, Oren Ben-Kiki wrote: > Brian wrote: > > To get the right thing, you'd need to do: > > > > use YAML; > > use YAML::int; > > use YAML::str; > > $map = {int => 12, str => '13'}; > > YAML::int->tag($map->{int}); > > YAML::str->tag($map->{str}); > > print Dump $map; > > > > Producing: > > > > --- > > int: 12 > > str: '13' > > Two questions. > > First: If I load the above document, using YAML::int, doesn't YAML::int > call "YAML::int->tag" automatically for all the integer nodes created by > "Load"? I thought that was the whole point of using it. If it doesn't do > that, what _does_ it do? YAML::int is intended to load a YAML implicit integer as a real Perl integer. And doing this is almost pointless from a Perl applications point of view. I suppose you're right, it should shadow all the loaded integers. But this doesn't help the N->Y case. Example: use YAML; use YAML::int; print Dump {int => 12, str => '13'}; yields: --- int: 12 str: 13 To get the desired result I can do one of two things: 1) I can force the programmer to call YAML::int->tag on the integers. 2) I can use C to determine if the scalar was stored as an integer. I kind of like 2 better, because most of the time it just works. Like in the example above it would just work. If the programmer happened to use the integer in string context, then she would have to tag it back. But for the most part it option 2 would result in less burden on the programmer. > Second: If I use YAML::int, doesn't YAML.pm call "YAML::str->tag" for > all the plain scalars that were _not_ integers? Or, alternatively, just > implicitly assume on output that all scalars that are not > "Something->tag"-ed are strings? When YAML::int (or any other YAML casting class) is used, *all* nodes are passed to it for casting. It would probably call YAML::str->tag on all the scalars that looked (regexp) like integers but actually were not (C API). And that would be a cue to the dumper to quote those strings. And untagged scalars would be emitted plain. > It seems to me that the answer for both questions should be "yes". The > semantics I suggest are: > > Case 0: If I don't use YAML::int or anything like that, then the parser > implicitly assumes Perl semantics. All implicit scalars are loaded and > dumped as strings, no tags are necessary, etc. If I load and dump the > above document in this mode, '13' will be converted to 13, and that's > OK. +1 > Case 1: If I use YAML::int and similar modules, then on loading the > parser invokes "YAML::int->tag" for all integer nodes it creates. On > output, it emits integers as plain scalars. Scalars that are _not_ > shadow-tagged, and that could be misinterpreted as integers, are quoted; > otherwise they may be emitted as plain. So '13' will remain quoted but > 'foo' may lose its quotes. +1 although things that could be misinterpreted would be shadow-tagged as str. ie None of these heuristics happen at the emitter level. They are all handled by either the application or the casting classes. Here is my view of how and where things happen. For loading YAML: 0) The application loads/registers the appropriate casting classes. 1) The parser returns cooked string values, tags, and the plain- flag. 2) The loader passes each node to each casting class in order, until one of them performs a cast. The result is loaded into the graph. The casting class is allowed to perform a side-effect (like shadow- tagging) as part of the cast. For dumping to YAML: 0) The application loads/registers the appropriate casting classes. 00) The application may also perform any shadowing/tagging it deems necessary before the dump. 1) The dumper passes each node to each casting class in order, until one of them performs a cast. 11) The dumper takes into consideration, results of casts and also any shadowing done by the application; it then makes appropriate calls to the emitter. 2) The emitter takes dump calls consisting of a string value, a tag, and a plain-flag. 22) The emitter can then do heuristics to determine the specific quoting style, how it wants to uncook the string value, etc. But it must obey the plain-flag. And it should have no direct intervention with the casting classes or the application shadow tables. All that work has been done by then. Doing things this way, lets you hook a parser to a emitter with no loader or dumper involved. It is a clean separation of concepts. > Programmatically case 0 and case 1 are just one case, where there's a > list of implicit types that's empty in case 0 and non-empty in case 1. > > Case 2: If I use YAML::int and similar modules, but also YAML::str, then > on loading the parser shadow-tags *all* scalar nodes, using either > "YAML::int->tag" or "YAML::str->tag". On output, the parser complains if > it encounters a node that is not explicitly shadow-tagged. It emits > integers as plain scalars, and quotes all strings that would be mistaken > for integers. I can see what you want to accomplish, but I would want to think more about this specific manner of accomplishing it. Anyway, see below. > Programmatically case 2 is almost the same as case 1 except for a > additional "Croak" calls here and there verifying that all scalar nodes > are properly tagged. > > > Now that is ghastly. > > What is "ghastly" is creating a document (or a value) with a non-Perl > schema from scratch, or performing "major" modifications (that change > the type) on a node within such a document. These require explicitly > tagging the scalar nodes (in case 1, just the non-str nodes, in case 2, > all the nodes). So you can't "trivially" write a non-Perl schema from a > Perl program. Hardly a surprise. > > Read-only operations are always trivial (using case 0, or possibly case > 1 if you are interested in the non-Perl schema distinctions). So is safe > round-tripping. Just "use YAML::plain". It behaves like YAML::int, but > unlike it, YAML::plain matches every value. Given the semantics of case > 1 or case 2 above, emitting the loaded document will preserve the plain > vs. non-plain status of each scalar node. This allows you to trivially > write a YAML pretty printer in Perl and be 100% certain that no matter > what the original schema is, the semantics will be preserved. > > > Sigh. This seems like a fragile way to do things, but it is > > explainable. I also hate to introduce C but I can figure that > > part out. (The C is easy; keeping it from hindering YAML.pm > > adoption is harder). > > I don't see that using C will solve the problem, because it goes beyond > integers (and floats). It also affects *any* type that anyone may ever > decide to use as an implicit type (Booleans, prices, whatever). The only > safe solution is something along the lines I described above. Which > doesn't require C at all. No. You're not getting it. Booleans, prices, whatever get loaded into objects. Then I can key off the object class to determine what to do. But the Perl SV is a differnt animal. It's three types in one, and you can't tell it's state without going to C. And even if you go to C and find out, you have to *assume* that since the application last used this value as a string, then it was meant to be *typed* as a string. > > It all comes down to specific use cases. The programmer must > > be aware of what she is trying to accomplish, and use the > > right settings. There is no perfect setting that always does > > the right thing. > > +1 on that. And I'm not sure that boiling everything down to 3 use cases today, is really worth the cycles. Let's just see what use cases arise. > > Hopefully I will be able to keep the easy use cases easy and > > the hard use cases possible. But then again I'm a Perl programmer :) > > The 3 "settings" I suggest above should do just that: > > Case 0 is the "Perl Native" schema case, which should be the most common > (for Perl programmers, that is). It is as easy as it gets - just "use > YAML.pm" and ignore shadows and tags. As you pointed out, any implicit > type that is implemented as an object (e.g. dates) should work fine in > this case. > > Case 1 is the "Lazy non-Perl" case, which should be less common. It > minimizes the pain (you only tag implicit non-str types that aren't > implemented as objects). For read-only applications, there's no pain at > all. Using YAML::plain, it allows you to trivially implement generic > YAML tools such as Y-Pretty-Print. > > Case 3 is the "Strict non-Perl" case, which would be the least common. > It incurs the most pain (tagging all scalars), and would only be used by > people doing things like schema processing that want to ensure no > untagged nodes slip through the cracks of heavy structural > transformations and so on. > > There's no C required, it satisfies the YAML spec requirements, and it > basically requires only a single implementation mechanism (with a few > conditional Croaks for the strict people). > > Have fun, > > Oren Ben-Kiki > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@be...> - 2004-02-28 22:50:12
|
Brian wrote: > Here is my view of how and where things happen. > > For loading YAML: +1 > For dumping to YAML: +1 > Doing things this way, lets you hook a parser to a emitter > with no loader or dumper involved. It is a clean separation > of concepts. +1 > No. You're not getting it. Booleans, prices, whatever get > loaded into objects. Then I can key off the object class to > determine what to do. Hmmm. I'm uncomfortable with loading a Boolean to a Perl object. I sort of assumed it is best to load booleans to '' and 1 (and shadow them as Booleans). Can I still simply write ``if($foo)'' if the value of ``$foo'' is (a reference to) an object of type Boolean? At any rate... > But the Perl SV is a different animal. It's three types in > one, and you can't tell it's state without going to C. And > even if you go to C and find out, you have to *assume* that > since the application last used this value as a string, then > it was meant to be *typed* as a string. I see where you are going with this. It actually fits neatly with the load/dump process you described. By default, you use the YAML::PerlSV "casting class", and only this class. It makes use of the Perl SV information to load/dump things as str/int/float, and is good enough "out of the box" for most Perl applications. If I specify my own "casting classes", they would be tested before YAML::PerlSV. Only if none of them match then YAML::PerlSV will be used. > And I'm not sure that boiling everything down to 3 use cases > today, is really worth the cycles. Let's just see what use > cases arise. The above is powerful enough to allow for every imaginable behavior, assuming the existence of appropriate additional "casting classes". Specifically, if there exist YAML::int, YAML::float, YAML::str (matches everything), YAML::plain (likewise) and YAML::noimplicit (matches everything and complains bitterly about it), then I can construct all of my three use cases and many more. Neat. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-02-28 00:49:55
|
I was thinking along a different line of thought, 1. We add a SCHEMA directive, which is any URL? 2. Plain scalars are forbidden in YAML documents which do not have a SCHEMA directive. 3. If your processor does not know the SCHEMA it must preserve the distinction between plain or not plain. We leave what "SCHEMA" means to a different specification. Thoughts? Clark On Sat, Feb 28, 2004 at 01:01:41AM +0200, Oren Ben-Kiki wrote: | Brian wrote: | > So the default behavior of YAML.pm (the new upcoming one) | > will be to load everything as a string. ie No tag resolution | > (other than defaulting to !str). | | OK. | | > Beyond that, users will be able to specify classes that | > affect type resolution. For example if a use just says: | > | > use YAML; | > use YAML::int; | > | > They will get integer tag resolution. Not that this would | > really be useful in a pure Perl application. | | But it would (should) be useful for round-tripping... See below. | | > Now in Python, using a string as a number would raise an exception. | > | > So there is this problem. If Python passes Perl this: | > | > --- | > int: 12 | > string: '13' | > | > And Perl has integer resolution turned on, it will still dump | > the loaded document like this: | > | > --- | > int: 12 | > string: 13 | | -1. IMVHO, if a user of YAML.pm chooses to "use YAML::int", this should | affect both input *and* output. That is to say, it should cause YAML.pm | to not emit in the plain style anything that would be misinterpreted as | an integer (and, of course, it should emit all integers as plain | scalars). Otherwise, YAML.pm isn't consistent with *itself* - doing | either YNY or NYN round-tripping will fail. | | > The only way out is to turn on a shadowing feature that keeps | > track of plain vs nonplain. This wouldn't really work though | > if the scalar value was changed and the shadow lost. | | Isn't this exactly what "use YAML::int" does? Somehow marking some nodes | as "integers" while others are "just strings"? | | Understandably, if the program modifies the data, it is also its | responsibility to modify this shadowing/meta-data. If you want to mess | with a cave drawing, you have use charcoal and get your hands dirty :-) | | > It seems that the Perl application would have to have code | > that kept the python schema intact. ie The programmer would | > have to know the schema and write it up in Perl code. | | It doesn't have to be a specific schema, actually. You might allow for | something like "use YAML::Common" which would load "common" types - | integer, float, Boolean, date... | | > So there's no magic bullet for cross language sharing. | > Schemas will indeed be important in this use case. | | Having a "common" set of types would do wonders for cross-language | compatibility. Of course you'd also have to allow an easy way for an | application to construct and manipulate such "cave drawings" directly, | in addition for allowing them to be loaded from and dumped to YAML. | | Have fun, | | Oren Ben-Kiki | | | | ------------------------------------------------------- | SF.Net is sponsored by: Speed Start Your Linux Apps Now. | Build and deploy apps & Web services for Linux with | a free DVD software kit from IBM. Click Now! | http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: <in...@tt...> - 2004-02-28 02:51:04
|
On 27/02/04 19:47 -0500, Clark C. Evans wrote: > I was thinking along a different line of thought, > > 1. We add a SCHEMA directive, which is any URL? > 2. Plain scalars are forbidden in YAML documents which > do not have a SCHEMA directive. > 3. If your processor does not know the SCHEMA it must > preserve the distinction between plain or not plain. > > We leave what "SCHEMA" means to a different specification. > > Thoughts? Where do you get your weed from? Must be good stuff! ;) Cheers, Brian > > Clark > > On Sat, Feb 28, 2004 at 01:01:41AM +0200, Oren Ben-Kiki wrote: > | Brian wrote: > | > So the default behavior of YAML.pm (the new upcoming one) > | > will be to load everything as a string. ie No tag resolution > | > (other than defaulting to !str). > | > | OK. > | > | > Beyond that, users will be able to specify classes that > | > affect type resolution. For example if a use just says: > | > > | > use YAML; > | > use YAML::int; > | > > | > They will get integer tag resolution. Not that this would > | > really be useful in a pure Perl application. > | > | But it would (should) be useful for round-tripping... See below. > | > | > Now in Python, using a string as a number would raise an exception. > | > > | > So there is this problem. If Python passes Perl this: > | > > | > --- > | > int: 12 > | > string: '13' > | > > | > And Perl has integer resolution turned on, it will still dump > | > the loaded document like this: > | > > | > --- > | > int: 12 > | > string: 13 > | > | -1. IMVHO, if a user of YAML.pm chooses to "use YAML::int", this should > | affect both input *and* output. That is to say, it should cause YAML.pm > | to not emit in the plain style anything that would be misinterpreted as > | an integer (and, of course, it should emit all integers as plain > | scalars). Otherwise, YAML.pm isn't consistent with *itself* - doing > | either YNY or NYN round-tripping will fail. > | > | > The only way out is to turn on a shadowing feature that keeps > | > track of plain vs nonplain. This wouldn't really work though > | > if the scalar value was changed and the shadow lost. > | > | Isn't this exactly what "use YAML::int" does? Somehow marking some nodes > | as "integers" while others are "just strings"? > | > | Understandably, if the program modifies the data, it is also its > | responsibility to modify this shadowing/meta-data. If you want to mess > | with a cave drawing, you have use charcoal and get your hands dirty :-) > | > | > It seems that the Perl application would have to have code > | > that kept the python schema intact. ie The programmer would > | > have to know the schema and write it up in Perl code. > | > | It doesn't have to be a specific schema, actually. You might allow for > | something like "use YAML::Common" which would load "common" types - > | integer, float, Boolean, date... > | > | > So there's no magic bullet for cross language sharing. > | > Schemas will indeed be important in this use case. > | > | Having a "common" set of types would do wonders for cross-language > | compatibility. Of course you'd also have to allow an easy way for an > | application to construct and manipulate such "cave drawings" directly, > | in addition for allowing them to be loaded from and dumped to YAML. > | > | Have fun, > | > | Oren Ben-Kiki > | > | > | > | ------------------------------------------------------- > | SF.Net is sponsored by: Speed Start Your Linux Apps Now. > | Build and deploy apps & Web services for Linux with > | a free DVD software kit from IBM. Click Now! > | http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > | _______________________________________________ > | Yaml-core mailing list > | Yam...@li... > | https://lists.sourceforge.net/lists/listinfo/yaml-core > > -- > Clark C. Evans Prometheus Research, LLC > Chief Technology Officer Turning Data Into Knowledge > cc...@pr... www.prometheusresearch.com > (main) 203.777.2550 (cell) 203.444.0557 > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Zenaan H. <ze...@fr...> - 2004-02-28 04:19:06
|
On Sat, 2004-02-28 at 11:47, Clark C. Evans wrote: > I was thinking along a different line of thought, > > 1. We add a SCHEMA directive, which is any URL? URIs please, not URLs. cheers zen |
From: Oren Ben-K. <or...@be...> - 2004-02-28 10:20:04
|
Zenaan Harkness wrote: > On Sat, 2004-02-28 at 11:47, Clark C. Evans wrote: > > I was thinking along a different line of thought, > > > > 1. We add a SCHEMA directive, which is any URL? > > URIs please, not URLs. Yeah, as Brian noted Clark was somewhat high when he suggested that :-) We already have a way to associate a schema URI with a document - just tag the root node. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@be...> - 2004-02-19 22:39:54
|
Bra=F2o Tich=FD wrote: > I think explicitly written null could only enhance=20 > readability. Not necessarily. When filling out a form-like file: --- Name: Foo Bar Favorite food: ... Then simply not providing a value seems the simplest way to, well, not provide a value. > perhaps it could be required at least in keys? Plain keys are already a special case, true enough... And an empty key, unlike an empty value, is admittedly confusing. Hmmm. Clark, Brian, what do you think? Have fun, Oren Ben-Kiki |