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

Datatype quandary
by Lou Burnard 26 Jun '15

26 Jun '15

We had agreed (fairly tentatively, but it is what Sebastian has since implemented) that in the new scheme of things, a purified attribute definition would simply embed a <dataRef> directly, rather than wrap it in some as-yet-unnamed alternative to the current <datatype> element. In testing this out against the Guidelines, I have now realised why this was not a good idea. Of the 466 instances of <datatype> in the current P5 source, a sizeable proportion (106) specify a @maxOccurs attribute to indicate that the attribute can (or cannot) take multiple instances of the datatype indicated. This can't be specified on <dataRef> itself at present, these attributes nopt being available. So we are left with the following choices: a) add @maxOccurs and @minOccurs to <dataRef> and cope with the ensuing chaos if the <dataSpec> being referenced permits multiple values b) define a whole raft of new <dataSpec>s and <dataRef>s, one for each combination of occurrence indicators and <dataref>, so that for example we will have teidata.pointer, teidata.pointers, teidata.atLeastTwoPointers etc etc. c) invent something which behaves just like <datatype> but has a different name and doesn't allow anything except <dataRef> as a child. d) permit <dataRef> as a child of <datatype> I bet smart chaps like you can tell which solution I am recommending... just for the record, the current model for <datatype> is an alternation of <macroRef> and "any-XML". In practice we use only the latter, as every <datatype> has a content resembling <rng:ref name="data.foo"/>. So proposal (d) above is arguably not really a change at all, since <dataRef> is just syntactic sugar for <macroRef> I'd like to move ahead on this this week, since it's holding up my testing of the purified version of the Guidelines. Can I ask for a quick response along the lines of EITHER "no problem" OR "hold on there I need to think about this" by Monday??? Or of course, "You idiot what about this completely different and much better solution"

2 4

Re: [tei-council] Datatype quandary
by Syd Bauman 26 Jun '15

26 Jun '15

I'm sure you've thought this through much more thoroughly than I, so I'm wondering if you can explicate this for me. Our end goal is to have a system in which the Guidelines, customization files, and non-TEI languages are expressed in PureODD, and all our processing chains work at least as well as they do now, right? But once we have the various processing working so that we can define one datatype using <dataSpec> and refer to it from a content model or attribute definition (or macro specification) with <dataRef>, why wouldn't we define them all that way? I realize that getting all our processing working is a tall order, as there is lots to do and some of it is very hard (or, at least, way beyond me). But if it works for one datatype, why not all? The answer might involve the fact that we're trying to build processing that can simultaneously handle *either* impure ODD or Pure ODD. While this seems nice to me, it doesn't strike me as a requirement. So perhaps I'm asking "why do we need co-existence?" If users are told "use all old or all new style ODD, submit old style to this process, new style to that process", I have no real problem with that. I guess I'm fuzzy on why co-existence is easier than big bang. If you could focus my lens on this, I'd appreciate it. > yes, if you want to go for co-existence you need all macroSpec and > new dataSpec coexisting in the same name pool. > > I dont think we are ready for a big bang conversion

1 0

Re: [tei-council] Touching Once (is so Hard to Keep)
by Syd Bauman 26 Jun '15

26 Jun '15

I think, or at least hope, this is the last of the "it didn't get delivered to list" re-posts. This one is from 2015-06-02 08:04, and was also sent to Sebastian, who answered me directly. Per his answer, reproduced below, I renamed the program 'Touch' to 'build-if-newer.sh' in r13246. (I post here in part because the commit message refers to this e-mail.) Since nothing has broken with the name-change (and some things work better), we could just delete the program entirely. > [Subject is the title of the last song on _Novella_, the 1977 > Renaissance album.] > > Can you tell me what the shell script "Touch" in directory P5/ is > for? It seems to do "If anything in ../P5/, ../Stylesheets/, or > ../I18N/ has been updated, then run a bunch of builds". But why, and > more importantly, why is it called "Touch"? Is it executed from some > other program(s) or only intended to be typed at the commandline? > > This turns out to be a real, if minor, problem, because while most > GNU/Linux systems default to case-sensitive file-systems, the Mac OS > X "Darwin" commandline defaults to a case-insensitive file-system. > Thus when running `make` on Mac OS X, this pgm gets executed when the > Makefile tries to execute a `touch`. > > I'd like to change the name of this cmd to > Touch.sh > build-if-updated.sh > make-if-updated.sh > or some such. > > P.S. I'm asking you, Sebastian, because no one but you has touched > this file (pardon the pun) in its entire Subversion hx on > current SF (i.e., since 2007-10 when you "put back executable > Touch"). SPQR> honestly, I have no memory of this script. i suggest you delete SPQR> it and see if anything breaks.

1 0

Re: [tei-council] bad date example
by Syd Bauman 26 Jun '15

26 Jun '15

This is from 2015-06-02 10:12, and is worth reading and reminding ourselves of the issue. > Indeed. Clearly there is controversy over this, although I thought it > would be pretty straigtforward. So that we don't forget to address > it, I've just created bug 762 and made it amber. > > BTW, yes, <precision> is, IMHO, the right answer. The problem there > is that @atLeast and @atMost are (appropriately) defined as > data.numeric, not a temporal datatype. > > Using LOC dates would also solve the problem. > > > Digging a little bit in the archives reveals that we had that sort > > of discussion before. Personally, I’m with Syd and would not mix > > notBefore/notAfter with from/to (nor with when) but this seems not > > to be agreed practice: > > * http://tei-l.970651.n3.nabble.com/Precision-of-time-information-for-state-t… > > * http://tei-l.970651.n3.nabble.com/datable-attributes-and-durations-of-uncer… > > BTW, for all sorts of fuzziness we have <precision>.

1 0

Re: [tei-council] New Jenkins build jobs for bleeding-edge and stable plugin
by Syd Bauman 26 Jun '15

26 Jun '15

This one from 2015-06-02 10:15. > > What do you see if you go to Help / Manage Add-ons? I see only one, > > the bleeding build. > > I see only one, but don't know which one it is. (Nor do I know how to > tell, unless I decipher the version #, which in this case is > "2.8.2".) > > > > I think the Preferences page just lists all updateSite.oxygen files > > that are known to Oxygen, not those which are active. > > > > Your post nicely copies my original post to the list, though, which > > I was supposed to re-send, so I'll consider it re-sent.

1 0

Re: [tei-council] repair 751, take 1
by Syd Bauman 26 Jun '15

26 Jun '15

I sent this 3 weeks ago (on 2015-06-05 23:32), but as far as I can tell, it never made it to the list itself. At least, it doesn't seem to be in the archives, and no one has responded. I realize some folks are off to my namesake city, but I'd like to get this off my plate. > Reminder to everyone to take a look at the solution in the branch at > https://svn.code.sf.net/p/tei/code/branches/P5/for-bug-751 Unless > there are objections, I'll plan to fold this in on or about Fri > 06-12. > > Problem: <event> is not allowed as a child of <org> > > Current ways <person> and <place> get child <event>: > > model.persEventLike => birth death event listEvent > model.placeEventLike => event > > > Proposed way <org>, <person>, and <place> get child <event> (in that > branch): > > new class, model.eventLike > > model.orgPart => model.eventLike > model.personPart => model.eventLike > place => model.eventLike > > removed model.placeEventLike and model.persEventLike (and made > <birth> and <death> directly members of model.personPart) > > > One might argue that we should keep model.persEventLike and > model.placeEventLike, and add model.orgEventLike. But since 2 of > those classes would have nothing but <listEvent> and <event> as > members, I took the slimmer route.

1 0

Fwd: Re: NVDL error from forums
by Martin Holmes 25 Jun '15

25 Jun '15

This is a patch from Radu. I've tested this and it works perfectly; our Spec and Guidelines files can now be validated. I'm waiting to hear if this is going to be part Oxygen 17.1. Either way, anyone editing specs or guidelines will probably want to install this. It seems to be the case that dataNode.xml, dataRef.xml, dataSpec.xml and interleave.xml are invalid, but I'm guessing it's because they reference each other, and can't validate against the last release of the schema. I'll try validating them against the latest Jinks NVDL. Cheers, Martin -------- Forwarded Message -------- Subject: Re: NVDL error from forums Date: Wed, 24 Jun 2015 09:19:02 +0300 From: Radu Coravu <radu_coravu(a)sync.ro> To: Martin Holmes <mholmes(a)uvic.ca> CC: Oxygen XML Editor Support <support(a)oxygenxml.com> Hi Martin, Applying the patch would be something like: 1) In the Oxygen installation folder there is a "lib" folder. In that folder you should create a new folder structure like: > endorsed/com/thaiopensource/validate/schematron/resources/ 2) In the "resources" folder copy the Schematron file I'm attaching. This patch should override the Schematron file which comes with the "jing.jar" library. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 6/23/2015 8:51 PM, Martin Holmes wrote: > Hi Radu, > > Many thanks for looking into the NVDL issue for us. On the board post: > > <http://www.oxygenxml.com/forum/topic11601.html> > > you mentioned a patch I could try out for you -- do you want to send it > over? > > The other solution (changing the prefix) is something we can fall back > to if we have to, but it will involve editing a lot of files (Schematron > is distributed all over our specification files), so I'd rather try > something else first. :-) > > Many thanks, > Martin >

1 1

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

24 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