Re: [Yaml-core] Modeling "mixed" content of XML using YAML

[Clark C . Evans <cce@cl...>]

On Tue, Dec 11, 2001 at 07:31:44AM -0800, Brian Ingerson wrote:
| On 11/12/01 09:19 -0500, Clark C . Evans wrote:
| > If we are willing to deal with another syntax-shorthand,
| > I'd rather assign the following...
| > 
| > ---
| > key = value
| > 
| > to mean...
| > 
| > ---
| > |: key
| > =: value
| 
| You've completely lost me. How is this a "short-hand"?

When the parser encounteres "tag =" it reports
a mapping with two keys.  A name key, and a 
value key.  The name key would be the scalar
value "tag" and the value key would be what ever
followed the equal sign, or what ever is on the
next line indented appropriately.

...

Oren wants a nice way to write a "named list"
as what is found in XML. Given the following,


<p>first paragraph</p><p>second<b>paragraph!</b></p>

He proposed that this could be written as...

---
- p: first paragraph
- p:
 - hello
 - b: world

which would be equivalent to...

---
- 
 p: first paragraph
-
 p:
  - hello
  -
   b: world

So, I call his proposal a "syntax short-hand", beacuse
it is yet another way to express mapping.

...

The problem with Oren's suggestion is that it
doesn't handle XML attributes.

<p bgcolor="red">paragraph</p><p>second<b>paragraph!</b></p>

I think a better way to write this is...

---
-
 |: p
 bgcolor: red
 =: paragraph
-
 |: p
 =: 
  - second
  - 
   |: b
   =: paragraph!


In this way, XML is loaded into YAML via a recursive
map/seq structure where the tag name is keyed by "|" 
(or any other special key, your choice) and the tag's 
value is "=".

Problem with the above, is that it isn't all that
pretty to look at (in text).  Although, it does
make alot of sense via the native interface.
So, I was proposing syntax sugar for this 
use-case (for XML mapping) so that the item above
could be written:

---
-
 |: p
 color: red
 =: paragraph
- p = 
 - second
 - b = paragraph!

In other words, those mappings that have only two
keys (= and |) could be given a nicer syntax.
What character we use for the tag name doesn't
matter (|), it could just as easily be @.

...

The advantage of this proposal over Oren's proposal
is that it handles XML attributes.  The disadvantage
is that it is a syntax-rewrite.

...

Let's just drop it... if someone wants to represent
XML as characters, let them use... XML!  Nothing
saying we can't make a simple XML2YAML converter 
using expat.

Best,

Clark

[Yaml-core] RE: irc

[Oren Ben-Kiki <orenbk@ri...>]

Clark C . Evans [mailto:cce@...] 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

Re: [Yaml-core] RE: irc

[Clark C . Evans <cce@cl...>]

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

I'm thinking of it in terms of the in-memory structure.
A map with only one entry isn't very useful, and IMHO,
probably gets in the way.  The *syntax* is nice below, 
I agree... however, I can't see why I'd ever want to
model the information in this way.  Native access would
be painful.

| For example, the list of issues I have with the draft:

(it's only a 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.

Ok.

| - The default *input* format  of an int is "auto detected".

I'd like the parser to do the detection; since each
format has a regex, this shouldn't be a problem.

| - The parser should give the loader a triplet (transfer, format,
|   value).

Ok.


| As for adding the date/time formats.


DATE and TIME are *critical* to support serializations
from relational databases and most business information.

| They are not directly supported by any of our target 
| languages (except *perhaps* for Java).

C and C++  ->  struct tm,  see output of localtime()
Python     ->  9-tuple, see output of time.localtime()
Perl       ->  array, see output of localtime()  
Java       ->  java.util.Date
SQL        =>  DATE, TIME, DATETIME 

These are classic.  Certainly there may be better 
Date/Time classes; but the above are the standard
ways to treat a date/time value.

| Also, are we settled on the exact format to use?

Subset of ISO 8601, motivated by the W3C subset 
http://www.w3.org/TR/NOTE-datetime

YYYY-MM-DD               (eg 1997-07-16)
hh:mmTZD                 (eg 19:20+01:00)
hh:mm:ss.sTZD            (eg 19:20:30.45+01:00)
YYYY-MM-DDThh:mmTZD      (eg 1997-07-16T19:20+01:00)
YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20.34.3+01:00)

As an alternative, we can allow RFC 822 style dates 
(the output of ctime function call); the only problem 
with this is that it allows for spaces.

Day Mon DD HH:MM:SS YYYY 

| duration-*

No durations, this is a big ball of mud.

Frankly, a time without a date is also slightly problematic;
but it's a problem all databases cope with and one that we
should be able to tolerate.

Clark

Re: [Yaml-core] RE: irc

[Brian Ingerson <ingy@tt...>]

On 11/12/01 02:51 +0200, Oren Ben-Kiki wrote:
> Clark C . Evans [mailto:cce@...] wrote:
> > | ---
> > | #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.

Well I can't believe I'm defending this, but here goes:

The thing I realized is that you don't need any special rules to implement
what you were asking for. Here is the entire rule:

"If a sequence entry is a map, you can always collapse the first line of the
map to the sequence line above."

Some points:

1) I'm only suggesting that we allow it. Not that we make it canonical.
2) The impementation seems painless since it's such a simple rule.
3) Due to the ? indicator, there is no ambiguity.
4) I really don't want to make this into a special case rule. If we don;t
have to, great.
5) The _recommended_ use of this would be for Oren's cases. (singletons)
5a) It would not be _recommended_ for multi entry maps.
6) I can't think of any situations that make this not work. If there are,
let's scrap it.
7) We can always add this later.
7a) As long as we don;t allow ': ' in implicit scalars (I don't think we do
now anyway)

Cheers, Brian

[Yaml-core] Modeling "mixed" content of XML using YAML

[Clark C . Evans <cce@cl...>]

If we are willing to deal with another syntax-shorthand,
I'd rather assign the following...

---
key = value

to mean...

---
|: key
=: value

Where "|" is some character we choose and
means "name", just as "=" means "value". The 
advantage of this interpretation is that it 
extends nicely to full XML.

<xml>text<tag>value</tag><tag att="val">content</tag>text
<another>more</another></xml>

xml = 
 - text
 - tag = value
 - 
  |: tag
  att: val
  =: content
 - "text\n"
 - another = more

This is far better since it gives the correct 
("complys with infoset") in-memory structure that 
you want when processing XML as YAML... a nested 
sequence of maps where the node's name and node's 
content are special keys and other keys starting
with alphabetic characters or underscore are attributes.

Clark

Re: [Yaml-core] Modeling "mixed" content of XML using YAML

[Brian Ingerson <ingy@tt...>]

On 11/12/01 09:19 -0500, Clark C . Evans wrote:
> If we are willing to deal with another syntax-shorthand,
> I'd rather assign the following...
> 
> ---
> key = value
> 
> to mean...
> 
> ---
> |: key
> =: value

You've completely lost me. How is this a "short-hand"?

Cheers, Brian

Re: [Yaml-core] Modeling "mixed" content of XML using YAML

[Clark C . Evans <cce@cl...>]

On Tue, Dec 11, 2001 at 07:31:44AM -0800, Brian Ingerson wrote:
| On 11/12/01 09:19 -0500, Clark C . Evans wrote:
| > If we are willing to deal with another syntax-shorthand,
| > I'd rather assign the following...
| > 
| > ---
| > key = value
| > 
| > to mean...
| > 
| > ---
| > |: key
| > =: value
| 
| You've completely lost me. How is this a "short-hand"?

When the parser encounteres "tag =" it reports
a mapping with two keys.  A name key, and a 
value key.  The name key would be the scalar
value "tag" and the value key would be what ever
followed the equal sign, or what ever is on the
next line indented appropriately.

...

Oren wants a nice way to write a "named list"
as what is found in XML. Given the following,


<p>first paragraph</p><p>second<b>paragraph!</b></p>

He proposed that this could be written as...

---
- p: first paragraph
- p:
 - hello
 - b: world

which would be equivalent to...

---
- 
 p: first paragraph
-
 p:
  - hello
  -
   b: world

So, I call his proposal a "syntax short-hand", beacuse
it is yet another way to express mapping.

...

The problem with Oren's suggestion is that it
doesn't handle XML attributes.

<p bgcolor="red">paragraph</p><p>second<b>paragraph!</b></p>

I think a better way to write this is...

---
-
 |: p
 bgcolor: red
 =: paragraph
-
 |: p
 =: 
  - second
  - 
   |: b
   =: paragraph!


In this way, XML is loaded into YAML via a recursive
map/seq structure where the tag name is keyed by "|" 
(or any other special key, your choice) and the tag's 
value is "=".

Problem with the above, is that it isn't all that
pretty to look at (in text).  Although, it does
make alot of sense via the native interface.
So, I was proposing syntax sugar for this 
use-case (for XML mapping) so that the item above
could be written:

---
-
 |: p
 color: red
 =: paragraph
- p = 
 - second
 - b = paragraph!

In other words, those mappings that have only two
keys (= and |) could be given a nicer syntax.
What character we use for the tag name doesn't
matter (|), it could just as easily be @.

...

The advantage of this proposal over Oren's proposal
is that it handles XML attributes.  The disadvantage
is that it is a syntax-rewrite.

...

Let's just drop it... if someone wants to represent
XML as characters, let them use... XML!  Nothing
saying we can't make a simple XML2YAML converter 
using expat.

Best,

Clark