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

feasibility and NVDL (and <xenoData>)
by syd＠paramedic.wwp.neu.edu 11 Jul '15

11 Jul '15

If the content model of <xenoData> is any.XML+, then the valid= of any <egXML> that contains a (valid) <xenoData> had better be "feasible" (or "false", I suppose), lest that <egXML> be flagged as having "error: unfinished element" by ./run-onvdl p5valid.nvdl v.xml If the content model of <xenoData> is any.XML*, then the valid= of the <egXML>s can be "true". This doesn't make sense to me, as the NVDL explicitly allows elements from the namespaces involved. But I'm guessing that before it checks the <egXML> itself for validity against the RELAX NG, it has removed elements from other namespaces (thus leaving an empty <egXML>). What is the difference between using "feasible" and "true" as far as processing is concerned? I.e., how does the feasibly-valid-checker (called p5.nvdl) know to apply the http://www.thaiopensource.com/validate/feasible to those <egXML>s flagged as "feasible" or "true", and how does the truly-valid-checker (called p5valid.nvdl) know not to? Must, of course, be that the latter is run against "v.xml", not p5.xml, but when and how is v.xml generated? For now I've checked in a version (to the P5-for-xenoData/ branch) with any.XML+ that uses "feasible" on its <egXML>s.

1 0

A quick question
by Martin Holmes 07 Jul '15

07 Jul '15

Can someone please remind me how to declare an attribute such that its content can be one or more of a set of values drawn from a fixed list? In other words, a closed valList, but allowing more than one item from the list. I'm sure I must have done this before, but I can't remember it. Cheers, Martin

2 1

readable xenoData
by Syd Bauman 04 Jul '15

04 Jul '15

I've put a complete copy of a P5-for-xenoData/ *with a built set of Guidelines and Exemplars* at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/. So see, e.g. http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Guidelin… (And someone let me know what the heck is the problem with the formatting -- it looks awful.) And use the schema at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Exemplar… to test it out.

3 5

link
by Hugh Cayless 29 Jun '15

29 Jun '15

https://docs.google.com/document/d/17EBZ56GTUpJM1pwhMYXx7NvKqA-W6OYZBv_GeHO…

3 5

App. Crit. discussion summary
by Hugh Cayless 29 Jun '15

29 Jun '15

Dear all, I’m trying to summarize the conclusions of the discussions Martin, Raff, and I had following the Ann Arbor meeting concerning what to do with block-level variation. If I’ve left out anything important, please correct me! * Syd’s suggestion that we allow more or less universal @wit and use that to distinguish between block-level variants doesn’t really fly, I’m afraid. It leads to a rather chaotic document, with a need for liberal use of @exclude attributes. It would be both hard to work with, and potentially quite hard to render. * The group feels that adding new app/lem/rdg elements for each level of block possible would also be too much. * We discussed at length whether a bending or breaking of the TEI Abstract Model† was in any way desired by structural app partisans. My own feeling is that it’s not, and Marjorie (the original filer of the bug) doesn’t want to do that sort of thing either: http://sourceforge.net/p/tei/bugs/753/#cd40/b53c <http://sourceforge.net/p/tei/bugs/753/#cd40/b53c> * Given that, we think some sort of structural app is needed. But we need to work on checking for Abstract Model violations and adding documentation warning against using structural app for evil. I’ve started to play with Schematron rules, but haven’t gotten as far as actually testing them yet. I may need some help generating a schematron document for my schema. For a bit of fun, you might want to check out the paper and demo I gave last week that uses HTML Custom Elements to render a TEI file with apps containing lines. The demo is at http://hcayless.github.io/appcrit/Propertius-1-15.html <http://hcayless.github.io/appcrit/Propertius-1-15.html> and the paper at https://github.com/hcayless/appcrit/blob/master/docs/DLL-seminar-paper.md <https://github.com/hcayless/appcrit/blob/master/docs/DLL-seminar-paper.md> † though I note that the actual definition is recursive (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#CFAM <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#CFAM>). The TEI Abstract Model is whatever the Guidelines says it is...

1 0

Google Hangout link
by Hugh Cayless 29 Jun '15

29 Jun '15

Here’s the link: https://plus.google.com/hangouts/_/g32giwnw3t5eqysbfveh5sd2lma I have also called in to the Economy Conference Call service, so you can join there if you prefer. Seems to work. It’s playing Vivaldi at me.

1 0

Next Telecon
by Hugh Cayless 29 Jun '15

29 Jun '15

We’ve had 7 participants in the Doodle poll for the next telecon, and the best date/time seems to be next Friday 6/19, at 09:00 EDT / 06:00 PDT / 14:00 BST / 15:00 CEST. I think this will be a relatively short meeting, mostly just followup on items from the F2F. Let’s do Google Hangouts again, but I will try to loop in the conference call as well, so that people can call into that if the internet isn’t playing nice. Hugh

8 12

Agenda for Monday
by Hugh Cayless 29 Jun '15

29 Jun '15

* Critical Apparatus Report * Status report on Standoff * Fall F2F update * Ticket Review from F2F If James is on the call, maybe he can tell us whether there’s anything new from Simple, but I don’t want to pressure the folks in Sydney to stay up half the night. You are excused unless you really want to join!

3 2

Monday's call
by Hugh Cayless 26 Jun '15

26 Jun '15

Hi all, I've been swamped this week prepping for and am now at a meeting in Oklahoma, so I've been slow getting agenda details out, but I will follow up on that later today. We will be meeting Monday the 29th at 07:00 PDT / 10:00 EDT / 15:00 BST / 16:00 CEST / 00:00 AEST in a Google Hangout, which I will initiate Monday morning and send the details out by email beforehand. I will also attempt to call into the Economy conference call system, so you can join that way if you need or prefer to. Details below: US: 866-906-0040 or 857-288-2640 Canada: Use US number. UK: 0800-016-3440 Germany: 0800-182-0270 France: 0800-916-758 Italy: 800-789-804 The access code is 5753850 (followed by the '#' key)

2 2

Re: [tei-council] Release of the Oxygen plugin
by Syd Bauman 26 Jun '15

26 Jun '15

Another post that did not make the list (and there are several more to follow), this one from 2015-06-02 10:18, and is now mostly irrelevant. > Sigh. That's too bad. Perhaps we should start with something > distinctly out of range. Kinda the way Apple did with the re-launch > of its signature operating system for Macintosh when it changed to > Unix-based. So we'd start with "10.0.0", and go up from there. > > Or perhaps not, and "3.0.0" will do just fine. > > > We can't start with a version below what's currently installed in > > people's Oxygens, I don't think, otherwise it won't show as an > > update.

2 1

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 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