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
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.int (unspecified format)
| org.yaml.int.decimal (default)
| 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
| syntax This has serialization specific
| items: leaf style, format,
| 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.
| Yaml-core mailing list
Clark C. Evans Axista, Inc.
XCOLLA Collaborative Project Management Software