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

SF restore is not complete yet
by Martin Holmes 29 Jul '15

29 Jul '15

Hi all, Just an update on the SF situation: I just tried to upload a new release of Roma to the Files area and that functionality is not yet working; it fails when you try to do it over SSH from the command line, and the GUI which is supposed to be available to admins on the website is not there yet. That means we cannot yet release updated versions of anything. Me no like. I'm copying Kevin on this in case he knows anything about the bandwidth expectations/agreements/limits that might pertain to our shared hosting with ADHO; it seems to me that we might well want to serve our files from our own server if we can. We had 1117 downloads of P5 (which is about 256MB) from SF in the last year, which would amount to less than 300GB per year. Could our hosting deal handle that? Cheers, Martin

2 3

July Telecon
by Hugh Cayless 28 Jul '15

28 Jul '15

Hi all, A reminder that we need to schedule our July telecon in a week or so. Please fill out the poll at http://doodle.com/xy2hqrpk9swnzhzd <http://doodle.com/xy2hqrpk9swnzhzd> if you haven’t yet. I’ve been traveling for a while, so I’m running a little behind on organization, but I’ll try to have an agenda up this week. Possible agenda Items: Source Control and administration discussion Fall F2F App validation? Ticket review What else? /** * 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/ **/

9 16

Re: [tei-council] Something weird about tei-c.org
by Martin Holmes 28 Jul '15

28 Jul '15

Hi Kevin, Sebastian et al, I've just done a quick bugfix for the Roma PHP webapp: <https://sourceforge.net/p/tei/bugs/724/> and tested it locally and it seems to work fine. As far as I can tell from browsing around the projects/tei/web/Vault directory, the current deployed version of Roma on tei-c is 4.15; the new build is 4.18. The system looks similar to the setup for P5, where the "current" symlink points to whatever should be the current version. I think (but I'm not sure) that we can get a new version deployed like this: - Create new 4.18 directory - Get the latest build from Jenkins: <http://teijenkins.hcmc.uvic.ca/job/Roma/lastSuccessfulBuild/artifact/tei-ro…> and unzip it into there. - Change the "current' symlink to point at it. However, there's something slightly odd going on. As far as I understand it, tei-roma/roma.php requires a file called config.php in the same directory. That file is (I thought) created by copying the file config-dist.php to config.php and then customizing it as necessary for the local install. roma/roma.php contains this: require_once( 'config.php' ); so it it's definitely expected to be available. But in current/tei-roma/roma, there is no config.php; there are various versions of config-dist.php resulting from what appears to be an svn conflict, where the differences amount only to the version number and date. So my question is: am I wrong about the fact that config.php is expected to be created from config-dist.php? That is what I did on my local test install, and it worked fine. If I'm right, that would seem to suggest that Roma on tei-c.org has been running slightly misconfigured, and managing without the missing config.php somehow (perhaps error messages are being suppressed). Does anybody know anything about this? I'm not seeing any documentation on how to deploy the PHP Roma, so I've started a new section on the wiki page: <http://wiki.tei-c.org/index.php/Roma#Getting_the_Roma_server_running> Cheers, Martin On 15-07-27 01:44 PM, Kevin Hawkins wrote: > As you've probably seen by now, we did in fact get a notification from > Uptime Robot, and it's already back up. > > This is the first time I've seen the TEI site go down while I'm at my > computer. The ADHO site remained up during that time, and given how > often I've seen notifications that that site goes down while the TEI > site stays up, it appears that these two sites function independently > despite sharing a hosting service. > > Nick, I'm going to turn off the Uptime Robot notifications for the ADHO > site for now. > > Kevin > > On 7/27/15 3:42 PM, Martin Holmes wrote: >> Hi Kevin, >> >> I was just working on Roma on tei-c when it stopped responding. I then >> went to try tei-c.org, and the site doesn't seem to be responding. If >> you ping it, the ping is returned by digitalhumanities.org, so tei-c >> appears to be up for services like isup.me, but wget requests never get >> a response, and I see this proxy error message eventually in my browser: >> >> Proxy Error >> >> The proxy server received an invalid response from an upstream server. >> The proxy server could not handle the request GET /index.xml. >> >> Reason: Error reading from remote server >> >> Additionally, a 502 Bad Gateway error was encountered while trying to >> use an ErrorDocument to handle the request. >> >> Just letting you know, because I don't know whether uptimerobot will >> notice it. >> >> Cheers, >> Martin

3 3

Looks like the SF svn repo is back up
by Martin Holmes 26 Jul '15

26 Jul '15

<http://sourceforge.net/blog/category/sitestatus/> I was able to do an svn update successfully on the TEI repo and my own CodeSharing repo. Cheers, Martin

1 0

F2F in Lyon in Oct
by Syd Bauman 24 Jul '15

24 Jul '15

Hugh -- Do we have definitve dates for the F2F in Lyon in 2015-10 yet? James and I are supposed to be at a meeting in Germany on Thu 10-22, Fri 10-23, and maybe Sat 10-24. The pre-conference workshops will be Mon 10-26, Tue 10-27, and Wed morning 10-28; conference proper from Wed afternoon 10-28 through Sat 10-31.

3 2

ODD question
by Hugh Cayless 22 Jul '15

22 Jul '15

Hello all, Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.x… <https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.x…> wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is… Thanks, Hugh /** * Hugh A. Cayless, Ph.D * hugh.cayless(a)duke.edu * Duke Collaboratory for Classics Computing (DC3) * http://blogs.library.duke.edu/dcthree/ **/

9 36

bug report: @rend vs @rendition
by Syd Bauman 21 Jul '15

21 Jul '15

Sourceforge is currently down, so I'm posting this here in lieu of a bug report. Will transfer it to a ticket assigned to me later. --------- The remarks associated with att.global.rendition say Where both @rendition and @rend are supplied, the latter is understood to override or complement the former. This seems correct to me. The prose of section 1.3.1.1.3 "Rendition Indicators" says In the TEI scheme, it is possible to supply information about the appearance of elements within a source document in the following distinct ways: 1. One or more properties may be specified as the default for all elements of a given type, using the @render attribute to point to rendition elements ; 2. One or more properties may be specified for individual element occurrences, using the @rend attribute with any convenient set of one or more sequence-indeterminate tokens; 3. One or more properties may be specified for individual element occurrences, using the @rendition attribute to point to rendition elements; 4. One or more properties may be supplied explicitly for individual element occurrences, using the @style attribute. If the same property is specified in more than one of the above ways, the one with the highest number in the list above is understood to be applicable. At the very least, 2 & 3 should be reversed, and use of the @selector of <rendition> needs to be added to the list. But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash. And why does @style override @rend? I think I'd prefer the reverse (but I'm not sure). Typo: extra space before semicolon in <item> #1.

4 9

question on <xenoData>
by Syd Bauman 14 Jul '15

14 Jul '15

First, <xenoData> should be a member of att.declarable. I think that's pretty much a no-brainer, but raise it here in case someone wants to object. But my next issue is at least non-obvious, if not controversial (and I hope it's not). How is a process to know whether the metadata supplied in <xenoData> applies to the TEI document or to the source thereof? Several possibilities jump to mind. 1) It doesn't. This is not our problem. Any project using <xenoData> will know what metadata they are using, so they'll figure it out just fine. 2) We add a new attribute to <xenoData>, @describes. Its possible values are "source" and "transcription" or some such. 3) We use a special @type (with values "source" and "transcription" or some such) for this, even though it's not quite right. 4) We add <xenoData> to att.typed and let projects come up with their own values of @type to assert this information. Maybe with suggested values (4a), maybe not (4b). 5) Instead of making <xenoData> a member of model.teiHeaderPart, and thus a younger sibling of <fileDesc>, we allow <xenoData> to occur as a child of <fileDesc> or as a child of <sourceDesc> (via membership in model.sourceDescPart). In the former case the metadata in <xenoData> is understood to apply to the TEI document; in the latter case the metadata in <xenoData> is understood to apply to the source from which the TEI document was derived. 6) Like (5), but leave <xenoData> as a member of model.teiHeaderPart instead of (6a) or in addition to (6b) a direct child of <fileDesc>. Personally, I'm leaning very strongly towards (2), (5), or (6a). That is, I think (1), (3), (4a), and (4b) are bad ideas, and prefer (6a) to (6b). That said, I'm open to thoughts, ideas, and suggestions.

8 36

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 08 Jul '15

08 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 27 Jun '15

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

27 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