Sean O'Dell wrote:
> On Tuesday 07 September 2004 11:26, David Hopwood wrote:
>>Sean O'Dell wrote:
>>>On Tuesday 07 September 2004 07:42, Clark C. Evans wrote:
>>>>Clearly, if one 'transforms' the graph on the way in, the 'schema'
>>>>is being altered, so if one wishes to round-trip, a reverse transform
>>>>on the way out would be required to convert the data structure back.
>>>>But this, once again, is an application-specific thingy.
>>>Schemas, I thought, are for validation and wouldn't alter the graph in
>>>any way. A set of transformation rules would be something different from
>>>a schema, and it would probably do nothing more than re-tag nodes, so it
>>>should be re-emittable all the way back from the fully loaded state.
In general, without having validated the graph against a schema (and as a
side effect found which nodes correspond to which schema productions), you
don't have enough information to apply a useful transformation. Maybe in
simple cases you can do a transformation just by looking at each node
individually, but that's very limited.
>>As it happens, once you have the mechanisms needed to validate a graph,
>>very little additional mechanism is needed to transform it. A schema
>>language essentially parses the graph, yielding a parse tree in which each
>>parse tree node corresponds to a graph node.
I may not have been clear: this parsing has nothing to do with parsing of
the YAML presentation. Consider a BNF grammar: it can be used to both
validate an input sequence, and (if the grammar is unambiguous) parse it
into a tree. More generally, a grammar can take a sequence, tree, graph,
or combination of these as input, and only if the data matches the schema,
output a tree that describes the data in terms of the schema productions.
A class of grammars that is particularly well-suited to this are the
Parsing Expression Grammars; see
>>At that point you have all the
>>information needed to fill in unspecified types: for each node, the schema
>>production tells you what kind of node it "should" be. In simple cases, all
>>you then need is a mapping from schema productions to tags, which is used
>>to change any unspecified tags. In more complicated cases, the API could
>>call an application-provided function depending on the production for each
IOW, parsing the graph, which is needed for validation, already does almost
everything you need in order to transform the graph.
> Actually, validation has branches and conditions that don't map very well to a
> simple transformation. The parser would do the parsing and a module
> somewhere between the parser and loader would validate the data against a
> template of conditions which determine whether or not the data is in the
> right format and values are within tolerances, and so forth.
The grammar defined using the schema language expresses the necessary branches
and conditions. Look at RELAX NG for an example:
It's not entirely suitable for YAML, but the principle is the same.
David Hopwood <david.nospam.hopwood@...>