Re: "YAML Easy Schemas"

On Jun 27, 10:03 pm, Peter Murphy <[email protected]> wrote:
> Trans,
>
> Thank you for putting the work into developing a schema language for YAML.

Much obliged :-)

> I do have one quibble. Where exactly is the spec for YPath? Most
> people would be interested in finding all nodes with a given tag
> property, and validating for that - but I can't even find how to do
> that in the language.

I share your quibble! YPath is not all that well defined and has never
really gotten past experimental implementations it seems. Eventually
someone really needs to take the reigns here and hammer out "YPath2",
so to speak and get YAML implementors on board to support it. --
Surely someone out there would enjoy taking up this project!?

> I want to try and see if I understand your spec by trying it against
> the "Invoice" example in the YAML spec:

Very good idea!

> http://www.yaml.org/spec/1.2/spec.html#id2761803
>
> There are a few comments, which indicate possible directions for the
> schema. All mistakes are mine. Example goes:
>
> ---
> /[YPath expression for all nodes of tag <tag:clarkevans.com,2002:invoice>]:

Do't think that is possible at this point. Not even sure what an
acceptable YPath would be to select by tag.

>   invoice: &mandatoryint
>      type: int
>      required: true #Shouldn't we use booleans like true and false?

If I recall correctly, true, false, yes and no parse as boolean
values.

>   date:
>      type: datetime #Indicate somehow that dates are required, but
> times are not?

yes, I am working to make types a bit more flexible than just the
standard types (http://yaml.org/type/index.html).

>      required: true
>   bill-to: &billing-schema-alias
>      type: map
>      required: true
>      value: # We could refer to this by Ypaths, but it feels more
> natural to embed in it the parent structure schema

Interesting idea. I will have to think about this.

>        given: &amms # Short for "All Mandatory Strings Schema"
>          type: str
>          required: true
>        family: *amms
>        address:
>            type: map
>            required: true
>            value:
>                lines: *amms
>                city: *amms # Or suburb.
>                state: &aoss # Short for "All Optional Strings Schema"
>                    type: string
>                    required: false # Not every country has states or provinces.
>                country: &aoss # Unnecessary if posting in the same country.
>                postal: &aoss # Some countries don't use postcodes.
>   ship-to: *billing-schema-alias # Yay for anchors and aliases!
>   tax: &currency # Should indicate two decimal places - no more, no less.
>     type: float
>     required: true

it would be interesting if we could specify precision. also, maybe it
could support a Cobol like PIC matcher?

>   total: *currency
>   comments: *amms
>   product:
>       type: seqorsing: # See below
>       required: true
>       value:
>         sku: *amms
>         quantity: *mandatoryint
>         description: *amms
>         price: *currency
> ...
>
> I've probably made some indentation mistakes in typing in YAML, but
> you get the gist. I think it is more natural to add a value property
> to indicate the type of a mapping value, rather than use Ypath
> expressions to refer to them.

You might be right. I originally thought that it all should be one
level deep as that would make it much simpler. But I can see how the
layering the schema in this way is somewhat more intuitive. And I was
considering how to do sub-paths, which is basically the same thing.

Hmm... How would `value` be used for a scalar?

> I also like the use of anchors and
> aliases to save me typing in the same thing.

Indeed, that a big plus I have been discovery too.

> One more thing. In the original invoice example, "product" is a
> sequence of separate products (in this case, 2). But if there is only
> one product, is it necessary to express it as a sequence of one
> product? Wouldn't it be more natural to let the user express it as a
> single value in that case? I thought adding a type "seqorsing"
> (sequence or singleton) would allow schema designers to validate
> documents like this, while saving YAML writers a little bit of work.

Ha "seqorsing" funny word :-)

if that is what your format will accept it can do that. But I think it
would be better to express this in the schema through some sort of
conditional logic --some way to say this value OR that value. But I am
not sure how yet. Maybe it has to be something like:

  product:
      required: true
      either-or:
        - type: map
          value: &product-value-schema
            sku: *amms
            quantity: *mandatoryint
            description: *amms
            price: *currency
        - type: seq
          value: &product-value-schema
...

Thanks for all this great feedback, btw!  I think YES is really
shaping up to be an awesome schema for YAML. I think the only real
roadblock is a solid YPath.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2