Support alternative method of declaring namespaces

[AndrewSales]

as suggested by @dmj in his presentation about ATOP at the 2023 SUM. This technique embeds SCH constraints and the existing ns method of declaring namespaces is cumbersome.

[sydb]

I am not 100% sure, but my instinct is that I am in favor. I presume the idea is that whenever you (the Schematron processor) need to resolve a namespace prefix (typically from a @context, a @select, or a @test) you examine all the ../namespace::* or all the ../namespace-node(), eh?

Sounds like a lot simpler way of doing things. In the worst case, of course, it is probably very expensive to go around looking up all the namespace nodes all the time. But I am betting that for the vast majority of Schematron schemas some serious optimizations could be performed, no?

[AndrewSales]

Thanks, Syd - glad to have you along.

I honestly haven't thought much about the how yet, having just noted this in the moment at the meetup. But what you describe sounds plausible.

@dmj did you already have some ideas around this? If we can put our heads together to find a viable route, it will probably merit an entry over at https://github.com/Schematron/schematron-enhancement-proposals/issues.

[dmj]

I though about two possibilities:

a. Keep sch:ns and allow it as child of sch:pattern, sch:assert, sch:report, sch:diagnostics, schand sch:rule and so on. A sch:ns as child of a, say, sch:pattern defines the namespace bindings for all contained rules.

b. Deprecate sch:ns and use the standardized namespace declaration mechanism. A query language expression would have access to all namespace bindings declared on the containing element or one of its parents.

[AndrewSales]

Thank you. (b) is appealing -- ns is easy to process, but it's never felt very XML-y.

[AndrewSales]

As you can see, raised as https://github.com/Schematron/schematron-enhancement-proposals/issues/62. Please do chip in if I misrepresent.