Some clarifications about the draft, please...
fge
fge
Laurie Harper
> Hello group,
>
> There are some clarifications I need wrt the draft as it currently stands, so that my implementation comply with it.
>
> * regexes. In the definition of patternProperties and pattern, it is specifies that property names/string values respectively must match. Now, it is unfortunately common that Java programmers understand "match" as "match all the input", whereas strictly speaking, a regex can match anywhere in its input (this is one thing I _hate_ with Java, that .matches() methods anchor regexes - they shouldn't). Does the draft mean "real" matching, or anchored matching?
JSON Schema is language agnostic, so the implementation of a particular method in a particular language has little bearing. In normal regex nomenclature, an expression with no anchoring meta-characters can match at any point in the source string.
> * ECMA 262/Perl 5: I use Rhino, because java.util.regex doesn't fit (it does not understand \b for instance, and it supports possessive quantifiers which ECMA 262 doesn't: /a++/ is legal in Java for instance). There is no MUST in the draft (there is a SHOULD for pattern though), should there be one?
IMHO a MUST would be excessively onerous, as different programming languages/environments offer different regex semantics. As it is, regular expressions in ECMA 262 and Perl 5 are not 100% compatible (ECMA 262 uses a subset of what Perl 5 supports).
> * can someone give an example of "schema dependency" (section 5.8)? I don't quite get the meaning of that, how is that different from "properties"?
First, a Simple Dependency:
schema = { "dependencies": { "foo": "bar" }}
means that if an instance has a property 'foo', it must also have a property 'bar'. The same thing expressed using a Schema Dependency:
schema = { "dependencies": { "foo": { "properties": { "bar": { "required": true }}}}}
In English: if an instance has a property 'foo', it must also comply with this schema, which states that the instance must have a property named 'bar'. Or, to put it another way, if an instance has a property named 'foo' it must also be valid according to schema.dependencies.foo.
> * how would one use "default" (5.20)?
schema = { ... "foo": { "default": 99 }}
meaning that an instance that has no property named 'foo' where 'foo' is allowed should be treated as though it has a property 'foo' with a value of 99.
> * disallow: the draft says: "[...]if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid". First, I don't see in the "types" definition that it can have schemas in it. And second, the "types" specification allows custom types without really specifying whether they should be names, etc. Can someone clarify?
'disallow' is just the inverse of 'type' -- so it can take any value that 'type' could take, with the opposite meaning. Section 5.1 specifies that 'type' can either be a string (Simple Type) or array (Union Type) and that, if it is an array, each value in the array may be either a string (Simple Type) or a schema.
I'm not sure what you mean by 'custom types' -- the specification only states that if a value is given for 'type' that is not in the list of values listed in the spec, validators are free to accept any instance value and MAY impose custom semantics on instance values.
L.
--
Laurie Harper
http://laurie.holoweb.net/
Paul C. Bryan
On 2011-07-16, at 5:28 AM, fge wrote:
> Hello group,
>
> There are some clarifications I need wrt the draft as it currently stands, so that my implementation comply with it.
>
> * regexes. In the definition of patternProperties and pattern, it is specifies that property names/string values respectively must match. Now, it is unfortunately common that Java programmers understand "match" as "match all the input", whereas strictly speaking, a regex can match anywhere in its input (this is one thing I _hate_ with Java, that .matches() methods anchor regexes - they shouldn't). Does the draft mean "real" matching, or anchored matching?
JSON Schema is language agnostic, so the implementation of a particular method in a particular language has little bearing. In normal regex nomenclature, an expression with no anchoring meta-characters can match at any point in the source string.
> * ECMA 262/Perl 5: I use Rhino, because java.util.regex doesn't fit (it does not understand \b for instance, and it supports possessive quantifiers which ECMA 262 doesn't: /a++/ is legal in Java for instance). There is no MUST in the draft (there is a SHOULD for pattern though), should there be one?
IMHO a MUST would be excessively onerous, as different programming languages/environments offer different regex semantics. As it is, regular expressions in ECMA 262 and Perl 5 are not 100% compatible (ECMA 262 uses a subset of what Perl 5 supports).
Laurie Harper
>> > * ECMA 262/Perl 5: I use Rhino, because java.util.regex doesn't fit (it does not understand \b for instance, and it supports possessive quantifiers which ECMA 262 doesn't: /a++/ is legal in Java for instance). There is no MUST in the draft (there is a SHOULD for pattern though), should there be one?
>>
>> IMHO a MUST would be excessively onerous, as different programming languages/environments offer different regex semantics. As it is, regular expressions in ECMA 262 and Perl 5 are not 100% compatible (ECMA 262 uses a subset of what Perl 5 supports).
>
> IMO, codifying named regex schemes would be an important objective, as it allows implementations in various languages to validate a given schema with identical behaviour. I would go so far as to require implementations minimally support specific types (i.e. MUST). To do otherwise would open up wide gaps in interoperability between implementations in different languages and environments.
Nice as that sounds in theory, it's just not practicable. There are just about as many 'specific types' of regular expression as there are regular expression matchers. I understand the desire to ensure maximum interoperability, but when it comes to regular expression matching we're stuck with the reality of what exists in the wild; there's only so much the spec can require of its implementors or promise its users.
If you want to author schemas that rely on regular expressions and have them be portable across implementations, you will have to restrict your use of regexs to what's going to work everywhere you care about.
Paul C. Bryan
On 2011-07-19, at 2:42 AM, Paul C. Bryan wrote:
>> > * ECMA 262/Perl 5: I use Rhino, because java.util.regex doesn't fit (it does not understand \b for instance, and it supports possessive quantifiers which ECMA 262 doesn't: /a++/ is legal in Java for instance). There is no MUST in the draft (there is a SHOULD for pattern though), should there be one?
>>
>> IMHO a MUST would be excessively onerous, as different programming languages/environments offer different regex semantics. As it is, regular expressions in ECMA 262 and Perl 5 are not 100% compatible (ECMA 262 uses a subset of what Perl 5 supports).
>
> IMO, codifying named regex schemes would be an important objective, as it allows implementations in various languages to validate a given schema with identical behaviour. I would go so far as to require implementations minimally support specific types (i.e. MUST). To do otherwise would open up wide gaps in interoperability between implementations in different languages and environments.
Nice as that sounds in theory, it's just not practicable. There are just about as many 'specific types' of regular expression as there are regular expression matchers. I understand the desire to ensure maximum interoperability, but when it comes to regular expression matching we're stuck with the reality of what exists in the wild; there's only so much the spec can require of its implementors or promise its users.
If you want to author schemas that rely on regular expressions and have them be portable across implementations, you will have to restrict your use of regexs to what's going to work everywhere you care about.
Paul
Francis Galiegue
[...]
>
>> * can someone give an example of "schema dependency" (section 5.8)? I don't quite get the meaning of that, how is that different from "properties"?
>
> First, a Simple Dependency:
>
> schema = { "dependencies": { "foo": "bar" }}
>
> means that if an instance has a property 'foo', it must also have a property 'bar'. The same thing expressed using a Schema Dependency:
>
> schema = { "dependencies": { "foo": { "properties": { "bar": { "required": true }}}}}
>
> In English: if an instance has a property 'foo', it must also comply with this schema, which states that the instance must have a property named 'bar'. Or, to put it another way, if an instance has a property named 'foo' it must also be valid according to schema.dependencies.foo.
>
OK, that's clear enough, thanks
>> * how would one use "default" (5.20)?
>
> schema = { ... "foo": { "default": 99 }}
>
> meaning that an instance that has no property named 'foo' where 'foo' is allowed should be treated as though it has a property 'foo' with a value of 99.
>
OK, my formulation was bad. I meant to ask for an example schema and
input in which the "default" value is actually necessary for
validation.
>> * disallow: the draft says: "[...]if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid". First, I don't see in the "types" definition that it can have schemas in it. And second, the "types" specification allows custom types without really specifying whether they should be names, etc. Can someone clarify?
>
> 'disallow' is just the inverse of 'type' -- so it can take any value that 'type' could take, with the opposite meaning. Section 5.1 specifies that 'type' can either be a string (Simple Type) or array (Union Type) and that, if it is an array, each value in the array may be either a string (Simple Type) or a schema.
>
> I'm not sure what you mean by 'custom types' -- the specification only states that if a value is given for 'type' that is not in the list of values listed in the spec, validators are free to accept any instance value and MAY impose custom semantics on instance values.
>
My thought at first is that a custom type was identified by a string
which in turn identifies a schema. Do we mean the same thing?
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)
AleiPhoenix
发自我的 iPad
--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To view this discussion on the web visit https://groups.google.com/d/msg/json-schema/-/Pla7TDEKv9AJ.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.
