> >However, I haven't yet uploaded any TEI packages as I'm still > >waiting for them to settle some outstanding licensing issues... > Oh oh ?
Sorry. This one's on my plate. I'm making slooow progress. I'd like to say I'll get a lot done on this issue this weekend, but in fact my wife just reminded me I have to do our taxes this weekend. Sigh. > > [SYSTEM identifier stuff] > There seem to be a few different options .. Only four I'd recommend, two each in each of the categories "local" and "remote": R1) http://www.tei-c.org/Guidelines/DTD/tei2.dtd R2) http://www.tei-c.org/P4X/DTD/tei2.dtd LA) /usr/share/xml/tei/p4/schema/dtd/tei2.dtd LR) [correct relative path to LA] Local vs. remote: While R2 has the advantage of being the canonical location, there are some potential disadvantages: * not useful when you're off the net * annoying when your net connection is slow * if & when we make updates to P4 (not common, but it does and will happen), the DTD you get is suddenly slightly different, and you may not know why * if & when someone re-arranges the TEI website (very likely to happen) such that this link no longer works (very unlikely to happen), you're screwed. R1 currently just resolves to R2. As it has no version information at all, it is a better way to refer to the DTD in the generic sense (i.e., in an article discussing large DTD projects), but a bad way to refer to it in any given DOCTYPE declaration. Note though that R1 only gives a major release version. Updates do occur (and will soon, actually) without changing the "P4X" name. Absolute v. local: Obviously in many cases a relative path would be indeterminable or silly. However, it could improve portability for those of us forced to use systems where we can't write to /usr/. (Not my Debian system, the solaris system I use at work.) Thus, if something is being created as a Debian package based on a particular view of a particular version of the TEI DTD, I'm inclined to say that LA is the best choice. You (the package creator) can make sure that your toys work with that particular DTD just fine. > [http://www.tei-c.org/P4X/DTD/tei2.dtd] seems rational to me as it > clearly places it in a namespace and scopes the version as well. Not a namespace in the XML sense of the word, of course. On catalogs -- Mark, I apologize for not having read the draft XML policy yet, but perhaps you can quickly clarify. If someone wants to create a Debian package that is TEI-based and thus depends on the TEI P4 package, and wants a bunch of FPIs in a catalog, is the package installation expected to alter /etc/xml/tei-p4.xml? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
