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