type attribute in p

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

type attribute in p

Martin Mueller

I just stumbled an earlier thread about a @type attribute for <p> , and there was a question about use cases. Here is one I can think of right away. In the days long ago, when I regularly thumbed the Classics review journal Gnomon, I always appreciated reviews that had a main argument in larger type and subsidiary stuff in smaller type.  So you could read the whole thing or skip the fine print. You could  model the fine print stuff as inline notes, but I think of notes as bits of text that sit explicitly outside the text stream, while the alternation of paragraphs in Gnomon stays within a sequential reading order.

 

Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

mholmes
This rather sounds like it might be a job for <argument>:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-argument.html>

Cheers,
Martin

On 2017-04-12 11:04 AM, Martin Mueller wrote:

> I just stumbled an earlier thread about a @type attribute for <p> , and
> there was a question about use cases. Here is one I can think of right
> away. In the days long ago, when I regularly thumbed the Classics review
> journal Gnomon, I always appreciated reviews that had a main argument in
> larger type and subsidiary stuff in smaller type.  So you could read the
> whole thing or skip the fine print. You could  model the fine print
> stuff as inline notes, but I think of notes as bits of text that sit
> explicitly outside the text stream, while the alternation of paragraphs
> in Gnomon stays within a sequential reading order.
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Martin Mueller
I don’t think so. I think of <argument>  as a summary of what follows. A Gnomon article might have the following sequence of paragraphs, where upper and lower case distinguish the different types:

PPPpPppPPp etc

I’m sure I’ve seen this elsewhere. The author sends the signal: “you can skip this paragraph, but it’s part of a continuous argument.” You could of course encode it, using @rend or @rendition. But a @type attribute might be a better way of articulating this discursive structure, and you could derive particular layout instructions from the structural encoding.  

On 4/12/17, 12:07 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Martin Holmes" <[hidden email] on behalf of [hidden email]> wrote:

    This rather sounds like it might be a job for <argument>:
   
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tei-2Dc.org_release_doc_tei-2Dp5-2Ddoc_en_html_ref-2Dargument.html&d=DwICaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=FXRw3zJHKvtQOXEKltpN_laj_RInMXBzcdv1PnglcCY&s=ArhMNH3Tk8ixBDtg8zBAzuPqb6vdxFjXXWPsylhv0BU&e= >
   
    Cheers,
    Martin
   
    On 2017-04-12 11:04 AM, Martin Mueller wrote:
    > I just stumbled an earlier thread about a @type attribute for <p> , and
    > there was a question about use cases. Here is one I can think of right
    > away. In the days long ago, when I regularly thumbed the Classics review
    > journal Gnomon, I always appreciated reviews that had a main argument in
    > larger type and subsidiary stuff in smaller type.  So you could read the
    > whole thing or skip the fine print. You could  model the fine print
    > stuff as inline notes, but I think of notes as bits of text that sit
    > explicitly outside the text stream, while the alternation of paragraphs
    > in Gnomon stays within a sequential reading order.
    >
    >
    >
   

Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

mholmes
Where you have a sequence of paragraphs of the same type, don't you just
have a div with that type? (The sequence may include only one paragraph,
of course.)

Cheers,
Martin

On 2017-04-12 11:33 AM, Martin Mueller wrote:

> I don’t think so. I think of <argument>  as a summary of what follows. A Gnomon article might have the following sequence of paragraphs, where upper and lower case distinguish the different types:
>
> PPPpPppPPp etc
>
> I’m sure I’ve seen this elsewhere. The author sends the signal: “you can skip this paragraph, but it’s part of a continuous argument.” You could of course encode it, using @rend or @rendition. But a @type attribute might be a better way of articulating this discursive structure, and you could derive particular layout instructions from the structural encoding.
>
> On 4/12/17, 12:07 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Martin Holmes" <[hidden email] on behalf of [hidden email]> wrote:
>
>     This rather sounds like it might be a job for <argument>:
>
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tei-2Dc.org_release_doc_tei-2Dp5-2Ddoc_en_html_ref-2Dargument.html&d=DwICaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=FXRw3zJHKvtQOXEKltpN_laj_RInMXBzcdv1PnglcCY&s=ArhMNH3Tk8ixBDtg8zBAzuPqb6vdxFjXXWPsylhv0BU&e= >
>
>     Cheers,
>     Martin
>
>     On 2017-04-12 11:04 AM, Martin Mueller wrote:
>     > I just stumbled an earlier thread about a @type attribute for <p> , and
>     > there was a question about use cases. Here is one I can think of right
>     > away. In the days long ago, when I regularly thumbed the Classics review
>     > journal Gnomon, I always appreciated reviews that had a main argument in
>     > larger type and subsidiary stuff in smaller type.  So you could read the
>     > whole thing or skip the fine print. You could  model the fine print
>     > stuff as inline notes, but I think of notes as bits of text that sit
>     > explicitly outside the text stream, while the alternation of paragraphs
>     > in Gnomon stays within a sequential reading order.
>     >
>     >
>     >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Paul Schaffner
In reply to this post by Martin Mueller
For a while I toyed with adding an attribute to a number of
elements that were found to be acting in this way: elements
that recurred, and behaved similarly, but were distinguished
by some functional feature. Short of using feature structures,
or abusing one of the rendition attributes, there didn't seem a
ready way to do this. (I think I tested out @role for this purpose.)

Martin's example seems to be of just this sort. Other examples
(not always involving <p>) might be:

1. lines of a hymn. Some lines are required (invariable); others
may optionally be skipped and are marked as such, e.g. by being
printed in smaller type.  LLllLlLL.

2. speeches or parts of speeches. Some plays present a full
reading text of a play but mark some speeches (or lines, etc.)
as bits to be skipped during actual performance. (Come to think
of it, the Congressional Record would do well to do likewise:)

3. marking source of a text. Some books distinguish the source
or authoritativeness of parts of its running text by typographic
means, e.g., the fourth edition might print everything new to
this edition in one font, but print everything carried over from
a previous edition in another font, so if you just want to read
the earlier text, stick to the text in the appropriate font. Similarly
with text rebutting an opponent: some paragraphs marked as
points on which the author agrees with the opponent, others
as divergent. &c &c

4. marking function within an argument. E.g. alternating paragraphs
representing opposing points of view (point / counterpoint); or
question and response; or doctrine and elaboration; or statement
and defense of same.

I'm still not sure that @type is quite right for this (since it feels
as though p @type should distinguish types of paragraphs, not types of
content), but I think I agree that the use case is real, and is perhaps
quite widely distributed.

pfs

On Wed, Apr 12, 2017, at 14:33, Martin Mueller wrote:

> I don’t think so. I think of <argument>  as a summary of what follows. A
> Gnomon article might have the following sequence of paragraphs, where
> upper and lower case distinguish the different types:
>
> PPPpPppPPp etc
>
> I’m sure I’ve seen this elsewhere. The author sends the signal: “you can
> skip this paragraph, but it’s part of a continuous argument.” You could
> of course encode it, using @rend or @rendition. But a @type attribute
> might be a better way of articulating this discursive structure, and you
> could derive particular layout instructions from the structural encoding.
>
> On 4/12/17, 12:07 PM, "TEI (Text Encoding Initiative) public discussion
> list on behalf of Martin Holmes" <[hidden email] on behalf of
> [hidden email]> wrote:
>
>     This rather sounds like it might be a job for <argument>:
>    
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tei-2Dc.org_release_doc_tei-2Dp5-2Ddoc_en_html_ref-2Dargument.html&d=DwICaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=FXRw3zJHKvtQOXEKltpN_laj_RInMXBzcdv1PnglcCY&s=ArhMNH3Tk8ixBDtg8zBAzuPqb6vdxFjXXWPsylhv0BU&e=
>     >
>    
>     Cheers,
>     Martin
>    
>     On 2017-04-12 11:04 AM, Martin Mueller wrote:
>     > I just stumbled an earlier thread about a @type attribute for <p> , and
>     > there was a question about use cases. Here is one I can think of right
>     > away. In the days long ago, when I regularly thumbed the Classics review
>     > journal Gnomon, I always appreciated reviews that had a main argument in
>     > larger type and subsidiary stuff in smaller type.  So you could read the
>     > whole thing or skip the fine print. You could  model the fine print
>     > stuff as inline notes, but I think of notes as bits of text that sit
>     > explicitly outside the text stream, while the alternation of paragraphs
>     > in Gnomon stays within a sequential reading order.
>     >
>     >
>     >
>    
>
--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Martin Mueller
Answering both Martin H. and Paul:

I’m not quite sure what is meant by the difference beween  “types of paragraph” and “types of content.” There is a functional difference in the paragrphs, which in principle could be expressed in many different ways. Lawyers have “fine print” and there the smaller expresses some form of subordination.

Martin H. suggests dividing the sequences of  paragraphs and fine print paragraphs into divs.  But the writer of a Gnomon review would never think of the fine print  paragraph as something that is separated from the previous paragraph by a div-like separation. The Guidelines suggest pretty strongly that a div marks a substantive division.  In my example and Paul’s you need something that says: “we are articulating some fluctuation or alternation within a hierarchical level, but we are not changing the level”. Which may not be easy, or, as Wallace Stevens said “The squirming facts exceed the squamous mind”, and XML is a squamous sort of thing.

On 4/12/17, 1:34 PM, "Paul Schaffner" <[hidden email]> wrote:

    For a while I toyed with adding an attribute to a number of
    elements that were found to be acting in this way: elements
    that recurred, and behaved similarly, but were distinguished
    by some functional feature. Short of using feature structures,
    or abusing one of the rendition attributes, there didn't seem a
    ready way to do this. (I think I tested out @role for this purpose.)
   
    Martin's example seems to be of just this sort. Other examples
    (not always involving <p>) might be:
   
    1. lines of a hymn. Some lines are required (invariable); others
    may optionally be skipped and are marked as such, e.g. by being
    printed in smaller type.  LLllLlLL.
   
    2. speeches or parts of speeches. Some plays present a full
    reading text of a play but mark some speeches (or lines, etc.)
    as bits to be skipped during actual performance. (Come to think
    of it, the Congressional Record would do well to do likewise:)
   
    3. marking source of a text. Some books distinguish the source
    or authoritativeness of parts of its running text by typographic
    means, e.g., the fourth edition might print everything new to
    this edition in one font, but print everything carried over from
    a previous edition in another font, so if you just want to read
    the earlier text, stick to the text in the appropriate font. Similarly
    with text rebutting an opponent: some paragraphs marked as
    points on which the author agrees with the opponent, others
    as divergent. &c &c
   
    4. marking function within an argument. E.g. alternating paragraphs
    representing opposing points of view (point / counterpoint); or
    question and response; or doctrine and elaboration; or statement
    and defense of same.
   
    I'm still not sure that @type is quite right for this (since it feels
    as though p @type should distinguish types of paragraphs, not types of
    content), but I think I agree that the use case is real, and is perhaps
    quite widely distributed.
   
    pfs
   
    On Wed, Apr 12, 2017, at 14:33, Martin Mueller wrote:
    > I don’t think so. I think of <argument>  as a summary of what follows. A
    > Gnomon article might have the following sequence of paragraphs, where
    > upper and lower case distinguish the different types:
    >
    > PPPpPppPPp etc
    >
    > I’m sure I’ve seen this elsewhere. The author sends the signal: “you can
    > skip this paragraph, but it’s part of a continuous argument.” You could
    > of course encode it, using @rend or @rendition. But a @type attribute
    > might be a better way of articulating this discursive structure, and you
    > could derive particular layout instructions from the structural encoding.
    >
    > On 4/12/17, 12:07 PM, "TEI (Text Encoding Initiative) public discussion
    > list on behalf of Martin Holmes" <[hidden email] on behalf of
    > [hidden email]> wrote:
    >
    >     This rather sounds like it might be a job for <argument>:
    >    
    >     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tei-2Dc.org_release_doc_tei-2Dp5-2Ddoc_en_html_ref-2Dargument.html&d=DwICaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=FXRw3zJHKvtQOXEKltpN_laj_RInMXBzcdv1PnglcCY&s=ArhMNH3Tk8ixBDtg8zBAzuPqb6vdxFjXXWPsylhv0BU&e=>     >
    >    
    >     Cheers,
    >     Martin
    >    
    >     On 2017-04-12 11:04 AM, Martin Mueller wrote:
    >     > I just stumbled an earlier thread about a @type attribute for <p> , and
    >     > there was a question about use cases. Here is one I can think of right
    >     > away. In the days long ago, when I regularly thumbed the Classics review
    >     > journal Gnomon, I always appreciated reviews that had a main argument in
    >     > larger type and subsidiary stuff in smaller type.  So you could read the
    >     > whole thing or skip the fine print. You could  model the fine print
    >     > stuff as inline notes, but I think of notes as bits of text that sit
    >     > explicitly outside the text stream, while the alternation of paragraphs
    >     > in Gnomon stays within a sequential reading order.
    >     >
    >     >
    >     >
    >    
    >
    --
    Paul Schaffner  Digital Content & Collections
    University of Michigan Libraries
    [hidden email] | https://urldefense.proofpoint.com/v2/url?u=http-3A__www.umich.edu_-7Epfs_&d=DwIFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=rFKoDcZtfLWWfby-JcHUXeYWRMA2_CQPoc4Ph-88R8Y&s=O5GdF4y3XOlsqlGAmPM9KqYcOWCtKQ9rjKpbKAqzpPY&e= 
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Paul Schaffner
In reply to this post by Paul Schaffner
I should perhaps have added an option: occasionally I have
'demoted' my paragraphs to <ab>s in circumstances like this,
precisely in order to take advantage of their @type and @subtype
attributes. pfs

On Wed, Apr 12, 2017, at 15:34, Paul Schaffner wrote:

> For a while I toyed with adding an attribute to a number of
> elements that were found to be acting in this way: elements
> that recurred, and behaved similarly, but were distinguished
> by some functional feature. Short of using feature structures,
> or abusing one of the rendition attributes, there didn't seem a
> ready way to do this. (I think I tested out @role for this purpose.)
>
> Martin's example seems to be of just this sort. Other examples
> (not always involving <p>) might be:
>
> 1. lines of a hymn. Some lines are required (invariable); others
> may optionally be skipped and are marked as such, e.g. by being
> printed in smaller type.  LLllLlLL.
>
> 2. speeches or parts of speeches. Some plays present a full
> reading text of a play but mark some speeches (or lines, etc.)
> as bits to be skipped during actual performance. (Come to think
> of it, the Congressional Record would do well to do likewise:)
>
> 3. marking source of a text. Some books distinguish the source
> or authoritativeness of parts of its running text by typographic
> means, e.g., the fourth edition might print everything new to
> this edition in one font, but print everything carried over from
> a previous edition in another font, so if you just want to read
> the earlier text, stick to the text in the appropriate font. Similarly
> with text rebutting an opponent: some paragraphs marked as
> points on which the author agrees with the opponent, others
> as divergent. &c &c
>
> 4. marking function within an argument. E.g. alternating paragraphs
> representing opposing points of view (point / counterpoint); or
> question and response; or doctrine and elaboration; or statement
> and defense of same.
>
> I'm still not sure that @type is quite right for this (since it feels
> as though p @type should distinguish types of paragraphs, not types of
> content), but I think I agree that the use case is real, and is perhaps
> quite widely distributed.
>
> pfs
>
> On Wed, Apr 12, 2017, at 14:33, Martin Mueller wrote:
> > I don’t think so. I think of <argument>  as a summary of what follows. A
> > Gnomon article might have the following sequence of paragraphs, where
> > upper and lower case distinguish the different types:
> >
> > PPPpPppPPp etc
> >
> > I’m sure I’ve seen this elsewhere. The author sends the signal: “you can
> > skip this paragraph, but it’s part of a continuous argument.” You could
> > of course encode it, using @rend or @rendition. But a @type attribute
> > might be a better way of articulating this discursive structure, and you
> > could derive particular layout instructions from the structural encoding.
> >
> > On 4/12/17, 12:07 PM, "TEI (Text Encoding Initiative) public discussion
> > list on behalf of Martin Holmes" <[hidden email] on behalf of
> > [hidden email]> wrote:
> >
> >     This rather sounds like it might be a job for <argument>:
> >    
> >     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tei-2Dc.org_release_doc_tei-2Dp5-2Ddoc_en_html_ref-2Dargument.html&d=DwICaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=FXRw3zJHKvtQOXEKltpN_laj_RInMXBzcdv1PnglcCY&s=ArhMNH3Tk8ixBDtg8zBAzuPqb6vdxFjXXWPsylhv0BU&e=
> >     >
> >    
> >     Cheers,
> >     Martin
> >    
> >     On 2017-04-12 11:04 AM, Martin Mueller wrote:
> >     > I just stumbled an earlier thread about a @type attribute for <p> , and
> >     > there was a question about use cases. Here is one I can think of right
> >     > away. In the days long ago, when I regularly thumbed the Classics review
> >     > journal Gnomon, I always appreciated reviews that had a main argument in
> >     > larger type and subsidiary stuff in smaller type.  So you could read the
> >     > whole thing or skip the fine print. You could  model the fine print
> >     > stuff as inline notes, but I think of notes as bits of text that sit
> >     > explicitly outside the text stream, while the alternation of paragraphs
> >     > in Gnomon stays within a sequential reading order.
> >     >
> >     >
> >     >
> >    
> >
> --
> Paul Schaffner  Digital Content & Collections
> University of Michigan Libraries
> [hidden email] | http://www.umich.edu/~pfs/
--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

C. M. Sperberg-McQueen
In reply to this post by Martin Mueller
> On Apr 12, 2017, at 12:04 PM, Martin Mueller <[hidden email]> wrote:
>
> I just stumbled an earlier thread about a @type attribute for <p> , and there was a question about use cases. Here is one I can think of right away. In the days long ago, when I regularly thumbed the Classics review journal Gnomon, I always appreciated reviews that had a main argument in larger type and subsidiary stuff in smaller type.  So you could read the whole thing or skip the fine print. You could  model the fine print stuff as inline notes, but I think of notes as bits of text that sit explicitly outside the text stream, while the alternation of paragraphs in Gnomon stays within a sequential reading order.
>  

Tw similar examples from the 20th century:  when the programming language REXX was introduced for IBM mainframes, at least one of the manuals (probably the User’s Guide) explicitly marked two reading paths, one for the first reading covering key concepts and avoiding some details, the other (a superset of the first, if I remember correctly) including discussions of details and less crucial topics.  I no longer recall how the two were distinguished (arrows and instructions to skip to section n.m? or type size? or …?).

And the TeX and LaTeX books explicitly mark some material with a ‘dangerous curve’ icon to signal that it may safely be skipped for introductory purposes.

Like Martin (Holmes), I see that this could be captured with divs and a strong stomach for a very broad interpretation of div.  Like Martin (Mueller), I think I’d rather use an attribute on p (or two distinctive element types); it doesn’t feel at all div-like to me.

My instinct would be to say this is a good example of why it’s important that conforming uses of TEI be allowed to add attributes and elements to the vocabulary, but I have the impression that not everyone agrees that extending the Guidelines should be a normal and accepted part of using TEI.  (TEI P3 was itself a conforming instance of TEI P3, which extended and modified the vocabulary slightly as a way of underscoring the point that extensions and modifications are not shameful or undesirable.  At least, that was what at least one of the editors thought and said.)

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Syd Bauman-10
I vaguely remember that REXX book ('twas the one with a playing card
on the front, no?), but I also don't recall how it differentiated
text that was intended for one track from the other.

But more importantly, it is *very* important that a conforming use
of TEI be allowed to add attributes and elements to the vocabulary.

My take on reality is that a lot of people out there in the world
would prefer to avoid doing so. I'm not sure if that's because they
find using ODD too hard (and if so is that because our documentation
is not good enough), or don't want to deal with multiple namespaces,
or think no one will like them (particularly their funding body) if
they add something to their schema. But rest assured, it is a normal
and accepted practice.

(Of the half-a-dozen or so main TEI customizations we use at the WWP,
three have added elements or attributes.)


> Tw similar examples from the 20th century: when the programming
> language REXX was introduced for IBM mainframes, at least one of
> the manuals (probably the User’s Guide) explicitly marked two
> reading paths, one for the first reading covering key concepts and
> avoiding some details, the other (a superset of the first, if I
> remember correctly) including discussions of details and less
> crucial topics. I no longer recall how the two were distinguished
> (arrows and instructions to skip to section n.m? or type size? or
> …?).
>
> And the TeX and LaTeX books explicitly mark some material with a
> ‘dangerous curve’ icon to signal that it may safely be skipped for
> introductory purposes.
>
> Like Martin (Holmes), I see that this could be captured with divs
> and a strong stomach for a very broad interpretation of div. Like
> Martin (Mueller), I think I’d rather use an attribute on p (or two
> distinctive element types); it doesn’t feel at all div-like to me.
>
> My instinct would be to say this is a good example of why it’s
> important that conforming uses of TEI be allowed to add attributes
> and elements to the vocabulary, but I have the impression that not
> everyone agrees that extending the Guidelines should be a normal
> and accepted part of using TEI. (TEI P3 was itself a conforming
> instance of TEI P3, which extended and modified the vocabulary
> slightly as a way of underscoring the point that extensions and
> modifications are not shameful or undesirable. At least, that was
> what at least one of the editors thought and said.)
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

mholmes
I'm one of the people who's inclined to resist the idea that extensions
of the TEI should be described as conformant. My main reason is this:

The TEI becomes more useful for more people and projects as it gains new
features and refines the ones it has. If your project has a need for a
new feature, this is the process that I think should take place:

1. Read the Guidelines carefully to make sure that what you want to do
really isn't supported (and check with TEI-L).

2. Implement it as a temporary extension in another namespace in your
project.

3. Put in a feature request to the TEI, giving your temporary extension
ODD fragment as an example.

4. Participate in the discussion that eventually leads to a collective
decision for an implementation.

5. Change your project ODD and data to use the standard implementation
and become fully conformant.

I don't think there's anything wrong with extending the TEI at all, but
I think if it's encouraged as an all-around Good Thing, the result will
be a multitude of projects with divergent idiosyncratic extensions which
inhibit interchange, while the TEI standard fails to evolve to handle
the new needs.

For the record, I've done variations of #1-#5 above several times; it
takes a while, but it typically works well, and everybody benefits.

Cheers,
Martin

On 2017-04-13 10:38 AM, Syd Bauman wrote:

> I vaguely remember that REXX book ('twas the one with a playing card
> on the front, no?), but I also don't recall how it differentiated
> text that was intended for one track from the other.
>
> But more importantly, it is *very* important that a conforming use
> of TEI be allowed to add attributes and elements to the vocabulary.
>
> My take on reality is that a lot of people out there in the world
> would prefer to avoid doing so. I'm not sure if that's because they
> find using ODD too hard (and if so is that because our documentation
> is not good enough), or don't want to deal with multiple namespaces,
> or think no one will like them (particularly their funding body) if
> they add something to their schema. But rest assured, it is a normal
> and accepted practice.
>
> (Of the half-a-dozen or so main TEI customizations we use at the WWP,
> three have added elements or attributes.)
>
>
>> Tw similar examples from the 20th century: when the programming
>> language REXX was introduced for IBM mainframes, at least one of
>> the manuals (probably the User’s Guide) explicitly marked two
>> reading paths, one for the first reading covering key concepts and
>> avoiding some details, the other (a superset of the first, if I
>> remember correctly) including discussions of details and less
>> crucial topics. I no longer recall how the two were distinguished
>> (arrows and instructions to skip to section n.m? or type size? or
>> …?).
>>
>> And the TeX and LaTeX books explicitly mark some material with a
>> ‘dangerous curve’ icon to signal that it may safely be skipped for
>> introductory purposes.
>>
>> Like Martin (Holmes), I see that this could be captured with divs
>> and a strong stomach for a very broad interpretation of div. Like
>> Martin (Mueller), I think I’d rather use an attribute on p (or two
>> distinctive element types); it doesn’t feel at all div-like to me.
>>
>> My instinct would be to say this is a good example of why it’s
>> important that conforming uses of TEI be allowed to add attributes
>> and elements to the vocabulary, but I have the impression that not
>> everyone agrees that extending the Guidelines should be a normal
>> and accepted part of using TEI. (TEI P3 was itself a conforming
>> instance of TEI P3, which extended and modified the vocabulary
>> slightly as a way of underscoring the point that extensions and
>> modifications are not shameful or undesirable. At least, that was
>> what at least one of the editors thought and said.)
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Syd Bauman-10
In reply to this post by Syd Bauman-10
> Martin Holmes and Hugh Cayless have commented on GitHub (without
> rebuttal from anyone else) that of course conformance requires ...
> validity against [tei_all.rng].

True enough, but the validity conformance requires is validity *of
the stuff in the TEI namespace*. Sort of like you used an NVDL schema
that validated constructs in the TEI namespace against tei_all.rnc
and tei_all.isosch, and constructs in your namespace against your
schema(s). Except that the ODD bulding process puts both of those
notional schemas (the TEI and yours) into one output file (.rng) or
two output files (.rnc and .isosch).


> Does it matter to you or WWP whether they are conforming or
> non-conforming uses of TEI?

Ooh. Good question. The answer is (of course) both yes and no. We
care, in the sense that we think about this issue and worry about it.
We do not care, in the sense taht we do not mind ending up with a
use of TEI that is not conforming.

To be fiar, though, I think only 1 of the ODDs I mentioned is
non-conformant.


I just speng ~6 mins looking for that book, and easily found the
cover. I was right, it has a playing card. But I did not find the
content. So I guess I don't get to be disappointed, and can keep a
memory of being thrilled at two different paths to read. (Except that
my recollection is I found it annoying. :-)


> I believe the manual is now publicly available from IBM’s web site
> for IBM documentation, but I don’t want to take the time to locate
> it again. I believe I did so once and didn’t find the two-path
> reading quite as dramatic as it sounds.
>
> >
> > But more importantly, it is *very* important that a conforming use
> > of TEI be allowed to add attributes and elements to the vocabulary.
>
> I’m glad to have elicited that statement from you, given how many
> times Martin Holmes and Hugh Cayless have commented on GitHub
> (without rebuttal from anyone else) that of course conformance requires
> (or possibly should require — I can’t usually tell whether they are
> interpreting the current text or proposing a change) validity against
> TEI All.
>
> Lou occasionally pipes up to say that of course extensions should be
> conforming, but then he  then explains that a conforming extension
> will be valid against TEI All, which seems to suggest that he is speaking
> an English-like language in which some of the terms he uses (‘valid’,
> perhaps, or ‘not’) have a very different meaning from their meaning in
> the variant of English I speak.
>
>
> >
> > My take on reality is that a lot of people out there in the world
> > would prefer to avoid doing so. I'm not sure if that's because they
> > find using ODD too hard (and if so is that because our documentation
> > is not good enough), or don't want to deal with multiple namespaces,
> > or think no one will like them (particularly their funding body) if
> > they add something to their schema. But rest assured, it is a normal
> > and accepted practice.
> >
> > (Of the half-a-dozen or so main TEI customizations we use at the WWP,
> > three have added elements or attributes.)
> >
>
> Does it matter to you or WWP whether they are conforming or
> non-conforming uses of TEI?
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Lou Burnard-6
In reply to this post by mholmes

I don't think anyone disagrees that this constitutes correct and appropriate practice. The TEI (we always say) is designed to be customized, and customization can mean extension as well as subsetting. Where there does seem to be disagreement is about the terminology. We use the words "clean", "unclean", "conformant" and the like with varying intentions and varying degrees of precision. That needs to be addressed.


On 13/04/17 19:35, Martin Holmes wrote:
I'm one of the people who's inclined to resist the idea that extensions of the TEI should be described as conformant. My main reason is this:

The TEI becomes more useful for more people and projects as it gains new features and refines the ones it has. If your project has a need for a new feature, this is the process that I think should take place:

1. Read the Guidelines carefully to make sure that what you want to do really isn't supported (and check with TEI-L).

2. Implement it as a temporary extension in another namespace in your project.

3. Put in a feature request to the TEI, giving your temporary extension ODD fragment as an example.

4. Participate in the discussion that eventually leads to a collective decision for an implementation.

5. Change your project ODD and data to use the standard implementation and become fully conformant.

I don't think there's anything wrong with extending the TEI at all, but I think if it's encouraged as an all-around Good Thing, the result will be a multitude of projects with divergent idiosyncratic extensions which inhibit interchange, while the TEI standard fails to evolve to handle the new needs.

For the record, I've done variations of #1-#5 above several times; it takes a while, but it typically works well, and everybody benefits.

Cheers,
Martin

On 2017-04-13 10:38 AM, Syd Bauman wrote:
I vaguely remember that REXX book ('twas the one with a playing card
on the front, no?), but I also don't recall how it differentiated
text that was intended for one track from the other.

But more importantly, it is *very* important that a conforming use
of TEI be allowed to add attributes and elements to the vocabulary.

My take on reality is that a lot of people out there in the world
would prefer to avoid doing so. I'm not sure if that's because they
find using ODD too hard (and if so is that because our documentation
is not good enough), or don't want to deal with multiple namespaces,
or think no one will like them (particularly their funding body) if
they add something to their schema. But rest assured, it is a normal
and accepted practice.

(Of the half-a-dozen or so main TEI customizations we use at the WWP,
three have added elements or attributes.)


Tw similar examples from the 20th century: when the programming
language REXX was introduced for IBM mainframes, at least one of
the manuals (probably the User’s Guide) explicitly marked two
reading paths, one for the first reading covering key concepts and
avoiding some details, the other (a superset of the first, if I
remember correctly) including discussions of details and less
crucial topics. I no longer recall how the two were distinguished
(arrows and instructions to skip to section n.m? or type size? or
…?).

And the TeX and LaTeX books explicitly mark some material with a
‘dangerous curve’ icon to signal that it may safely be skipped for
introductory purposes.

Like Martin (Holmes), I see that this could be captured with divs
and a strong stomach for a very broad interpretation of div. Like
Martin (Mueller), I think I’d rather use an attribute on p (or two
distinctive element types); it doesn’t feel at all div-like to me.

My instinct would be to say this is a good example of why it’s
important that conforming uses of TEI be allowed to add attributes
and elements to the vocabulary, but I have the impression that not
everyone agrees that extending the Guidelines should be a normal
and accepted part of using TEI. (TEI P3 was itself a conforming
instance of TEI P3, which extended and modified the vocabulary
slightly as a way of underscoring the point that extensions and
modifications are not shameful or undesirable. At least, that was
what at least one of the editors thought and said.)

Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

Lou Burnard-6
In reply to this post by C. M. Sperberg-McQueen



On 13/04/17 17:50, C. M. Sperberg-McQueen wrote:
. (TEI P3 was itself a conforming instance of TEI P3, which extended and modified the vocabulary slightly as a way of underscoring the point that extensions and modifications are not shameful or undesirable. At least, that was what at least one of the editors thought and said.)

? I think you mean "TEI Lite was itself..." I don't remember any way in which P3 self-modified.

Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

C. M. Sperberg-McQueen
> On Apr 13, 2017, at 1:59 PM, Lou Burnard <[hidden email]> wrote:
>
>
>
> On 13/04/17 17:50, C. M. Sperberg-McQueen wrote:
>> . (TEI P3 was itself a conforming instance of TEI P3, which extended and modified the vocabulary slightly as a way of underscoring the point that extensions and modifications are not shameful or undesirable. At least, that was what at least one of the editors thought and said.)
>
> ? I think you mean "TEI Lite was itself..." I don't remember any way in which P3 self-modified.

My local copy of the P3 DTD includes two files called p3x.dtd and
p3xents.dtd, which show the following changes:

  - The elements code, ident, index, and eg are added to various model
     classes (x.data, x.metadata, x.inter) so that they can appear
     within and (and in the case of eg) between paragraphs.
     
  - The elements eg, tagdoc, entdoc, and classdoc are defined as
    x.common, which I think allows them to appear within divs.
   
  - In class m.lists, the member 'label' is suppressed.

  - In class m.sgmlKeywords, member 'val' is suppressed.

  - The element declarations for EntDoc, ClassDoc, valDesc, and
    dataDesc are overridden.
 
  - Elements decl, refBy, members, ident, and code are added.

  - All elements in the standard TEI P3 TSD (teitsd2b.dtd) are
    included (P3 defines them as appearing in separate tag-set
    documentation materials and not in TEI.2 documents).
     
This is very close to what I remembered before looking it up, but I
had forgotten that 'gi' and 'att' were already defined (in the TSD),
and I had forgotten the changes to the classes ‘lists’ and
’sgmlKeywords'.

Of course, in one respect P3 probably isn't conformant:  I cannot find
a TSD for the additions and changes.  I think we intended to make one,
but never quite got around to it.


********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: type attribute in p

John P. McCaskey-2
In reply to this post by Martin Mueller

Will Durant used this technique in The Story of Civilization. The difference in type size was subtle, even easy to overlook. Both kinds of paragraphs were part of a single narrative flow, but the slightly smaller print let the author say to the reader, “Yes, this part is a little more difficult, and I know this whole book is very long. If you skip this paragraph, don’t worry. You’ll still be able to follow what comes next.” Durant’s note was: “To bring the book into smaller compass, reduced type has been used for technical and recondite material.”


On 4/12/2017 2:04 PM, Martin Mueller wrote:

I just stumbled an earlier thread about a @type attribute for <p> , and there was a question about use cases. Here is one I can think of right away. In the days long ago, when I regularly thumbed the Classics review journal Gnomon, I always appreciated reviews that had a main argument in larger type and subsidiary stuff in smaller type.  So you could read the whole thing or skip the fine print.