Provide a source URL field

[VictorNicollet]

A root-level optional field that holds an URL where the most recent version of the résumé can be found.

Typical use case: my résumé can be found on a job search website, on an alumni network and in a common database, but the official and up-to-date version should be downloaded from my own website at https://nicollet.net/resume.json.

Field name suggestions: url, canonicalUrl, officialUrl or even latest.

[ocram]

+1, could be done like this: #82

[DonDebonair]

+1, shall we move discussion about the implementation to #82 ?

[thomasdavis]

I'm still trying to get a full picture of the concept, and I'm wondering if it makes sense.

Take for example, you have a jresume somewhere and it's officialUrl is pointing to a hosted jresume on your homepage. Now imagine you change the officialUrl of the jresume stored at your original officialUrl and so on...

I was looking into a revision property as an auto incremented integer whenever a publish action happens to your resume. So you can compare and see if something is out of date. Not sure how that works into officialUrl stuff either.

Anybody have any good examples of a similar scenario?

[VictorNicollet]

Altering the officialURL would be a cheap and sane way to perform a redirect when you move your jresume to a new location. As long as you don't create loops.

As far as revision goes, a timestamp would be both more human-friendly and easier to handle than a revision number (the latter requires some way of determining that two jresumes are two revisions of a single document...)

[olivif]

no action on this for a year, I see there is even a PR open for it #82. I don't think we have strong support for adding this in, I suggest we revisit later 😄

thoughts? @PeterDaveHello @thomasdavis @chrisdotcode @stp-ip

[stp-ip]

I think it is needed and a good practice to provide a canonical url. I reused this PR and the idea in my opinionated draft: https://github.com/stp-ip/resume-schema/blob/2015-draft/schema.json#L15
I think the PR should be merged and this closed. Perhaps later we could improve the wording on the description.

[olivif]

@stp-ip I am not opposed to having the url, it just seemed like no one was really raving about it. I am OK with merging.

[chrisdotcode]

Yes, I'm agreement with a canonical source.

[stp-ip]

Ok so we agree on canonical with type url and a small description that this is the url to find the latest version. So I would say PR needed.

[stp-ip]

Concerning the revision: #49

[aloisdg]

semver allow to use versioning and tag. I think it is enough. We can close this issue.

[thomasdavis]

I do agree to some extent and 90% happy for it to be included.

Though in my mind it sounds like a property that would be included in a meta format or considered meta data in general.

e.g.

For the open source registry registry-server, the resume.json's are stored in mongo with a top level view that looks like:

resume: {},
meta: {}

The meta property contains information such as the username and potential pass-phrase for that particular resume.

Given that situation, I imagine that a canonical url would generally be a part of meta information once subscribed to a service.

As above though, if that argument isn't strong, let us merge it in.

[stp-ip]

I think version and canonical should be first class citizens and not be pushed to meta data. Too important to include at the end within a meta-data section. At least in my opinion.

For further version discussions I would still suggest #49.
For the canonical addition we would need a new PR, after we agreed on the name and the section to add it.

As a side note there is a suggestion open for a meta data section: #204

[thomasdavis]

@stp-ip Do you know of any example projects of which to emulate?

#204 Would have solved the problem I had when implementing the registry server and makes sense in the context of this issue too.

+1 to canonical going into meta and moving discussion to that thread.

[aloisdg]

Agreed.

[stp-ip]

@thomasdavis I was against pushing version and canonical into the meta data section, but as it seems the separation between data and meta data is cleaner. I agree.

I would still leave this issue to track the progress on the canonical url.

Decision: Use canonical and have it in the meta data section proposed in #204

[olivif]

@stp-ip does it make sense to have one meta issue (no pun intended) tracking all the additions to the metadata field? I think it's only canonical and version for now but more might pop up.

[stp-ip]

Done see #225

[olivif]

super 😄

[olivif]

Added in #237