From 71797f3a7a7975fd9fdf50986792f85f4ae68cff Mon Sep 17 00:00:00 2001 From: Syd Bauman Date: Sun, 8 Sep 2024 19:54:30 -0400 Subject: [PATCH] various tweaks, some important: * more truthful discussion of sch:ns element * fixed incorrect context= attributes in an example * added missing Oxford comma * removed no longer valid reference to "isoschematron" as value for scheme= attribute * reversed logic: i.e., changed an sch:report that tested not(TST) to an sch:assert that tests TST. --- .../en/TD-DocumentationElements.xml | 49 ++++++++++--------- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/P5/Source/Guidelines/en/TD-DocumentationElements.xml b/P5/Source/Guidelines/en/TD-DocumentationElements.xml index d5acac80bc..bf9cd341f8 100644 --- a/P5/Source/Guidelines/en/TD-DocumentationElements.xml +++ b/P5/Source/Guidelines/en/TD-DocumentationElements.xml @@ -837,8 +837,9 @@ to mark any technical term, thus: + - One of the attributes @name, @ref or @key must be supplied + One of the attributes @name, @ref, or @key must be supplied @@ -858,15 +859,17 @@ to mark any technical term, thus:

-

The constraints in the preceding example all related to attributes in the empty namespace, and the - Schematron rules did not therefore need to define a TEI namespace prefix. The Schematron language ns element should be used to do this when a constraint needs to refer to a - TEI element, as in the following example, which models the constraint that a TEI div must - contain either no subdivisions or at least two of them: +

Note that the tei: prefix needs to be bound to the TEI + namespace using the Schematron language ns element, but typically this only + need be done once. The following two examples are written + presuming that the namespace binding for tei: has occured + elsewhere. The first models the constraint that a TEI + div must contain either no subdivisions or at least two + of them: - if it contains any subdivisions, a division must contain at least two of them @@ -874,19 +877,21 @@ to mark any technical term, thus: - Schematron rules are also useful where an application needs to enforce rules on attribute values, as - in the following examples which check that various types of title are provided: + The second demonstrates that Schematron rules are also useful + where an application needs to enforce rules on attribute values, + here checking that various types of title are provided + in the TEI header: - + an introductory component of the title is expected - + a main title must be supplied @@ -903,8 +908,8 @@ to mark any technical term, thus: - You should provide information in a figure from - which we can construct an alt attribute in HTML + You should provide information in a figure from + which we can construct an alt attribute in HTML @@ -918,9 +923,8 @@ to mark any technical term, thus: - A <table> should have a caption, using a <head> - element - Do not use tables to lay out the document body + A <table> should have a caption, using a <head> element + Do not use tables to lay out the document body @@ -943,12 +947,13 @@ to mark any technical term, thus: customization that (among other things) adds and explains this value for use in validating their customization file. Thus using schemes other than those provided for by the TEI - (currently schematron and isoschematron) - may require somewhat more effort when creating a customization - file. Such private schemes will generally be even more - problematic on implementation of the constraints themselves, - as it may require siginficant programming work. The TEI only - provides this capability for the suggested values.

+ (currently only schematron) may require somewhat + more effort when creating a customization file. Such private + schemes will generally be even more problematic on + implementation of the constraints themselves, as it may + require siginficant programming work. The TEI only provides + this capability for the suggested value + (schematron).

Attribute List Specification