Brian Ingerson [mailto:ingy@...] wrote:
> > Using format-as-version is a hack that only works for collections.
> > However, it makes as much sense to version scalar type families.
> Please explain more. I don't really understand your statements.
> What else would you use a format on a class for? As the "schema"
> for an object class changes, it seems to me to be very much the
> "format" that is changing.
I wouldn't; that's why the spec doesn't allow a format for a class :-)
If we ever allow a format for a collection, it should follow the logical
separation we have established between a format and a type family: The
format is intended for indicating how to scan an object of a given type
from the node. This given type is uniquely identified by the type
Consider !type[#/]1.0 and !type[#/]2.0. They might have different
fields, different semantics when loaded, etc. They are simply not the
same type family, in the YAML sense. Assuming proper use of the version
notation, the relationship between them is similar to the relationship
between int and float - there's an overlap in the allowed values, but
the type families are not identical.
That said, an application may load a !type[#/]1.0 YAML node into a
!type[#/]2.0 native object, if it knows about version 2.0 and chooses
not to (or is unable to) use version 1.0 of the type. This would be a
very reasonable heuristic, assuming proper use of the version notation.
But it must be seen for what it is - a *transformation* of the object
type family, similar to "upcasting" an int to a float. It would require
explicit support from the type-specific loading code. Often it does not
work for very old versions (e.g., loading !type/1.0 node into a system
using version !type/10.5 - Word documents come to mind).
An application may also allow loading objects of different versions at
the same time. Code is an obvious example: a dynamically loaded library,
a browser plug-in, device drivers, kernel modules...
IMO !type/1.0 and !type/2.0 are different (related) types; the version
number therefore belongs in the type family and not in the format.