Schematron at the level of model or class?

[martindholmes]

@lb42 raises an interesting question here:

https://github.com/TEIC/TEI/pull/2161#issuecomment-900951541

If Schematron is defined at the level of a model (or a class, I guess), is it correctly processed into working Schematron or not? In other words, does a Schematron rule defined in the context of model.pLike end up generating working Schematron that applies to all the members of model.pLike?

We should check, and if as I suspect it doesn't work, then we should first of all prevent constraintSpec as a child of <classSpec>, and then decide if we want to make this work, and if so, how to do it.

[sydb]

Huh? We have 13 <constraintSpec>s inside <classSpec> in the GLs,[1] (and at least 1 more in tei_customization.odd and 3 more in tei_simplePrint.odd) and although I have not looked at each carefully, I have looked at a few and quickly glanced at the others, and they all make sense to me.

Yes, as currently construed one needs to specify a @context to use a Schematron constraint inside a <classSpec>, but that is not much of a problem, especially for those (like you, @martindholmes) who think you should always specify a @context, anyway!

More importantly, it is difficult (and fragile) to differentiate between the attributes defined by the class and attributes similarly named elsewhere. E.g., to write a constraint that catches the @function of att.segLike, but not the @function of <material> and <metamark> is a pain.

And, most importantly (i.e., the biggest problem, I think), there is no way to express “any attribute defined by this class” or “members of this class”, you just have to list them, and change that list when the attributes or membership changes. I suspect that we could set up a system using abstract patterns and changes to the stylesheets that could do the right thing for the implied context of class membership, but I am not sure, and it would be a lot of work.

notes

[1] They are: %att.datable.w3c; has att-datable-w3c-when %att.datable.w3c; has att-datable-w3c-from %att.datable.w3c; has att-datable-w3c-to %att.datable; has calendar %att.measurement; has att-measurement-unitRef %att.typed; has subtypeTyped %att.pointing; has targetLang %att.spanning; has spanTo-2 %att.styleDef; has schemeVersionRequiresScheme %att.repeatable; has MINandMAXoccurs %att.identified; has spec-in-module %att.deprecated; has deprecation-two-month-warning %att.deprecated; has deprecation-should-be-explained

[lb42]

All 13 existing cases are of an attribute class though. Is a constraint within a model class correctly processed?

Reluctantly using Outlook for Androidhttps://aka.ms/ghei36

---

From: Syd Bauman @.> Sent: Thursday, August 19, 2021 3:03:13 AM To: TEIC/Stylesheets @.> Cc: Lou Burnard @.>; Mention @.> Subject: Re: [TEIC/Stylesheets] Schematron at the level of model or class? (#519)

Huh? We have 13 s inside in the GLs,[1] (and at least 1 more in tei_customization.odd and 3 more in tei_simplePrint.odd) and although I have not looked at each carefully, I have looked at a few and quickly glanced at the others, and they all make sense to me.

Yes, as currently construed one needs to specify a @context to use a Schematron constraint inside a , but that is not much of a problem, especially for those (like you, @martindholmeshttps://github.com/martindholmes) who think you should always specify a @context, anyway!

More importantly, it is difficult (and fragile) to differentiate between the attributes defined by the class and attributes similarly named elsewhere. E.g., to write a constraint that catches the @function of att.segLike, but not the @function of and is a pain.

And, most importantly (i.e., the biggest problem, I think), there is no way to express “any attribute defined by this class” or “members of this class”, you just have to list them, and change that list when the attributes or membership changes. I suspect that we could set up a system using abstract patterns and changes to the stylesheets that could do the right thing for the implied context of class membership, but I am not sure, and it would be a lot of work.

notes

[1] They are: %att.datable.w3c; has att-datable-w3c-when %att.datable.w3c; has att-datable-w3c-from %att.datable.w3c; has att-datable-w3c-to %att.datable; has calendar %att.measurement; has att-measurement-unitRef %att.typed; has subtypeTyped %att.pointing; has targetLang %att.spanning; has spanTo-2 %att.styleDef; has schemeVersionRequiresScheme %att.repeatable; has MINandMAXoccurs %att.identified; has spec-in-module %att.deprecated; has deprecation-two-month-warning %att.deprecated; has deprecation-should-be-explained

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/TEIC/Stylesheets/issues/519#issuecomment-901529538, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAFBJ5CM6TP4CMMI7JQ2H4DT5RJ5DANCNFSM5CMJ6JZA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[martindholmes]

I think @sydb you slightly missed my point. As it stands, constraints can be specified in multiple locations for two distinct purposes: for tidiness (put the constraint inside the elementSpec it applies to) and as a shortcut for context (put the constraint inside the elementSpec and trust the processing to derive and express the correct context at build time). The P5 source no longer does the latter, IIRC -- I think we always supply the full @context -- but we used to. Other ODD authors might still have examples of constraintSpecs which expect the processor to derive the correct context.

So my question was simply: does the processing find a constraintSpec in the context of a model class and do something with it, and if it does do something with it, does it make any attempt to derive a context or does it expect the context to be fully expressed? Maybe it's not a question worth answering, and maybe nobody does this or will ever do it. But I thought it was worth having the Stylesheets group take a look at it.

[sydb]

@lb42: Well, in the sense that nothing goes wrong, I guess it is correctly processed: IIRC the Schematron comes through ODD processing just fine. But there is no attempt in the Stylesheets to supply a proper default @context for a model class. Thus you (the ODD writer) need to provide a @context yourself. Worse, you are left without any way to say “the context is any element in this class” — you have to list the members manually if that’s what you want. (Which appropriately rubs us all the wrong way, of course.)

@martindholmes: Gotcha. I think reply to @lb42, immediately above, answers your question. (But note that of the 82 <constraintSpec>s in the Guidelines, 50 of them do not have a @context within.) To be clear I am not remotely against taking a look at this situation and trying to make it better. I just tested, BTW, and if you do not specify a context in a model class, the Stylesheets use just context="*", which seems like a bad idea. So at least for the moment a constraint that says “don’t do this” is probably in order.

[sydb]

We (@martindholmes, @HelenaSabel, and I) think that, while this should be fixed, it is not going to be fixed for months or years, if ever. So in the meantime we should instead open a TEI issue for adding a constraint that warns a user not to do this (or that she will get the wrong result if she does, or whatever). By “this” I mean use a <constraintSpec> without an explicit @context inside a <classSpec> (or anywhere else without an implicit context generated by the Stylesheets).

So, until that ticket is created and acted on, no need to assign this to anyone.

[lb42]

As originally designed, I think, constraintSpec was supposed to protect the user from knowing too much about the mysteries of schematron. So there is no direct way of specifying @context within your ODD source, except of course in the schematron code itself. Instead there are some simplifying assumptions -- the context is the element within whose spec the constraint is being declared, for example; or the context is the document root when the constraintSpec appears outside of an elementSpec. I think it would be sensible to add another such simplifying assumption about the case where a constraintSpc appears inside a classSpec. And maybe these assumptions need to be better documented somewhere, for the benefit of idiots like me who keep forgetting things...