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

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

09 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