Re: [Yaml-core] Agreement at last?

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

On Thu, Aug 09, 2001 at 03:14:10PM +0200, Oren Ben-Kiki wrote:
| > It's not obvious.  I'd just rather throw an error
| > if the user can't support an integer. It's not like
| > the above data structure is even going to be remotely
| > useable to the application programmer anyway.
| 
| Strong disagreement. It is very usable for a large
| class of applications - generic, schema independent
| applications: Y-Grep, Y-Digital-Sign.,Y-Pretty-Print,
| Y-Word-Count, Y-Transform, Y-Editor, Y-Diff, Y-Merge,
| Y-Browse... I *want* these to be possible.

Right, and I'm with you here.  Chances are these items
will be written without trying to convert the YAML
into a native data structure... but they will also
be done with full knowledge of the YAML information
model.  Perhaps using the sequential access interface.

And in this case, the sequential access interface
will have a type attribute on each node; so no
rewrite is required.  It is not necessary that the
sequential interface knows the details of the given
class/type if all it is doing is moving the node
around... this even applies to a unknown typed
node...  there just isn't a problem here.

It's the native access that is the problem.  I'd
like the warnings to occur when one tries to
"cast" a YAML stream into native data structures,
but one or more types is not found.  In this 
case, one won't be doing generic processing.


| Me: The YAML system *must* expand unrecognized !class as
| shorthand maps (likewise for '&', '*', '~' if it doesn't
| support them).
| 
| You: The YAML system *may* do exactly the same, but may
| also just emit a warning and strip away the data.

Or, if using an interface which supports the color
on each node... it may just emit a warning and
not strip away the type information.  This is the
generic YATL application.

| I agree! Anyone who is knowingly throwing away data when
| there's an alternative is within his rights. As long as
| he doesn't call it round trip :-)

Right.  Or, they may do the round-trip at the
application level, where the appliction programer
preserves the data structures.  For instance,
let's assume the tuple type:

  (2,3): hello
  (3,4): baby

In this case, the perl programmer may say, 
"well, for purposes of my work, I can treat
 the keys as strings with no loss of generality"

| So, the proposed compromise:
| 
| - The YAML data model would be a graph of nodes,
|   each node is a null or a map, list, reference, or scalar,
|   each non-null node having a type.
| 
| - This model may be serialized to text:
| 
| node: !type &anchor <map/list/string>
| 
| - This model may be flattened into a pure
|   map/list/string model:
| 
| node: %
|     !: class
|     &: anchor
|     =: <map/list/string>
| 
|   This is just an alternative representation of the
|   same typed-node model, not a lower layered model.
|   Just like the serialized form is an alternative
|   form of the model. There are probably a zillion
|   other ways to represent the same model (e.g.,
|   using RDF). This one is only special in that
|   it is the "by convention" way to represent
|   the full model through REXX/Shell/etc.
|   pure map/list/string data structures.
|
| - Unquoted scalar types are subject to regexp
|   based type inference (OK, no leading alpha).
|   Using single quotes prevents this inference.
|   The set of ~ for null, *<anchor> for reference,
|   integers and floats is the "by convention"
|   set for exchanging data between modern
|   programming languages.
| 
| - An application loading the file may choose
|   to use whatever works for it. It "should"
|   try to recognize as many types as possible.
|   It is its choice whether to discard or flatten
|   unrecognized type data (Y-Diff will flatten,
|   Y-Load-Http-Config will complain and discard).
|
| Agreed?

YES.  This is a very good compromise.

Best,

Clark