CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Kevin Hawkins
On 2:59 PM, John A. Walsh wrote:

> Please see my comments below.
>
> On Wednesday, March 21, 2012 at 11:56 AM, Martin Holmes wrote:
>> If we're going to encourage people to use @html:style, then we need
>> to build that into the system (in other words, we need to formally
>> adopt that attribute, in its namespace). The same proposal was
>> originally made with regard to<zone>/@points (for which we could
>> have used the @svg:points), but in the event we decided not to, and
>> created our own @points attribute.
>>
>> So I think we have two distinct proposals on the table:
>>
>> 1. Change the datatype of @rend so that CSS code with spaces
>> violates neither the letter nor the spirit of the datatype.
>>
>> 2. Formally adopt @html:style, and update the Guidelines to
>> strongly encourage people using CSS to switch from @rend to
>> @html:style.
>>
>> I could live with either of these, personally, although the second
>> would involve some work on existing code and markup.
>
>
> I also prefer option 1, the problem with with option 2 is that it
> implies that the CSS is describing desired HTML output rather the the
> renditions encountered in the source document. There is still a
> need/desire to use CSS to describe the renditions of the source
> document, and for this purpose, @rend seems more appropriate. But I
> wholeheartedly endorse option 1.

I disagree with John Walsh's interpretation of option 2.  When the TEI
uses an attribute from the xml: namespace, such as @xml:lang, we simply
say that the lang= attribute is to be used as defined in that namespace
(in the case of xml:, these are defined in the XML spec).

Likewise, when we specify @html:rend, we are saying that the rend=
attribute is to be used as defined in the html: namespace.  If a TEI
document includes a namespace declaration for html: that points to an
XHTML spec, you can refer to that specification for the semantics of
this element.  The XHTML spec says to use this element only with certain
values expressed in CSS.

I prefer (2) because it means that in the distant future, once use of
CSS strings is no longer allowed in @tei:rend, anyone processing a
heterogeneous corpus of TEI texts can easily process @tei:rend and
@html:rend differently.

--Kevin
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Martin Holmes
Kevin, I think you mean @html:style rather than @html:rend, don't you?

There's one other issue we might consider with regard to @html:style.
The XHTML spec includes a CSS stylesheet full of default values which
specify, for instance, that <div> is a block element, and <span> is
inline. Most users of CSS in the (X)HTML realm never really think about
this, but it has implications (for instance, setting "text-align:
center" on <span> will normally have no effect because it has a default
property of "display: inline").

When we write stylesheets for rendering TEI to XHTML, we also piggy-back
on this default stylesheet; we have no need to specify that <tei:list>
is a block element if we're converting it to <html:ul>. There are in TEI
a great many such assumptions, particularly with regard to display
attributes. <tei:table>, for instance, is presumably inherently
"display: table".

We might want to consider making these default assumptions explicit in
the form of a default CSS stylesheet for TEI elements, so that users of
@html:style (or @rend with CSS, if that's the preferred route) will know
what they're starting from, and what they need to be explicit about.

Cheers,
Martin

On 12-03-22 04:00 PM, Kevin Hawkins wrote:

> On 2:59 PM, John A. Walsh wrote:
>> Please see my comments below.
>>
>> On Wednesday, March 21, 2012 at 11:56 AM, Martin Holmes wrote:
>>> If we're going to encourage people to use @html:style, then we need
>>> to build that into the system (in other words, we need to formally
>>> adopt that attribute, in its namespace). The same proposal was
>>> originally made with regard to<zone>/@points (for which we could
>>> have used the @svg:points), but in the event we decided not to, and
>>> created our own @points attribute.
>>>
>>> So I think we have two distinct proposals on the table:
>>>
>>> 1. Change the datatype of @rend so that CSS code with spaces
>>> violates neither the letter nor the spirit of the datatype.
>>>
>>> 2. Formally adopt @html:style, and update the Guidelines to
>>> strongly encourage people using CSS to switch from @rend to
>>> @html:style.
>>>
>>> I could live with either of these, personally, although the second
>>> would involve some work on existing code and markup.
>>
>>
>> I also prefer option 1, the problem with with option 2 is that it
>> implies that the CSS is describing desired HTML output rather the the
>> renditions encountered in the source document. There is still a
>> need/desire to use CSS to describe the renditions of the source
>> document, and for this purpose, @rend seems more appropriate. But I
>> wholeheartedly endorse option 1.
>
> I disagree with John Walsh's interpretation of option 2.  When the TEI
> uses an attribute from the xml: namespace, such as @xml:lang, we simply
> say that the lang= attribute is to be used as defined in that namespace
> (in the case of xml:, these are defined in the XML spec).
>
> Likewise, when we specify @html:rend, we are saying that the rend=
> attribute is to be used as defined in the html: namespace.  If a TEI
> document includes a namespace declaration for html: that points to an
> XHTML spec, you can refer to that specification for the semantics of
> this element.  The XHTML spec says to use this element only with certain
> values expressed in CSS.
>
> I prefer (2) because it means that in the distant future, once use of
> CSS strings is no longer allowed in @tei:rend, anyone processing a
> heterogeneous corpus of TEI texts can easily process @tei:rend and
> @html:rend differently.
>
> --Kevin
> .
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
([hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Kevin Hawkins
Yes, sorry for any confusion!

On 3/22/12 7:23 PM, Martin Holmes wrote:
> Kevin, I think you mean @html:style rather than @html:rend, don't you?
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

John Walsh-2
In reply to this post by Kevin Hawkins
Kevin,

I'm afraid I have to disagree back.

The XHTML spec does not state the html's @style attribute must contain CSS. It states, "This module declares the 'style' attribute, used to support inline style markup." It does not redefine @style from its previous definition in HTML 4, which states: "The syntax (http://www.w3.org/TR/REC-html40/types.html#type-style) of the value of the style (http://www.w3.org/TR/REC-html40/present/styles.html#adef-style) attribute is determined by the default style sheet language (http://www.w3.org/TR/REC-html40/present/styles.html#default-style). For example, for [[CSS2]] inline style, use the declaration block syntax described in section 4.1.8 (without curly brace delimiters)." That default style sheet language may be (and almost always is) CSS, but it doesn't have to be. The spec goes on to explain how to declare a default stylesheet language with a <meta> tag. If CSS was the only style language allowed by the spec, there would also be no need for the @type="text/css" on the <style> el!
 ement.

HTML's @style does have the advantage (over TEI's @rend) of specifying a mechanism to declare what sort of values are being thrown into the attribute. I had recommended previously that TEI implement such a mechanism. The TEI Guidelines do not prescribe the use of any particular standard in @rend. I believe that is as it should be. People should be free to use CSS, made-up style names, rendition ladders, whatever. But certainly it can only be helpful to provide a mechanism for TEI documents to declare what they are populating @rend with.

And I still see another problem with html's @style. TEI has always been very clear that @rendition and @rend are meant to describe rendition/style features in the *source* text. I believe that important clarity is lost with html's @style.  Now if one wanted to add an attribute to describe style instructions for a browser or other output system, then html's @style would be a very good choice.

John


On Thursday, March 22, 2012 at 7:00 PM, Kevin Hawkins wrote:

> On 2:59 PM, John A. Walsh wrote:
> > Please see my comments below.
> >
> > On Wednesday, March 21, 2012 at 11:56 AM, Martin Holmes wrote:
> > > If we're going to encourage people to use @html:style, then we need
> > > to build that into the system (in other words, we need to formally
> > > adopt that attribute, in its namespace). The same proposal was
> > > originally made with regard to<zone>/@points (for which we could
> > > have used the @svg:points), but in the event we decided not to, and
> > > created our own @points attribute.
> > >
> > > So I think we have two distinct proposals on the table:
> > >
> > > 1. Change the datatype of @rend so that CSS code with spaces
> > > violates neither the letter nor the spirit of the datatype.
> > >
> > > 2. Formally adopt @html:style, and update the Guidelines to
> > > strongly encourage people using CSS to switch from @rend to
> > > @html:style.
> > >
> > > I could live with either of these, personally, although the second
> > > would involve some work on existing code and markup.
> >
> >
> >
> >
> > I also prefer option 1, the problem with with option 2 is that it
> > implies that the CSS is describing desired HTML output rather the the
> > renditions encountered in the source document. There is still a
> > need/desire to use CSS to describe the renditions of the source
> > document, and for this purpose, @rend seems more appropriate. But I
> > wholeheartedly endorse option 1.
>
>
>
> I disagree with John Walsh's interpretation of option 2. When the TEI
> uses an attribute from the xml: namespace, such as @xml:lang, we simply
> say that the lang= attribute is to be used as defined in that namespace
> (in the case of xml:, these are defined in the XML spec).
>
> Likewise, when we specify @html:rend, we are saying that the rend=
> attribute is to be used as defined in the html: namespace. If a TEI
> document includes a namespace declaration for html: that points to an
> XHTML spec, you can refer to that specification for the semantics of
> this element. The XHTML spec says to use this element only with certain
> values expressed in CSS.
>
> I prefer (2) because it means that in the distant future, once use of
> CSS strings is no longer allowed in @tei:rend, anyone processing a
> heterogeneous corpus of TEI texts can easily process @tei:rend and
> @html:rend differently.
>
> --Kevin
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Martin Mueller
I'd like to repeat my earlier comment that this discussion really calls
for an intelligent summary of the issues and options, and I'd like to add
an anecdote. Almost a decade ago I did a fair amount of work with Peter
Robinson's Anastasia and felt very proud about writing little tcl scripts
that actually worked and produced frames and iframes in reasonably
reader-friendly ways.

Several months ago I dove into eXist and xquery. I thought a knew a little
about TEI, could learn something about xquery, and that html would be the
simple thing. Guess what? The hard thing turned out to be html and more
specifically the relationship between TEI and html.

I think there is a lot of useful work that the Council could do here, not
only in terms of deciding what you can or cannot do with rend attributes
but in giving guidance to the perplexed about how to manage the
relationships between these two very different daughters of SGML. They may
not like each other very much, but they have to get along, and for the
likes of me getting them to get along is the hard thing.

MM

On 3/22/12 7:51 PM, "John A. Walsh" <[hidden email]> wrote:

>Kevin,
>
>I'm afraid I have to disagree back.
>
>The XHTML spec does not state the html's @style attribute must contain
>CSS. It states, "This module declares the 'style' attribute, used to
>support inline style markup." It does not redefine @style from its
>previous definition in HTML 4, which states: "The syntax
>(http://www.w3.org/TR/REC-html40/types.html#type-style) of the value of
>the style
>(http://www.w3.org/TR/REC-html40/present/styles.html#adef-style)
>attribute is determined by the default style sheet language
>(http://www.w3.org/TR/REC-html40/present/styles.html#default-style). For
>example, for [[CSS2]] inline style, use the declaration block syntax
>described in section 4.1.8 (without curly brace delimiters)." That
>default style sheet language may be (and almost always is) CSS, but it
>doesn't have to be. The spec goes on to explain how to declare a default
>stylesheet language with a <meta> tag. If CSS was the only style language
>allowed by the spec, there would also be no need for the @type="text/css"
>on the <style> el!
> ement.
>
>HTML's @style does have the advantage (over TEI's @rend) of specifying a
>mechanism to declare what sort of values are being thrown into the
>attribute. I had recommended previously that TEI implement such a
>mechanism. The TEI Guidelines do not prescribe the use of any particular
>standard in @rend. I believe that is as it should be. People should be
>free to use CSS, made-up style names, rendition ladders, whatever. But
>certainly it can only be helpful to provide a mechanism for TEI documents
>to declare what they are populating @rend with.
>
>And I still see another problem with html's @style. TEI has always been
>very clear that @rendition and @rend are meant to describe
>rendition/style features in the *source* text. I believe that important
>clarity is lost with html's @style.  Now if one wanted to add an
>attribute to describe style instructions for a browser or other output
>system, then html's @style would be a very good choice.
>
>John
>
>
>On Thursday, March 22, 2012 at 7:00 PM, Kevin Hawkins wrote:
>> On 2:59 PM, John A. Walsh wrote:
>> > Please see my comments below.
>> >
>> > On Wednesday, March 21, 2012 at 11:56 AM, Martin Holmes wrote:
>> > > If we're going to encourage people to use @html:style, then we need
>> > > to build that into the system (in other words, we need to formally
>> > > adopt that attribute, in its namespace). The same proposal was
>> > > originally made with regard to<zone>/@points (for which we could
>> > > have used the @svg:points), but in the event we decided not to, and
>> > > created our own @points attribute.
>> > >
>> > > So I think we have two distinct proposals on the table:
>> > >
>> > > 1. Change the datatype of @rend so that CSS code with spaces
>> > > violates neither the letter nor the spirit of the datatype.
>> > >
>> > > 2. Formally adopt @html:style, and update the Guidelines to
>> > > strongly encourage people using CSS to switch from @rend to
>> > > @html:style.
>> > >
>> > > I could live with either of these, personally, although the second
>> > > would involve some work on existing code and markup.
>> >
>> >
>> >
>> >
>> > I also prefer option 1, the problem with with option 2 is that it
>> > implies that the CSS is describing desired HTML output rather the the
>> > renditions encountered in the source document. There is still a
>> > need/desire to use CSS to describe the renditions of the source
>> > document, and for this purpose, @rend seems more appropriate. But I
>> > wholeheartedly endorse option 1.
>>
>>
>>
>> I disagree with John Walsh's interpretation of option 2. When the TEI
>> uses an attribute from the xml: namespace, such as @xml:lang, we simply
>> say that the lang= attribute is to be used as defined in that namespace
>> (in the case of xml:, these are defined in the XML spec).
>>
>> Likewise, when we specify @html:rend, we are saying that the rend=
>> attribute is to be used as defined in the html: namespace. If a TEI
>> document includes a namespace declaration for html: that points to an
>> XHTML spec, you can refer to that specification for the semantics of
>> this element. The XHTML spec says to use this element only with certain
>> values expressed in CSS.
>>
>> I prefer (2) because it means that in the distant future, once use of
>> CSS strings is no longer allowed in @tei:rend, anyone processing a
>> heterogeneous corpus of TEI texts can easily process @tei:rend and
>> @html:rend differently.
>>
>> --Kevin
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Sebastian Rahtz
In reply to this post by John Walsh-2
On 23 Mar 2012, at 00:51, John A. Walsh wrote:
>
> And I still see another problem with html's @style. TEI has always been very clear that @rendition and @rend are meant to describe rendition/style features in the *source* text. I believe that important clarity is lost with html's @style.  

that's a fair point, it _is_ misleading a bit.

So far as I can see now:

 * we know what @rendition does, its semantics and syntax are clear. I can work with texts which use it
 * @rend is a private black box of tokens with no defined mechanism for the author to explain what she is saying.
     but its very widely used in that private code mode. I don't see any way to drop that TEI feature or pretend that
    we can deprecate it. overloading it as a container for CSS takes us nowhere for interoperability
 * we don't have the inline alternative to @rendition which lets us avoid the indirection

Now, its tempting to make up a new attribute @style which would contain (e.g.) CSS, except
that it misses the crucial extra bit of data - the @scheme attribute on <rendition>[1]. We say
explicitly that this may contain XSL FO as well as CSS, and the reader can follow that chain.
If we have @style, we lose the clue.

so we could define a new @cssrend which explicitly says its contents are CSS. it would work.
who likes that?

[1] which is optional. should we not make it mandatory? or say explicitly that CSS is the default?
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

John Walsh-2
Sebastian,

How about instead of new CSS rend attribute, we introduce a single element for the header:

<rendValues scheme="CSS"/> or
<rendValues scheme="tokens"/> or
<rendValues scheme="renditionLadders"/> or  
<rendVAlues scheme="XSLFO"/>

<rendValues> should not be empty but should optionally allow something like macro.specialPara for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.

More fleshed out versions might look like:

<rendValues scheme="tokens">
The <att>rend</att> attribute in this document is populated with whitespace separated tokens. Each token designates a specific rendition or style. Examples include:
<list>
<item>bold</item>
<item>italic</item>
<item>center</item>
<item>large</item>
<item>small></item>
</list>
</rendValues>

or

<rendValues scheme="CSS">
The <att>rend</att> attribute in this document is populated with inline CSS property/value declarations. See <ptr target="http://www.w3.org/TR/CSS2/"/>.
</rendValues>

My reservation about @cssrend is that it is bound to a particular language. When the New Better Style Sheet language is introduced, we would need to define @nbssrend.

I acknowledge that lots of people use tokens in @rend, but we've also heard from a number of people on the list using CSS in @rend. We also know that people use rendition ladders. Since @rend is not overly specified, we will always have variation, even with @cssrend. I think it's better (for interchange and XSLT style sheet authors) to build in a standard mechanism to allow the document to express how it is using @rend.

If you learn the document is using CSS in @rend, the XSLT solution is simple--just copy the contents of @rend into your output @style.

John  

--  
| John A. Walsh
| Assistant Professor, School of Library and Information Science
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| www: <http://www.slis.indiana.edu/faculty/jawalsh/>
| Voice:812-856-0707 Fax:812-856-2062 <mailto:[hidden email]>


On Friday, March 23, 2012 at 5:13 AM, Sebastian Rahtz wrote:

>  
> On 23 Mar 2012, at 00:51, John A. Walsh wrote:
> >  
> > And I still see another problem with html's @style. TEI has always been very clear that @rendition and @rend are meant to describe rendition/style features in the *source* text. I believe that important clarity is lost with html's @style.  
>  
> that's a fair point, it _is_ misleading a bit.
>  
> So far as I can see now:
>  
> * we know what @rendition does, its semantics and syntax are clear. I can work with texts which use it
> * @rend is a private black box of tokens with no defined mechanism for the author to explain what she is saying.  
> but its very widely used in that private code mode. I don't see any way to drop that TEI feature or pretend that
> we can deprecate it. overloading it as a container for CSS takes us nowhere for interoperability
> * we don't have the inline alternative to @rendition which lets us avoid the indirection
>  
> Now, its tempting to make up a new attribute @style which would contain (e.g.) CSS, except
> that it misses the crucial extra bit of data - the @scheme attribute on <rendition>[1]. We say
> explicitly that this may contain XSL FO as well as CSS, and the reader can follow that chain.
> If we have @style, we lose the clue.
>  
> so we could define a new @cssrend which explicitly says its contents are CSS. it would work.
> who likes that?
>  
> [1] which is optional. should we not make it mandatory? or say explicitly that CSS is the default?
> --
> Stormageddon Rahtz  
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>  
> Sólo le pido a Dios
> que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Sewell, David R. (drs2n)
I think some version of this recommendation is the way to go. That would
back up the P5 Guidelines ("Although the contents of the @rend attribute
are free text, in any given project, encoders are advised to adopt a
standard vocabulary with which to describe typographic or manuscript
rendition of the text") with a place to document the "standard
vocabulary" in use.

On Fri, 23 Mar 2012, John A. Walsh wrote:

> Sebastian,
>
> How about instead of new CSS rend attribute, we introduce a single element for the header:
>
> <rendValues scheme="CSS"/> or
> <rendValues scheme="tokens"/> or
> <rendValues scheme="renditionLadders"/> or
> <rendVAlues scheme="XSLFO"/>
>
> <rendValues> should not be empty but should optionally allow something like macro.specialPara for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.
>
> More fleshed out versions might look like:
>
> <rendValues scheme="tokens">
> The <att>rend</att> attribute in this document is populated with whitespace separated tokens. Each token designates a specific rendition or style. Examples include:
> <list>
> <item>bold</item>
> <item>italic</item>
> <item>center</item>
> <item>large</item>
> <item>small></item>
> </list>
> </rendValues>
>
> or
>
> <rendValues scheme="CSS">
> The <att>rend</att> attribute in this document is populated with inline CSS property/value declarations. See <ptr target="http://www.w3.org/TR/CSS2/"/>.
> </rendValues>
>
> My reservation about @cssrend is that it is bound to a particular language. When the New Better Style Sheet language is introduced, we would need to define @nbssrend.
>
> I acknowledge that lots of people use tokens in @rend, but we've also heard from a number of people on the list using CSS in @rend. We also know that people use rendition ladders. Since @rend is not overly specified, we will always have variation, even with @cssrend. I think it's better (for interchange and XSLT style sheet authors) to build in a standard mechanism to allow the document to express how it is using @rend.
>
> If you learn the document is using CSS in @rend, the XSLT solution is simple--just copy the contents of @rend into your output @style.
>
> John
>
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www: <http://www.slis.indiana.edu/faculty/jawalsh/>
> | Voice:812-856-0707 Fax:812-856-2062 <mailto:[hidden email]>
>
>
> On Friday, March 23, 2012 at 5:13 AM, Sebastian Rahtz wrote:
>
>>
>> On 23 Mar 2012, at 00:51, John A. Walsh wrote:
>>>
>>> And I still see another problem with html's @style. TEI has always been very clear that @rendition and @rend are meant to describe rendition/style features in the *source* text. I believe that important clarity is lost with html's @style.
>>
>> that's a fair point, it _is_ misleading a bit.
>>
>> So far as I can see now:
>>
>> * we know what @rendition does, its semantics and syntax are clear. I can work with texts which use it
>> * @rend is a private black box of tokens with no defined mechanism for the author to explain what she is saying.
>> but its very widely used in that private code mode. I don't see any way to drop that TEI feature or pretend that
>> we can deprecate it. overloading it as a container for CSS takes us nowhere for interoperability
>> * we don't have the inline alternative to @rendition which lets us avoid the indirection
>>
>> Now, its tempting to make up a new attribute @style which would contain (e.g.) CSS, except
>> that it misses the crucial extra bit of data - the @scheme attribute on <rendition>[1]. We say
>> explicitly that this may contain XSL FO as well as CSS, and the reader can follow that chain.
>> If we have @style, we lose the clue.
>>
>> so we could define a new @cssrend which explicitly says its contents are CSS. it would work.
>> who likes that?
>>
>> [1] which is optional. should we not make it mandatory? or say explicitly that CSS is the default?
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
>
--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: [hidden email]   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Kevin Hawkins
In reply to this post by Kevin Hawkins
Responses to various people below ...

John A. Walsh wrote:
> Kevin,
>
> I'm afraid I have to disagree back.
>
> The XHTML spec does not state the html's @style attribute must
> contain CSS.

Oh dear, you're right.  I had no idea.  I retract my statement.

Martin Mueller wrote:
 > I'd like to repeat my earlier comment that this discussion really calls
 > for an intelligent summary of the issues and options,

I agree, except that as you can see, we're still working out the
options.  I think once those come into focus, we'll be able to do this.

Sebastian Rahtz wrote:
> Now, its tempting to make up a new attribute @style which would contain (e.g.) CSS, except
> that it misses the crucial extra bit of data - the @scheme attribute on <rendition>[1]. We say
> explicitly that this may contain XSL FO as well as CSS, and the reader can follow that chain.
> If we have @style, we lose the clue.
>
> so we could define a new @cssrend which explicitly says its contents are CSS. it would work.
> who likes that?
>
> [1] which is optional. should we not make it mandatory? or say explicitly that CSS is the default?

Inventing a new TEI attribute -- @cssrend or maybe @cssstyle -- sounds
to me increasingly like the best option.

--Kevin
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Sebastian Rahtz
In reply to this post by Sebastian Rahtz
On 23 Mar 2012, at 11:37, John Walsh wrote:

> How about instead of  new CSS rend attribute, we introduce a single element for the header:
>
> <rendValues scheme="CSS"/> or
> <rendValues scheme="tokens"/> or
> <rendValues scheme="tokens/>
>
> rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.

Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
a document is consistent and useable.

my concern is the overlap with ODD. It gives us two places to list the possible token values,
if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
I'd prefer a very succinct and limited syntax.

How about an attribute on <text> of @rendscheme with the possible values of "tokens",
"css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
we would set the datatype of @rend to plain text (i.e. anything legal in XML),

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Laurent Romary
In reply to this post by Kevin Hawkins
Echoing Martin M. here, could someone provide a compilation of issues/arguments/options in a note? The discussion has been dense at times ;-)
Laurent

Le 23 mars 2012 à 14:42, Kevin Hawkins a écrit :

> Responses to various people below ...
>
> John A. Walsh wrote:
>> Kevin,
>>
>> I'm afraid I have to disagree back.
>>
>> The XHTML spec does not state the html's @style attribute must
>> contain CSS.
>
> Oh dear, you're right.  I had no idea.  I retract my statement.
>
> Martin Mueller wrote:
> > I'd like to repeat my earlier comment that this discussion really calls
> > for an intelligent summary of the issues and options,
>
> I agree, except that as you can see, we're still working out the options.  I think once those come into focus, we'll be able to do this.
>
> Sebastian Rahtz wrote:
>> Now, its tempting to make up a new attribute @style which would contain (e.g.) CSS, except
>> that it misses the crucial extra bit of data - the @scheme attribute on <rendition>[1]. We say
>> explicitly that this may contain XSL FO as well as CSS, and the reader can follow that chain.
>> If we have @style, we lose the clue.
>>
>> so we could define a new @cssrend which explicitly says its contents are CSS. it would work.
>> who likes that?
>>
>> [1] which is optional. should we not make it mandatory? or say explicitly that CSS is the default?
>
> Inventing a new TEI attribute -- @cssrend or maybe @cssstyle -- sounds to me increasingly like the best option.
>
> --Kevin

Laurent Romary
INRIA & HUB-IDSL
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Daniel O'Donnell-2
In reply to this post by Sebastian Rahtz
I prefer this approach as well (i.e. something indicating the scheme to be used in understanding the att value). It is more compact, checkable, it is less tied to a single technology, and, potentially, less open to future problems of competing schemas or ambiguity about rend at the element level from competing attribute values. @CSSStyle means tying things very closely to a specific language and leaves open the problem of what to do if people want to associate a different style language to it or if rend at cssstyle disagree.

I may have missed this in the discussion, but has anybody proposed something like Sebastian proposes, except at the element level--i.e. @rend and (optional) @rendscheme (with let's say a default of token or something set in the header)? This would allow element-level flexibility while still being automatically checkable.

I have the feeling that this kind of solution was proposed a long time ago when we were first discussing @rend and whether you could use CSS in it.
________________________________________
From: TEI (Text Encoding Initiative) public discussion list [[hidden email]] on behalf of Sebastian Rahtz [[hidden email]]
Sent: March-23-12 7:53
To: [hidden email]
Subject: Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

On 23 Mar 2012, at 11:37, John Walsh wrote:

> How about instead of  new CSS rend attribute, we introduce a single element for the header:
>
> <rendValues scheme="CSS"/> or
> <rendValues scheme="tokens"/> or
> <rendValues scheme="tokens/>
>
> rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.

Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
a document is consistent and useable.

my concern is the overlap with ODD. It gives us two places to list the possible token values,
if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
I'd prefer a very succinct and limited syntax.

How about an attribute on <text> of @rendscheme with the possible values of "tokens",
"css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
we would set the datatype of @rend to plain text (i.e. anything legal in XML),

--
Stormageddon Rahtz
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

John Walsh-2
In reply to this post by Sebastian Rahtz
Sebastian,

I very much like your revision of the proposal. Current structures in <encodingDesc> would still allow encoders to elaborate on @rendScheme should they so desire, and as you suggest, pointing to the ODD would be preferable to relisting the tokens in the header. If people ever use @rend in the header, then perhaps @rendScheme should go on <TEI> rather than <text>. I imagine there are cases where @rend is used in the header.  

Or @rendScheme could (shudder) be a global attribute that allowed one to change to different schemes within a document. Elements would inherit @rendScheme from their closest @rendScheme-bearing ancestor.

John  

--  
| John A. Walsh
| Assistant Professor, School of Library and Information Science
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| www: <http://www.slis.indiana.edu/faculty/jawalsh/>
| Voice:812-856-0707 Fax:812-856-2062 <mailto:[hidden email]>


On Friday, March 23, 2012 at 9:53 AM, Sebastian Rahtz wrote:

> On 23 Mar 2012, at 11:37, John Walsh wrote:
>  
> > How about instead of new CSS rend attribute, we introduce a single element for the header:
> >  
> > <rendValues scheme="CSS"/> or
> > <rendValues scheme="tokens"/> or
> > <rendValues scheme="tokens/>
> >  
> > rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.  
>  
> Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
> a document is consistent and useable.
>  
> my concern is the overlap with ODD. It gives us two places to list the possible token values,
> if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
> I'd prefer a very succinct and limited syntax.  
>  
> How about an attribute on <text> of @rendscheme with the possible values of "tokens",
> "css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
> we would set the datatype of @rend to plain text (i.e. anything legal in XML),
>  
> --
> Stormageddon Rahtz  
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>  
> Sólo le pido a Dios
> que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Sebastian Rahtz
In reply to this post by Daniel O'Donnell-2
On 23 Mar 2012, at 14:31, O'Donnell, Dan wrote:

>
> I may have missed this in the discussion, but has anybody proposed something like Sebastian proposes, except at the element level--i.e. @rend and (optional) @rendscheme (with let's say a default of token or something set in the header)? This would allow element-level flexibility while still being automatically checkable.


I see what you mean, but common sense makes me recoil from

 <p rendscheme="css" rend="font-size: 11pt;"> <hi rend="bold italic" rendscheme="tokens">hello</hi></p>

with a feeling of nausea :-}

Still, if it has to be, it has to be.

The mechanism seems quite clumsy, but it does appear to provide a way forward.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Lou Burnard-6
In reply to this post by John Walsh-2
I agree that specifying the notation used for @rend values makes a lot
of sense, and resolves most of the issues raised in this discussion. It
is the way we deal with other similar cases where we allow for users to
make up their own schemes,

John, I note (and support) your assertion that @rend and @rendition
alike are concerned with the rendition of the *source* of a TEI encodied
document rather the desired or recommended rendition for it. But in that
case, how can it make sense to use @rend in the TEI Header which (except
for the very specific case of a <biblFull> by definition has no
pre-existing source?

I would resist the temptation to allow arbitrary mixtures of @rend
schemes within a single document. If that's really a requirenment, I
suggest it should be handled by means of the existing @decls attribute.





On 23/03/12 14:34, John A. Walsh wrote:

> Sebastian,
>
> I very much like your revision of the proposal. Current structures in<encodingDesc>  would still allow encoders to elaborate on @rendScheme should they so desire, and as you suggest, pointing to the ODD would be preferable to relisting the tokens in the header. If people ever use @rend in the header, then perhaps @rendScheme should go on<TEI>  rather than<text>. I imagine there are cases where @rend is used in the header.
>
> Or @rendScheme could (shudder) be a global attribute that allowed one to change to different schemes within a document. Elements would inherit @rendScheme from their closest @rendScheme-bearing ancestor.
>
> John
>
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:<http://www.slis.indiana.edu/faculty/jawalsh/>
> | Voice:812-856-0707 Fax:812-856-2062<mailto:[hidden email]>
>
>
> On Friday, March 23, 2012 at 9:53 AM, Sebastian Rahtz wrote:
>
>> On 23 Mar 2012, at 11:37, John Walsh wrote:
>>
>>> How about instead of new CSS rend attribute, we introduce a single element for the header:
>>>
>>> <rendValues scheme="CSS"/>  or
>>> <rendValues scheme="tokens"/>  or
>>> <rendValues scheme="tokens/>
>>>
>>> rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.
>>
>> Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
>> a document is consistent and useable.
>>
>> my concern is the overlap with ODD. It gives us two places to list the possible token values,
>> if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
>> I'd prefer a very succinct and limited syntax.
>>
>> How about an attribute on<text>  of @rendscheme with the possible values of "tokens",
>> "css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
>> we would set the datatype of @rend to plain text (i.e. anything legal in XML),
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Daniel O'Donnell-2
In reply to this post by Sebastian Rahtz
I think we could eliminate some of this if we did a couple of other things:

1) made rendscheme optional when it doesn't differ from the default (which for reasons of neutrality and backwards compat., rather than convenience, I'd recommend be "token"). So your example would now be

<p rendscheme="css" rend="font-size: 11pt;"> <hi rend="bold italic">hello</hi></p>

2) allowed users set their own default either in the header or just as part of the ODD (so people could set the value of rend to CSS rather than token, which I think is probably the most common case): I think in general people /will/ want to set this, because I suspect most projects will have a usual style language they mostly use and only the occasional exception.

e.g. <p rend="font-size: 11pt;"> <hi rend="scary_letters" rendscheme="token">hello</hi></p>

3) Allowed people to set what the available schemes are somewhere, with perhaps a TEI default being CSS, ?XSL-FO?, token.

Any of this is less revolting, IMO, than an @CSSstyle att coming into potential conflict with @rend, and then, inevitably, the requests for @XSL-FOStyle, @LaTeX and god knows what else!

________________________________________
From: Sebastian Rahtz [[hidden email]]
Sent: March-23-12 8:56
To: O'Donnell, Dan
Cc: [hidden email]
Subject: Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

On 23 Mar 2012, at 14:31, O'Donnell, Dan wrote:

>
> I may have missed this in the discussion, but has anybody proposed something like Sebastian proposes, except at the element level--i.e. @rend and (optional) @rendscheme (with let's say a default of token or something set in the header)? This would allow element-level flexibility while still being automatically checkable.


I see what you mean, but common sense makes me recoil from

 <p rendscheme="css" rend="font-size: 11pt;"> <hi rend="bold italic" rendscheme="tokens">hello</hi></p>

with a feeling of nausea :-}

Still, if it has to be, it has to be.

The mechanism seems quite clumsy, but it does appear to provide a way forward.
--
Stormageddon Rahtz
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Daniel O'Donnell-2
In reply to this post by Lou Burnard-6
I agree with you, Lou and John, about the fact that we are focussed on the appearance of the source document (though this raises an interesting ontological question with born-digital TEI documents: can they have no @rend/rendition, since there was no "appearance" in their "source"?).

But that's why I would also argue that you need to be able to mix rendition languages: CSS (and the like) are very handy short hand for representing many of the types of things we see in source documents (and so offer a controlled language for describing maybe 90% of the encoding done across our community). But the nature of our community's encoding work also means they will inevitably hit things that can't be easily described in CSS (and not just in manuscripts).

So personally, while I agree that it is wise to avoid mixing languages arbitrarily as much as possible, the peculiar nature of the standard TEI encoding situation (attempting to describe analogue-born documents from arbitrary periods and cultures in computer language) is almost invariably going to encounter features outside any predefined scheme other than "arbitrary tokens."

I need to think about @decls as a solution (by which i unfortunately mean, "look up").

-dan
________________________________________
From: TEI (Text Encoding Initiative) public discussion list [[hidden email]] on behalf of Lou Burnard [[hidden email]]
Sent: March-23-12 8:56
To: [hidden email]
Subject: Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

I agree that specifying the notation used for @rend values makes a lot
of sense, and resolves most of the issues raised in this discussion. It
is the way we deal with other similar cases where we allow for users to
make up their own schemes,

John, I note (and support) your assertion that @rend and @rendition
alike are concerned with the rendition of the *source* of a TEI encodied
document rather the desired or recommended rendition for it. But in that
case, how can it make sense to use @rend in the TEI Header which (except
for the very specific case of a <biblFull> by definition has no
pre-existing source?

I would resist the temptation to allow arbitrary mixtures of @rend
schemes within a single document. If that's really a requirenment, I
suggest it should be handled by means of the existing @decls attribute.





On 23/03/12 14:34, John A. Walsh wrote:

> Sebastian,
>
> I very much like your revision of the proposal. Current structures in<encodingDesc>  would still allow encoders to elaborate on @rendScheme should they so desire, and as you suggest, pointing to the ODD would be preferable to relisting the tokens in the header. If people ever use @rend in the header, then perhaps @rendScheme should go on<TEI>  rather than<text>. I imagine there are cases where @rend is used in the header.
>
> Or @rendScheme could (shudder) be a global attribute that allowed one to change to different schemes within a document. Elements would inherit @rendScheme from their closest @rendScheme-bearing ancestor.
>
> John
>
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:<http://www.slis.indiana.edu/faculty/jawalsh/>
> | Voice:812-856-0707 Fax:812-856-2062<mailto:[hidden email]>
>
>
> On Friday, March 23, 2012 at 9:53 AM, Sebastian Rahtz wrote:
>
>> On 23 Mar 2012, at 11:37, John Walsh wrote:
>>
>>> How about instead of new CSS rend attribute, we introduce a single element for the header:
>>>
>>> <rendValues scheme="CSS"/>  or
>>> <rendValues scheme="tokens"/>  or
>>> <rendValues scheme="tokens/>
>>>
>>> rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.
>>
>> Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
>> a document is consistent and useable.
>>
>> my concern is the overlap with ODD. It gives us two places to list the possible token values,
>> if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
>> I'd prefer a very succinct and limited syntax.
>>
>> How about an attribute on<text>  of @rendscheme with the possible values of "tokens",
>> "css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
>> we would set the datatype of @rend to plain text (i.e. anything legal in XML),
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Sebastian Rahtz
In reply to this post by Daniel O'Donnell-2
On 23 Mar 2012, at 15:06, O'Donnell, Dan wrote:

> I think we could eliminate some of this if we did a couple of other things:
>
> 1) made rendscheme optional when it doesn't differ from the default (which for reasons of neutrality and backwards compat., rather than convenience, I'd recommend be "token"). So your example would now be
>
> <p rendscheme="css" rend="font-size: 11pt;"> <hi rend="bold italic">hello</hi></p>
>
no, because @rendscheme would naturally be inherited, surely?

> 2) allowed users set their own default either in the header or just as part of the ODD (so people could set the value of rend to CSS rather than token, which I think is probably the most common case): I think in general people /will/ want to set this, because I suspect most projects will have a usual style language they mostly use and only the occasional exception.
>
i'd worry a bit about it being in the ODD, as thats not so easily accessible to an interoperability validator.

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

Daniel O'Donnell-2
And, having looked it up, I think Lou's right that we should be using @decls to set the default (though I still think we need the ability to set element level exceptions to the default scheme).

I said the ODD only because you'd raised the issue. Header is good for me. Also could we set a list of possible values for @rendscheme? It seems to me it would be an encoding benefit if the list of possible values could be constrained.
________________________________________
From: Sebastian Rahtz [[hidden email]]
Sent: March-23-12 9:16
To: O'Donnell, Dan
Cc: [hidden email]
Subject: Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

On 23 Mar 2012, at 15:06, O'Donnell, Dan wrote:

> I think we could eliminate some of this if we did a couple of other things:
>
> 1) made rendscheme optional when it doesn't differ from the default (which for reasons of neutrality and backwards compat., rather than convenience, I'd recommend be "token"). So your example would now be
>
> <p rendscheme="css" rend="font-size: 11pt;"> <hi rend="bold italic">hello</hi></p>
>
no, because @rendscheme would naturally be inherited, surely?

> 2) allowed users set their own default either in the header or just as part of the ODD (so people could set the value of rend to CSS rather than token, which I think is probably the most common case): I think in general people /will/ want to set this, because I suspect most projects will have a usual style language they mostly use and only the occasional exception.
>
i'd worry a bit about it being in the ODD, as thats not so easily accessible to an interoperability validator.

--
Stormageddon Rahtz
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Reply | Threaded
Open this post in threaded view
|

Re: CSS in @rend (was Re: Why no space, etc. in DIV's @type?)

John Walsh-2
In reply to this post by Lou Burnard-6
Please see below.



On Friday, March 23, 2012 at 10:56 AM, Lou Burnard wrote:  

> I agree that specifying the notation used for @rend values makes a lot  
> of sense, and resolves most of the issues raised in this discussion. It  
> is the way we deal with other similar cases where we allow for users to  
> make up their own schemes,
>  
> John, I note (and support) your assertion that @rend and @rendition  
> alike are concerned with the rendition of the *source* of a TEI encodied  
> document rather the desired or recommended rendition for it. But in that  
> case, how can it make sense to use @rend in the TEI Header which (except  
> for the very specific case of a <biblFull> by definition has no  
> pre-existing source?

I agree with this stance, but it makes me think of a couple other issues.

1. While it's difficult to imagine appropriate uses of @rend in the header, @rend is a global element and is allowed in the header, so does it make sense to declare the scheme of at rend after it has potentially been used?

2. Related to your other point below, I'm also hesitant to allow multiple schemes within a single document, but I presented the option (and textually "shuddered" as I did so) to see if others found it useful. If we decide for the simpler one-scheme-per-document approach, TEI/@rendScheme may be preferable over text/@rendScheme, because <group><text/><text/><text/></group> structures would allow multiple @rendScheme declarations. So perhaps we should attach @rendScheme to the root element (TEI or teiCorpus) to avoid such cases.

John
 
>  
> I would resist the temptation to allow arbitrary mixtures of @rend  
> schemes within a single document. If that's really a requirenment, I  
> suggest it should be handled by means of the existing @decls attribute.


I agree with this too (you'll note that I textually "shuddered" when I suggested the more complicated option), but I threw out the other option to see if others found it useful.  

This brings up another issue. If @rendScheme is attached to <text>, once could still have multiple values in the following structure:

<group>
 <text/>
 <text/>
 <text/>
</group>

>  
>  
>  
>  
>  
> On 23/03/12 14:34, John A. Walsh wrote:
> > Sebastian,
> >  
> > I very much like your revision of the proposal. Current structures in<encodingDesc> would still allow encoders to elaborate on @rendScheme should they so desire, and as you suggest, pointing to the ODD would be preferable to relisting the tokens in the header. If people ever use @rend in the header, then perhaps @rendScheme should go on<TEI> rather than<text>. I imagine there are cases where @rend is used in the header.
> >  
> > Or @rendScheme could (shudder) be a global attribute that allowed one to change to different schemes within a document. Elements would inherit @rendScheme from their closest @rendScheme-bearing ancestor.
> >  
> > John
> >  
> > --
> > | John A. Walsh
> > | Assistant Professor, School of Library and Information Science
> > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> > | www:<http://www.slis.indiana.edu/faculty/jawalsh/>
> > | Voice:812-856-0707 Fax:812-856-2062<mailto:[hidden email]>
> >  
> >  
> > On Friday, March 23, 2012 at 9:53 AM, Sebastian Rahtz wrote:
> >  
> > > On 23 Mar 2012, at 11:37, John Walsh wrote:
> > >  
> > > > How about instead of new CSS rend attribute, we introduce a single element for the header:
> > > >  
> > > > <rendValues scheme="CSS"/> or
> > > > <rendValues scheme="tokens"/> or
> > > > <rendValues scheme="tokens/>
> > > >  
> > > > rendValues should not be empty but allow paragraphs and such for further explanation and/or links to specs or documentation on, say, rendition ladders, etc.
> > >  
> > > Yes, I am attracted to something like that. it has the crucial advantage of allowing an automated check that
> > > a document is consistent and useable.
> > >  
> > > my concern is the overlap with ODD. It gives us two places to list the possible token values,
> > > if we follow your proposal, and has the likelihood of redundancy across documents. For that reason
> > > I'd prefer a very succinct and limited syntax.
> > >  
> > > How about an attribute on<text> of @rendscheme with the possible values of "tokens",
> > > "css", "text" and maybe "ladders"? default would be "tokens", i.e. an unordered set of distinct words.
> > > we would set the datatype of @rend to plain text (i.e. anything legal in XML),
> > >  
> > > --
> > > Stormageddon Rahtz
> > > Head of Information and Support Group
> > > Oxford University Computing Services
> > > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> > >  
> > > Sólo le pido a Dios
> > > que el futuro no me sea indiferente
> >  
>  
123