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

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

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