Brian Ingerson wrote:
> > BTW, These are all one way "Loader" transfers. You don't preserve
> > and
> > "Store" these things. The Loader has the choice of performing the
> > transfer or
> > preserving the original data along with the transfer type.
> *All* transfers are "loader" transfers. You are right about the
> OK use whatever semantics you want, but most transfers can roundtrip,
> while these cannot. (ie a dumper can't produce a "!include file" node if
> that node was transfer with the contents of the included file)
Let me rephrase...
The key observation is that a loader may not change the model. On the
So, by definition, the loader *must* round trip !include nodes. It is the
application module which is *changing* the graph model by applying a filter
which replaces this "!include" node with a node obtained from the
For convenience this changing-the-model-operation filter may be offered by a
loader implementation... but it still isn't a loading operation under our
definition, and would require an explicit parameter to activate (IMVHO).
Example: A YTL engine getting a pattern for manipulating the "!include"
nodes - say, changing the included paths from directory A to directoy B or
whatever. If expanding !include was considered a parsing or loading
operation, you'd have to twist your brain around the explanation for why it
isn't being expanded in this case.
If you consider expansion of includes to be a (*logically*) post-loading
filter, then things are perfectly simple: the YLT engine doesn't call the
filter. In fact, since applying filters is an application-level decision, it
becomes trivial to provide ways for some includes to be expanded and for
some not to be. Remember XSLT's problems with applying itself to XSLT input?
Another example would be application flags that specify the root for
relative included URLs; controlling whether an unfound included file stops
parsing or continues with a null value; etc. etc. All these are a big issue
if you consider them to be a loading issue and easy if they are considered a
> > Hmmm. I always thought the parser should get its list of implicit
> > types from
> > the outside... Basically, told by the loader which types the loader
> > can handle.
> Huh? How? Is our parser going to be required to have an emmbedded regex
> engine? How are we going to pass in implicit types on the fly?
I expect there would be several types of YAML systems:
Fixed schema: Treats as an error any unknown type. The parser/loader there
is hard-wired - probably they'd be merged into a single module.
Such implementations may be used in embedded devices, special-purpose
I want to ensure that a fixed-schema system is not required to handle
anything beyond !str, !map and !seq to be considered valid YAML. Here's no
point in requiring more: such systems know exactly what the input schema is,
and if it is only these three, why label them non-compliant?
Extendible scheme: Allows the addition of application defined types. The
parser/loader there must provide, as you point out, a regexp engine (or,
adding a new type requires you to provide a "doesMatchMyType()" method).
Such systems would be used for creating YAML frameworks; they make writing
YAML applications much easier, at the cost of a heavier library. I expect
most actual YAML systems would be built around this sort of framework.
Again, the minimal set of built-in types for such a system is !str, !map and
!seq. All other types can be added by the application. Of course I'd expect
a reasonable implementation to provide you with the code necessary to
implement many other types, most important of which would be the types
defined in the core spec, yaml.org, etc. - but the application still
controls which of these is actually used.
No schema: Allows any valid YAML to be processed. This means that it mostly
gives up on loading; instead it encodes the transfer method in some way that
round-trips it (special keys are one way to do so).
Of course a no-schema system may support some types without encoding like a
fixed-schema system and may even allow this set to be extended like an
extendible-schema system. In fact it makes perfect sense to build the
no-schema system on top of an extendible-schema system, from a software
engineering point of view.
This sort of systems would be needed for things like YTL, YAML editors etc.
Some of them may work at the syntax or tree level...
At any rate, it makes no sense to "require" any transfer types for a
no-schema system because all transfers are supported.
> > As for which types go into the spec and which don't, my reasoning is
> > that
> > the YAML spec should be "sufficient" for "most" applications.
> OK. Well I think !include will be a cornerstone so please add it.
I'd really rather not. Not because you can't make the case it isn't basic -
I don't quite agree, but you could make a convincing case. The reason I
don't want to add it is because it is too complex to specify properly. To
add it you'd need to specify YPATH first; there's the question of error
I think that YPATH would be the next thing on our spec agenda - it is even
more useful than schema, IMO. We should keep in mind !include as a use case
when we discuss it. When we are done, we can decide where/how to add
!include to the list of sanctioned types. If we want to add it to the core
at that time, fine.
In the mean while I see no problem with implementing !include-doc and
!include-seq (or better names) that work when given a URL (without a
fragment) and do the expected thing... Just make expanding them an option (I
don't much care what the default setting is, as long as the setting is under