Hi Magda and thanks for the quick reply. While you're there, let me explain that the main change I've had to make so far has been in the way things are tweaked so as to permit <paramList> to appear within <valItem>. The version James checked in earlier did this by simply adding <paramList> to the model.descLike class. But that means <paramList> pops up in all sorts of places where it makes no sense, e.g. inside <person>. So I have taken the view that it would be better to add it explicitly to the content of <valItem>, and chosen a place for it after the model.descLike elements, rather than before them, for consistency with other content models. Hope that doesn't annoy anyone... On 21/01/16 20:57, Magdalena Turska wrote:

Hi Lou,

thanks for pointing this out. I believe that having @output as a closed list is indeed wrong. Not only output could be given as any format, as yet unforeseen even, but output is basically any view of the document one might want to produce, thus 'print-for-ones-who-could-not-be-bothered-with-footnotes' might well coexist with 'print-as-we-would-send-to-UOP', both targetting same format but presenting the document in a distinct way.

Thus having answered a) I believe b) is a moot point (@output value is just an identifier of a transformation defined by models for which this output applies).

Asking Simpletons doesn't hurt. Much. I hope. :)

Magdalena

On 21 January 2016 at 20:35, Lou Burnard wrote:

...

I've made a bit more progress on the "processing model" extensions to ODD proposed by the TEI Simpletons a while ago, and now have a version of P5 based on the current dev branch which includes them AND builds correctly. But I havent yet finished hacking the prose into shape, and I have some questions.

Here's the first.

The @output attribute "the intended output method" (that's clearly wrong though; surely it should be "the intended output target"?) is defined with a closed list of values "web", "print", and "plaintext".

a) why is this a closed list? I can think of lots of other possible values e.g. "mobile device", "PDF", "text-to-speech synthesizer" for starters...

b) what exactly does "plaintext" mean?

And here's the zero'th. To whom if not the Council should I be addressing this query?

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

Lou -- Has this been dealt with, yet? My instinct is that we need a general purpose system, because I might want to express equivalences in DocBook or NLM, not HTML. As for <outputRendition>, I guess the same is true. Why shouldn't I be allowed to express my output in DSSSL or FO or Waterloo Script? But two thoughts on outputRendition: * The @versionDate on most everything is set to May of 2009. * I'm thinking that maybe "first-letter" should be "first-character". After all, it might be a numeral, a dingbat, or an arithmetic symbol instead.

Oh, and here's another one.

The <equiv> element is used quite a lot in the current document, apparently to provide an HTML element which behaves more or less the same as some model behaviour. For example

<valItem ident="link"> <desc versionDate="2015-08-21" xml:lang="en">create hyperlink</desc> <equiv name="a"/> <paramList> <paramSpec ident="content"/> <paramSpec ident="uri"> <desc versionDate="2015-08-21" xml:lang="en">link url</desc> </paramSpec> </paramList> </valItem>

(Note incidentally, that I took it on myself to give the second parameter a different name from the behaviour to which it is attached -- both were formerly known as "link", which I found just too confusing)

My question is: how on earth do I know that "a" is the name of an HTML element rather than (say) the indefinite article ? It certainly isn't defined as such in the TEI spec for <equiv> which says this attribute names "the underlying concept of which the parent is a representation" It makes me feel rather uncomfortable to be special casing this usage without explanation of any sort.

In much the same way, although the draft doesn't say it explicitly anywhere, am I right in thinking that the value of <outputRendition> is *by definition* a piece of CSS, and can never be anything else?

On 05/02/16 16:17, Syd Bauman wrote:

Lou --

Has this been dealt with, yet?

Not to my knowledge.

My instinct is that we need a general purpose system, because I might want to express equivalences in DocBook or NLM, not HTML.

This is a comment on the spec for <equiv>, right? Do you have a suggestion as to how I'm supposed to know that <equiv name="foo"/> means this element is equivalent to docbook:foo , or html:foo or what?

As for <outputRendition>, I guess the same is true. Why shouldn't I be allowed to express my output in DSSSL or FO or Waterloo Script? Because if you do we need to know which it is, and it's not clear where you'd specify that. Certainly not at the level of individual <outputRendition>s, we hope.

But two thoughts on outputRendition:

* The @versionDate on most everything is set to May of 2009.

I blame James for careless cut and paste. Will fix.

* I'm thinking that maybe "first-letter" should be "first-character". After all, it might be a numeral, a dingbat, or an arithmetic symbol instead.

Yes, changed accordingly.

...

Oh, and here's another one.

The <equiv> element is used quite a lot in the current document, apparently to provide an HTML element which behaves more or less the same as some model behaviour. For example

<valItem ident="link"> <desc versionDate="2015-08-21" xml:lang="en">create hyperlink</desc> <equiv name="a"/> <paramList> <paramSpec ident="content"/> <paramSpec ident="uri"> <desc versionDate="2015-08-21" xml:lang="en">link url</desc> </paramSpec> </paramList> </valItem>

(Note incidentally, that I took it on myself to give the second parameter a different name from the behaviour to which it is attached -- both were formerly known as "link", which I found just too confusing)

My question is: how on earth do I know that "a" is the name of an HTML element rather than (say) the indefinite article ? It certainly isn't defined as such in the TEI spec for <equiv> which says this attribute names "the underlying concept of which the parent is a representation" It makes me feel rather uncomfortable to be special casing this usage without explanation of any sort.

In much the same way, although the draft doesn't say it explicitly anywhere, am I right in thinking that the value of <outputRendition> is *by definition* a piece of CSS, and can never be anything else?

OK, thanks for the clarification: could you supply an example we could add to the prose to make this point succintly? On 06/02/16 11:36, Magdalena Turska wrote:

Can we get back to this discussion? Section on Outputs http://teic.github.io/TEI/TD.html#TDPMOU is where I have most objections to the current prose. Starting with '@output attribute is used to associate particular processing models with a specific type of output channel or output format' I don't like the assumption that output is the same as format/channel/device, and the current wording suggests there can be one set of processing directives per 'type of output'. I think this is a common case where multiple views of the document are offered for the same channel/output/format, eg like here http://vangoghletters.org/vg/letters/let570/letter.html view of the letters with/without line endings. Format stays the same (HTML), channel/device stays the same (website), but still we would be talking two (even if only slightly) different @outputs in the odd.

Thus I believe we should avoid suggesting that `output` means `format` and state somewhere that @output is just an identifier of a certain intended processing scenario. And provide an example that illustrates this.

Am I the only one having trouble with this?

Magdalena

On 21 January 2016 at 20:57, Magdalena Turska wrote:

...

Hi Lou,

thanks for pointing this out. I believe that having @output as a closed list is indeed wrong. Not only output could be given as any format, as yet unforeseen even, but output is basically any view of the document one might want to produce, thus 'print-for-ones-who-could-not-be-bothered-with-footnotes' might well coexist with 'print-as-we-would-send-to-UOP', both targetting same format but presenting the document in a distinct way.

Thus having answered a) I believe b) is a moot point (@output value is just an identifier of a transformation defined by models for which this output applies).

Asking Simpletons doesn't hurt. Much. I hope. :)

Magdalena

On 21 January 2016 at 20:35, Lou Burnard wrote:

...

I've made a bit more progress on the "processing model" extensions to ODD proposed by the TEI Simpletons a while ago, and now have a version of P5 based on the current dev branch which includes them AND builds correctly. But I havent yet finished hacking the prose into shape, and I have some questions.

Here's the first.

The @output attribute "the intended output method" (that's clearly wrong though; surely it should be "the intended output target"?) is defined with a closed list of values "web", "print", and "plaintext".

a) why is this a closed list? I can think of lots of other possible values e.g. "mobile device", "PDF", "text-to-speech synthesizer" for starters...

b) what exactly does "plaintext" mean?

And here's the zero'th. To whom if not the Council should I be addressing this query?

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