further specify the format of iri-references throughout

[karenetheridge]

• $id cannot have a fragment at all, so separate it from the common definiiion
• $ref, $dynamicRef, $recursiveRef must be a iri-reference to a schema location: when the fragment is non-empty, it must refer to an $anchor or a json-pointer
• absoluteKeywordLocation in result outputs must use canonical IRIs/iri-references: either there is no fragment, or it is non-empty and encodes a json pointer

Also fixed the output schema which erroneously still identifies absoluteSchemaLocation as a uri, not an iri.

[karenetheridge]

I'm not sure this change is necessary, but I'm ok with it. I assume we aren't talking about a change to the already released meta-schema, but rather that this would be part of the next draft?

There's no reason why this can't go into the current draft's metaschema, because it is not adding an additional restriction that wasn't already there, but rather making the metaschema more conformant to existing language.

That is -- it lets implementations catch problems earlier by applying a schema against the metaschema, rather than having to catch problems with custom code during evaluation.

[jdesrosiers]

There's no reason why this can't go into the current draft's metaschema

We generally don't consider meta-schemas living documents. Once they are released, we don't change them any more than we would change the spec. We have made exceptions for fixing bugs in meta-schemas, but this isn't fixing anything, it's just making it more strict. I don't think we have a rule written down anywhere about how to deal with this kind of thing (we probably should), but historical precedent seems to indicate that this should go in the next draft.

[karenetheridge]

We generally don't consider meta-schemas living documents.

We have in the past, however, fixed inconsistencies between the written spec and the metaschema, where the written spec prevails (because it very definitely is versioned and cannot be revised before the next release).

[jdesrosiers]

We have in the past, however, fixed inconsistencies between the written spec and the metaschema, where the written spec prevails

Right, which is essentially bug fixes. This is not a bug fix. I don't feel strongly enough about this to try to block it, but I do feel that it's important for more voices to express opinions on whether we should be making this kind of change for meta-schemas before this gets approved. Even better would be if we decide on guidelines for when we want to allow updating meta-schemas and document that decision.

[handrews]

@karenetheridge @jdesrosiers it would probably be a good idea to start a discussion in the community repo on the meta-schema process. It can complement my spec release process discussion (https://github.com/json-schema-org/community/discussions/7) but please start a new discussion! The meta-schema process should be separate. I do not have an opinion on it (or rather, we tried my opinion, but no one liked it- which I say with humor, it's just time to try someone else's ideas).

In the meantime let's put this on hold while we sort out the process concerns.

[jdesrosiers]

The draft-next branch has been merged and is now closed. The merge target for this PR has been changed to main. Here are the recommended steps to get your branch reabsed properly.

1. Make sure your remote for the json-schema-org/json-schema-spec repo is up-to-date. (Example: git fetch upstream).
2. Rebase your commits onto main. (Example: git rebase --onto upstream/main abcd123~1 (replace abcd123 with the commit hash of the first commit in your PR)).
3. Force push the rebased branch to your fork. (Example: git push --force origin my-branch).

[handrews]

@karenetheridge I think this would need to be reworked now that JSON Schema uses IRIs rather than URIs, and I'm not quite sure how the regexes would work in that case. Along with the branch changes, perhaps this is best closed and a new PR submitted?

[karenetheridge]

I have rebased against the updates to main.

[gregsdennis]

Good reminder that I need to update the output schema to the new structure. 👍

This should go through first, then I'll do that update.

[gregsdennis]

@karenetheridge please address @notEthan's regex concerns, but I think this is good.