HI Dan,

O'Donnell, Dan wrote:
> Hi John,
> 
> I was agreeing with the non-universal typers, as I find the argument
> so convincing that p is sugar for ab@type=p and hence that p@type is
> really ab@[log in to unmask] 

I think there's a danger here: we're saying that when @type is on <ab> 
it means @type, but when it's on <p> it means @[log in to unmask] It would be 
better, I think, to say that if <p> = <ab type="paragraph">, then <p> 
should have @subtype (but not @type).

But that would inevitably cause confusion.

Although I know what it apparently means to say that "<p> is syntactic 
sugar for <ab type="paragraph">, I realize that I don't know what it 
_really_ means in terms of TEI's structure and intent. Perhaps that is 
what we need to clarify (or I need to learn).

Cheers,
Martin


My point was that perhaps the solution to
> this perennial issue is to explain the rationale... But that that
> might require us to do some serious thinking about what actually /is/
> sugar among the core elements.
> 
> I like this generally because I think a) there is considerable room
> for work on the question of the relationship between generic vs.
> specific elements and b) being very specific about this type of
> relationship would considerable ease some difficulties have with TEI.
> 
> 
> You're right about thread getting weird... I was travelling and my
> cell phone seems to have decided that sending out emails as soon as
> they are written is common. It's been throwing them off at all sorts
> of weird times.
> 
> ----------- Daniel O'Donnell University of Lethbridge (From my mobile
> telephone)
> 
> --- original message --- From: "John A. Walsh" <[log in to unmask]> 
> Subject: Re: Typing <p>s and others Date: January 18, 2010 Time:
> 11:1:16
> 
> Dan,
> 
> A key point below seems to be a valid desire to "creat[e] very fine 
> distinctions between uses of elements." As many others have already 
> described in this thread (or the sister thread; I think we diverged
> at some point), there are many ways to make such distinctions in TEI 
> without resorting to the arguably extreme position that every single 
> element in the TEI so general or broad in its semantics that it 
> requires @type (and @subtype?) attributes.
> 
> John
> 
> On Mon, Jan 18, 2010 at 11:38 AM, O'Donnell, Dan 
> <[log in to unmask]> wrote:
>> I don't find the reductio ad absurdum argument about @type all that
>> convincing. And, moreover, I think in the type of analytic work
>> members of our community do it is not particularly weird to imagine
>> that they might be interested in creating very fine distinctions
>> between uses of elements (I'm also not convinced that the leaders'
>> opinions are necessarily a strong ipso facto reason for denying
>> it). Given that the cost is relatively low and this is a perennial
>> issue, I've always been a universal @[log in to unmask] It has always seemed to
>> me to be a painless no brainer.
>> 
>> The one argument I've found convincing on the other side is that if
>> tei:ab@type='p' = tei:p, then tei:p@type='x' is really the same as
>> tei:ab@type='p'/@subtype='x'
>> 
>> But this raises a really intersting set of issues: a) are we as
>> specific and consequential as we should be about which canonical
>> elements like p are actually sugar for a generic element like
>> ab@type? B) Have we gone through to check that @type doesn't show
>> up on any element that is really sugar for a generic element that
>> currently doesn't allow a subtype?
>> 
>> This is an exciting argument to me as it really asks us to consider
>> the role of generic elements and their relationship to potentially
>> sweet specific elements like p.
>> 
>> ----------- Daniel O'Donnell University of Lethbridge (From my
>> mobile telephone)
>> 
>> --- original message --- From: "Hugh Cayless"
>> <[log in to unmask]> Subject: Re: Typing <p>s and others Date:
>> January 17, 2010 Time: 9:8:1
>> 
>> It might. I don't want to argue much for p/@type, because I don't
>> want to use it myself, and I'm not sure there are any great
>> arguments in favor of it.  If the leaders of the TEI want to say
>> some elements can be typed and some can't then I think that's
>> absolutely their prerogative.
>> 
>> I see @type being used in at least two ways:
>> 
>> 1) it marks an element as actually being a member of a child class
>> (to use object-oriented terminology), so <ab type="paragraph"> is
>> <p>, like <name type="place"> is <placeName>, and you pick one or
>> the other style based on your needs and/or the constraints of the
>> schema you're using.
>> 
>> 2) It provides meta-information about the element that is useful in
>> characterizing it and will be useful downstream (in online display,
>> or search indexing, or whatever) for treating that element
>> differently than its cohorts, so  <div type="translation"> perhaps,
>> or <placeName type="ancient">.
>> 
>> The problem with <p> is that while use #1 is almost certainly
>> nonsense for @type in its case, I'm not 100% sure it follows that
>> use #2 is also.
>> 
>> Your point about the dangers of rich syntax is well taken, and from
>> your examples we already have it :-).  It makes the need for an
>> "Effective TEI" or "TEI Patterns and Antipatterns" guide very
>> clear.
>> 
>> Hugh
>> 
>> On Jan 17, 2010, at 7:30 PM, Syd Bauman wrote:
>> 
>>>> Personally, I think @type should be available anywhere you
>>>> might conceivably want to distinguish one use of an element
>>>> from another, and I can imagine wanting to do that with <p> (<p
>>>>  type="introduction">, etc. perhaps).
>>> A quite reasonable position, but wouldn't that be <p 
>>> ana="#introduction">?
>>> 
>>> I bring this up not to be pedantic, but to make a point. The TEI
>>> is not a "standard" per se; it is rather a set of Guidelines
>>> collected from, among other things, actual practices in the
>>> community, and thus sometimes the Guidelines need to embrace more
>>> than one method for encoding the same information. Because of its
>>> diverse intended use and audience, a variety of methods for doing
>>> the same sort of thing will often be required.
>>> 
>>> Nonetheless, TEI behaves as a standard in many ways. And as such,
>>>  having more than one way to express exactly the same thing can 
>>> actually be harmful rather than helpful.
>>> 
>>> We don?t want rich syntax, we want rich semantics. ... I don?t 
>>> want ten ways to express the same thing, or even two ways to 
>>> express exactly the same thing.               -- Tommie Usdin 
>>> http://conferences.idealliance.org/extreme/html/2002/Usdin01/EML2002Usdin01.html
>>> 
>>> 
>>> We already have multiple ways to indicate that a particular
>>> passage (e.g., the 1st para; say it has xml:id="p1") is an
>>> introduction: * <span from="#p1">introduction</span> * <span
>>> inst="#p1">introduction</span> * <interp
>>> inst="#p1">introduction</interp> * <interp
>>> xml:id="intro">introduction</interp> ... <p ana="#intro"
>>> xml:id="p1">[1] Not only am I loathe to add another, I'd like to
>>> get rid of 2 or 3 of these.
>>> 
>>> So while I completely agree with the broad position of using
>>> type= wherever there is a need to distinguish one use of an
>>> element from another using an enumeration, I think it's really
>>> important to examine these cases quite carefully, rather than add
>>> type= willy- nilly.
>>> 
>>> Note ---- [1] Worth noting here that the <interp> need not be
>>> present. If it's not, this effectively changes ana= from a
>>> pointer (not machine constrained unless you write the code
>>> yourself) to a local vocabulary (not controlled unless you write
>>> the software yourself) with slightly weird restrictions on its
>>> syntax.
>>> 
> 
> 
> 

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]