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

interleave.xml?
by Martin Holmes 24 Jun '15

24 Jun '15

There's a file called interleave.xml in the Specs. Its log shows: r13221 | sbauman | 2015-05-27 18:03:01 -0700 (Wed, 27 May 2015) | 1 line Add the 'Id' Subversion keyword to source files that don't have it. ------------------------------------------------------------------------ r13076 | louburnard | 2014-11-21 04:18:32 -0800 (Fri, 21 Nov 2014) | 2 lines add interleave; fix bug #700 in tite Is it still an active part of the Pure ODD plan? Cheers, Martin

2 1

odd gotcha (or bug?)
by Lou Burnard 24 Jun '15

24 Jun '15

ODD processing always has a surprise up its virtual sleeve. Let's suppose your ODD wants to add <persName> and <orgName> and <placeName> from the namesdates module. Let's further suppose you want to see only W3C date values in your dating attributes. So your ODD has something like this <moduleRef key="namesdates" include="orgName persName placeName"/> <classSpec type="atts" ident="att.datable-iso" mode="delete" module="namesdates"/> <classSpec type="atts" ident="att.datable-custom" mode="delete" module="namesdates"/> Sound plausible? But it doesn't do what you expect. In the first place, the presence of the module attribute on <classSpec> generates the following entirely mysterious schematron error : E [ISO Schematron] Specification att.datable-custom: the value of the module attribute ("namesdates") should correspond to an existing module, via a moduleSpec or moduleRef In the second place, the moduleRef to namesdates will naturally include those classes along with the elements you've requested. In the third place, if you realise this is happening (and you are a smart ODD coookie if you do), you can replace the moduleref with elementRefs for the elements you want <elementRef key=orgName/> <elementRef key="persName"/> <elementRef key="placeName"/> Whereupon, huzza, those pesky classes disappear. Not because of your <classSpec>s of course, but because you've removed the moduleRef` In fact you can remove the classSpecs completely: if there is any way to delete a class which is specific to a module (i.e. not defined in the tei module), this isn't it, though it works fine for classes which *are* defined in that module.

4 16

pics from Ann Arbor
by Syd Bauman 23 Jun '15

23 Jun '15

No time to do anything nice with these, so this is just a pile (of reduced-size images) without any digital editing or album software. These two links are to the same set of 52 images: http://bauman.zapto.org/~syd/temp/4TEICouncil/Ann_Arbor_2015-05/ http://bauman.zapto.org/~syd/temp/4TEICouncil/Ann_Arbor_2015-05.tgz The all-at-once tarball is ~11 MiB.

1 0

NVDL validation of spec files
by Martin Holmes 23 Jun '15

23 Jun '15

As you may have noticed, our NVDL validation process for files in the P5 Source has been failing recently, with this error: "Attribute @xsl:dummy-for-xmlns is not allowed on element <xsl:stylesheet>" I raised this on the Oxygen forum, and we have two possible solutions suggested by Radu: <http://www.oxygenxml.com/forum/post34459.html> One involves a patch to Oxygen, which I'm going to try out first. If that works, I think we should just wait for it to come out in 17.1. The other involves changing the namespace prefix in our isosch file, which looks trivial but will need some investigation to make sure it will work just in that individual file, or whether there are other uses of that prefix that will need to be brought in line elsewhere in the specs. I don't think so (except for one in constraintSpec.xml), but some caution might be in order; there's a lot of stuff in Utilities that looks like it might be affected. Cheers, Martin

1 0

Re: [tei-council] Three kinds of data ref
by Lou Burnard 19 Jun '15

19 Jun '15

But why would you bother to do that when you can put a valList in dreckly? (could use xinclude if v lazy) On 19/06/15 18:56, Sebastian Rahtz wrote: > @ref could point to a remote TEI doc with a dataSpec which is just a valList > > Sebastian

1 0

dataSpec content
by Lou Burnard 12 Jun '15

12 Jun '15

I had proposed defining dataSpec without any wrapper element for the parts of it which actually define the datatype itself i.e. with an (alternate|dataRef|valList) in its content model. Sebastian points out, reasonably enough, that this makes life difficult for someone wishing to modify or change the "content" of an existing dataSpec, and is not consistent with our previous practice. I take the point, but find it hard to imagine anyone wanting to write an ODD which would modify one of our existing datatypes, when defining a new one with a different name would be much simpler and more transparent. Indeed, maybe you shouldnt be allowed to modify existing datatypes. Thanks to Sebastian's much-appreciated late night activity, the Pure ODD branch on SF (P5-Pure) now has a test file and we have a test implementation to test.... yours in purity L

3 2

p5odds-examples-odd
by Lou Burnard 10 Jun '15

10 Jun '15

I just noticed that recent changes have made p5odds-examples.odd invalid. This is the ODD file that defines the schema which is used by nvdl to validate examples in the body of the Guidelines, so it's fairly crucial that it continue to function. The error is only detected by schematron, and relates to defaultVal fiddling: I have corrected the ODD and checked it in, but I am now wondering at what stage exactly in the build process does the corresponding RNG file get generated. Simply running Make doesn't hack it, so it must be amongst the arcana involved in doing a new distribution. anyone else noticed this?

2 3

F2F Minutes Frozen
by Hugh Cayless 10 Jun '15

10 Jun '15

I’m getting ready to publish the minutes from Ann Arbor, so I have frozen the Google Doc. If you have any remaining changes you want to put in, you should let me know immediately. Thanks, Hugh /** * Hugh A. Cayless, Ph.D * Chair, TEI Technical Council * Duke Collaboratory for Classics Computing (DC3) * hugh.cayless(a)duke.edu * http://blogs.library.duke.edu/dcthree/ **/

1 0

Re: [tei-council] dataypes: the never ending story
by Syd Bauman 09 Jun '15

09 Jun '15

I understand completely that conversion to Pure ODD is a big deal, but is converting <datatype> to <dataSpec> going to have a much larger impact than using <elementRef> instead of <rng:ref>, etc.? My point is that conversion to Pure ODD is a big deal either way, no? I think you're right, project management, and maybe even some money, is in our future. (And I can already hear Hugh muttering "git-fork" under his breath. :-) > my heart slightly fails me when I start thinking about the side > effects of dropping <datatype> and converting all the Guidelines to > <dataSpec>. The existing .odd files out there stop working > (potentially), Roma stops working, as does its little cousin > Byzantium, the documentation of the Guidelines probably gets hosed, > a small myriad of utilities fall over. > > I hate to say it, but changes of this scale need a bit of project > management. > > else you need a team of dedicated people fixing things on the fly.

2 1

dataypes: the never ending story
by Lou Burnard 09 Jun '15

09 Jun '15

If we are to abide by Martin's eminently suggestion of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following a) make a set of new <dataSpec> elements corresponding with the existing <macroSpec type="dt">s b) since @ident values are supposed to be unique, these new things will all have to have different names (I suggest teidata.foo rather than data.foo) c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined Anyone got any better ideas?

3 11

unencoded words that maybe should be
by Syd Bauman 08 Jun '15

08 Jun '15

I'm going over the minutes, and strolled across bug 740. It lists an instance where a few words that should have been encoded as <gi> were not. I wondered about others. So I created http://bauman.zapto.org/~syd/temp/4TEICouncil/list-of-PCDATA-idents.html In principle, it is probably a useful task for someone to go through this set and find the few that really should be encoded as <gi> or <ident> and fix them. In fact, it's obviously a huge task that would take multi-person coordination and lots of time for little benefit.

1 0

iso schemaron syntax
by Lou Burnard 08 Jun '15

08 Jun '15

Does this look vaguely right <sch:assert test="name(parent(.))='dataSpec' and not(contains(dataRef))">An alternate element inside a dataSpec may contain only dataRef children </sch:assert> ? #tooLazyToLookItUp

2 2

oxygen-tei plugin
by Martin Holmes 08 Jun '15

08 Jun '15

Hi all, Sebastian released a new version of the Stylesheets yesterday, prompting a new version of the oxygen-tei plugin, so I've taken the opportunity of this release to enact some changes we agreed on a while ago: The new version number of the plugin is 3.0.0; this disentangles its version numbering from P5 releases. The new location and file name for the plugin is: http://sourceforge.net/projects/tei/files/oxygen-tei/oxygen-tei-3.0.0.zip The file is now named oxygen-tei-x.x.x.zip to match the actual project name and to distinguish it from the debian package, and it's in a new folder called "oxygen-tei". I've left the old "tei-oxygen" folder on SF in place for the moment, just in case, so right now there's additional potential confusion, but if all is well after a couple of days I'll do two things: 1. Move the last couple of releases with the old filenames into the new folder and give them new filenames, adjusting the updateSite.oxygen file accordingly. 2. Remove the old folder and the rest of the old versions. Please yell if you don't think I should do either of those things. Cheers, Martin

2 2

Implementation of @selector on <rendition>
by Martin Holmes 08 Jun '15

08 Jun '15

At the FtF I got the go-ahead to implement the feature request described in detail here: <http://wiki.tei-c.org/index.php/Proposal_for_@selector_attribute_on_renditi…> with the proviso that I should once more call it to everyone's attention for any final objections before I go ahead and do it. If I don't hear objections in the next few days I'll make this change. Cheers, Martin

1 0

nvdl validation of Spec files in Oxygen not working
by Martin Holmes 08 Jun '15

08 Jun '15

Lou and I discovered the other day that the current setup by which Oxygen validates Spec files when you're editing them does not work for some reason. That means that when you're editing a Spec file, you have to be extra careful not to screw anything up. We don't know why it's not working; it looks like something changed around the time of the release of Oxygen 16.1. Cheers, Martin

1 0

defaultVal deprecation
by Martin Holmes 08 Jun '15

08 Jun '15

Hi all, I think a couple of messages got lost when the lists went weird last week, so I thought I should summarize something I need feedback on. I was under the impression that I had the go-ahead to remove defaultVals when the Council was convinced it was a good idea, but Syd reminded me that we should actually deprecate things for a couple of years before removing them. However, there is no mechanism for deprecating <defaultVal>; it's not a member of att.deprecated so it can't have @validUntil added to it. So I hereby recommend that <defaultVal> be added to att.deprecated. If I don't hear any shouts of objection within the next couple of days I'll do that. That of course will require that the Guidelines build then do something with @validUntil on <defaultVal>. That will be my next order of business on this ticket. Meanwhile, I've created this wiki page with all the current defaultVals: <http://wiki.tei-c.org/index.php?title=DefaultVal_candidates_for_removal> It turns out that there are no required attributes with defaultVal, so that low-hanging fruit doesn't exist. Cheers, Martin

1 0

New Jenkins build jobs for bleeding-edge and stable plugin
by Martin Holmes 04 Jun '15

04 Jun '15

Hi all, I have what looks like a working setup on my Jenkins box for building two versions of the Oxygen TEI plugin. The original build job, "oxygen-tei", to which some of you may have subscribed, is now replaced by "oxygen-tei-bleeding", to which you can subscribe here: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei-bleeding/lastSuccessfulBuild/…> while there is also now "oxygen-tei-stable", to which if you want you can subscribe here: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei-stable/lastSuccessfulBuild/ar…> The idea is that oxygen-tei-bleeding builds with the latest plugin code against the latest trunk builds of P5 and the Stylesheets, enabling us to see if any change to any of these has broken the plugin; oxygen-tei-stable builds with the latest plugin code, but against the current release versions of P5 and the Stylesheets, enabling us to see what a release version of the plugin would look like if either we or Syncro built one right now. The build is now being done with ant, and in addition to these two targets, there's also: ant syncro which builds a version for the Syncro folks using the latest stable P5 and Stylesheets, as they would do when creating a build for a new Oxygen release. Up to now they've been using our original update-and-upload.sh script, and then preventing it from uploading to SourceForge as it tries to do. That script also requires that you _know_ the correct versions of P5 and the Stylesheets, and supply them correctly on the command line; the new ant build script works that information out for itself. Finally, there is: ant stable which is what our release technician would use during a P5 release process, or what we would use to release an official build of our version of the plugin. This builds in the same way as the version above, but also offers to upload the result to SourceForge, and creates a new version of the updateSite.oxygen file which it offers to upload to tei-c.org. This should make releasing a new plugin version much easier, I hope (although it can only truly be tested for real when we come to release a version, so I'd like to be the one who runs it for real the first time in case something goes wrong). I've added the new job configs for Jenkins to SVN, where James can find them for the Oxford Jenkins, when he has the time. This is all brand-new and only gently tested, so let me know if you try anything, and please report any problems with as much detail as you can. Cheers, Martin

3 4

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 02 Jun '15

02 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 31 May '15

31 May '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