From: why t. l. s. <yam...@wh...> - 2002-09-03 06:59:48
|
I've had some time to review this schema discussion some more and I'm becoming more interested in seeing this realized. And as I've thought about it, I think we could do alot by leveraging YAML and YPath. More thoughts below... Steve Howell (sh...@zi...) wrote: > Well, I thought a little bit about the OR scenario. Basically I would use a > sequence to provide a list of alternative types. > > name: Name > type: > - type: map > items: > - name: firstname > type: scalar > - name: lastname > type: scalar > - type: scalar > > Pretty ugly, huh? This would validate either of these documents: > > Name: Rolf Veen > --- > Name: > firstname: clark > lastname: evans Here's my idea of a cool schema for the above: --- #YAML:1.0 !whys/schema /: map: {} /Name: str: {} seq: /firstname: str: {} /initial: str: {} ~: {} /lastname: str: {} Okay, this may or may not make sense right off, but I find it pretty readable. Basically the root-level map contains YPath expressions as the keys. I don't know if they necessarily need to be processed in order, so I figured a regular map would work fine. Each entry in the map has a value which is a map with keys for each plausible type. The value of the nested map shows options pertinent to validating that type entry. So the above schema reads: /: map: {} 'The top level element is a map with no special options.' /Name: str: {} 'The Name key in the map can be a string...' seq: '...or a sequence...' /firstname: str: {} '...where the firstname is a string...' /initial: str: {} ~: {} '...the initial can be a string or not required...' /lastname: str: {} '...and the lastname value must be a string.' An example of options to include with a type might be stuff like allowed styles or simple grammar. For example, you could required the lastname to be in a literal block: /lastname: str: block: literal I've also thought it would be wise to allow many schema in a single file, allowing a large schema to be broken into parts: --- #YAML:1.0 !whys/schema name-schema: /: map: {} # .. rest of name schema employees-schema: /: map: {} /*: name-schema: {} > > A different thing is that if we finally have an event tree representing > > the schema, then we can build a validating parser even with the push > > parser, at least in Java. Code could be something like: > > > > YamlSchema schema = new YamlSchema("schema.yml"); > > > > try { > > Object graph = Yaml.load("aFile.yml", schema); > > } > > catch ( SyntaxException e) { ... } > > catch ( SchemaException e) { ... } > > > > The exceptions abort the parsing process. > > Or (for the above schema with several types): YamlSchemaDocument ysd = new YamlSchemaDocument( "schema.yml" ); try { Object graph = Yaml.load( "aFile.yml", ysd.getSchema( "employees-schema" ) ); } catch ... I know I've wandered quite a ways from what Steve's pitching (and it's all still just coming together in my mind today), but I think it could be powerful to use YPath to do this. You'll see a similiar idea in my YamlDiff solution: http://wiki.yaml.org/yamlwiki/YamlDiff Another grey donkey has passed, _why |