Why no space, etc. in DIV's @type?

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

Why no space, etc. in DIV's @type?

John P. McCaskey
Oxygen tells me that a type field in a <div> element must be an XML
name. I don't see this in the guidelines.

Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
would make a fine <div> @type. No?

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

Re: Why no space, etc. in DIV's @type?

Lou Burnard-6
On 19/03/12 23:16, John P. McCaskey wrote:
> Oxygen tells me that a type field in a <div> element must be an XML
> name. I don't see this in the guidelines.

The @type attribute is derived from the att.typed class, and has a
declared datatype of data.enumerated, which maps to a single XML name.
See
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.enumerated.html

>
> Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
> would make a fine <div> @type. No?
>

Not with the current definition, no. One reason for not permitting
spaces is that they introduce an ambiguity. Some attributes have a value
of more than one data.name, so that multiple values can be given on a
single attribute. If a value could contain spaces, you could not tell
how many such values were being supplied. Another potential source of
confusion is that whitespace can take many forms: is "major section" the
same as "major                 section" or   "major
section" ?

The @type attribute is meant to be used for coded values, not
descriptive strings.
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

Conal Tuohy-2
On 19/03/12 23:16, John P. McCaskey wrote:
>> Oxygen tells me that a type field in a <div> element must be an XML
>> name. I don't see this in the guidelines.

On 20/03/12 10:43, Lou Burnard wrote:
> The @type attribute is meant to be used for coded values, not
> descriptive strings.
>
And further to this point: one often overlooked feature of XML names, as
data types, is that they can be made globally unique, through the use of
XML namespaces. An XML namespace is a distinct vocabulary of XML names,
uniquely identified by a URI, which itself can provide a link to
documentation about the vocabulary.

I think XML namespaces are a potentially very powerful mechanism for
sharing and managing controlled vocabularies for e.g. @type values,
though I've not het seen it used within the TEI community, personally.
XML namespaces have been around for a while in TEI, but I don't think
their full potential has been realised.


--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

John P. McCaskey
In reply to this post by Lou Burnard-6
That makes sense.

Is there a canonical way to encode a descriptive string associated with
each enumerated @type value? Maybe a lookup table of sorts in encodingDesc?

I see that "part", "chapter", "section", "abstract" and so on are common
@type values. A style sheet (which is what I am writing) could display
these. But then along comes "toc".

-- John

On 3/19/2012 7:43 PM, Lou Burnard wrote:

> On 19/03/12 23:16, John P. McCaskey wrote:
>> Oxygen tells me that a type field in a <div> element must be an XML
>> name. I don't see this in the guidelines.
>
> The @type attribute is derived from the att.typed class, and has a
> declared datatype of data.enumerated, which maps to a single XML name.
> See
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.enumerated.html
>
>>
>> Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
>> would make a fine <div> @type. No?
>>
>
> Not with the current definition, no. One reason for not permitting
> spaces is that they introduce an ambiguity. Some attributes have a
> value of more than one data.name, so that multiple values can be given
> on a single attribute. If a value could contain spaces, you could not
> tell how many such values were being supplied. Another potential
> source of confusion is that whitespace can take many forms: is "major
> section" the same as "major                 section" or   "major
> section" ?
>
> The @type attribute is meant to be used for coded values, not
> descriptive strings.
>
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

Sebastian Rahtz
On 20 Mar 2012, at 01:31, John P. McCaskey wrote:

>
> Is there a canonical way to encode a descriptive string associated with each enumerated @type value? Maybe a lookup table of sorts in encodingDesc?
>
the recommended way is (I claim) to define an ODD for your project which provides a closed enumerated list of values
for div/@type, and then you can use <valDesc> to explain what they mean. But thats not the same thing as a lookup table
of rendering values. Personally I have that sort of table embedded in my XSL, but I'm not entirely happy with that. But equally
I'd be unhappy embedding it in the TEI XML - apart from anything else, values may vary for different circumstances

--
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: Why no space, etc. in DIV's @type?

John P. McCaskey
On 3/20/2012 7:24 AM, Sebastian Rahtz wrote:
On 20 Mar 2012, at 01:31, John P. McCaskey wrote:
Is there a canonical way to encode a descriptive string associated with each enumerated @type value? Maybe a lookup table of sorts in encodingDesc?
the recommended way is (I claim) to define an ODD for your project which provides a closed enumerated list of values for div/@type, and then you can use <valDesc> to explain what they mean. But thats not the same thing as a lookup table of rendering values.[snip] But equally I'd be unhappy embedding it in the TEI XML [snip]
I have in mind the names of divisions that are specific to works, not ones that are the same across a project.

From Karl Popper's The Logic of Scientific Discovery:
- Part 1: Introduction to the Logic of Science
- Chapter 1: A Survey of Some Fundamental Problems
- Section 77: Decisive Experiments
- Appendix i: Definition of the Dimension of a Theory
- New Appendix ii: A Note on Probability

I'd put Part, Chapter, Section, and Appendix in div @type; 1, 1, 77, i, and ii in div @n; then each of the titles in <head>.

And I wouldn't know what to do with New Appendix.

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

Re: Why no space, etc. in DIV's @type?

Sebastian Rahtz
On 20 Mar 2012, at 13:09, John P. McCaskey wrote:

>>
> I have in mind the names of divisions that are specific to works, not ones that are the same across a project.
>
> From Karl Popper's The Logic of Scientific Discovery:
> - Part 1: Introduction to the Logic of Science
> - Chapter 1: A Survey of Some Fundamental Problems
> - Section 77: Decisive Experiments
> - Appendix i: Definition of the Dimension of a Theory
> - New Appendix ii: A Note on Probability
>
> I'd put Part, Chapter, Section, and Appendix in div @type; 1, 1, 77, i, and ii in div @n; then each of the titles in <head>.


you could join up with Syd's thread of a few days ago and write
   
     <head><label>New Appendix ii: </label>A Note on Probability</head>

or

  <head n="New Appendix ii">A Note on Probability</head>
--
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: Why no space, etc. in DIV's @type?

John P. McCaskey
On 3/20/2012 9:49 AM, Sebastian Rahtz wrote:

> On 20 Mar 2012, at 13:09, John P. McCaskey wrote:
>> I have in mind the names of divisions that are specific to works, not ones that are the same across a project.
>>
>>  From Karl Popper's The Logic of Scientific Discovery:
>> - Part 1: Introduction to the Logic of Science
>> - Chapter 1: A Survey of Some Fundamental Problems
>> - Section 77: Decisive Experiments
>> - Appendix i: Definition of the Dimension of a Theory
>> - New Appendix ii: A Note on Probability
>>
>> I'd put Part, Chapter, Section, and Appendix in div @type; 1, 1, 77, i, and ii in div @n; then each of the titles in<head>.
> you could join up with Syd's thread of a few days ago and write
>       <head><label>New Appendix ii:</label>A Note on Probability</head>
> or
>       <head n="New Appendix ii">A Note on Probability</head>
Those would work, but they do seem like workarounds. All the examples
and recommendations I've seen have "part", "section", "chapter",
"appendix" in @type.

Would the best practice recommendation be: "Don't do that because
someday you might have a two-word type." Or: "Include a @type, but
always also put a pretty string in <head><label>." Or: "The description
does say @n is for a number, but it also allows 'some other label' and
that's really what you should put there."

None seem appealing.

Maybe the best is just "Use underscores for spaces and remove them
during formatting."

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

Re: Why no space, etc. in DIV's @type?

John P. McCaskey
In reply to this post by Lou Burnard-6
On 3/19/2012 7:43 PM, Lou Burnard wrote:
> On 19/03/12 23:16, John P. McCaskey wrote:
>> Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
>> would make a fine <div> @type. No?
> If a value could contain spaces, you could not tell how many such
> values were being supplied. Some attributes have a value of more than
> one data.name, so that multiple values can be given on a single
> attribute. If a value could contain spaces, you could not tell how
> many such values were being supplied.
So @type values are separated by space. That makes sense. Should these
then be legal @type values in a <div>: "introduction prose", "preface
prose", "section verse", "commentary prose"?

Oxygen's validator says no, but I don't see in the guidelines how to
know whether the @type on a particular element allows multiple
space-separated values or not.

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

Re: Why no space, etc. in DIV's @type?

Sebastian Rahtz
In reply to this post by John P. McCaskey
On 20 Mar 2012, at 15:00, John P. McCaskey wrote:

>> you could join up with Syd's thread of a few days ago and write
>>      <head><label>New Appendix ii:</label>A Note on Probability</head>
>> or
>>      <head n="New Appendix ii">A Note on Probability</head>
> Those would work, but they do seem like workarounds. All the examples and recommendations I've seen have "part", "section", "chapter", "appendix" in @type.

yes, but thats performing a different function, I'd say. "Chapitre 1" and "Chapter 1" are both div/@type='chapter'

>
> Would the best practice recommendation be: "Don't do that because someday you might have a two-word type." Or: "Include a @type, but always also put a pretty string in <head><label>." Or: "The description does say @n is for a number, but it also allows 'some other label' and that's really what you should put there."
>
> None seem appealing.
I'd say the middle one is the way to go, personally. It all depends - if you don't plan to
use strict typologies, just forget the @type entirely.

but I don't know why you are encoding these texts, maybe you should expand on your use case
a bit?

>
> Maybe the best is just "Use underscores for spaces and remove them during formatting."


I would say that this is the worst thing to do, to use the @type attribute for controlling formatting,
and then add additional private rules on how to use it.
--
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: Why no space, etc. in DIV's @type?

John P. McCaskey
On 3/20/2012 11:20 AM, Sebastian Rahtz wrote:
>> Would the best practice recommendation be: ... Or: "Include a @type, but always also put a pretty string in<head><label>." ...
>> >  
>> >  None seem appealing.
> I'd say the middle one is the way to go, personally. It all depends - if you don't plan to use strict typologies, just forget the @type entirely.
>
> but I don't know why you are encoding these texts, maybe you should expand on your use case a bit?
I'm working up a stylesheet that would display parallel corpora. I'm not
really encoding many texts myself, just trying to make a general-purpose
stylesheet that works with texts others have encoded.

Every coded text I've seen would have "chapter" as @type and "1" as @n.

I haven't seen cases where the encoder saw "Chapitre 1" in a source,
changed that to "chapter" and "1" in the TEI, and then put "Chapitre" or
"Chapitre 1" somewhere else in the encoding. It makes sense. I just
haven't seen it and was basically looking for the recommended way to do it.

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

Re: Why no space, etc. in DIV's @type?

Lou Burnard-6
On 20/03/12 15:42, John P. McCaskey wrote:

> On 3/20/2012 11:20 AM, Sebastian Rahtz wrote:
>>> Would the best practice recommendation be: ... Or: "Include a @type,
>>> but always also put a pretty string in<head><label>." ...
>>> > > None seem appealing.
>> I'd say the middle one is the way to go, personally. It all depends -
>> if you don't plan to use strict typologies, just forget the @type
>> entirely.
>>
>> but I don't know why you are encoding these texts, maybe you should
>> expand on your use case a bit?
> I'm working up a stylesheet that would display parallel corpora. I'm not
> really encoding many texts myself, just trying to make a general-purpose
> stylesheet that works with texts others have encoded.
>
> Every coded text I've seen would have "chapter" as @type and "1" as @n.
>
> I haven't seen cases where the encoder saw "Chapitre 1" in a source,
> changed that to "chapter" and "1" in the TEI, and then put "Chapitre" or
> "Chapitre 1" somewhere else in the encoding. It makes sense. I just
> haven't seen it and was basically looking for the recommended way to do it.
>
>

I think, as both Sebastian and I have suggested, the recommendation
would indeed be to use @type for a normalised version of the "type" of
section, independently of how it actually appears in your source. If the
latter is encoded in the source (and the recommendations do say you can
leave it out if its form is completely regular) it belongs in <head>,
possibly with a nested <label>.

So the TEI recommends any and all of the following practices:

a) <div type="chap" n="42">
<p>This is chapter 42.,...</p>


b) <div xml:lang="fr" type="chap" n="42">
    <head>Chapitre 42</head>
    <p>Voici le debut du chapitre 42... </p>

c) <div type="chap" n="42">
    <head>Chapter <label xml:lang="la">xlii</label></head>

d) <div n="xlii">
    <p>Here begins chapter 42...</p>

Writing general purpose stylesheets to deal with all of these
possibilities is not exactly trivial, as Sebastian's gray hairs will
confirm. On the other hand, the variation corresponds well with the many
different ways people choose to apply the TEI.
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

Lou Burnard-6
In reply to this post by John P. McCaskey
On 20/03/12 15:16, John P. McCaskey wrote:

> On 3/19/2012 7:43 PM, Lou Burnard wrote:
>> On 19/03/12 23:16, John P. McCaskey wrote:
>>> Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
>>> would make a fine <div> @type. No?
>> If a value could contain spaces, you could not tell how many such
>> values were being supplied. Some attributes have a value of more than
>> one data.name, so that multiple values can be given on a single
>> attribute. If a value could contain spaces, you could not tell how
>> many such values were being supplied.
> So @type values are separated by space. That makes sense. Should these
> then be legal @type values in a <div>: "introduction prose", "preface
> prose", "section verse", "commentary prose"?
>
> Oxygen's validator says no, but I don't see in the guidelines how to
> know whether the @type on a particular element allows multiple
> space-separated values or not.
>

Sorry, I was a bit misleading. In the case of @type only single values
are permitted. But there are other cases where multiple values are
available: look for a @maxoccurs on the <datatype> element. See for
example @commodity on elements which are members of the att.measurement
class
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

John P. McCaskey
In reply to this post by Lou Burnard-6
On 3/20/2012 12:50 PM, Lou Burnard wrote:

> So the TEI recommends any and all of the following practices:
>
> a) <div type="chap" n="42">
> <p>This is chapter 42.,...</p>
>
> b) <div xml:lang="fr" type="chap" n="42">
> <head>Chapitre 42</head>
> <p>Voici le debut du chapitre 42... </p>
>
> c) <div type="chap" n="42">
> <head>Chapter <label xml:lang="la">xlii</label></head>
>
> d) <div n="xlii">
> <p>Here begins chapter 42...</p>
>
> Writing general purpose stylesheets to deal with all of these
> possibilities is not exactly trivial, as Sebastian's gray hairs will
> confirm. On the other hand, the variation corresponds well with the
> many different ways people choose to apply the TEI.

I wonder if anyone has ever used any of these recommendations. I suspect
the most common approach has been to take what is in the source, make it
lowercase, and put that (possibly abbreviated) into @type. With some
Googling, I readily find type="chapter" and type="chapitre" and
type="kapitel".

It seems to me the recommendations fail to capture the semantics of a
work's segmentation. "New Appendix 42" is not merely the heading above
some text. The table of contents, the citation system, the index, the
pagination, may all recognize "New Appendix" as the name for some
structural element, not merely as the first words in the heading of some
divisions.

I can see a need to encode "New Appendix" as say, "newApp", and then use
newApp in tables of contents, division types, indexes, etc. But then
you'd want, I'd think, a place to say newApp is rendered as "New
Appendix" in all those places in the course (or maybe even give some
multilingual alternatives).

It doesn't matter much for my project, since the common approach appears
universal enough and the recommendations would render well enough. I'll
just put "Chap 42" above each block of text (or "42" in the case of d)
and render what follows as I would any other <head> or <div> content --
since it has no semantic markers, it should not, of course, be rendered
any other way.

If the encoder was forced to use newApp and doesn't want to see "NewApp
42", he or she can suppress the display of @type in the CSS.

But whether I'm right or not about all that, the good news is that I
don't need to do any lookups or conditional formatting here. On to other
parts.

Thanks,
John
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

Sebastian Rahtz
In reply to this post by John P. McCaskey


I'm working up a stylesheet that would display parallel corpora. I'm not really encoding many texts myself, just trying to make a general-purpose stylesheet that works with texts others have encoded.

Every coded text I've seen would have "chapter" as @type and "1" as @n.


Ok, understood. Then I suggest that for your purposes, the @type and @n are probably irrelevant and can be ignored. Maybe use @n if you like. Generate your own style of display for the headings, turning them into <hN> depending on their hierarchical position.  I don't think reproduction of typeset style is your priority, when comparing modernish philosophical texts.

Others may shout me down at this point :-)

Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

James Cummings
In reply to this post by Lou Burnard-6
Some of the discussion of @type as a token reminds me of the discussion we recently had about @rend and why spaces in that indicate additional tokens not spaces in a single value.

See http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/ for some other thoughts on that.

JamesC
(On holiday honest)

--
James Cummings, InfoDev, OUCS, University of Oxford

Lou Burnard <[hidden email]> wrote:


On 20/03/12 15:16, John P. McCaskey wrote:

> On 3/19/2012 7:43 PM, Lou Burnard wrote:
>> On 19/03/12 23:16, John P. McCaskey wrote:
>>> Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
>>> would make a fine <div> @type. No?
>> If a value could contain spaces, you could not tell how many such
>> values were being supplied. Some attributes have a value of more than
>> one data.name, so that multiple values can be given on a single
>> attribute. If a value could contain spaces, you could not tell how
>> many such values were being supplied.
> So @type values are separated by space. That makes sense. Should these
> then be legal @type values in a <div>: "introduction prose", "preface
> prose", "section verse", "commentary prose"?
>
> Oxygen's validator says no, but I don't see in the guidelines how to
> know whether the @type on a particular element allows multiple
> space-separated values or not.
>

Sorry, I was a bit misleading. In the case of @type only single values
are permitted. But there are other cases where multiple values are
available: look for a @maxoccurs on the <datatype> element. See for
example @commodity on elements which are members of the att.measurement
class
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

John Walsh-2
James,

As TEI supports and encourages the use of CSS in <rendition> elements, I think TEI should also support and encourage the use of CSS in @rend attributes. It can be useful to use both @rendition and @rend in one's documents, using @rendition to point to styles and formatting rules that are used throughout the document and @rend for special cases that may exist only once in a document. In such manner TEI supports pointers to styles (like HTML's @class) and inline styles (like HTML's @style). I believe it would be inconsistent to argue the utility of describing styles using an existing standard like CSS in the context of <rendition> and @rendition while not supporting the use of the same existing standard in the related @rend attribute. And I don't think we can fully support CSS in @rend without allowing white space that is not a token separator. E.g., <ab rend="border:1px solid black;"></ab> or <title rend='font-family:"Helvetica Nueu";'>A Vision of Spring Before Winter</title>.

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 Tuesday, March 20, 2012 at 2:48 PM, James Cummings wrote:

> Some of the discussion of @type as a token reminds me of the discussion we recently had about @rend and why spaces in that indicate additional tokens not spaces in a single value.
>
> See http://blogs.oucs.ox.ac.uk/jamesc/2011/12/01/rend-and-the-war-on-text-bearing-attributes/ for some other thoughts on that.
>
> JamesC
> (On holiday honest)
>
> --
> James Cummings, InfoDev, OUCS, University of Oxford
>
> Lou Burnard <[hidden email] (mailto:[hidden email])> wrote:
>
>
> On 20/03/12 15:16, John P. McCaskey wrote:
> > On 3/19/2012 7:43 PM, Lou Burnard wrote:
> > > On 19/03/12 23:16, John P. McCaskey wrote:
> > > > Is this true? If so, why? It seems "major section" or "chapter/Kapitel"
> > > > would make a fine <div> @type. No?
> > >
> > >
> > > If a value could contain spaces, you could not tell how many such
> > > values were being supplied. Some attributes have a value of more than
> > > one data.name (http://data.name), so that multiple values can be given on a single
> > > attribute. If a value could contain spaces, you could not tell how
> > > many such values were being supplied.
> >
> >
> > So @type values are separated by space. That makes sense. Should these
> > then be legal @type values in a <div>: "introduction prose", "preface
> > prose", "section verse", "commentary prose"?
> >
> > Oxygen's validator says no, but I don't see in the guidelines how to
> > know whether the @type on a particular element allows multiple
> > space-separated values or not.
>
>
>
> Sorry, I was a bit misleading. In the case of @type only single values
> are permitted. But there are other cases where multiple values are
> available: look for a @maxoccurs on the <datatype> element. See for
> example @commodity on elements which are members of the att.measurement
> class
Reply | Threaded
Open this post in threaded view
|

Re: Why no space, etc. in DIV's @type?

Sewell, David R. (drs2n)
A strong +1 for John's remarks on CSS in @rend. We use precisely the convention
that John describes for our TEI-based publications, and it is possibly the
single most indispensable feature of our tagging practice. Were the TEI
priesthood to ban it, we would continue to consider ourselves good TEI-ers, but
blithely ignore the ban. (Taking a cue from the well-known inclination of
religious flocks to ignore certain ex cathedra prohibitions that don't always
make sense in the real world.)

David


On Tue, 20 Mar 2012, John A. Walsh wrote:

> James,
>
> As TEI supports and encourages the use of CSS in <rendition> elements, I think TEI should also support and encourage the use of CSS in @rend attributes. It can be useful to use both @rendition and @rend in one's documents, using @rendition to point to styles and formatting rules that are used throughout the document and @rend for special cases that may exist only once in a document. In such manner TEI supports pointers to styles (like HTML's @class) and inline styles (like HTML's @style). I believe it would be inconsistent to argue the utility of describing styles using an existing standard like CSS in the context of <rendition> and @rendition while not supporting the use of the same existing standard in the related @rend attribute. And I don't think we can fully support CSS in @rend without allowing white space that is not a token separator. E.g., <ab rend="border:1px solid black;"></ab> or <title rend='font-family:"Helvetica Nueu";'>A Vision of Spring Before Winter</title
 >.
>
> John
>
>

--
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: Why no space, etc. in DIV's @type?

Martin Holmes
In reply to this post by John Walsh-2
I agree with John wholeheartedly. In a perfect world, we would want to
turn all CSS rendering instructions into <rendition> elements and point
to them with @rendition, but before you get to that stage you need to
mark up styles as you progress through the document. I think this is a
reasonable way to proceed:

First, mark up styles as you encode, using CSS in @rend.

Once the document is complete, use XSLT to rework the document,
detecting all distinct style collections (elements carrying exactly the
same collection of property-value pairs), and constructing <rendition>
elements from them. At the same time, @rend attributes can be replaced
with @rendition attributes pointing to the <rendition> elements that are
created.

The result is a fairly optimal document in which CSS is confined to the
header and organized into what amounts to rulesets. But creating the
rulesets as you go along, and remembering what they are and how to link
to them, is very messy; it's much easier to see that the paragraph
happen to be transcribing is:

font-size: 80%; font-variant: small-caps;

and to type <p rend="font-size: 80%; font-variant: small-caps;">...</p>

than to remember that somewhere in the header you have:

<rendition xml:id="small-caps-size-80-percent">...

or whatever you chose to call it.

In other words, for simple cases @rend="[css]" is much simpler than
using @rendition; and for complicated cases, @rend="[css]" is a good
intermediate stage from which you can later generate your <rendition>
elements.

Cheers,
Martin

On 12-03-20 01:29 PM, John A. Walsh wrote:

> James,
>
> As TEI supports and encourages the use of CSS in<rendition>
> elements, I think TEI should also support and encourage the use of
> CSS in @rend attributes. It can be useful to use both @rendition and
> @rend in one's documents, using @rendition to point to styles and
> formatting rules that are used throughout the document and @rend for
> special cases that may exist only once in a document. In such manner
> TEI supports pointers to styles (like HTML's @class) and inline
> styles (like HTML's @style). I believe it would be inconsistent to
> argue the utility of describing styles using an existing standard
> like CSS in the context of<rendition>  and @rendition while not
> supporting the use of the same existing standard in the related @rend
> attribute. And I don't think we can fully support CSS in @rend
> without allowing white space that is not a token separator. E.g.,<ab
> rend="border:1px solid black;"></ab>  or<title
> rend='font-family:"Helvetica Nueu";'>A Vision of Spring Before
> Winter</title>.
>
> John
>

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

Re: Why no space, etc. in DIV's @type?

Sebastian Rahtz
I've got a load of sympathy for rend="border: solid 1pt red" or whatever, but it's so totally at variance
with rend="bold italic" that I find it hard to vote for their co-existence. I feel much more like using @html:style
in my TEI XML document, and keeping @rend for the token names, or adding a new @style.

If there's no way for a document consumer to tell the difference between the two systems, the limited
interchange value that @rend has is even more eroded.
--
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