Dear all, a brief report on my work on correspDesc. (I’ll respond to Lou’s input separately) (I’m a little bit behind with documentation because my children passed their illnesses on to me …) So, I implemented correspDesc in revision 13129 and only needed three shots to make the Jenkins servers build the Guidelines (Yeah!). That said, I needed several tries locally before (which to my surprise worked almost flawlessly). I found it especially useful to run only the 'p5.xml‘ target which is quite quick and will create p5subset.xml along with p5.xml. This was helpful, because my naive assumption was that everything under P5/Source/Specs would automagically be included. It is not, you rather need a <specGrp> (in some Guidelines chapter?) with Xincludes of the files. * So, question 1: is this a bug or a feature? if it’s a feature (what I do think, because we do not implement elements without accompanying prose, do we?) it should probably be documented in TCW20 or did I missed it?! * question 2: how are the xml:ids (for <specGrp>s, <div>s etc) within the Guidelines chapters created? I just made them up … Best Peter
On 11/02/15 14:36, Peter Stadler wrote: > > everything under P5/Source/Specs would automagically be included. It is not, you rather need a <specGrp> (in some Guidelines chapter?) with Xincludes of the files. > * So, question 1: > is this a bug or a feature? if it’s a feature (what I do think, because we do not implement elements without accompanying prose, do we?) it should probably be documented in TCW20 or did I missed it?! It is definitely not a bug. Although component files (*Spec.xml) can lurk undetected in the Specs directory, they will not and should not be used to build anything unless they are explicitly Xincluded in the main source. There is a directory Source/Defunct into which such files go to die. > * question 2: > how are the xml:ids (for <specGrp>s, <div>s etc) within the Guidelines chapters created? I just made them up … Yes, that's how the rest of them were created!
HI Peter, TCW20 does include info on this: "Hence, to add a new element (say <saintName> ) you might proceed as follows: 1. Write a new file saintName.xml containing an <elementSpec> for your new element and add it to the Specs folder. Look at other specifications to see which ODD elements to use. Note that we do not use <valDesc> at this time, instead using only a <datatype> . 2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: " [example follows] We could perhaps be more specific about the fact that if you don't carry out step 2, then the spec won't be included. We definitely don't want to include spec files automatically, because there are often half-finished spec files in the folder under development. AFAIK, we just make up the ids for sections as we need them. :-) Cheers, Martin On 15-02-11 06:36 AM, Peter Stadler wrote:
Dear all,
a brief report on my work on correspDesc. (I’ll respond to Lou’s input separately) (I’m a little bit behind with documentation because my children passed their illnesses on to me …)
So, I implemented correspDesc in revision 13129 and only needed three shots to make the Jenkins servers build the Guidelines (Yeah!). That said, I needed several tries locally before (which to my surprise worked almost flawlessly). I found it especially useful to run only the 'p5.xml‘ target which is quite quick and will create p5subset.xml along with p5.xml. This was helpful, because my naive assumption was that everything under P5/Source/Specs would automagically be included. It is not, you rather need a <specGrp> (in some Guidelines chapter?) with Xincludes of the files. * So, question 1: is this a bug or a feature? if it’s a feature (what I do think, because we do not implement elements without accompanying prose, do we?) it should probably be documented in TCW20 or did I missed it?!
* question 2: how are the xml:ids (for <specGrp>s, <div>s etc) within the Guidelines chapters created? I just made them up …
Best Peter
Am 11.02.2015 um 17:48 schrieb Martin Holmes <mholmes@uvic.ca>:
2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: „ No, step 2 simply inserts the description of a given element at that point in the Guidelines. But you’ll also need a <specGrp> (not <specList>) to include that specification.
Best Peter
On 11/02/15 17:01, Peter Stadler wrote:
Am 11.02.2015 um 17:48 schrieb Martin Holmes <mholmes@uvic.ca>:
2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: „ No, step 2 simply inserts the description of a given element at that point in the Guidelines. But you’ll also need a <specGrp> (not <specList>) to include that specification.
Well, sorry, that is what the text says! "to reference the description..." it does *not* say "to include that specification"
Am 11.02.2015 um 19:31 schrieb Lou Burnard <lou.burnard@retired.ox.ac.uk>:
On 11/02/15 17:01, Peter Stadler wrote:
Am 11.02.2015 um 17:48 schrieb Martin Holmes <mholmes@uvic.ca>:
2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: „ No, step 2 simply inserts the description of a given element at that point in the Guidelines. But you’ll also need a <specGrp> (not <specList>) to include that specification.
Well, sorry, that is what the text says! "to reference the description..." it does *not* say "to include that specification“
That is exactly my point. The documentation is missing a step 3: „Edit the source of the relevant chapter to include a reference to the new element. Use a <specGrp>, like this: <specGrp xml:id="D2242" n="Calendar Description"> <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/calendarDesc.xml"/> <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/calendar.xml"/> </specGrp> „ Best Peter
Apologies, you're right. Now remedied: <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.2> Cheers, Martin On 15-02-11 09:01 AM, Peter Stadler wrote:
Am 11.02.2015 um 17:48 schrieb Martin Holmes <mholmes@uvic.ca>:
2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: „ No, step 2 simply inserts the description of a given element at that point in the Guidelines. But you’ll also need a <specGrp> (not <specList>) to include that specification.
Best Peter
Excellent, thank you Martin!
Am 11.02.2015 um 20:11 schrieb Martin Holmes <mholmes@UVIC.CA>:
Apologies, you're right. Now remedied:
<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.2>
Cheers, Martin
On 15-02-11 09:01 AM, Peter Stadler wrote:
Am 11.02.2015 um 17:48 schrieb Martin Holmes <mholmes@uvic.ca>:
2. Edit the source of the relevant chapter (presumably ND-namesdates.xml in this example) to include a documentation of the element. Use a <specList> to reference the description from your new spec within the body of the text, like this: „ No, step 2 simply inserts the description of a given element at that point in the Guidelines. But you’ll also need a <specGrp> (not <specList>) to include that specification.
Best Peter
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
participants (3)
-
Lou Burnard -
Martin Holmes -
Peter Stadler