[tei-council] proc mod queries 2

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 21/01/16 21:18, Lou Burnard wrote:

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