Ok. Here are four additional proposals for this 'change set'.
#1 Change the YAML version to 1.1
This is a substantial change set, and we have lots of documents out
there that assume older semantics; the whole purpose of the directive
was to cover this case. If we bump the version to 1.1 we have the
following:
- If a 1.1 Parser runs into a 1.0 document, it can either load using
the old rules, perhaps with a warning or give the the user a
chance to load with the new rules anyway.
- If a 1.0 Parser runs into a 1.1 document, it can also issue a
warning, and load the best of its ability... probably choking
if there are tags; but clearly getting the private types wrong.
The specificaiton will "grow" an appendix describing the old
behavior, and marking it as depreciated. Really, this is 1.2 as we
should have bumped the version when we got rid of default implicit
typing... let's not make the same mistake twice.
#2 Special hook for 'YAML Type Repository' tags.
One of the main goals of YAML is allowing data to be shared across
multiple programming languages. There are several reasons why one
would want to use YAML types along with private types, and types from
other tag sets. So, to help facilitate this we propose using !! to
mark YAML tags, without needing a %TAG:yaml.org,2002: directive.
--- %TAG:clarkevans.com,2004:wibble/^cce
- !int # int
- !!int # tag:yaml.org,2002:int
- !cce^int # tag:clarkevans.com,2004:wibble/int
...
--- %TAG:clarkevans.com,2004:default/
%TAG:clarkevans.com,2004:wibble/^cce
- !int # tag:clarkevans.com,2004:default/int
- !!int # tag:yaml.org,2002:int
- !cce^int # tag:clarkevans.com,2004:wibble/int
...
This is introduced to hopefully address some of the concerns
about making it inconvient to access built-in YAML types,
and thus worries that it would hinder loading of documents
across different programming languages. The compelling use
case for this was configuration files, where most types will
be private, but some built-in types may be desired without
having to use directives.
#3 Placement and scope of directives
In YAML 1.1, directives will be a property of the stream and must
appear _before_ any document starts. They then apply to all
documents in the stream.
%TAG:clarkevans.com,2004:wibble/^cce
---
- !int
- !cce^wick
# directives are not allowed here
---
- !int
- !cce^bing
The rationale for this is that it would be tedious to find a %TAG
unless it is at the top of the document and clearly shouts that it is
magical. Not allowing it anywhere else in the document is justified
by the cost of 'hunting' down a directive. While someone may want to
'concatinate' streams, they can do so after they remove the document.
Perhaps the parser can give a _warning_ if it finds directives that
repeat previous directives, and issue an _error_ if they find a
directive that conflicts with a previous directive.
#4 Directives start in column 0
Since directives in YAML 1.1 will be "stream" items, there is
no justification for the current 'single-token' constraint placed
on them. In particular, they should start in column 0 and
extend till the end of the line. This also allows directives to
use spaces liberally, and comments.
#!/comments/are/still/allowed/here
%YAML 1.1 # this is optional
%TAG clarkevans.com,2004:wibble cce # 'cce' prefix
# comments are here as well
%TAG bytecode@.../ # default prefix
# and here
---
- !int JUMP # tag:bytecode@...
- !!int 324 # tag:yaml.org,2002:int
- !cce^int # tag:clarkevans.com,2004:wibble
This should also allow for greater clarity in what can be a
very ugly mechanism. But, at least the uglyness is a bit less
ugly and always at the top of the file in plain view.
That's it. I'm not sure if all of this is a great idea; but I
think it is on the whole "good" idea, and Oren seems to agree.
Brian has not yet seen nor agreed; so this is open for debate.
I've asked Oren to write up the next 'draft' of the changeset
assuming these are all accepted. He is the production king.
Clark
|