Re: [tei-council] Proofreading processing model rewrite

Many thanks (again) for your careful reading! These fixes all applied, except that I am not sure what to do about where to place the <specDesc> for paramList. L On 27/01/16 19:02, Scholger, Martina (martina.scholger@uni-graz.at) wrote:

Dear Lou,

here is the rest of the comments...

22.5.5.4 Behaviours and their parameters

-- In the examples above we have used without explanation or definition two simple behaviours : a superfluous whitespace before the colon -- ...inline and block, but here, the behaviours inline and block are encoded with <code>, later, behaviours and parameters are elsewhere encoded with <ident> -- The 'parameters' of a 'behaviour' resemble the arguments of a function in many programming languages: here, parameters and behaviour is encoded with <soCalled>, in the sentences before with <term>. Is that intentional? -- <elementSpec ident="ref" mode="add"> <model behaviour="link"> <param name="uri"> @target </param> <param name="content"> . </param> </model> </elementSpec>

superfluous whitespace before and after @target and .

<elementSpec ident="ref" mode="add"> <model behaviour="link"> <param name="uri">@target</param> <param name="content">.</param> </model> </elementSpec> -- The parameters available for a given behaviour are defined as a part of the definition of the behavioour double "oo" in behaviour -- Chapter 22.5.5.4 additionaly lists the elements <paramList> and <paramSpec>. It is a bit confusing that the description and example of <paramList> is in 22.5.5.7. Furthermore, 22.5.5.7. has the same name as 22.5.5.1: "Defining a processing model". Maybe a consequence of rearranging the chapters? I would either merge chapter 22.5.5.7 here, or move the <specList> (paramList and paramSpec) to 22.5.5.7 and refer to 22.5.5.4. --------------------------

22.5.5.5 Outputs

...intended to cope with at least the following three situations : a superfluous whitespace before the colon -- 2. there is no text inside the element but there is a when encoding of when as <att>when</att> ---------------------------

22.5.5.6 Model sequence

...the online behaviour inline instead of online -- (called "footnote" here) behaviours (footnote) are elsewhere encoded with <ident> -- given by the parameter place missing colon after place -----------------------------

22.5.5.7 Defining a processing model

see above, 22.5.5.7 has the same name as chapter 22.5.5.1 -- link behaviour presented above : a superfluous whitespace before the colon -- Similarly the valItem which defines the behaviour named alternate has two parameters: one also called alternate and the other called default behaviours (alternate) and parameters (alternate, default) are elsewhere encoded with <ident> ----------------------------

22.5.5.8 Implemention

...should be acted upon . a superfluous whitespace before the period -- ...attributes, element, and text nodes elements (plural?) -- ...The special behaviour omit behaviours (omit) are elsewhere encoded with <ident>

-----Ursprüngliche Nachricht----- Von: tei-council-bounces@lists.tei-c.org [mailto:tei-council-bounces@lists.tei-c.org] Im Auftrag von Lou Burnard Gesendet: Mittwoch, 27. Jänner 2016 12:04 An: tei-council@lists.tei-c.org Betreff: Re: [tei-council] Proofreading processing model rewrite

Thanks for the careful proofing Martina! I've fixed all those up.

My bad habit of putting spaces before colons is probably the effect of working in France too long (where people complain if I don't) ...

On 26/01/16 20:13, Scholger, Martina (martina.scholger@uni-graz.at) wrote:

...

Dear Lou,

I have started with the proofreading of the processing model (from 22.5.5 to 22.5.5.3) and found some typos. My suggestions are listed below. Do you find that useful or would you prefer some other format for further feedback?

Best, Martina

22.5.5 Processing Models

@modelSequence (sequence of processing model ) there is an superfluous whitespace before the closing bracket

I would suggest to do the listing of the elements (<model>, <modelSequence>, <modelGrp>) in the same order as the following description. In the description the order is <model>, <modelGrp>, <modelSequence>.

22.5.5.1 .This is achieved by means of the following attributes and elements : a superfluous whitespace before the colon

@predicate the condition under which this model applies, given as an XPath Predicate Expression "predicate expression" in lower case like in 22.5.5.4

@behaviour names the process or function which this processing model uses in order to produce output missing period after output

@output the intended output method missing period after method

@predicate, @behaviour As above, the sequence of attributes is different than the sequence of their description

22.5.5.3 Model Contexts and Outputs

In the second example, the content of the <outputRendition> has an superfluous whitespace before the colon and there is a semicolon missing: <outputRendition>font-size : 7pt</outputRendition> In keeping with the first example, it should look like this: <outputRendition>font-size: 7pt;</outputRendition>

-----Ursprüngliche Nachricht----- Von: tei-council-bounces@lists.tei-c.org [mailto:tei-council-bounces@lists.tei-c.org] Im Auftrag von Hugh Cayless Gesendet: Dienstag, 26. Jänner 2016 20:57 An: TEI Council Betreff: Re: [tei-council] Proofreading processing model rewrite

On Tue, Jan 26, 2016 at 2:49 PM, Lou Burnard wrote:

...

On 26/01/16 15:54, Hugh Cayless wrote:

...

I've done it, but it's not hard:

Thanks!

...

1) Make the html-web target in the branch you want 2) git checkout gh-pages 3) cd to the root of the repo

er, which repo exactly?

...

4) rsync -av P5/Guidelines-web/en/html/ ./ (i.e. copy the HTML files to the root directory)

root of what? The TEI repo

...

5) git add, commit, push (if your changes mean new files, you'll need to

...

explicitly add them)

new HTML files you mean? Yeah, if you've defined a new element, for example, you'll have a new reference page for it.

...

"gh-pages" is just a branch that has HTML content in it. When you push it,

...

GitHub publishes it to the github.io site.

We could automate this, but it seems it might be a good thing to have a site that's a bit more stable than Jenkins, which updates with every push, and that allows us to put up builds from branches without doing anything special. What do you all think?

I'm not sure what you're suggesting but I'm not very keen on cluttering up the repo with lots of versions of generated HTML.

They only exist in the branch, so they're not really cluttering anything up.

...

...

On Tue, Jan 26, 2016 at 7:35 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

I've now made some further revision to the structure of the chapter. Does

...

the github.io version update itself automatically, or do I need to do something ?

On 26/01/16 11:25, Lou Burnard wrote:

Thanks for the quick reaction James. Some comments below

...

-- 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

-- 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