[Yaml-core] RE: irc

[Oren Ben-K. <or...@ri...>]

Clark C . Evans [mailto:cc...@cl...] wrote:
> I'd like to put this off for some time, I'm
> just way too behind on my day job.   

I guess so...

> I'm not convinced of the use case for this
> feature... it only applies to Oren's 
> embedding of Minimal XML (a very small
> subset). 

Forget XML, I was thinking about the general case. I found myself using it a
lot when I tried to cast postings into YAML.

For example, the list of issues I have with your posting about the draft:
 - Type family vs. format: OK.
 - Only syntax has format: not OK.
 - Default *input* int format is 'decimal: not OK.
 - Default *output* int format is 'decimal': OK.
 - Equality based on default *output* format: OK.
 - Type family round trips: OK.
 - Format round does not round trip: OK.
 - Parser passing a pair: not OK.
Instead:
- The tree model should have the format property.
- The default *input* format  of an int is "auto detected".
- The parser should give the loader a triplet (transfer, format, value).

Otherwise the tree model is good as dead. Nobody in his right mind would
implement the 'int' transfer method as converting '0xA' to '10' and only
then to the integer 10. The same trick would be done for every transfer
method. Hence every sane implementation would simply skip the tree model.
Yuck.

What is wrong with using a triplet there?

As for adding the date/time formats. They are not directly supported by any
of our target languages (except *perhaps* for Java). Also, are we settled on
the exact format to use?

timestamp: YYYY-MM-DD HH:MM:SS.SSSSS+HH:MM
date: YYYY-MM-DD
time: HH:MM:SS.SSSSS+HH:MM
duration-seconds: HH:MM:SS.SSSSS
duration-days: YYYY-MM-DD
duration-time: YYYY-MM-DD HH:MM:SS.SSSSS

As in:

estimated-work: 0000-02-14 (months and two weeks)
time to impact: 00:00:01.5 (a seconf and a half)

Date and time are *trouble*. And you forgot currency, which is also touble
:-) I'd rather keep them at a separate spec. We'd all be surprised how long
it would end up being ;-)

Brian Ingerson wrote:
> | I would like to irc at some point to discuss allowing the 
> | collapsing of a
> | sequence entry that is a map.

OK. I'm now in EST in NY, and am available evenings for IRC.

> | ---
> | - foo: bar
> |  moo: mar
> |  too: far
> | ...
> | 
> | I think it can really be as simple as always allowing it in 
> | every case, but
> | to not have it as a standard emmission.

Hmmm. Now if we were using two spaces for indentation :-)

> | ---
> | #a complicated one
> | - !map &001 ? ! &002 \
> |   multi line
> |   key

Ugh!!! I'd rather give up on the whole idea first. There's simply no point
to allowing this.

Have fun,

	Oren Ben-Kiki