Re: [Yaml-core] a 4-stages 3-process model

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

This was a rough straw-man.  Let me summarize the
rationale once more (I love to say the same thing
30 different ways).

   1.  Oren has pointed out that Equality, and hence
       the non-duplication necessary for a Function can
       only occur when you know the native type 
       (assuming the native type has an equality operator)

       Thus, if you try to use the non-duplication 
       constraint any earlier it's going to be somewhat
       of a hack (either a wrapper or contrived rules)

   2.  Beyond Equality, and obvious stuff like toString,
       most operators which would be useful within  YPATH
       or similar tools only happen at the Native level

   3.  Most stuff will make it to the Native model.  For
       most application processing, people will usually
       have limited types and probably have Native 
       bindings for these thingys.  If your binding
       doesn't have the proper types... one hand is
       tied behind your back and anyway, so in this
       case there is always the "generic graph" 
       model (without type resolution) to fall back on.

   4.  Duplicates in keys are actually very useful 
       for getting XML people to convert over 
       to YAML.   Once they are here, they'll want
       the full native model; and by then the circut
       will be complete.   Also, the model which
       allows duplicates is well fleshed-out as
       Minimal XML (see SML-DEV) 

   5.  So.  This leads to 4 models:

       1.  The raw syntax
       2.  The parser output  (serial)
       3.  An in-memory graph, w/o typing
       4.  A native in-memory with typing

       There is one more that I forgot,
       and that is applying typing but
       not resolving the aliases...

       5.  Events with typing

             SYNTAX
               |
             EVENTS
            /      \
        TYPED      UNTYPED
        EVENTS     GRAPH
           \       /
             TYPED
             GRAPH 

         It's kinda funny that when moving
         to a graph, you loose the key order
         (unless is is preserved) and when
         you move to typed, you can detect
         duplicates (unless you allow them).

         I guess if you wanted, you could
         have another flag to indicate if
         the two restrictions (no key order
         and no duplicates) are in-effect.
  
Hmmm.  On to Mike's questions....         

On Wed, Sep 11, 2002 at 12:33:57AM -0700, Mike Orr wrote:
| >    - When constructing a NATIVE binding for a scalar
| >      node, the conversion must be only a function of
| >      the node's character content and transfer.
| 
| Meaning, the conversion must not be a function of what?

It shouldn't be using data from nearby comments or
time-of-day, for example.  Ok.  I admit, it's a bit 
paranoid and the restriction isn't probably needed.  ;)

| >   The native representation for YAML is a graph of
| >   native objects.  Objects are either Scalar or 
| >   Collections.  Collections are functional, "mappings".
| 
| Why does the unified word Collection appear here?
| We already distinguished sequences and mappings a couple
| models ago, and I'm sure the native representation isn't 
| going to put a sequence into a dictionary.

Well, at this point each native object is going to 
know what it is... and the only really interesting
thing about a collection is that you can pass it
a key and get a value.   So in this regard lists
and maps are identical.   By not having the
list/map distinction in this model ypath and
such wouldn't have to manage the distinction.

Knowing my luck, I'm sure I can't do this...
and Oren will tear it apart (as well as
tons of other stuffs in the model)

| Any suggestions what to call the user-level tools that operate
| at each level?  We can't call them loaders/dumpers since those
| words are reserved.  How about importers (load) and exporters
| (dump).  The only problem is that "import" is a reserved word
| in some languages.

Hmm.  Not really.  I'll think on it.

Clark