- Tei-council - lists.tei-c.org

Minutes Doc and scheduling
by Hugh Cayless 04 Jun '15

04 Jun '15

Hope that by now everyone’s made it home safely. Can we all look over the minutes doc while the meeting is still fresh in our memories and correct/add anything that’s missing? I will plan to freeze the document on Friday June 5th and convert the minutes over for the website. Re scheduling the next telecon: Do we want to try to stick with Fridays at 09:00 or 10:00 EDT? That’s 06:00/07:00 PDT, 14:00/15:00 BST, 15:00/16:00 CEST. I’m flexible as to day of the week during the summer—when I’m not actually away, of course. Fridays in June/July look particularly difficult. I’ll either be on vacation or away on business for several of them. Doodle poll for June telecon: http://doodle.com/q5ixp76erdceeydk <http://doodle.com/q5ixp76erdceeydk> Doodle poll for July telecon: http://doodle.com/xy2hqrpk9swnzhzd <http://doodle.com/xy2hqrpk9swnzhzd> Doodle poll for August telecon: http://doodle.com/txi5p2cn3mhmfizr <http://doodle.com/txi5p2cn3mhmfizr> Thanks to all of you for your hard work last week. It felt to me like we covered a lot of ground. All the best, Hugh

8 10

defaultVals for removal
by Martin Holmes 03 Jun '15

03 Jun '15

Hi all, Re this ticket: <https://sourceforge.net/p/tei/feature-requests/546/?page=1> I was under the impression from our discussion at the FtF that my job was to present the case for removing defaultVals one by one, and then remove them if Council did not object. However, Syd points out that this should be done through deprecation, so I've now added @validUntil on <defaultVal> on att.fragmentable/@part. We'll see what shows up in the Guidelines build as a result -- I'm not sure whether there's adequate handling in the Stylesheets for it. Meanwhile, I've generated a complete list of atts with defaultVal here: <http://wiki.tei-c.org/index.php/DefaultVal_candidates_for_removal> since that seems to be what Syd was expecting. He was tasked with removing those which are on required attributes, but there don't seem to be any of those. Cheers, Martin

1 1

Re: [tei-council] [tei:feature-requests] #546 <defaultVal> should be removed from all specs
by Syd Bauman 03 Jun '15

03 Jun '15

Martin -- We'll talk tomorrow, I'm sure, but I'm not sure this is OK. I know you hate default values, as do I, and we want to get rid of them. But I'm not sure it's acceptable to yank them out w/o warning. DTD users might be upset. Besides, changing the semantics of a value like that is the sort of thing users need warning about. Those who actually have part="N" explicitly expressed may well be using it to say "I can't tell if this is a fragment or not". MH> att.fragmentable's @part now has no defaultVal, and the "N" value MH> now actually means "no", as it should. Rev 13232.

2 6

dataSpec content
by Lou Burnard 01 Jun '15

01 Jun '15

I'm still poking away at my datatype replacement ticket ... We agreed that <dataSpec> should be used to fully specify a TEI-defined datatype and also noted in passing that its existing <content> child needed additional constraints (e.g, it shouldnt allow you to supply elementRefs) In fact it seems to me that the "content" of a dataSpoe should be much more restrictive: I'd like for it to contain just <alternate>, <sequence>, <valList>, or <dataRef>, with the additional constraint that <alternate> and <sequence>s it contains can contain only one or more <dataRef>s If no-one has any counterproposal that's what i am planning to try to implement anyway.

2 1

Fast-track a simple ticket
by Martin Holmes 31 May '15

31 May '15

Hi all, This ticket: <https://sourceforge.net/p/tei/feature-requests/561/> arose out of our re-working yesterday of Laurent's standoff proposal. I'd like to fast-track it if we can; it seems straightforward to me, and doesn't involve any Birnbaum issues. While I get around to figuring out the actual change to the Spec file, could you all check to see if you have any objections to it in principle? Cheers, Martin

6 7

rng:group but no rng:choice
by Peter Stadler 31 May '15

31 May '15

I just stumbled across the content model of climate (and there are more …) which looks like <content> <rng:group> <rng:zeroOrMore> <rng:ref name="model.headLike"/> </rng:zeroOrMore> <rng:choice> <rng:group> <rng:oneOrMore> <rng:ref name="model.pLike"/> </rng:oneOrMore> </rng:group> <rng:group> <rng:oneOrMore> <rng:ref name="model.labelLike"/> </rng:oneOrMore> </rng:group> </rng:choice> <rng:zeroOrMore> <rng:choice> <rng:ref name="model.noteLike"/> <rng:ref name="model.biblLike"/> </rng:choice> </rng:zeroOrMore> <rng:zeroOrMore> <rng:ref name="climate"/> </rng:zeroOrMore> </rng:group> </content> My question is: is there some magic to the surrounding rng:group or could that be deleted? (I don’t intend to do so but was just wondering …) Best Peter

2 2

rework of standoff proposal
by Peter Stadler 31 May '15

31 May '15

Dear all, a Council working group (PFS, LB, MH, FC, SM, PWS) just created an alternative proposal as the "Ann Arbor" branch at https://github.com/laurentromary/stdfSpec/tree/AnnArbor. The changes in detail: * killed mapStruct * renamed annotationGrp —> listAnnotation * renamed model.annotationPart —> model.annotation * got rid of dash in module name * removed class att.confidence in favor of https://sourceforge.net/p/tei/feature-requests/561/ * added some more elements to model.annotation * removed standOffHeader in favor of teiHeader(!!) We did not update the examples yet. I’m curious about Laurent’s reaction and will probably have a conf call in the next week with him (— Laurent?!) Best Peter

5 12

Recommendations on values of @xml:id (FR #540)
by Raffaele Viglianti 31 May '15

31 May '15

Hi all, Martin Mueller asked on the list for recommendations on good uses of xml:ids, which resulted in a good discussion and a FR. I summarized the main suggestions on the ticket on SourceForge, but I post them here as well because I think we need to discuss this further, see below. The Guidelines already have some recommendations (numbering based on doc structure): * The Guidelines already suggest numbering based on doc structure ( http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS2) * Use 3 letters (e.g. from the title)+ 3 digits, incremental. E.g. HOL001, HOL002, etc.. * Same as above, but no fix number of digits. E.g. HOL1, HOL2, etc. * Prefix an id with name of element (this is simpler version of what the Guidelines already recommend) * Give tei:TEI an id and prefix every other id in the document with it (to guarantee cross-corpus uniqueness) These are all reasonable suggestions and there can be plenty more - which is why I think that the TEI should *not* give any recommendation on best practices for xml:id because it's a project management issue, not an encoding one. Myself, I prefer random ids, a practice that avoids introducing yet another level of complexity and data management. I understand the human readability, but sequences are too easily broken. And when parsing, relying on ID content instead of TEI content sounds like a bad idea.

7 16

Next defaultVal to be nuked
by Martin Holmes 30 May '15

30 May '15

I hereby nominate att.divLike/@org's defaultVal: <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.divLike.html> This has its own novel brand of silliness: There are two values, and the first value, "composite", means "no claim is made about the sequence in which the immediate contents of this division are to be processed, or their inter-relationships." Yet THIS IS NOT THE DEFAULT VALUE; the _other_ one, "uniform", which _does_ make a claim, is the default. Well FFS. It shall die unless I hear otherwise in the next few hours. cheers, Martin

3 5

eXist-db password changed
by Peter Stadler 30 May '15

30 May '15

Sid argued strongly that we should change the admin password for the eXist-db that serves Roma (the issue arose around the discussion of tickets [feature-requests:#527] and [bugs:#747]). Hence, I duly changed the password and documented it as described in [1] and briefly checked that Roma still works. If you encounter any side effects, please let me know! Best Peter [1] http://www.tei-c.org/Activities/Council/Working/tcw22.xml

2 1