Schematron / schematron-enhancement-proposals

This repository collects proposals to enhance Schematron beyond the ISO specification
9 stars 0 forks source link

Specify the query language binding in use when embedding Schematron (@sch:queryBinding) #52

Open dmj opened 2 years ago

dmj commented 2 years ago

Rationale: We need a convenient way to specify the query language binding in use when embedding Schematron rules or pattern in a host language such as XML Schema or TEI ODD. Schematron has the queryBinding attribute on the schema element. We can reuse it but put it in the Schematron namespace to avoid polluting the host language.

Add

5.4.16 sch:queryBinding attribute

When embedding Schematron, the sch:queryBinding attribute may be used on the outermost element of the host document to declare the query binding in use.

rjelliffe commented 2 years ago

It seems a reasonable idea.

But why isn't embedding good enough? The extraction program can just look for any sch:schema first, and use that, surely?

It might be a good idea to check with Murata whether Japan would support this at ISO. I think historically they have regarded things that enhance the XSD ecosystem as making the world worse not better: indeed, the fundamental reason for DSDL was how bad XSD was shaping up to be ("shaping up" is surely the wrong term for the bloated XSD.)


Ramble:

I do not know: but I thought that ever since XSD grew its assertions, people had stopped with the embedded Schematron assertions in XSD; and for RELAX NG/DSDL, didn't NVRL reduce the need too?

I have always been surprised by people doing it, and I developed it! (with Eddie Robertson...)

My problem is that it does not fit into the XSD Left Hand Side system, so it is not an "integration" just an "interleaving": you can never be sure that an embedded rule only applies to the element or attribute declaration it is defined in.

And the more that XSD substitution groups and derived types etc. are used, the more that you have to try to recreate the XSD structured type system in XPath: say someone makes an XSD where vanilla A is typed to contains only Bs, and then a different place where where X/A contains only Cs, you can model it with two Schematron rules contexts, but they are in different locations: so you have to find every occurrence of an element name in any content model in a structural type and then figure out which elements use that type: you need to understand the whole schema in order to know what contexts you need to use.

Schematron is inside out compared to XSD: in Schematron you say "lets put everything about X together, for every context it appears in" while in XSD you say "lets factor out all the contexts for X throughout the schema and see what appears in each of them"

Regards Rick

On Tue, 6 Sept 2022, 9:56 pm David Maus, @.***> wrote:

Rationale: We need a convenient way to specify the query language binding in use when embedding Schematron rules or pattern in a host language such as XML Schema or TEI ODD. Schematron has the queryBinding attribute on the schema element. We can reuse it but put it in the Schematron namespace to avoid polluting the host language.

Add

5.4.16 sch:queryBinding attribute

When embedding Schematron, the sch:queryBinding attribute may be used on the outermost element of the host document to declare the query binding in use.

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/52, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKOQRSRO3FYZOGBEIRTV44WO7ANCNFSM6AAAAAAQFYBU6U . You are receiving this because you are subscribed to this thread.Message ID: @.***>

AndrewSales commented 8 months ago

I understand the use case, but I think it's outside the scope of the standard to define this and there would be no way to enforce its usage.

There's already mention of using Schematron elements elsewhere, in informative Annex "Use of Schematron as a vocabulary" allowing the technique Rick describes. With embedding individual rules and patterns, we're really into implementation territory, I feel.