formatting examples need to have year for context

[jbfaden]

My reading of the uri_templates spec, is that templates like

http://example.com/data_$(j;pad=none).dat

are not correct because the spec itself must contain the context. The example has 1999-01, so I think that the template should be

http://example.com/data_$(j;pad=none;Y=1999).dat

While I can see the logic that this could be formatted, ignoring the year, this causes problems for my code which assumes these are set.

See section: https://github.com/hapi-server/uri-templates/wiki/Specification#filenames-with-missing-date-information

I could probably introduce a mode into my code which would support this, but in this case I think the spec needs to be modified.

[jbfaden]

See also https://github.com/hapi-server/uri-templates/blob/master/formatting.json

[rweigel]

I do recall that we agreed and discussed that data_$(j;pad=none).dat is OK for formatting/generation. timeRange sets the context.

[rweigel]

I re-read your comment and I think that you agree that it is OK.

But I think it would be awkward to have a special case for year unless the justification was that it was generally difficult to implement versus difficult to implement in existing code.

[jbfaden]

Yes, I can put this in. It's just more code, and this is already almost 2000 lines long. This only adds about 50 more lines, because I have to keep track of the context anyway, to support $(j,Y=1999). The new code is figuring out implicitly that a context is needed, whereas before I didn't have to worry about this.

[rweigel]

May just report "not implemented" if someone tries to use it.

[jbfaden]

I'd like to have at least one complete implementation of this, just so we have a reference implementation people can test against. (Your formatting.json is working nicely, by the way.)

[jbfaden]

This is done. The URITemplates code can have the context set so that codes like $m.dat can be parsed with a year as context.

[rweigel]

Pro tip: You can refer to the commit that closes by copying the the commit hash into the editor, e.g., 44400f042142a0650bea137a8d29ab4b75e3c28e

Even faster, you can enter "Closes #4" in your commit message and the issue will automatically be closed and the link will be put there for you.

[jbfaden]

I will try to use your pro tip. Often there are multiple commits, though. I suppose I would just point to the last commit.

[rweigel]

I have not tried it, but quite often I see people make a fork and then merge the fork with several commits. I think there is a way to do this with branches as well. It is somewhat difficult to motivate myself to do when I am the only person committing however.

On Wed, Aug 5, 2020 at 10:27 AM Jeremy Faden notifications@github.com wrote:

I will try to use your pro tip. Often there are multiple commits, though. I suppose I would just point to the last commit.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hapi-server/uri-templates/issues/4#issuecomment-669225585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUQ57Q7IE2VEIEPU4WV35DR7FT47ANCNFSM4POXMQWA .

[jbfaden]

I don't push things that are not complete, but as I put in each change (e.g. shift modifier) I would push it. Branching is pretty easy, and I can show you how that's done if you ever need it.

Also there are things you might have a look at, for example 4626d5e3a517edb270dfb6abff478a4f68a740fe, c9f3173c9ba46463c66b2079469b4322ab054804, and b70603b559ad0c1e11b59cc34077357d92770e80

(Works, neat!)