From: Trans <tra...@gm...> - 2011-06-27 05:00:51
|
Hi all, I started a new project this evening: https://github.com/rubyworks/yes It all started with a use case I had for a Schema. I gave Kwalify a whirl and it worked okay, but I wanted to be able to hack on Kwalify's code. But when I looked at Kwalify's code my eyes went all wobbly. It's complicated!!! So I gave it some thought and came up with this idea. It's pretty simple, which makes it pretty cool (IMHO). Only question is if I'll be able to work in some of the more difficult kinds of validation, but I think the odds are good. If any one has any suggestions or would like to contribute in code, please do so. And yes, maybe the name is kind of lame. I don't know. A friend of mine suggested a more direct name like `yaml-validator`. |
From: Brad B. <bm...@ma...> - 2011-06-27 13:15:37
|
Hello, FWIW, yes, I like the name. A couple of words popped out as I read the docs: s/entriess/entries/; s/spaces/newlines/; I'm not a ruby guy, so I'm not like to help with code, sorry. Quick question, though: What does a yes file for a yes file look like? Regards, Brad On Mon, Jun 27, 2011 at 1:00 AM, Trans <tra...@gm...> wrote: > Hi all, > > I started a new project this evening: https://github.com/rubyworks/yes > > It all started with a use case I had for a Schema. I gave Kwalify a > whirl and it worked okay, but I wanted to be able to hack on Kwalify's > code. But when I looked at Kwalify's code my eyes went all wobbly. > It's complicated!!! So I gave it some thought and came up with this > idea. It's pretty simple, which makes it pretty cool (IMHO). Only > question is if I'll be able to work in some of the more difficult > kinds of validation, but I think the odds are good. > > If any one has any suggestions or would like to contribute in code, > please do so. > > And yes, maybe the name is kind of lame. I don't know. A friend of > mine suggested a more direct name like `yaml-validator`. > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Trans <tra...@gm...> - 2011-06-27 15:25:41
|
On Jun 27, 9:15 am, Brad Baxter <b...@mail.libs.uga.edu> wrote: > Hello, > > FWIW, yes, I like the name. A couple > of words popped out as I read the docs: > > s/entriess/entries/; > s/spaces/newlines/; > > I'm not a ruby guy, so I'm not like to help > with code, sorry. Quick question, though: > What does a yes file for a yes file look like? Awesome question! And fun to work out, as the command line to validate was: $ yaml-yes yes.yes yes.yes :-) Simplistically it works out thus far to be: --- /*: type: map /*/type: type: str /*/required: type: bool /*/range: type: str pattern: '^\d+\.\.(\d+|n)$' /*/pattern: type: str /*/fnmatch: type: str |
From: Peter M. <pet...@gm...> - 2011-06-28 02:04:01
|
Trans, Thank you for putting the work into developing a schema language for YAML. 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 want to try and see if I understand your spec by trying it against the "Invoice" example in the YAML spec: 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>]: invoice: &mandatoryint type: int required: true #Shouldn't we use booleans like true and false? date: type: datetime #Indicate somehow that dates are required, but times are not? 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 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: ¤cy # Should indicate two decimal places - no more, no less. type: float required: true 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. I also like the use of anchors and aliases to save me typing in the same thing. 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. What are your thoughts, Trans? Best regards, Peter -- Email: pet...@gm... WWW: http://www.pkmurphy.com.au/ |
From: Trans <tra...@gm...> - 2011-06-28 05:04:11
|
On Jun 27, 10:03 pm, Peter Murphy <peterkmur...@gmail.com> 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: ¤cy # 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. |
From: Trans <tra...@gm...> - 2011-06-28 05:05:38
|
P.S. Note sure how much Syck's YPath implementation supports but here's some YPath reference: http://pyyaml.org/browser/trunk/TestingSuite/ypath.yml?rev=71 |
From: Trans <tra...@gm...> - 2011-06-28 15:47:04
|
Just occured to me that: --- /[YPath expression for all nodes of tag <tag:clarkevans.com, 2002:invoice>]: invoice: &mandatoryint type: int Would have to be: --- /[YPath expression for all nodes of tag <tag:clarkevans.com, 2002:invoice>]: value: invoice: &mandatoryint type: int which I'm not sure I care for. I get the feeling I need some other way to deal with tags. Any suggestions? |
From: Trans <tra...@gm...> - 2011-06-28 16:35:34
|
Ok. I figured out the tag thing I believe. It was simply: --- /: tag: <tag:clarkevans.com, 2002:invoice> Playing with the idea of `values' vs not using that, here are possible examples: https://gist.github.com/1051496 |
From: Ingy d. N. <in...@in...> - 2011-06-29 14:53:08
|
Hi Trans, Sorry for the late reply but I'm at a Perl conference and catching up on email. I should just mention that I've had the idea of a YeS schema language for a couple years now, but haven't gotten around to working much on it. You can see it's listed here: http://ingy.pyrl.org/ I can write more later, but the basic idea is a shallow YAML mapping something like this: +top: address address: - name - street - city - state - zip name: +str city: +str state: +state +state: [AK, IL, TX, WA] Apologies for incompleteness here... Anyway, I just wanted to point out that I've been planning on doing something with the same name for years. I sure you just stumbled on the name yourself. Maybe we can work together on it. Cheers, ingy On Mon, Jun 27, 2011 at 1:00 AM, Trans <tra...@gm...> wrote: > Hi all, > > I started a new project this evening: https://github.com/rubyworks/yes > > It all started with a use case I had for a Schema. I gave Kwalify a > whirl and it worked okay, but I wanted to be able to hack on Kwalify's > code. But when I looked at Kwalify's code my eyes went all wobbly. > It's complicated!!! So I gave it some thought and came up with this > idea. It's pretty simple, which makes it pretty cool (IMHO). Only > question is if I'll be able to work in some of the more difficult > kinds of validation, but I think the odds are good. > > If any one has any suggestions or would like to contribute in code, > please do so. > > And yes, maybe the name is kind of lame. I don't know. A friend of > mine suggested a more direct name like `yaml-validator`. > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Trans <tra...@gm...> - 2011-06-29 16:46:03
|
On Jun 29, 10:53 am, Ingy dot Net <i...@ingy.net> wrote: > Hi Trans, > > Sorry for the late reply but I'm at a Perl conference and catching up on > email. Just glad to see you are still around :-) > I should just mention that I've had the idea of a YeS schema language for a > couple years now, but haven't gotten around to working much on it. You can > see it's listed here:http://ingy.pyrl.org/ Well damn. And I thought I was so clever coming up with that name. > I can write more later, but the basic idea is a shallow YAML mapping > something like this: > > +top: address > address: > - name > - street > - city > - state > - zip > name: +str > city: +str > state: +state > +state: [AK, IL, TX, WA] > > Apologies for incompleteness here... Interesting approach. I certainly like the simplicity of it. How far can it go? Looks like it might be limited to a schema for mappings, their member types and enumerated values. More? For instance how to specify a field is required? > Anyway, I just wanted to point out that I've been planning on doing > something with the same name for years. I sure you just stumbled on the name > yourself. Maybe we can work together on it. That would be great! The reason I even got into this is b/c I have a need for a very strict YAML document format. At first I was coding a validating reader in Ruby just for the format, but then realized that my use case was exactly what a schema was meant to do. So off I went exploring the possibilities and wound up here. Short story short, I am in need of a highly capable schema that can really nail down my format. What do you think of my YPath approach? |
From: Ingy d. N. <in...@in...> - 2011-06-29 19:48:26
|
Trans, I'll review your proposal and offer a more complete version of my ideas in the next 24 hours. I have a very strong interest in the following things to happen in the next few years: - YAML Schema Language - YAML Style Language - YAML 2.0 spec - major simplification based on real world usage - JSYNC Implementations across several languages - Use a common API - Use that experience to drive a common YAML API - A book on YAML/JSON Cheers, Ingy On Wed, Jun 29, 2011 at 12:45 PM, Trans <tra...@gm...> wrote: > > > On Jun 29, 10:53 am, Ingy dot Net <i...@ingy.net> wrote: > > Hi Trans, > > > > Sorry for the late reply but I'm at a Perl conference and catching up on > > email. > > Just glad to see you are still around :-) > > > I should just mention that I've had the idea of a YeS schema language for > a > > couple years now, but haven't gotten around to working much on it. You > can > > see it's listed here:http://ingy.pyrl.org/ > > Well damn. And I thought I was so clever coming up with that name. > > > I can write more later, but the basic idea is a shallow YAML mapping > > something like this: > > > > +top: address > > address: > > - name > > - street > > - city > > - state > > - zip > > name: +str > > city: +str > > state: +state > > +state: [AK, IL, TX, WA] > > > > Apologies for incompleteness here... > > Interesting approach. I certainly like the simplicity of it. How far > can it go? Looks like it might be limited to a schema for mappings, > their member types and enumerated values. More? For instance how to > specify a field is required? > > > Anyway, I just wanted to point out that I've been planning on doing > > something with the same name for years. I sure you just stumbled on the > name > > yourself. Maybe we can work together on it. > > That would be great! > > The reason I even got into this is b/c I have a need for a very strict > YAML document format. At first I was coding a validating reader in > Ruby just for the format, but then realized that my use case was > exactly what a schema was meant to do. So off I went exploring the > possibilities and wound up here. Short story short, I am in need of a > highly capable schema that can really nail down my format. > > What do you think of my YPath approach? > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Trans <tra...@gm...> - 2011-06-30 01:33:20
|
On Jun 29, 3:48 pm, Ingy dot Net <i...@ingy.net> wrote: > Trans, > > I'll review your proposal and offer a more complete version of my ideas in > the next 24 hours. Looking forward to it. > I have a very strong interest in the following things to happen in the next > few years: > > - YAML Schema Language > - YAML Style Language > - YAML 2.0 spec - major simplification based on real world usage > - JSYNC Implementations across several languages > - Use a common API > - Use that experience to drive a common YAML API > - A book on YAML/JSON As my little niece likes to say "Wooooowww!!!!!" :-) |