Allow type for grammars applied to non-XML structures

[AndrewSales]

xvrl/schema/xvrl.rnc

Lines 143 to 149 in 19438c4

	schema =
	element schema {
	common.attr,
	attribute href { xsd:anyURI }?,
	attribute schematypens { xsd:anyURI },
	attribute version { text }?
	}

Should we follow the xml-model convention of type='{MIME-type}' here, since non-XML grammars may not have an associated namespace?

[gimsieke]

Sure, let’s have it here, too.

[gimsieke]

In the light of xmlcalabash/xmlcalabash3#258, it becomes evident that for schema languages without a schematypens recommendation in the xml-model spec, we might need another kind of identifier for a given schema language, such as JSON Schema.

"Relax NG – compact syntax" doesn’t have an associated schematypens in the xml-model spec, either. But it has a distinct type in xml-model lingo, application/relax-ng-compact-syntax. I’d rather call it content-type in this spec though.

JSON Schema seems to have the associated content-type application/schema+json.

So if we introduce @content-type and make both @content-type and @schematypens optional, we can (but are not required to) identify many validation languages by one or both of @content-type or @schematypens.

We need not make @content-type and @schematypens alternatives (a Q{http://relaxng.org/ns/structure/1.0}choice, formally;). You should be allowed to say <schema href="example.sch" content-type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron" version="2016"/>.

But what to do with schema languages that have neither a distinct content type nor a schematypens? Look at jsontron), JSound, or the JSON Schema Definition Language. content-type is probably application/json. I think their @content type is just application/json and their @schematypens is undefined.

Then we probably need a list of schema languages in order to name them in the absence of distinct content-type and schematypens values.

It is desirable to have a list of canonical names for known schema types (instead of free-text identifiers), but probably not the values in the "Schema Name" column in [xml-model’s Appendix C Suggested Use](https://www.w3.org/TR/xml-model/#d0e689] or the values that Oxygen offers because they contain spaces.

I’d prefer a token for each language:

language	content-type	schematypens
DTD	application/xml-dtd
XSD	application/xml	http://www.w3.org/2001/XMLSchema
RNG	application/xml	http://relaxng.org/ns/structure/1.0
RNC	application/relax-ng-compact-syntax
Schematron	application/xml	http://purl.oclc.org/dsdl/schematron
NVDL	application/xml	http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0
JSON	application/schema+json
JSound	application/json
jsontron	application/json
JSD	application/json
…

Some languages can only be identified by their @language, for example <schema href="example.json" language="jsontron"/>.

You should be allowed to give the complete set of attributes, as in <schema href="example.sch" language="Schematron" content-type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron" version="2016"/>

My recommendation is to make @schematypens optional and introduce two new optional attributes on schema, @language and @content-type.

The @language value can either be one of a token from a list or, for languages not contained in the list, a string that starts with 'x-':

    attribute language {  list {
        (("DTD" | "XSD" | "RNG" | "RNC" | "Schematron" | "NVDL" | "JSON" | "JSound" | "jsontron" | "JSD") 
         | xsd:token { pattern = "x-[\-._/\w]+" } )} },

I suggest not to make the tokens repeatable. For example, one could be tempted to say language="RNG Schematron" for an RNG schema with embedded Schematron. But each of the RNG and Schematron validations will have a report of its own, therefore a single token suffices.

Alternatively, @language could just contain text.

Likewise, attribute content-type { xsd:token { pattern = "\w+/[\-.\w]+(\+[\-.\w]+)?" } }? vs. attribute content-type { text }?.

We can think about specifying a token list for the @schematypens values (the ones given in the xml-model spec), and someone™ can add co-occurrence constraints for the attributes…

I’ll submit a PR for these changes.