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

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?

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

new HTML files you mean?

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

On Tue, Jan 26, 2016 at 7:35 AM, Lou Burnard 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

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

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

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

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

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

I agree that it's really not satisfactory to have numbering down to 5 levels, and I did try this as a new 22.4.5, but that makes a mess of the current organisation of the chapter. The procmod stuff ought to be a sibling of what are currently 22.4.4.1 and 22.4.4.2, since these sections all describe children of elementSpec. I will have another crack at organizing things better. Yes. You have a better sense of elsewhere in the guidelines where we do this but it seemed weird to me (especially since procmod has so many of its own sections). I'll have a look at what you've done later.

Yes, "In the present implementation" was just wiggle room in case we decide not to use CSS in the future. See below.

Ah, so implementation in the sense of 'in this release of the TEI Guidelines'? Yes, below.

...

You are right that at the bottom of the Output Rendition section we could say something about 'Why CSS', but this is for the same reason that we suggest elsewhere inside the <rendition> element as a formally declared stylesheet language. This might suggest that we should be having a @scheme attribute like <rendition> with css as a value? Well, that's one of my major unresolved questions. *Do* we want to permit anything other than CSS?

I think we should probably mirror what we do on <rendition> where it is possible to use something else, but all our examples and recommendation is to use CSS where possible.

Much clearer, thanks.

thanks. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford