Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for co-occurrence constraints #22

Open
anweiss opened this issue May 23, 2018 · 6 comments
Open

Support for co-occurrence constraints #22

anweiss opened this issue May 23, 2018 · 6 comments
Labels

Comments

@anweiss
Copy link

anweiss commented May 23, 2018

I don't currently see any support for co-occurrence constraints in the spec. Would be great to allow for values on the right-hand side of control operators to be cross-references to other map/group entry types in the same instance document.

@cabo
Copy link
Contributor

cabo commented May 23, 2018

While there are no co-occurrence constraints in CDDL, many actual use cases can be addressed by using the fact that a group is a grammar:

postal = {
  ( street: text,
    housenumber: text) //
  ( pobox: text .regexp "[0-9]+" )
}

Can you tell us more about the specific use cases you have in mind?

@anweiss
Copy link
Author

anweiss commented May 23, 2018

Sure thing. So for example:

session = {
  timeout: uint,
}

other-session = {
  timeout: uint  .lt [session.timeout],
}

In this example, for a given instance document, I'd like for the value of the timeout entry in the other-session map to be less than the value of the timout entry in the session map.

@anweiss
Copy link
Author

anweiss commented May 23, 2018

Ideally, would love to use CDDL to validate data relationships in JSON instance documents.

@cabo
Copy link
Contributor

cabo commented May 23, 2018

Right, this would require an XPath-like mechanism to crawl the tree to find that other item (which may be later in the serialization...). This is probably done better with a separate, predicate-based mechanism. It is interesting to see how this was not done for W3C schema, e.g.: https://www.w3.org/wiki/Value_arithmetic_required_-_attributes

On a more philosophical note, this moves the language way more into the context-sensitive realm. It is true that the key uniqueness constraint on maps already does this -- there is no way I know around that in a JSON-derived generic data model.

On a practical note, people are writing data validators in Python and not Schematron. Are we sure we can find a notation that is actually better than Python for this? If we do, this could be something for CDDL 1.1.

(When we did DSSSL, the precursor of XSLT/XSL, we opted to use Scheme as a programming language to write the transformations in. That had some amazing power [it was also where the tree-crawling that then went into XSLT was designed]. It also was sometimes hard to get right, and to understand what was specified.)

@cabo
Copy link
Contributor

cabo commented May 24, 2018

A related question would be: What is your favorite way to navigate a JSON tree? JSONpath?

@anweiss
Copy link
Author

anweiss commented May 24, 2018

I've been using JSON Pointer and the I-D JSON Relative Pointer

@cabo cabo added the CDDL 2.0 label Jul 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants