New namespace and annex for new features?

[rjelliffe]

As a language grows, it becomes a large implementation effort for new developers and entrants. I think we can see that with XSLT 3, where there is a very large implementation effort compared to even XSLT 1. I think one of the strengths of Schematron is that it can be implemented with relative small effort (compared to other schema languages.)

So I think ISO's strategy should be to arrange updates in a way that helps new entrants, by partitioning features.

In real tactical terms, I suggest that new features and changed be divided into "core" and "full".

• The "core" would be those features that an implementation cannot ignore: for example, "sch:rule", "sch:rule-set" and "sch:phase" go to construction and execution and so are core. Every implementation must honour them.
• The "full" are those features that relate to reporting, which an implementation may not find useful or necessary. For example: sch:title, sch:assert/@Severity, sch:diagnostic, sch:property. An implementation does not need to use them, but should not barf on them.

On top of this, I think the editor should consider whether any new non-core elements or attributes should go into a second namespace, and that this namespace and the changes should all be in a normative annex. In other words,

• Core Schematron elements and attributes are in the standard body
• Existing non-code Schematron elements and attribute continue in the standard body
• New non-core Schematron elements and attributes go in a new normative annex with a new names.

So an implementer always has to implement the core features. And they decide how to handle the non-core elements and attributes (which could be to ignore them: it does not change the basic result of any assertion in any fired rule, but it could affect what information is reported.)

[AndrewSales]

A namespace change was discussed at length in #42 and rejected by the Working Group. What is the intention behind raising it again here?

I don't think the language has grown significantly enough at this time to justify the editorial effort involved in partitioning the standard as suggested. There are also benefits of continuity in maintaining the text of the standard and understanding how it has evolved which can be had by leaving its structure essentially intact.

[rjelliffe]

The proposal in #42 was not for a new namespace. It was for a comprehensive system to allow versioning with namespaces, to allow better management. Without such a mechanism, namespaces become untenable and work against schema evolution. This proposal is to use namespaces so that 1) The use of new elements that do not change assertion status will not cause an existing Schematron implementation to barf unnecessarily. Because they are in the new namespace and regarded as foreign elements. This encourages their adoption with the legacy framework. 2) The use of new elements that could change the assertion status will cause an existing Schematron implementation to barf. Because they are not known. This proposal was not discussed as part of #42 AFAICS Rick

…

On Tue, Aug 20, 2024 at 3:11 AM Andrew Sales ***@***.***> wrote: A namespace change was discussed at length in #42 <#42> and rejected by the Working Group. What is the intention behind raising it again here? I don't think the language has grown significantly enough at this time to justify the editorial effort involved in partitioning the standard as suggested. There are also benefits of continuity in maintaining the text of the standard and understanding how it has evolved which can be had by leaving its structure essentially intact. — Reply to this email directly, view it on GitHub <#78 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKOX54QQRA4F2ISZ2DTZSIRK7AVCNFSM6AAAAABMPQQ5QWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJXGA2DKNZTHA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>