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

[GitHub] Your password has changed
by GitHub 24 Aug '15

24 Aug '15

Hello TEITechnicalCouncil, We wanted to let you know that your GitHub password was changed. If you did not perform this action, you can recover access by entering james+teitechnicalcouncil(a)blushingbunny.net into the form at https://github.com/password_reset. To see this and other security events for your account, visit https://github.com/settings/security. If you run into problems, please contact support by visiting https://github.com/contact or replying to this email.

1 0

[GitHub] Please reset your password
by GitHub 24 Aug '15

24 Aug '15

We heard that you lost your GitHub password. Sorry about that! But don’t worry! You can use the following link within the next day to reset your password: https://github.com/password_reset/00d3e5078f85464a1ac91e3975609ef5c77315e27… If you don’t use this link within 24 hours, it will expire. To get a new password reset link, visit https://github.com/password_reset Thanks, Your friends at GitHub

1 0

Re: [tei-council] [TEI-L] <relation> w/in <placeList>
by Syd Bauman 21 Aug '15

21 Aug '15

Re: discussion Gabby & Martin are having on TEI-L I think this is evidence in support for a linked data block element that is a child of <text> but not in <front>, <body>, or <back> that is specifically for this kind of stuff (<relation>s).

1 0

[GitHub] Please verify your email address.
by GitHub 21 Aug '15

21 Aug '15

Hey, we want to verify that you are indeed "TEITechnicalCouncil". Verifying this address (tei-council(a)lists.tei-c.org) will let you receive notifications and password resets from GitHub. If you wish to continue, please follow the link below: https://github.com/users/TEITechnicalCouncil/emails/16451158/confirm_verifi… If you’re not TEITechnicalCouncil or didn’t request verification, you can ignore this email.

4 4

Validating Specs
by James Cummings 21 Aug '15

21 Aug '15

Hiya, I'm starting to look at creating individual spec files for the processing model documentation additions to the Guidelines and when I loaded up some random spec files (e.g. in SF svn: P5/Source/Specs/affiliation.xml) to use as a model I notice it didn't validate. We added an xml-model of: <?xml-model href="http://tei.it.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/relea…" type="application/xml" schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?> to these some time back. (And part of me wants to point out that maybe this should be http://bits.nsms.ox.ac.uk:8080/ or we should set up jenkins really to run on tei.it rather than use some URL rewrites...) However, the error message I'm getting in oXygen is: "Attribute @xsl:dummy-for-xmlns is not allowed on element <xsl:stylesheet>" I can't find where this is being caused. It doesn't seem to be in our p5odds.rng or p5odds.isosch files. Any suggestions? -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

2 2

SVN Users
by Hugh Cayless 20 Aug '15

20 Aug '15

Looks like we can achieve a happier SVN to Git conversion if we supply Git with a mapping between SourceForge usernames and proper names + email addresses in the form hcayless = Hugh Cayless <philomousos(a)gmail.com> I’ve started a spreadsheet with usernames who’ve committed to our repo at https://docs.google.com/spreadsheets/d/1N8hIBphezGsNB0SvEx7wSamyshNrszeNrlm… <https://docs.google.com/spreadsheets/d/1N8hIBphezGsNB0SvEx7wSamyshNrszeNrlm…> Can you all please pitch in to help fill it out? Thanks, Hugh

5 19

Fwd: Re: editing the TEI stylesheets
by James Cummings 19 Aug '15

19 Aug '15

Forwarding this reminder to tei-council to remind them that they need to keep a watching eye on such pull requests. (Once set up, we should get notifications sent to tei-council if possible) -James -------- Forwarded Message -------- Subject: Re: editing the TEI stylesheets Date: Wed, 19 Aug 2015 09:43:31 +1200 From: Stuart A. Yeates <syeates(a)gmail.com> To: James.Cummings(a)it.ox.ac.uk <James.Cummings(a)it.ox.ac.uk> CC: Sebastian Rahtz <sebastian.rahtz(a)it.ox.ac.uk> OK, so I sent a pull request almost a week ago https://github.com/TEIC/Stylesheets/pull/114 Do I need to notify someone? Or has feedback gone somewhere I'm missing... cheers stuart -- ...let us be heard from red core to black sky On Wed, Aug 12, 2015 at 10:01 PM, James Cummings <James.Cummings(a)it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>> wrote: Hi Stuart, The TEI Technical Council is currently reviewing how it uses GitHub as part of examining whether it is a suitable replacement for SourceForge in moving Guidelines development there. As you know, it moved the Stylesheets (and other software) building there some time ago. Although you (and various others) are members of the Stylesheets repository I believe the correct github etiquette is to fork, then issue a pull request. However, I think as long as you are flagging that you are making the change (or open an issue and then make the change as a result of that) it should probably be fine. (Though when you say 'regularise the display of attribute values' I'd be interested to know what you mean by regularise. There are some options and logic already in there.) The change in your forked version won't get looked at by Jenkins. We're also looking at whether some of the GitHub hosted alternative continuous integration systems might replace Jenkins. So, to be honest, you could do either, but fork+change+pull-request will ensure that it gets other eyes on it before going into the system. Jenkins uses the most up-to-date stylesheets when next building the Guidelines. I know it used to email when doing commits to the Guidelines SF SVN repository that broke something (or more accurately when someone committing around the same time as you broke something ;-) ) and I'm assuming that is still the case. I don't think it emailed just when it was running a job based on your commits...just when that job failed and your commit was one of those possible causes. That is my understanding at least, some of our council github gurus may correct me. -James On 12/08/15 10:26, Stuart A. Yeates wrote: I've got a change I'd like to make to the stylesheets used to generate the HTML version of the standard (a minor change to regularise the display of attribute values), but I'm not quite sure how to go about it. Do I just push a change request to https://github.com/TEIC/Stylesheets ? Or fork it? Does that get tested by jenkins? Jenkins used to send me emails when it ran a job based on my commits, but I've not seen one for a couple of recent commits, is that because I'm not on the council any more? cheers stuart -- ...let us be heard from red core to black sky -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> Academic IT Services, University of Oxford -- Dr James Cummings, Academic IT Services, University of Oxford TEI Consultations: tei(a)it.ox.ac.uk

4 12

Validation errors in the Guidelines HTML output
by Martin Holmes 14 Aug '15

14 Aug '15

Hi all, I just discovered the VNU HTML validator, and I'm using it on another project; just for fun I ran it on a clean Guidelines build, and there seem to be about 150 errors, mostly minor and easily fixable. But it caused me to wonder why our build process didn't catch them, and I'm going to look into that. Validating modern HTML is notoriously difficult, but we should do the best we can, I think. Cheers, Martin

2 2

langUsage content model
by Lou Burnard 10 Aug '15

10 Aug '15

The process of TEI content models proceeds apace and (as might be expected) is turning up a few oddities in some unfrequented corners. For example, the content model of <langUsage> is currently (in the source) <content> <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <choice>  <ref name="language"/> </choice> </oneOrMore> </content> Now, this is clearly nonsense : you can't have an alternation with just one option. But did we really want to remove the possibility for having a purely documentary <langUsage> such as <p>Contains various unrecognised Polynesian languages</p>? Can anyone remember why we made this change ? I would have expected to see something like <choice> <oneOrMore> <rng:ref name="model.pLike"/> </oneOrMore> <oneOrMore> <rng:ref name="language"/> </oneOrMore> myself.

4 5

pure odd update
by Lou Burnard 10 Aug '15

10 Aug '15

I've now managed to get the P5-Pure branch of the P5 source up to date with the rest of the world, and have successfully run the P5 test suite (almost) to completion. *It would be very helpful if someone else could check this branch out and confirm that it works for them too!* The main difference is that all datatypes are now expressed using the new dataSpec and dataRef elements we discussed approx 3 million years ago. This in turn means that the old data.foo macroSpecs are now redundant, (we now use dataSpecs called teidata.foo). I have however left the old macroSpecs in the build, since their absence obviously causes existing ODDs that reference them to fall over. It's a pain however, and I would really like to get data.foo deprecated as soon as possible. Only a few (like 2 ore 3) of our test ODDs actually refer to them, but I've no way of telling how many ODDs out there in the wild do, nor how upsetting their maintainers would find it to be told to turn <rng:ref name="data.foo"/> into <dataRef key="teidata.foo"/> passim et seriatim (If you're wondering, the "(almost)" above means that my poor little laptop gave up trying to compile the massive tei_allPlus.odd.processed into tei_allPlus.rng ... probably the heat.)

4 35

more daft alternates
by Lou Burnard 10 Aug '15

10 Aug '15

Something similar occurs in <fvLib> which currently has a model <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <choice> <ref name="model.featureVal"/> </choice> </zeroOrMore> and in <classes> which currently is <choice xmlns="http://relaxng.org/ns/structure/1.0"> <zeroOrMore> <ref name="memberOf"/> </zeroOrMore> </choice> I'm regarding both of these as corrigible errors in the main P5 source and correcting them. But would appreciate feedback on the <langUsage> case.

1 0

default vals and mandatory attributes
by Lou Burnard 07 Aug '15

07 Aug '15

Just for a change, here's a technical query. The TEI Enrich ODD (part of the Exemplars suite) is riddled with things like this: <attList> <attDef ident="columns" mode="change" usage="req"> <defaultVal>1</defaultVal> </attDef> </attList> which are now generating error messages from Schematron like this E [ISO Schematron] It does not make sense to make "1" the default value of @columns, because that attribute is required. Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?

3 8

Council's Future
by Hugh Cayless 06 Aug '15

06 Aug '15

As I hinted a couple of emails ago, I'd like to think about new models for how Council might work, with the following things in mind: 1. There is a push underway to improve the gender balance of the Council membership, which I'm fully in favor of, but which means we have a largish list of nominees and therefore the potential for a largish influx of new members in January, and possibly again the following year. My sense is that we could still be better at on-boarding new members. 2. I feel like having Council be purely an elected body carries with it both risks and rewards. The reward is clearly the periodic influx of new ideas and perspectives. The risk is that we lose expertise and continuity when Council members rotate off—and sometimes they rotate off for reasons like they forgot to submit a statement, or didn't read their email. We don't do a very good job of continuing to involve interested contributors after they've left. We say that new members don't have to be super-technical, and that's true, but there *are* wizard-level technical and conceptual components to the TEI and we need to have people who can manage them. As an aside, I'd like to see a push for making it *much* easier to do things like build the Guidelines, but I think we have enough on our plate at the moment. So what could we do to mitigate the risks and amplify the rewards? I've mentioned in the past that I'd like to see, besides the elected body of Council members, a group of committers who serve in much the same way as Council members but are there because they've been appointed and are willing to contribute. Committers might be subscribed to the Council mailing list, participate (as available) on teleconferences, and come to F2F meetings (perhaps subject to budgeting). They would be identified as Committers by the TEI—i.e. they would be listed on the website and could put it on their CVs. There's some precedent for this, of course: we've drafted Lou in the past when he wasn't technically on Council. My point is that, while former Council members don't lose their commit privileges now, they do get removed from the Council list, and are not included in meetings anymore, nor are they recognized in any way, so they lose the incentive to continue to contribute, with the result that they stop. That's not to say that people can't just serve their time on Council and then move on to other things, but that valuable, interested contributors should have a means to continue their work and should be recognized for doing so. Does this sound in any way sensible? What should be the benefits of being a Committer? How would they be appointed? What role(s) would they play? Should they be former Council members, or could we draft anyone (provided they have the ability and desire to contribute of course)? What do you all think? Obviously this would involve some rule changes and I assume we'd have to involve the Board, etc...

7 27

I've just test-migrated my CodeSharing project from SF to GH
by Martin Holmes 05 Aug '15

05 Aug '15

Hi all, especially Raff, our migration manager. I just migrated my project from SF to GitHub in the following steps: === 1. PREPARATION === Do a freeze (not a problem for my tiny project). Make sure you have complete backups and checkouts. Prepare a JSON file called users_sf2gh.json which consists of the equivalent user names from SF and GitHub, like this: { "martindholmes" : "martindholmes", "stadlerpeter" : "peterstadler" } (Obviously this needs a bit of research.) === 2. GETTING TICKETS ETC. OUT OF SF ========================== Do a full export of the SF project from here: https://sourceforge.net/p/[proj]/admin/export This is not instant; you'll get an email when it's complete and you can download it as a zip. That produced these files for me: admin.json discussion.json tickets.json wiki.json It doesn't include the code, of course. === MOVING CODE TO GITHUB ===================================== Go here: https://import.github.com/new/ and follow the instructions to import your code. This was quick for my tiny project, but would take a long time for the TEI codebase. The commit history is preserved correctly, as far as I can see. I provided the https URL for the SF repo: https://svn.code.sf.net/p/[proj] While that's going on, or after it's finished, you're offered the option to provide the list of SF/GitHub user equivalences you've already specified in the JSON file, through a web form (you'll use the JSON file itself later, when importing tickets). === MOVING TICKETS TO GITHUB ================================= I used this PERL script for this: https://github.com/cmungall/gosf2github Beware: there is a typo (occurring in two places) which omits a quotation mark in the example; I've added a patch and sent a pull request to fix it. There are several stages to this: 1. Set up an OAUTH token for the Git repo here: https://github.com/settings/tokens 2. Get a list of the project collaborators in JSON format from github like this: curl -H "Authorization: token YOURTOKEN" https://api.github.com/repos/[entity]/[project]/collaborators > [project]-collab.json 3. Run the PERL script, which pulls down each ticket from SF and pushes it up to GitHub -- this is my command line: perl gosf2github.pl -a martindholmes -u users_sf2gh.json -c codesharing-collab.json -r martindholmes/CodeSharing -s codesharing/tickets -t [MYTOKEN] tickets.json You can run it with the -k flag first to do a dry-run and see the curl statements that would be addressed to github without sending them. This successfully imported the two tickets I had created as a test, one open and one closed, with embedded XML code successfully preserved. Hope this helps. It's nice to be on vacation. There's time to actually do stuff. :-) Cheers, Martin

4 7

Test GLs repo on GitHub
by Hugh Cayless 03 Aug '15

03 Aug '15

All, I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like. Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard. Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future. GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.

5 19

Why are we using a pantor.com namespace?
by Martin Holmes 31 Jul '15

31 Jul '15

In Utilities/guidelines.xsl.model, I see this: xmlns:pantor="http://www.pantor.com/ns/local" and something similar in the following files: Query/simplify.xsl Utilities-1/colorsvg.xsl Utilities-1/divsplit.xsl Utilities-1/generate-label.xsl Utilities-1/guidelines-latex.xsl Utilities-1/guidelines-print.xsl Utilities~1/guidelines.xsl.model Utilities~1/odd2ebnf.xsl Utilities~1/odd2exodd.xsl Utilities~1/rng2ebnf.xsl Utilities~1/split.xsl Utilities/guidelines-print.xsl Sometimes it maps to the prefix "pantor" and sometimes to the prefix "local". pantor.com seems to be some kind of electronic stock trading platform: <http://www.pantor.com/> The Stylesheets repo contains a file called RngToRnc.xsl, which is an ancient stylesheet apparently dating back to 2002, last edited by Syd in 2010. But this does not appear to use the pantor: or local: prefixes, and neither prefix seems to be actually used anywhere. Does anyone have any recollection of what was going on here? If we're not using this namespace, it would be good to get rid of it, especially since it's usually rather confusingly mapped to the prefix "local". Cheers, Martin

2 3

svn:keywords
by Peter Stadler 29 Jul '15

29 Jul '15

It just occurred to me that GitHub won’t support svn:keywords such as $Date$ or $Rev$. Humans will probably adjust themselves but I don’t know whether any software piece in our (some) processing pipeline relies on this information? Best Peter

5 5

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

28 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 20 Jul '15

20 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