[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TEI -biting the bullet



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



Reply to: