Define a textual format for Schematron about schematron-enhancement-proposals HOT 8 OPEN

from schematron-enhancement-proposals.

Maybe something along the lines of RelaxNG with its text format?

from schematron-enhancement-proposals.

From my POV Schematron is used to check XML and the people defining the rules are therefore not completely anti-XML. But a regular XML editor allows such users to enter the most relevant information in element content, not in attributes.

So I see the current use of having the rules in an attribute as the main pain point. All other pointy angles stuff could be hidden by a suitably configured XML editor.

from schematron-enhancement-proposals.

I see #41 has a contradictory requirement: to allow element based languages as queries.

So if we want to have a textual format to avoid horrid XML tags, wouldn't it also needs to cope with not only how to convert Schematron's XML to non-tags but also how to convert XML-tagged @context, @text, @value-of into non-tags, which could only happen by replacing tags with some other delimiter system (i.e. JSON).

from schematron-enhancement-proposals.

I see #41 has a contradictory requirement: to allow element based languages as queries.

As with @michael-aka-mmh's comment, this and #41 are both proposals to make Schematron easier to work with.

So if we want to have a textual format to avoid horrid XML tags, wouldn't it also needs to cope with not only how to convert Schematron's XML to non-tags but also how to convert XML-tagged @context, @text, @value-of into non-tags, which could only happen by replacing tags with some other delimiter system (i.e. JSON).

So if we want to have a format with a lower barrier to entry, with a lower cognitive load, that's easier for beginners to use, ...

Firstly, #41 and a configured XML editor will probably get you there.

Secondly, I don't know what a textual format would be, so I wouldn't rule it out because of its as yet unknown delimiter system. It might be JSON-like, it might be CSS-like (where <rule> and above are like @ rules and @test is like a CSS selector, or something), or it might be something completely different. It might use { and } to delimit XPaths to be evaluated, same as XSLT's attribute value templates and, now, text value templates. I don't know: this is just a proposal, not a fully-feature solution.

from schematron-enhancement-proposals.

One method would be to start with JSON with the common mapping (element is an array of object, first object is attributes) and then see if there were any regular changes that could be made to simplify it.

"schema" : [
    
    { "phase": "#ALL",
      "qlb":"xpath2"
      "xmlns":"http://purl.oclc.org/dsdl/schematron"
    },  
    {"pattern": [
       {"id": "p1"},
       {"rule": [
          { "context": "a/b/c",
           "id":"r1"},
           {"assert": [
              { "test":"x/y",
                 "role":"error" },
               "#text":"a/b/c should not contain x/",
               ] 
            }
         ]
       }
      ]
    }
  ]

Then you could,say, strip out the quotes on the names, use the quote delimiter as short hand for #"text:", remove all {}, and replace the syntax of the attributes (i.e. the first in each array) with @ delimiter. The commas are not needed either, due to the simpler set of tokens. Lets replace the : with = just because we can, and remove it from named arrays. And replace the [] with {}, again for no good reason.

So this gives a short-hand syntax convertable to JSON convertable to XML (and back)

schema  {    
    @phase= "#ALL"
    @qlb="xpath2"
    @xmlns="http://purl.oclc.org/dsdl/schematron"
    pattern {
       @id="p1"
       rule {
          @context="a/b/c"
           @id="r1"
           assert {
              @test="x/y"
              @role="error" 
              "a/b/c should not contain x/"
               }
         }
    }
}

from schematron-enhancement-proposals.

So it's not infeasible, but I think it's still an open question whether we can come up with something that enough people would want to write by hand (especially if there is #41 and a decent XML editor).

Half of me wants to work more on this, and half of me wants to point out that at this point we'd be better served by getting more enhancement proposals to the point of being provably not infeasible (or, if necessary, provably infeasible).

• The well-known attributes don't really need @
• The values of well-known attributes don't really need quotes, but might then need a closing delimiter (and suddenly it looks more like CSS)
• What about mixed-content messages?

from schematron-enhancement-proposals.

The well-known attributes don't really need @

Sure. I was aiming at a general syntax that could be converted (to JSON) based only on delimiters, because that doesn't break on, e.g. upgrades or foreign elements. (And @ might help with questions and communication between XML people and these alleged short-syntax people.)

What about mixed-content messages?

AFIK, the JSON treatment of mixed content is:

 XML:     abc<name/>def          
 JSON   [ "#text":"abc", "name":"", "#text":"def"]

Using my rules above, this is

      "abc"   name="" "def" 

The XML has 3 characters overhead; the JSON has 28 characters overhead; my simplified one has 9 chars overhead. So maybe it is worthwhile in the short form to just drop into an XML-ish syntax for mixed content :

      " abc<name/>def"

That has the advantage of, if you are converting to XML element syntax, you just plonk the string in (after delimiter adjustment.) Simpler than parsing.

Some subset of markdown might be possible, except markdown doesn't support the attributes (nor any the RTL tagging?) But lists, p, title, i, b, code could be adopted, I guess.

from schematron-enhancement-proposals.