Bug in META.json LINT

[Jim Nasby]

As I read the spec[1], it should be ok to stick a custom field anywhere
in the doc, but I'm getting these errors with [2]:

Field /prereqs/X_end: Should be a map structure [Spec v1.0.0]
• Field /prereqs/test/X_end: Should be a map structure [Spec v1.0.0]
• Field /prereqs/test/requires/X_end: No value [Spec v1.0.0]
• Field /prereqs/runtime/X_end: Should be a map structure [Spec v1.0.0]
• Field /prereqs/runtime/requires/X_end: No value [Spec v1.0.0]
• Field /prereqs/X_comment: Should be a map structure [Spec v1.0.0]
• Field /prereqs/build/X_end: Should be a map structure [Spec v1.0.0]
• Field /prereqs/build/X_comment: Should be a map structure [Spec v1.0.0]
• Field /prereqs/build/requires/X_end: No value [Spec v1.0.0]

Is that intentional?

(BTW, I'm using X_end so I don't have to screw around with trailing
comma's. X_comment is what you'd think it is.)

[1] Any keys not described in this specification document (whether
top-level or within compound data structures described herein) are
considered custom keys and must begin with an “x” or “X” and be followed
by an underscore; i.e. they must match the pattern: /\Ax_/i. If a custom
key refers to a compound data structure, subkeys within it do not need
an “x_” or “X_” prefix.

[2]
https://github.com/decibel/pg_acl/blob/675124944774ad115590c3b11e72a94028800141/META.json
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

[David E. Wheeler]

On Jan 7, 2016, at 2:31 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:

> As I read the spec[1], it should be ok to stick a custom field anywhere in the doc, but I'm getting these errors with [2]:
>
> Field /prereqs/X_end: Should be a map structure [Spec v1.0.0]

The spec says that, for /prereqs:

> This is a Map that describes all the prerequisites of the distribution. The keys are phases of activity, such as configure, build, test, or runtime. Values are Maps in which the keys name the type of prerequisite relationship such as requires, recommends, suggests, or "conflicts", and the values provide sets of prerequisite relations.

So the only keys allowed there are phases of activity, and values must be maps. I assume you have a non-map value for X_end, and X_end will not be allowed there, anyway, since it’s not a known phase of activity. Phases are documented here:

http://pgxn.org/spec/#Phases

> • Field /prereqs/test/X_end: Should be a map structure [Spec v1.0.0]

Only relationships are allowed as keys here, requires, recommends, suggests, or conflicts.

> • Field /prereqs/test/requires/X_end: No value [Spec v1.0.0]

Does this one have a value? It should be a version spec.

Best,

David

[Jim Nasby]

On 1/7/16 4:57 PM, David E. Wheeler wrote:
> On Jan 7, 2016, at 2:31 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:
>
>> As I read the spec[1], it should be ok to stick a custom field anywhere in the doc, but I'm getting these errors with [2]:
>>
>> Field /prereqs/X_end: Should be a map structure [Spec v1.0.0]
>
> The spec says that, for /prereqs:
>
>> This is a Map that describes all the prerequisites of the distribution. The keys are phases of activity, such as configure, build, test, or runtime. Values are Maps in which the keys name the type of prerequisite relationship such as requires, recommends, suggests, or "conflicts", and the values provide sets of prerequisite relations.
>
> So the only keys allowed there are phases of activity, and values must be maps. I assume you have a non-map value for X_end, and X_end will not be allowed there, anyway, since it’s not a known phase of activity. Phases are documented here:

Argh, right, the keys are special.

How about applying the same /\Ax_/i filtering here too? AFAICT that
wouldn't case a problem anywhere but requires (since an extension could
theoretically start with x_, even though that's a damn weird name...)

[David E. Wheeler]

On Jan 7, 2016, at 3:33 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:

> Argh, right, the keys are special.
>
> How about applying the same /\Ax_/i filtering here too? AFAICT that wouldn't case a problem anywhere but requires (since an extension could theoretically start with x_, even though that's a damn weird name...)

Where? The API server depends on the spec to display things properly on the site.

D

[Jim Nasby]

Certainly wherever uploads are being checked.

I would think the site would only be looking for well-known keys anyway, no?

[David E. Wheeler]

On Jan 8, 2016, at 2:39 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:

>> Where? The API server depends on the spec to display things properly on the site.
>
> Certainly wherever uploads are being checked.

No, I mean where in the META spec?

Frankly I don’t see the point. x_* fields are useful for experimentation in areas where there is no predefined list of allowed field names (e.g., in the resources section). Everywhere else, it makes more sense to me to have a discussion about expanding the list of allowed fields.

> I would think the site would only be looking for well-known keys anyway, no?

Probably, but it does rely on the spec enforcement on upload so it can be lazy about such things.

David

[Jim Nasby]

On 1/8/16 7:05 PM, David E. Wheeler wrote:
> No, I mean where in the META spec?

The way the spec is documented leads me to think they'd be permissible
anywhere. The only place I see that being a problem is in
prereqs/*/requires, because a legitimate extension could start with x_.

> Frankly I don’t see the point. x_* fields are useful for experimentation in areas where there is no predefined list of allowed field names (e.g., in the resources section). Everywhere else, it makes more sense to me to have a discussion about expanding the list of allowed fields.

https://github.com/decibel/pgxntool/blob/master/META.in.json

Notice the comment documentation and the use of "X_end" keys to make
editing less error prone.

If it's a big problem to change then I guess it'n not worth it.

[David E. Wheeler]

On Jan 8, 2016, at 9:00 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:

> The way the spec is documented leads me to think they'd be permissible anywhere. The only place I see that being a problem is in prereqs/*/requires, because a legitimate extension could start with x_.

Well, it documents what fields are allowed, but perhaps in each of those sections it should day whether or not x_ fields are also allowed.

>> Frankly I don’t see the point. x_* fields are useful for experimentation in areas where there is no predefined list of allowed field names (e.g., in the resources section). Everywhere else, it makes more sense to me to have a discussion about expanding the list of allowed fields.
>
> https://github.com/decibel/pgxntool/blob/master/META.in.json
>
> Notice the comment documentation and the use of "X_end" keys to make editing less error prone.

Well, you could just remove that key when your template processing code sees it.

> If it's a big problem to change then I guess it'n not worth it.

It’s not a big problem. I think there should be discussion for proposed new keys, and about whether x_ fields should be allowed where there is otherwise a fixed list of keys.

Best,

David