-
Notifications
You must be signed in to change notification settings - Fork 112
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
Closer alignment with JSON Schema #46
Comments
This is a really good idea - and there is already re-use of some of the json schema with the types etc. In terms of mappings:
Challenges:
|
Yes, I think a |
I have to say I don't like the order item that much but I guess it would be essential. What's the neatest example of json schema handling for arrays? It also seems that id is a special keyword in json schema (obviously not so much an issue if we switch to keys approach but that has challenges too - like required uniqueness ...) |
I hadn't thought of non-unique table headers - maybe use a composite key of I haven't seen examples where JSON schema handles array order. For an unordered array, see e.g. "Set of products schema" on this page. |
@jpmckinney hmmm, issue is that array itself is not a natural part of json schema - we aren't talking here about using describing arrays using json schemas but how we use json schema itself ... Two options:
|
I like this idea! I'm wondering why we would try to use properties when json schema defines I'm also confused by the use of the |
@tryggvib |
Hmmm... Well using JSON schema to describe a CSV is probably not what it was originally intended for ;) A CSV doesn't have an array but each row in the CSV can be seen as an array so I think that would be a good fit. An array is json is ordered (at least according to the spec on json.org where it says "An array is an ordered collection of values." So here's what I'm thinking: {
"$schema": "http://link-to-dataprotocols-sdf-schema/",
"items": [
{
"id": "foo",
"title": "bar",
"description": "...",
"type": "date",
"format": "YYYY.MM.DD"
},
{
"id": "baz"
...
},
...
]
} So items is a list of subschemas. |
@tryggvib Ah, but |
@jpmckinney I'm not sure I understand you there. JSON schema says this about
So it's only an object if all items are supposed to follow the same schema. With a CSV row different values in the columns we could use an array of scheams to define it (which must abide to the position condition). The problem with that is the only row that doesn't necessarily conform with the schema, the header row. Either we define that as part of the json schema (and make it harder to read) or we skip it (like the current schema does). |
Indeed, you are correct. I'd never seen examples where the value of |
I generally like this though I must say items seems a lot less descriptive than fields (I note that e.g. Google BigQuery schema also uses fields ...) |
@paulfitz another request for your (excellent) thoughts here. I'm still in 2 minds about what to do here. Real compatibility would involve quite significant changes to JTS and would interact with many of the existing proposals. But that does not mean this is a "bad thing" (tm). |
We are well beyond this discussion by now. I think we've got as much from JSON Schema as we'll get into the JTS spec by now. Can this issue be closed? |
FIXED / WONTFIX. @pwalsh i think you are right - at this point we are unlikely to get that much more alignment and we have a fair amount (e.g. reuse of types etc). @jpmckinney if you have any thoughts here or think we should reopen please say! |
I agree that we've probably gone as far as we can on this. Thanks! |
* Normalized Data Package navigation * Fixed Data Resource navigation/formatting/links * Fixed data package formatting * Fixed Table Schema formatting * Improve Table Schmea navigation * Improved constraints navigation * Improved Table Schema refs * Simplified Data Package navigation * Simplify Data Resource navigation
It seems to me like you can use JSON Schema (or something very close) to describe CSVs just as well as JSON files, where instead of:
You'd have:
format
has a different meaning in JSON Schema, so maybe mint ascheme
property.JSON Schema is already well supported, so I figure it would be a benefit to try to be as close to it as possible.
The text was updated successfully, but these errors were encountered: