Re: [Yaml-core] Cleaning things up...

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

Brian brought up a problem with this.  What about
sub-typing.  In other words, int.I32 ?    IMHO,
inlcuding format as part of the transfer method
is a good idea.  Thus, this means we need to find
a syntax separator for the format, how about a 
semi-colon?

  !int;hex
  !int.I32;hex

Best,

Clark

On Sun, Dec 09, 2001 at 12:39:22PM -0500, Clark C . Evans wrote:
| Ok.  I think I have the solution to this irking problem!
| By transfer method, we actually have two things.  For the
| serialization, it has one or more formats (one of which
| a given value has) which is auto-detected.   For the native
| binding, we have a type family. 
| 
| How about we define a transfer method as a pair including
| both family and format?  We can then encode both of them
| as part of the transfer string by a convention.
| 
|   org.yaml.FAMILY(.FORMAT)?
| 
|   org.yaml.int            (unspecified format)
|   org.yaml.int.decimal    (default)
|   org.yaml.int.hex
|   org.yaml.int.octal
| 
|   org.yaml.binary         (unspecified format)
|   org.yaml.binary.base64  (default)
|   org.yaml.binary.baseUNI (like base64, but uses printable unicode
| 
|   org.yaml.datetime           (short for org.yaml.iso8601)
|   org.yaml.datetime.iso8601   (a limited form of iso8601)
|   org.yaml.datetime.ctime     (the standard unix ctime() call)
| 
| We can verify that all org.yaml. transfer methods have a unique
| last part to their name; so that !base64 can be short for
| org.yaml.binary.base64 -- if a non-format transfer encoding
| is used, then the parser must auto-detect the specific
| format (obvious implicit does both... type and format)
| 
| A few notes:
| 
|   0.  When a transfer method is "registered" by the
|       system; the string, format, and type family
|       must be provided.  Just beacuse we use a 
|       magic to easily split the family from the 
|       format doesn't mean that this is required.
| 
|   1.  Formats apply only to particular type families, so
|       it does make sense to use a hierarchical naming
|       convention.  Although we could use org.yaml.base64,
|       I see no real purpose in this.  It's nice to have
|       binary in the offical name given that we can have
|       the parser do the !base64 short hand in either case.
| 
|   2.  Let's keep transfer method as a single unit; even
|       though it has the type family and format components.
|       The type family component is mandatory; but the
|       format component can be optional.   I'd rather not
|       introduce a new format indicator.
| 
|   3.  Just to note; reporting the format helps in two 
|       ways:  (a) for the emitter, it would be helpful
|       for an editor to choose to output specific 
|       integers as hex (colors for example); and
|       (b) for the loader, it would be cool if the
|       parser can give the exact format of the string
|       to the loader so that it can be sucked-in
|       more efficiently
| 
| Ahh.  Been pulling my hair out with this one lately.   
| What do you both think?   
| 
| ...
| 
| On a related theme, I've come up with the final
| names for the three information models described
| in the concepts chapter.  They are
| 
|    graph     This is kinda the "native model"
|              but basically is the simplest
|              model of YAML.  It includes
|              type family, but not format.
| 
|    tree      This is the flattened graph.
|              It also has family, but not
|              format
| 
|    syntax    This has serialization specific
|              items:  leaf style, format,
|              comments
| 
| Note an API may mix all three models... or
| more likely involve inheritance; the graph
| is realized as a tree, and the syntax is
| an enhancement of the tree.
| 
| In this model, transfer method becomes a 
| word used to refer to family and/or format
| and is specifically bound to the serialization.
| 
| I think this will clean things up significantly.
| 
| Best,
| 
| Clark
| 
| _______________________________________________
| Yaml-core mailing list
| Yam...@li...
| https://lists.sourceforge.net/lists/listinfo/yaml-core

-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525 
XCOLLA Collaborative Project Management Software