Re: [Yaml-core] Open Issues

[Clark C . E. <cc...@cl...>]

On Mon, Nov 12, 2001 at 10:49:47PM +0200, Oren Ben-Kiki wrote:
| - Scalar forms. I summerized the new proposal, which requires 5 separate
| scalar types. We can go with it, keep things as they are today, or try to
| simplify it further.

How about...

block: |
 This is a block scalar (no implicit or escaping),
 it is very simple no suprises.  WYSIWYG
folded: \
 This is a folded scalar (no implicit or escaping)
 it is very simple, no suprises (other than the
 line folding propery).
other:
 - We throw everything else into the third form.
 - It can be single line as above, or it
  can wrap on to the second line like this one.
 - "it can be single ' or double \" quoted.\n
  Also, this form can be implicit, as the next
  the next one shows..."
 - 345

In this way, "other" is almost identical to the
"key" syntax, only that multiple-line unquoted
scalar is not allowed.   Further, the "key"
syntax is probably what will be used in YPATH.

| - References. OK, Alias != Pointer. Fine. Now, how does YAML serialize
| "\$a->[0]"? I posted an example showing why this is hard (and how
| Data::Dumper gets it wrong). I also showed how it can be done given some
| creative use of the '!ref' type. We need to decide on this.

Since it appears Perl is kinda "broken" here... Brian?
The Perl version could just treat it as one
would expect from seralizing C, where access
to a member of an array doesn't imply knowedge
of the array.  This way Pointers are dumb, and
can probably transfer to other langauges that 
have pointer mechanism.  

That said, if the construct described would be 
serialized in the dumb way... is it consistent?
If so, then i'd say do a dumb serialization
(without the array knowleege) and issue a warning
if such monsters are encountered.  This one is
squarely in Brian's domain.

| - Info model. If Clark comes up with a reformulation of 
|   the info model that JAP can grok, I'd be happy to include 
|   it into the spec, and more than happy to re-work the simpler
|   productions :-)

Great. 

| - Pipelining. Let's leave it out for now - right?

Base64 is the only use case... it'd be nice to have
a cleaner solution for this though.  Perhaps it's best
just to include base64 methods and let the user handle
the issue...
 
| - YPATH, APIs. Let's not go there yet.

Ok.  However I don't think we can move to "release canidate"
till some of the APIs are worked out, in case there is
some inconsistency we need to fix-up.

| At any rate, we are very close. Let's finish it.

+1

Clark