Re: [xml-dev] Is JSON Schema simpler than XML Schema?

[Webb Roberts <webb@webbroberts.com>]

I've gotten frustrated with JSON Schema. I haven't been able to use JSON Schema to implement any kind of useful type system, to model data as objects that maps to RDFS, or to XML Schema, or to programming language constructs.

I haven't been able to use JSON Schema to model any kind of reuse of data definitions. The "allOf" constraint is too broad to support specialization of classes or refinement of concepts (so I can't define a "car" that specializes "vehicle").

Properties are totally local to a schema, which means that there's no real reference mechanism from one property to another, so there's not anything to reuse, and no way to indicate that you're reusing a thing. There's also no way to specialize a property value or provide more choices on a given concept ("USPS state code" satisfies "state").

The mechanics of "additionalProperties" surprise me: you can say that additional properties are prohibited, or that they're OK, or that they're OK as long as they satisfy a schema (e.g., you can add whatever you want, as long as they're all booleans). This means that schemas are either super-open ("everything is valid as long as it's foreign to me") or super-closed ("nothing is valid that is not specified in this particular definition). I can't figure out how to use JSON Schema to describe how anything may be extended in a useful way. 

JSON Schema can validate some simple JSON formats, but I'm boggled as to how to scale it to anything beyond the simplest cases.

I feel like JSON-LD has added a lot of value to JSON, and it would be really nice to see a JSON-LD-friendly schema language that can constrain syntax in a sane way, with syntax and tools that JSON people can understand and use.

Webb


> On 2018-08-01, at 10:57, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:
> 
> 
> 
> On Wed, Aug 1, 2018 at 9:36 AM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
> 
> One of the purported advantages of JSON Schema is that it is simpler than XML Schema.
> 
> 
> CSV is also simpler than XML. Whether or not that is  advantage of CSV depends on the context
>  
> 
> After converting an XML Schema to JSON Schema, I am skeptical of such claims.
> 
> In a previous post, I invited suggestions for converting an xs:complexType with mixed content to an equivalent JSON Schema. After assessing several approaches, I arrived at a JSON Schema representation. I represented the following xs:complexType
> 
> <xs:complexType name="InternationalString" mixed="true">
>     <xs:choice minOccurs="0" maxOccurs="unbounded">
>         <xs:element name="bdo" type="bdoType" />
>         <xs:element name="bdi" type="bdiType" />
>     </xs:choice>
>     <xs:attribute name="direction" type="directionType" />
> </xs:complexType>
> 
>  
> 
> with this JSON Schema:
> 
> "InternationalString": {
>     "type": "array",
>     "items": {
>         "anyOf": [
>             {
>                 "type": "object",
>                 "properties": {
>                         "$": {"type": "string"}
>                 }
>             },
>             {
>                 "type": "object",
>                 "properties": {
>                         "bdo": {"$ref": "#/definitions/bdoType"}
>                 }
>             },
>             {
>                 "type": "object",
>                 "properties": {
>                         "bdi": {"$ref": "#/definitions/bdiType"}
>                 }
>             },
>             {
>                 "type": "object",
>                 "properties": {
>                        "@direction": {"$ref": "#/definitions/directionType"}
>                 }
>             }
>         ]
>     }
> }
> 
>  
> 
> One could reasonably argue that the XML Schema representation is simpler. At the very least, it is shorter.
> 
> 
> Aren't you overlooking the fact that one is not a accurate representation of the other because the JSON InternationalString doesn't have the extensible and inheritable semantics of the complex type you  are trying to mimic  and the XML model allows mixed content which the JSON model cannot accommodate.
>  
> 
> The XML Schema that I converted has a second xs:complexType which extends the above xs:complexType with an attribute:
> 
> <xs:complexType name="PedigreeStringType">
>     <xs:complexContent mixed="true">
>         <xs:extension base="InternationalString">
>             <xs:attribute name="pedigree" type="xs:string" />
>         </xs:extension>
>     </xs:complexContent>
> </xs:complexType>
> 
>  
> 
> I believe this xs:complexType cannot be represented in JSON Schema. (If that is not correct, please let me know). The best that one can do is to copy the JSON Schema definition of "InternationalString" and add the versionattribute:
> 
> 
> and you represented an atomic concept (the version XML atttribute) with a JSON object which allows it to have non-atomic content. 
>  
> 
> "PedigreeStringType": {
>     "type": "array",
>     "items": {
>         "anyOf": [
>             . . .  copy the InternationalString JSON Schema representation
>             {
>                 "type": "object",
>                 "properties": {
>                        "@pedigree": {"type": "string"}
>                 }
>             }
>         ]
>     }
> }
> 
>  
> 
> As you know, the danger of copy-and-paste is that if the parent type (InternationalString) is changed, then I must ensure that the changes are also made wherever I did a copy-and-paste.
> 
> Summary: I think it is probably true that JSON Schema is simpler than XML Schema for simple things.
> 
>  
> The InternationalString  content model you are trying to replicate is a simple thing . 
> 
>  
> But for complex things, such as expressing mixed content and creating type hierarchies, I think XML Schema is simpler and more powerful.
> 
> I welcome your comments.
> 
> 
> 
> You may as well ask whether an apple is simpler than an orange.