From bogus@does.not.exist.com Tue Sep 18 09:59:42 2007 From: bogus@does.not.exist.com () Date: Tue, 18 Sep 2007 13:59:42 -0000 Subject: No subject Message-ID: call, there were no objections to meet on Sep 23rd, 1300 UTC, so I would like to set this time for the conference. Perry, could I ask you to set this up and inform us of the procedure? Collection of the agenda items will start now. The agenda will also include the usual reports from WG; we also need to discuss the report from our work that we will present to the members meeting in Nancy. All the best, Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From bogus@does.not.exist.com Tue Sep 18 09:59:42 2007 From: bogus@does.not.exist.com () Date: Tue, 18 Sep 2007 13:59:42 -0000 Subject: No subject Message-ID: Council meeting next year, I got the impression that there were no strong objections against a meeting in May in Gent, but for many a meeting adjacent to ALLC/ACH would be considerably more difficult to arrange. Taking this in account and realizing that some of us will have to make the trip to Europe thus twice within a month, I would like to propose the meeting for may 13-15, on the Thursday to Saturday pattern we had last year. This means that we start after Lunch on Thursday, so members attending from Europe could come in same day, if they wish. We will then meet the whole Friday and reserve Saturday for possible extension, bringing us to a total of 1 1/2 to 2 meeting days. The decision has not been easy (and I was wondering if there are better ways to arrive at such a decision), but I hope everybody will be able to adjust her plans and will be able to join us in Gent.

With this I would like to wish everybody a nice holiday season, whatever holiday the country you live in might schedule at this time of the year. In Japan, this happens to be the New Year holiday where once a year the whole country seems to close down for business and become busy visiting Temples and Shrines, Friends and Relatives and feasting in many other ways.

All the best, Christian Wittern

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Fri Jan 5 21:24:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 5 Jan 2007 21:24:04 -0500 (EST) Subject: [tei-council] Comments on the conformance document In-Reply-To: <0F41634B-9414-489A-94C0-5FFD058B01A9@loria.fr> Message-ID: <200701060224.l062O4kR012397@draco.services.brown.edu>

From: Syd Bauman
Date: Fri, 5 Jan 2007 21:24:04 -0500 (EST)
[Council -- my apologies. I wrote this back in late September, but for
some reason it never got posted. The recent discussion on TEI-L had me
look for it, and finding that it never got posted here it is ... I'm
not sure there is much, if anything, new here.]

LB> The TEI's claim is that has sufficient generality and coverage in
LB> its semantics that it can be customized to meet most needs
LB> without too much effort. ... we need to have a metric to assess
LB> the interchangeability ... of the resulting documents. That's
LB> what conformance is.
While it may be a very good idea for us to have a metric to assess
interchangeability, I don't think it's a requirement. After all, P3
and P4 did not have such a metric, or at least not at the same level
of nuance. Nonetheless, I agree that it's a good idea to discuss such
a metric in the Guidelines. But I think (*very* strongly) that the
metric of ease of interchange should not be confused with a
definition of conformance. After all, I can (and should be able to)
create TEI documents that are 100% conformant, but because they rely
on my own taxonomy of type=, my own method for indicating rhyme=, my
own method for indicating rend=, etc., are not easily plopped into
your system. On the other hand, I can create a document that has an
added element which your system could accommodate with only the
smallest of tweaks.
That is, all of the degrees of interchangeability discussed at
http://www.tei-c.org.uk/wiki/index.php/Conformance describe conformant
documents (correction: #5 does not describe a TEI document at all,
and I do not think it should be on the list).
I think that we should focus this discussion on the degrees of
interchangeability, and stop mis-using the term "conformance".
Conformance is a separate (although related) issue about making what
you've done with respect to the Guidelines explicit in a specified,
predictable, way.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 05 2007 - 21:24:08 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 6 10:39:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 06 Jan 2007 15:39:58 +0000 Subject: [tei-council] numbered divs, a proposed solution Message-ID: <459FC2CE.5080805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 06 Jan 2007 15:39:58 +0000
You can hardly have failed to notice the argument on TEI-L
which revolved around Ron vd B's innocuous expectation
that if he deleted mumbered divs in his ODD, he would
get a valid DTD.
I know one should not solve a general problem by dealing
with a special case case, but I also think that there is a time for
compromise and practicality, so I have a firm proposal which
I'd like you to consider. I claim it will solve this problem
at a relatively small cost, compared to the public
embarassment this will keep on causing.
The idea is that we much simplify the content model of ,
and to allow _either_ paragraph-like
objects (macro.component) _or_
div-like objects (as well as the existing top and bottom elements).
The "div-like" would be expressed as a new
class model.divLike, and its membership would be
div, div0, div1 and divGen.
Good things:
1. so long as at least one member of the class exists, any other can
be safely deleted
2. you can create new objects easily which will be allowed inside
Bad things:
1. you can interleave div, div1 and div0 ad lib.
2. if model.divLike is entirely empty, it fails at present cos of
globals being ambiguous
Strange things:
1. you can interleave div and divGen ad lib. that strikes me as
moderately desirable.

To deal with the first bad thing, I have added a Schematron test
which detects silly combinations. The second requires
some more jiggery-pokery; I think it's solvable with a lot
of patience.
My proposal for the content model of is below. The fully-worked
example is in P5/Test/testfand.odd in Subversion.
Views? I have not tried integrating this into the main TEI and running
all tests, but I have a tei_all with these changes and done
some obvious tests which threw up no funnies.
I take it as axiomatic that we cannot simply leave the
current setup as it is. We must do _something_ to allow
the simple case of "delete numbered divs" to work.















































name="pattern.body">


You cannot mix numbered divs with unnumbered divs in body


You cannot mix div0 with div1 at the same level in body




-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 06 2007 - 10:40:22 EST

From James.Cummings at oucs.ox.ac.uk Mon Jan 8 05:30:39 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 08 Jan 2007 10:30:39 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <459FC2CE.5080805@oucs.ox.ac.uk> Message-ID: <45A21D4F.8020004@oucs.ox.ac.uk>
From: James Cummings
Date: Mon, 08 Jan 2007 10:30:39 +0000
Sebastian Rahtz wrote:
> You can hardly have failed to notice the argument on TEI-L
> which revolved around Ron vd B's innocuous expectation
> that if he deleted mumbered divs in his ODD, he would
> get a valid DTD.
I agree that this is an innocuous expectation and that he should be able to
delete numbered divs. When we discussed and decided to drop support for SGML
(around 2006-09-14) it was mentioned that the support for DTDs was also
difficult. I'm assuming this is an example of that. Does this problem exist in
the generated schemas, or only the DTDs?
> I know one should not solve a general problem by dealing
> with a special case case, but I also think that there is a time for
> compromise and practicality, so I have a firm proposal which
> I'd like you to consider. I claim it will solve this problem
> at a relatively small cost, compared to the public
> embarassment this will keep on causing.
I agree that the problem needs to be solved one way or another.
> The "div-like" would be expressed as a new
> class model.divLike, and its membership would be
> div, div0, div1 and divGen.
I suppose we couldn't re-open the issue of whether we should just get rid of the
option of div0|div1 and just pick one or the other?
> Bad things:
> 1. you can interleave div, div1 and div0 ad lib.
> 2. if model.divLike is entirely empty, it fails at present cos of
> globals being ambiguous
These are both quite bad in my mind. 1) The whole point of divs vs numbered divs
is that they are mutually exclusive isn't it? I mean I'm not supposed to be
able to use both in the same document?
> To deal with the first bad thing, I have added a Schematron test
> which detects silly combinations. The second requires
> some more jiggery-pokery; I think it's solvable with a lot
> of patience.
So, is the real issue behind this whether we want to rely on Schematron for
these tests? And to do so for a special case solution? Does adopting Schematron
for this have any negative implications?
> I take it as axiomatic that we cannot simply leave the
> current setup as it is. We must do _something_ to allow
> the simple case of "delete numbered divs" to work.
I agree that something must be done. Does any one have any suggested alternatives?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 05:30:52 EST
From Syd_Bauman at Brown.edu Mon Jan 8 12:48:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 8 Jan 2007 12:48:10 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A21D4F.8020004@oucs.ox.ac.uk> Message-ID: <17826.33754.484151.883531@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 8 Jan 2007 12:48:10 -0500
I may not get to give this issue full attention for a little while,
but some brief thoughts follow.

> > You can hardly have failed to notice the argument on TEI-L
> > which revolved around Ron vd B's innocuous expectation
> > that if he deleted mumbered divs in his ODD, he would
> > get a valid DTD.
>
> I agree that this is an innocuous expectation and that he should be
> able to delete numbered divs.
I agree, too, although as I think I've said before, this could be
documented around, rather than really solved.

> When we discussed and decided to drop support for SGML (around
> 2006-09-14) it was mentioned that the support for DTDs was also
> difficult. I'm assuming this is an example of that. Does this
> problem exist in the generated schemas, or only the DTDs?
Exactly correct. The problem exists in DTDs and probably in W3C
Schemata, although I don't know that anyone has tested the latter.
The problem does *not* exist in Relax NG.

> > I know one should not solve a general problem by dealing with a
> > special case case, but I also think that there is a time for
> > compromise and practicality, so I have a firm proposal which I'd
> > like you to consider. I claim it will solve this problem at a
> > relatively small cost, compared to the public embarassment this
> > will keep on causing.
>
> I agree that the problem needs to be solved one way or another.
I have not looked at Sebastian's proposal here closely enough to give
a real opinion on it, so I am *not* saying here that I prefer the
brute-force or hack methods better. But I am curious: does the above
statement mean that you have looked at the FAND ODDs I posted on the
wiki and don't think they are viable solutions?[1]

> > The "div-like" would be expressed as a new class model.divLike,
> > and its membership would be div, div0, div1 and divGen.
>
> I suppose we couldn't re-open the issue of whether we should just
> get rid of the option of div0|div1 and just pick one or the other?
We can, and perhaps should, but it doesn't make any significant
difference. I.e., the non-deterministic content model problem will
exist whenever all numbered divs are deleted in your ODD, whether
div0 is among them or not.

> These are both quite bad in my mind. 1) The whole point of divs vs
> numbered divs is that they are mutually exclusive isn't it? I mean
> I'm not supposed to be able to use both in the same document?
Not within the same , , or .

> So, is the real issue behind this whether we want to rely on
> Schematron for these tests? And to do so for a special case
> solution? Does adopting Schematron for this have any negative
> implications?
These are exactly the important questions to address up front, I
think.

> > I take it as axiomatic that we cannot simply leave the current
> > setup as it is. We must do _something_ to allow the simple case
> > of "delete numbered divs" to work.
>
> I agree that something must be done. Does any one have any
> suggested alternatives?
While I may be convinced that something must be done, I am not
convinced yet.

Notes
-----
[1] http://www.tei-c.org/wiki/index.php/FAND1_hack and
http://www.tei-c.org/wiki/index.php/FAND2_replace
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 08 2007 - 12:48:14 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 15:56:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 20:56:54 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <17826.33754.484151.883531@emt.wwp.brown.edu> Message-ID: <45A2B016.6070906@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 08 Jan 2007 20:56:54 +0000
Syd Bauman wrote:
>
> But I am curious: does the above
> statement mean that you have looked at the FAND ODDs I posted on the
> wiki and don't think they are viable solutions?[1]
>
the ingenious hack #1 only works for DTDs. I am considering implementing
this directly in odd2dtd, so that when you have an empty
class, a _DUMMY_ is inserted. But it puzzles me as
to _why_ it works, since the content model _is_ ambiguous.
And what about W3C schema.
hack #2 is too complex. sorry. such a simple task
has to be easier, in my book.
>
>> So, is the real issue behind this whether we want to rely on
>> Schematron for these tests? And to do so for a special case
>> solution? Does adopting Schematron for this have any negative
>> implications?
>>
>
> These are exactly the important questions to address up front, I
> think.
>
I am sure you and James have a nice view up there
sitting on the fence :-}
but I'd rather see a concrete expression of yes
or no for the principal question.....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 15:57:08 EST
From jawalsh at indiana.edu Mon Jan 8 16:13:12 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Mon, 8 Jan 2007 16:13:12 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> Message-ID:
From: John A. Walsh
Date: Mon, 8 Jan 2007 16:13:12 -0500
On Jan 8, 2007, at 3:56 PM, Sebastian Rahtz wrote:
>> So, is the real issue behind this whether we want to rely on
>> Schematron for these tests? And to do so for a special case
>> solution? Does adopting Schematron for this have any negative
>> implications?
I think the negative implication is that if we tell the TEI user
community that they need to use DTDs + Schematron (or W3C/RELAX NG +
Schematron) to validate their documents correctly, many of them will
run away screaming. Or they will run away silently because they
don't want to admit they don't know or care what Schematron is. And
they'll probably run back to the perceived warm comforting arms of P4
and plain old DTDs. I think the user community needs the choice
between DTD and W3C; some, including me, want the choice of RELAX NG
as well. They don't want a requirement to use Schematron, except for
their own content validation. I think it's important that we avoid a
need to use Schematron.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 16:13:26 EST
From djbpitt+tei at pitt.edu Mon Jan 8 16:13:04 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 08 Jan 2007 16:13:04 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: <45A2B3E0.3020503@pitt.edu>
From: David J Birnbaum
Date: Mon, 08 Jan 2007 16:13:04 -0500
Dear Sebastian (cc Council),
> I am sure you and James have a nice view up there
> sitting on the fence :-}
>
> but I'd rather see a concrete expression of yes
> or no for the principal question.....
Reluctant yes. The two "bad things" bother me and I'm not happy about
having to rely on Schematron, but those limitations pale in comparison
to living in a world where one cannot remove numbered divs, and I can't
think of a better solution.
Best,
David

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 08 2007 - 16:13:29 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 16:40:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 21:40:11 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: Message-ID: <45A2BA3B.1020801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 08 Jan 2007 21:40:11 +0000
John A. Walsh wrote:
>
> I think the user community needs the choice between DTD and W3C;
> some, including me, want the choice of RELAX NG as well. They don't
> want a requirement to use Schematron, except for their own content
> validation. I think it's important that we avoid a need to use
> Schematron.
>
Fair view. If that's what the majority think, back to the drawing board :-{
I'm trying some more tricks now.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 16:40:30 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 17:49:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 22:49:11 +0000 Subject: [tei-council] solving unnumbered divs (bis) Message-ID: <45A2CA67.6020900@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 08 Jan 2007 22:49:11 +0000
I have done some more work on this, and I am able to solve
one of the problems. I have implemented Syd's No1 Hack
in the ODD processing, whereby any model class which
has no members is replaced by "_DUMMY_". It shuts
up the XML processor nicely. So far so good,
it would let you entirely delete any kind of div.
Now, supposed we have *two* classes, one
for div and divGen, one for divGen, div1 and div0. Now
we can say that you can have one set or the other.
All well and good, we don't need the Schematron thing
any more.
Spotted the problem? yes, its . If its
in both classes, its ambiguous.
I could make _another_ class for divGen, I suppose.
Oh lordy lordy.
Anyone got a suggestion to get me out of this last hole?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 17:49:28 EST
From Syd_Bauman at Brown.edu Mon Jan 8 18:48:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 8 Jan 2007 18:48:35 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: <17826.55379.927889.377121@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 8 Jan 2007 18:48:35 -0500
> > But I am curious: does the above statement mean that you have
> > looked at the FAND ODDs I posted on the wiki and don't think they
> > are viable solutions?[1]
> >
> the ingenious hack #1 only works for DTDs.
Why do you say that? Both the .rng and .rnc files I get from roma are
valid, and seem to work exactly as expected (i.e., as the DTD does).

> I am considering implementing this directly in odd2dtd, so that
> when you have an empty class, a _DUMMY_ is inserted.
Seems like a route we may want to follow.

> But it puzzles me as to _why_ it works, since the content model
> _is_ ambiguous.
Again, what makes you say that? The content model for , e.g.,
certainly looks deterministic to me.[1] Xerces J, xmllint, and
onsgmls all say the DTD is fine.

> And what about W3C schema.
I don't know, and haven't tested, although it seems unlikely that
what is deterministic in its Relax NG source would be converted into
something non-deterministic by trang.

> hack #2 is too complex. sorry. such a simple task has to be easier,
> in my book.
Allow me to play devil's advocate. First, I will argue that it's not
an at all difficult task. To remove numbered divs go to the sample
ODD, find the part that says "copy-and-paste this section", copy it,
paste it into your ODD, and you're done. Heck, there could even be a
little check-box on the Roma web interface that caused this
oh-so-common request to happen for you.
But more to the point, when did it become the TEI's goal to protect
users from schema code? While certainly not as nice as a class-system
change, this change is still easier than it was in P4.

Notes
-----
[1] It is as follows:
(
( %model.divWrapper; | %model.global; )*,
(
(
( %macro.component;, %model.global;*)+,
(
( divGen, %model.global;* )*,
(
( div, ( div | divGen | %model.global; )* )
|
( DO_NOT_USE_THIS, ( DO_NOT_USE_THIS | divGen | %model.global; )* )
|
( DO_NOT_USE_ME, ( DO_NOT_USE_ME | divGen | %model.global; )* )
)?
)
)
|
(
( divGen, %model.global;* )*,
(
( div, ( div | divGen | %model.global; )* )
|
( DO_NOT_USE_THIS, ( DO_NOT_USE_THIS | divGen | %model.global; )* )
|
( DO_NOT_USE_ME, ( DO_NOT_USE_ME | divGen | %model.global; )* )
)
)
),
%model.divWrapper.bottom;*
)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 08 2007 - 18:48:41 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:03:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:03:24 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2CA67.6020900@oucs.ox.ac.uk> Message-ID: <45A2DBCC.6040002@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 09 Jan 2007 00:03:24 +0000
I am glad to say that the question of W3C schema allowing
non-deterministic content
models appears to be a non-issue. My test XSD file seems to have come
through
with no problem.
So I now have an ODD which can delete any or all of div0, div1, div and
divGen,
and the RELAXNG, DTD and XSD schemas all work as expected. div0|div1 and
div cannot co-exist.
The price I have had to pay is inventing *3* new classes,
model.divLike, model.ndivLike, and model.divGenLike.
It's a hideous price to pay, but it works.
So, if you don't mind those 3 new classes,
and you don't find it strange have a DTD like this:
_DUMMY_model.divGenLike))*,(((%macro.component;),(%model.global; |
_DUMMY_model.divGenLike)*)+ | (_DUMMY_model.divLike,(%model.global; |
_DUMMY_model.divGenLike)*)+ | ((%model.ndivLike;),(%model.global; |
_DUMMY_model.divGenLike)*)+),(%model.divWrapper.bottom;)*)>
then I claim victory, pending a full test.
Here is the final content model:


































































-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 19:03:29 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:09:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:09:13 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <17826.55379.927889.377121@emt.wwp.brown.edu> Message-ID: <45A2DD29.8050008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 09 Jan 2007 00:09:13 +0000
Syd Bauman wrote:
>> the ingenious hack #1 only works for DTDs.
>>
>
> Why do you say that? Both the .rng and .rnc files I get from roma are
> valid, and seem to work exactly as expected (i.e., as the DTD does).
>
yes, sorry, I lied. The dummies are not needed in the
other languages, of course.
>
>> But it puzzles me as to _why_ it works, since the content model
>> _is_ ambiguous.
>>
>
> Again, what makes you say that? The content model for , e.g.,
> certainly looks deterministic to me.[1] Xerces J, xmllint, and
> onsgmls all say the DTD is fine.
>
yes, its technically OK. but if you have
(DUMMY | foo), (DUMMY2 | foo)
and you meet just a "foo", where does it come from?
>
> Allow me to play devil's advocate. First, I will argue that it's not
> an at all difficult task. To remove numbered divs go to the sample
> ODD, find the part that says "copy-and-paste this section", copy it,
> paste it into your ODD, and you're done. Heck, there could even be a
> little check-box on the Roma web interface that caused this
> oh-so-common request to happen for you.
>
I wish I could go along with saying that's acceptable, but I just
can't.....
> But more to the point, when did it become the TEI's goal to protect
> users from schema code?
speaking for myself, since the dawn of creation. its axiomatic
in my book. I realize we have different books :-}

Anyway, having divLike classes adds the enormous advantage that
you can now easily add your own new object to be a child of .
Don't tell me *that* was easy before!
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 19:09:26 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:11:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:11:58 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2DD29.8050008@oucs.ox.ac.uk> Message-ID: <45A2DDCE.2040102@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 09 Jan 2007 00:11:58 +0000
I should also note that the technique of using DUMMY_model.***** to
replace any
empty class model.***** may well solve a slew of other nasty problems
which are simply less common than the unnumbered div thing.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 19:12:06 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 8 20:50:10 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Tue, 09 Jan 2007 10:50:10 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2DBCC.6040002@oucs.ox.ac.uk> Message-ID: <45A2F4D2.3010702@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Tue, 09 Jan 2007 10:50:10 +0900
Sebastian Rahtz wrote:
> The price I have had to pay is inventing *3* new classes,
> model.divLike, model.ndivLike, and model.divGenLike.
> It's a hideous price to pay, but it works.
It does not seem too high to me, though. Remember the class meeting,
where we invented classes by the dozens before lunch?
But seriously, I think this is the solution we have been hoping for, no
schematron, no unpleasant ODD massaging.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 08 2007 - 20:50:46 EST

From James.Cummings at oucs.ox.ac.uk Tue Jan 9 07:23:54 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Jan 2007 12:23:54 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2DBCC.6040002@oucs.ox.ac.uk> Message-ID: <45A3895A.8060709@oucs.ox.ac.uk>
From: James Cummings
Date: Tue, 09 Jan 2007 12:23:54 +0000
Sebastian Rahtz wrote:
> So I now have an ODD which can delete any or all of div0, div1, div and
> divGen,
> and the RELAXNG, DTD and XSD schemas all work as expected. div0|div1 and
> div cannot co-exist.
>
> The price I have had to pay is inventing *3* new classes,
> model.divLike, model.ndivLike, and model.divGenLike.
> It's a hideous price to pay, but it works.
I think that Sebastian's solution is good and elegant. The only problem it
causes is in fact a great opportunity. Currently his solution allows me to
validate a document whose body looks like this:



test





test




As you can see this allows me to have *both* div1 and div0 at the top level.
However, I don't think his elegant solution should be thrown out with the
bathwater. No, no, instead this is an opportunity to solve yet another TEI
problem. If we remove div1 from the model.ndivLike class, then the solution
works perfectly.
The only side effect is that people are unable to start a document using div1
... in my mind this is hardly a drawback. (While I have no preference of
starting with div0 or div1, my cummings compromise for the month is that
removing div1 from the class is a much easier change than removing div0 from the
class and entirely.) Moreover, if people really want to start their documents at
div1, all they have to do is add it to the model.ndivLike class (and optionally
remove div0 from said class).
This is not a flaw, it is an opportunity.
-James
>
> So, if you don't mind those 3 new classes,
> and you don't find it strange have a DTD like this:
>
>
> _DUMMY_model.divGenLike))*,(((%macro.component;),(%model.global; |
> _DUMMY_model.divGenLike)*)+ | (_DUMMY_model.divLike,(%model.global; |
> _DUMMY_model.divGenLike)*)+ | ((%model.ndivLike;),(%model.global; |
> _DUMMY_model.divGenLike)*)+),(%model.divWrapper.bottom;)*)>
>
> then I claim victory, pending a full test.
>
> Here is the final content model:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 09 2007 - 07:24:06 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 9 07:37:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 12:37:15 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A3895A.8060709@oucs.ox.ac.uk> Message-ID: <45A38C7B.9030302@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 09 Jan 2007 12:37:15 +0000
Truly James he speaks the truth. This *is* the time to remove that
div0/div1 weirdness.

div1: "contains a first-level subdivision of the front, body, or back
of a text (the largest, if
div0 is not used, the second largest if it is)."
igh.
OK, whats the case for the defence?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 09 2007 - 07:37:28 EST

From laurent.romary at loria.fr Tue Jan 9 08:15:28 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Jan 2007 14:15:28 +0100 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A38C7B.9030302@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Tue, 9 Jan 2007 14:15:28 +0100
It reminds me of Monty Python and the Holy Grail (1975): "Burn"
Le 9 janv. 07 ? 13:37, Sebastian Rahtz a ?crit :
> Truly James he speaks the truth. This *is* the time to remove that
> div0/div1 weirdness.
>
>
> div1: "contains a first-level subdivision of the front, body,
> or back
> of a text (the largest, if
> div0 is not used, the second largest if it is)."
>
> sigh.
>
> OK, whats the case for the defence?
>
> --
> Sebastian Rahtz
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 09 2007 - 08:16:56 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 9 08:33:28 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 13:33:28 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: Message-ID: <45A399A8.9000705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 09 Jan 2007 13:33:28 +0000
I have just back-ported the contents of my test ODD into the body
of the TEI [1] and re-run all the tests. There are no unexpected results,
so I claim that my FAND approach works.
However, having removed div1 from model.divNLike
as per James' suggestion, I do hit a number of examples
in the Guidelines which use in that way;
if I reverse the polarity, I find some starting
elements.
There are three choices:
1. mandate div0 as the top level, and fix our own examples.
2. remove div0 entirely from the TEI
3. start again and try to reimplement the existing allowance.
I'd vote for 1.
[1] no, I have not submitted it to Sourceforge Subversion:-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 09 2007 - 08:33:41 EST
From Syd_Bauman at Brown.edu Thu Jan 11 11:03:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 11 Jan 2007 11:03:21 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 Message-ID: <17830.24521.896613.773882@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 11 Jan 2007 11:03:21 -0500
Are we set for the dates for meeting in Berlin?
pre-meeting event: 2007-04-25
meeting: 2007-04-26/27
Back in 2006-11-23/26 the following folks said they could make at
least the meeting dates (and most, if not all, said they could make
the pre-event, too):
LR, SR, LB, CT, DO, CW, JC.
Those dates are also fine w/ me, for both pre-meeting and meeting.
JW posted saying pre-meeting event was OK; I presume you meant the
meeting dates were OK, too, yes? That would mean 9 of the expected 14
attendees have responded in the affirmative.
April 2007
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 11 2007 - 11:03:25 EST
From jawalsh at indiana.edu Thu Jan 11 11:04:40 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 11 Jan 2007 11:04:40 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <17830.24521.896613.773882@emt.wwp.brown.edu> Message-ID: <59623B8F-F89C-444F-A2CB-E80AAAE7C023@indiana.edu>
From: John A. Walsh
Date: Thu, 11 Jan 2007 11:04:40 -0500
Syd,
Yes. I'm clear for both the meeting and the pre-meeting event.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote: > Are we set for the dates for meeting in Berlin? > pre-meeting event: 2007-04-25 > meeting: 2007-04-26/27 > > Back in 2006-11-23/26 the following folks said they could make at > least the meeting dates (and most, if not all, said they could make > the pre-event, too): > LR, SR, LB, CT, DO, CW, JC. > Those dates are also fine w/ me, for both pre-meeting and meeting. > > JW posted saying pre-meeting event was OK; I presume you meant the > meeting dates were OK, too, yes? That would mean 9 of the expected 14 > attendees have responded in the affirmative. > > April 2007 > Su Mo Tu We Th Fr Sa > 1 2 3 4 5 6 7 > 8 9 10 11 12 13 14 > 15 16 17 18 19 20 21 > 22 23 24 25 26 27 28 > 29 30 > > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 11 2007 - 11:04:51 EST
From mjd at hum.ku.dk Thu Jan 11 11:09:19 2007 From: mjd at hum.ku.dk (M. J. Driscoll) Date: Thu, 11 Jan 2007 17:09:19 +0100 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <59623B8F-F89C-444F-A2CB-E80AAAE7C023@indiana.edu> Message-ID: <45A66F3F.6562.1CA0461@localhost>
From: M. J. Driscoll
Date: Thu, 11 Jan 2007 17:09:19 +0100
These dates are fine for me, too.
I'm fairly sure I'd already confirmed this, but one never really knows, does
one?
MJD
> Syd,
>
> Yes. I'm clear for both the meeting and the pre-meeting event.
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote:
>
> > Are we set for the dates for meeting in Berlin?
> > pre-meeting event: 2007-04-25
> > meeting: 2007-04-26/27
> >
> > Back in 2006-11-23/26 the following folks said they could make at
> > least the meeting dates (and most, if not all, said they could make
> > the pre-event, too):
> > LR, SR, LB, CT, DO, CW, JC.
> > Those dates are also fine w/ me, for both pre-meeting and meeting.
> >
> > JW posted saying pre-meeting event was OK; I presume you meant the
> > meeting dates were OK, too, yes? That would mean 9 of the expected 14
> > attendees have responded in the affirmative.
> >
> > April 2007
> > Su Mo Tu We Th Fr Sa
> > 1 2 3 4 5 6 7
> > 8 9 10 11 12 13 14
> > 15 16 17 18 19 20 21
> > 22 23 24 25 26 27 28
> > 29 30
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 11 2007 - 11:09:34 EST

From arianna.ciula at kcl.ac.uk Thu Jan 11 11:53:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 11 Jan 2007 16:53:58 +0000 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <45A66F3F.6562.1CA0461@localhost> Message-ID: <45A66BA6.6020708@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 11 Jan 2007 16:53:58 +0000
I am sure I had confirmed as well, but probably directly with Laurent.
Arianna
M. J. Driscoll wrote:
> These dates are fine for me, too.
>
> I'm fairly sure I'd already confirmed this, but one never really knows, does
> one?
>
> MJD
>
>> Syd,
>>
>> Yes. I'm clear for both the meeting and the pre-meeting event.
>>
>> John
>> --
>> | John A. Walsh
>> | Assistant Professor, School of Library and Information Science
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | www:
>> | Voice:812-856-0707 Fax:812-856-2062 edu>
>>
>>
>> On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote:
>>
>>> Are we set for the dates for meeting in Berlin?
>>> pre-meeting event: 2007-04-25
>>> meeting: 2007-04-26/27
>>>
>>> Back in 2006-11-23/26 the following folks said they could make at
>>> least the meeting dates (and most, if not all, said they could make
>>> the pre-event, too):
>>> LR, SR, LB, CT, DO, CW, JC.
>>> Those dates are also fine w/ me, for both pre-meeting and meeting.
>>>
>>> JW posted saying pre-meeting event was OK; I presume you meant the
>>> meeting dates were OK, too, yes? That would mean 9 of the expected 14
>>> attendees have responded in the affirmative.
>>>
>>> April 2007
>>> Su Mo Tu We Th Fr Sa
>>> 1 2 3 4 5 6 7
>>> 8 9 10 11 12 13 14
>>> 15 16 17 18 19 20 21
>>> 22 23 24 25 26 27 28
>>> 29 30
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 11 2007 - 11:52:41 EST
From Syd_Bauman at Brown.edu Thu Jan 11 12:38:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 11 Jan 2007 12:38:47 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <45A66BA6.6020708@kcl.ac.uk> Message-ID: <17830.30247.305923.647231@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 11 Jan 2007 12:38:47 -0500
> I am sure I had confirmed as well, but probably directly with
> Laurent.
Nope. You confirmed to the list, as did DP. I just missed it because
you two confirmed *after* LR's follow-up. Sorry, no insult intended,
I promise!
So that means 11 of 14 have confirmed. I'm guessing that means we're
a "go" for those dates, but would like to hear from the local
organizer (LR) and chair (CW) before writing it down in pen on my
calendar.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 11 2007 - 12:38:50 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 01:12:49 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 15:12:49 +0900 Subject: [tei-council] test of telecon options Message-ID: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 12 Jan 2007 15:12:49 +0900
Dear Council members,
I hope everybody had a good start into the new year, the year of the
wild pig in this part of the world. As usual, the start into the year
is very slow in Japan, with lots of holidays, so we are just getting
into working mode here again in the last couple of days.
In preparation for our next teleconference, which is scheduled for Jan
23 at 1200 UTC, I would like to invite those who have time for a little
chat at the same time this next Monday (Jan. 15). The purpose is to
test if the highspeedconferencing.com system, which allows to call in
from VoIP and landline phones would give us better acoustic performance
than our current system.
Personally, I would like to see Syd among the volunteers for this chat,
since I had the most difficulties with the line from Brown so far
(maybe because it is just on the opposite site of the planet?), but
anybody is welcome. Sebastian, would you please give us instructions
what to do?
Apart from that, I hope everybody is busy chopping away on the action
items (for a reminder, please look at
http://www.tei-c.org/Council/tcm27.xml?style=printable)
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 01:12:57 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:16:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:16:09 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45A77C09.3050604@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 12 Jan 2007 12:16:09 +0000
> anybody is welcome. Sebastian, would you please give us instructions
> what to do?
>
>
an email should come soon, if I have done it right

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 07:16:22 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:21:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:21:34 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A77C09.3050604@oucs.ox.ac.uk> Message-ID: <45A77D4E.6050701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 12 Jan 2007 12:21:34 +0000
sigh. of course my gmail account cannot email council.
I append the message it should have sent you.
Dear TEI Council List,
sebastian.rahtz has scheduled a conference for:
Monday, January 15, 2007 12:00 PM (GMT+00:00)
Notes:

>From Skype call +99008275326922
In the US, call 1-712-432-4000
Calling from Europe, call
In Austria: 0820 400 01562
In Belgium: 0703 59 984
In France: 0826 100 266
In Germany 01805 00 7620
In UK: 0870 119 2350
Enter Conference Room Number : 5326922

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 07:21:46 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 07:52:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 21:52:28 +0900 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <17830.30247.305923.647231@emt.wwp.brown.edu> Message-ID: <45A7848C.9040900@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 12 Jan 2007 21:52:28 +0900
Syd Bauman wrote:
> So that means 11 of 14 have confirmed. I'm guessing that means we're
> a "go" for those dates, but would like to hear from the local
> organizer (LR) and chair (CW) before writing it down in pen on my
> calendar.
I had the impression we already decided about that. Anyway, if
necessary, here we go
"there is one more thing..."
The TEI Tecnical Council will hold its annual meeting for 2007 in
Berlin, Germany from April 26 to 27, with a pre-conference workshop on
April 25. See you there!
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 07:53:06 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 07:54:48 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 21:54:48 +0900 Subject: [tei-council] test of telecon options In-Reply-To: <45A77D4E.6050701@oucs.ox.ac.uk> Message-ID: <45A78518.3070802@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 12 Jan 2007 21:54:48 +0900
Sebastian Rahtz wrote:
> sigh. of course my gmail account cannot email council.
Thanks.
> sebastian.rahtz has scheduled a conference for:
> Monday, January 15, 2007 12:00 PM (GMT+00:00)
>
> Notes:
>
>
>
>>From Skype call +99008275326922
> In the US, call 1-712-432-4000
> Calling from Europe, call
> In Austria: 0820 400 01562
> In Belgium: 0703 59 984
> In France: 0826 100 266
> In Germany 01805 00 7620
> In UK: 0870 119 2350
Is there a land line to call from Japan or New Zealand?
Just curious if we have a fallback option here...
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 07:55:50 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:59:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:59:36 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A78518.3070802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45A78638.9030003@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 12 Jan 2007 12:59:36 +0000
Wittern Christian wrote:
>
> Is there a land line to call from Japan or New Zealand?
>
> Just curious if we have a fallback option here...
>
>
no, I am afraid not, you'd have to call the US number.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 07:59:48 EST
From daniel.odonnell at uleth.ca Fri Jan 12 11:28:02 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 12 Jan 2007 09:28:02 -0700 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1168619282.32635.8.camel@caedmon>
From: Daniel O'Donnell
Date: Fri, 12 Jan 2007 09:28:02 -0700
As much as I'd like to give it a tryout, I hope I'll be forgiven missing
a GMT 1200 (MST 0500) test call!
-dan
On Fri, 2007-01-12 at 15:12 +0900, Wittern Christian wrote:
> Dear Council members,
>
> I hope everybody had a good start into the new year, the year of the
> wild pig in this part of the world. As usual, the start into the year
> is very slow in Japan, with lots of holidays, so we are just getting
> into working mode here again in the last couple of days.
>
> In preparation for our next teleconference, which is scheduled for Jan
> 23 at 1200 UTC, I would like to invite those who have time for a little
> chat at the same time this next Monday (Jan. 15). The purpose is to
> test if the highspeedconferencing.com system, which allows to call in
> from VoIP and landline phones would give us better acoustic performance
> than our current system.
> Personally, I would like to see Syd among the volunteers for this chat,
> since I had the most difficulties with the line from Brown so far
> (maybe because it is just on the opposite site of the planet?), but
> anybody is welcome. Sebastian, would you please give us instructions
> what to do?
>
> Apart from that, I hope everybody is busy chopping away on the action
> items (for a reminder, please look at
> http://www.tei-c.org/Council/tcm27.xml?style=printable)
>
> All the best,
>
> Christian
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 11:28:06 EST
From Syd_Bauman at Brown.edu Fri Jan 12 16:30:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 12 Jan 2007 16:30:44 -0500 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17831.65028.155844.769109@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 12 Jan 2007 16:30:44 -0500
> ... a little chat at the same time this next Monday (Jan. 15). ...
> I would like to see Syd among the volunteers for this chat, since I
> had the most difficulties with the line from Brown so far
I will make every effort to dial in at 2007-01-15 00:00Z [1], but as
it is a holiday here in the States, I will have to do so from home,
not from work. On the other hand, IIRC, most of the trouble we've had
hearing each other, Christian, has been while I'm at home. (I
generally take early morning conference calls from home.)
Looking forward!
Note
---- [1] Some timezone equivalents: Calgary Canada - Alberta Mon 05:00 Chicago U.S.A. - Illinois Mon 06:00 Indianapolis U.S.A. - Indiana Mon 07:00 Providence U.S.A. - Rhode Island Mon 07:00 London U.K. - England Mon 12:00 Paris France Mon 13:00 Taipei Taiwan Mon 20:00 Kyoto Japan Mon 21:00 Wellington New Zealand Tue 01:00 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 12 2007 - 16:30:51 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 15 07:22:16 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Mon, 15 Jan 2007 21:22:16 +0900 Subject: [tei-council] teleconference scheduled for 2007-01-23, 1200 GMT on highspeedconferencing.com Message-ID: <45AB71F8.5030903@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Mon, 15 Jan 2007 21:22:16 +0900
Dear Council members,
Thanks to Sebastian, Matthew Driscoll, Tone Merete and Laurent, we just
successfully conducted our test on the highspeedconferencing.com system.
The results were encouraging for me; the voices from Europe much more
audible than usual. Although we missed our colleagues from the American
continent, understandably, it is hard to say how it will scale to 15
people in the line instead of just 5, but I think it is worth a try and
if successful should make the calls much less costly, since most
participants would not need to make oversea calls. However, for those
planning to use skype to connect -- please get a good headset to use,
otherwise you will spoil the whole experience.
Now, back to business. I am starting to collect agenda items. If you
have something you think should be on our mind, please post it to the
list. Updates on work items, reports, documents for review etc. please
post them and announce them here before the weekend!
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 15 2007 - 07:23:00 EST

From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 07:26:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 12:26:53 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A38C7B.9030302@oucs.ox.ac.uk> Message-ID: <45AE160D.8050404@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 17 Jan 2007 12:26:53 +0000
Sebastian Rahtz wrote:
> Truly James he speaks the truth. This *is* the time to remove that
> div0/div1 weirdness.
>
>
> div1: "contains a first-level subdivision of the front, body, or
> back
> of a text (the largest, if
> div0 is not used, the second largest if it is)."
>
> sigh.
>
> OK, whats the case for the defence?
>
(a) History. Precedent. Early doc processing systems use h0 and some h1
as the biggest class; if you were brung up on a "start from zero" one,
it's less of a headache.
(b) Safety net. If you start from div1, as sure as eggs is eggs, some
time you will find you need a bigger grouping, so you'll be glad that
div0 is there.
These both look pretty tenuous to me, but they're the best I can think
of. Any others?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 07:26:57 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 07:30:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 12:30:21 +0000 Subject: [tei-council] FAND Message-ID: <45AE16DD.6030705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 12:30:21 +0000
Can I ask for a decision on Monday about my proposal to
sort out numbered divs in the body/front/back? It is
encapsulated in the ODD at
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Test/testfand.odd?revision=1971&view=markup
In summary:
* define 3 newmodel classes: divLike, divNLike, divGenLike
* redefine front/body/back to allow 3 basic models
1. paragraphs
2. divLike + divGenLike
3. divNLike + divGenLike
* have divNLike consisting of div0 only. people who want to start with
div1 need to do a customization
I am really very keen to not have this drag on. Maybe we can
start 2007 with some decision-making? :-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 07:30:33 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 07:31:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 12:31:54 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE160D.8050404@computing-services.oxford.ac.uk> Message-ID: <45AE173A.1050303@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 12:31:54 +0000
Lou Burnard wrote:
>
> (a) History. Precedent. Early doc processing systems use h0 and some
> h1 as the biggest class; if you were brung up on a "start from zero"
> one, it's less of a headache.
dont buy that one
>
> (b) Safety net. If you start from div1, as sure as eggs is eggs, some
> time you will find you need a bigger grouping, so you'll be glad that
> div0 is there.
if you have that problem, you should be using
......

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 07:32:04 EST

From Syd_Bauman at Brown.edu Wed Jan 17 11:50:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 17 Jan 2007 11:50:45 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE173A.1050303@oucs.ox.ac.uk> Message-ID: <17838.21477.770977.617028@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 17 Jan 2007 11:50:45 -0500
I was under the impression, perhaps incorrectly, that a large part of
the decision to support both and (just as with the
decision to support both numbered and unnumbered
s)q was because
different communities within TEI were quite stuck on one or the
other. In many ways the TEI is a set of community consensus
Guidelines (as opposed to a standard from on high or a set of best
practices, although I daresay it has elements of those, too).
I doubt those communities have changed their love of one over the
other, although perhaps with the advent of XSLT they are more willing
to have local vs interchange formats that differ.
Of course, now that our pricing structure is based on "div0" as the
most expensive, we can't very well start at "div1", can we? :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 11:50:49 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 12:08:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 17:08:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.21477.770977.617028@emt.wwp.brown.edu> Message-ID: <45AE57F3.7070702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 17:08:03 +0000
Syd Bauman wrote:
> I was under the impression, perhaps incorrectly, that a large part of
> the decision to support both and (just as with the
> decision to support both numbered and unnumbered
s)q was because
> different communities within TEI were quite stuck on one or the
> other.
Indeed. I am sure that is so, but let's look forward.
What shall we do now, in P5? Is it your
belief that we should leave things as they are?
Sorry to push, but I want to avoid the outcome
of "yes it's not right as it is, but we're not sure
what to do, so we'll keep brooding over it
and maybe look again next year".
You know my views on the "it's ready
when it's ready" philosophy :-}
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 12:14:43 EST
From daniel.odonnell at uleth.ca Wed Jan 17 12:22:22 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 10:22:22 -0700 Subject: [tei-council] Agenda item? Message-ID: <1169054542.7389.38.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 17 Jan 2007 10:22:22 -0700
Hi all,
I have a topic that I hesitantly mention: tei:choice. My own conviction
is that we have too narrow a content model for the element. But I
understand that it may be too late to revisit the question?
I've been asking around to find a consensus on when an element of P5 has
been "decided" and only minor modifications are considered possible, but
we apparently don't have one.
If anybody thinks this is worth discussing at this telco or the next, I
can prepare something.
-dan
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 12:16:23 EST
From Syd_Bauman at Brown.edu Wed Jan 17 12:28:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 17 Jan 2007 12:28:22 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE57F3.7070702@oucs.ox.ac.uk> Message-ID: <17838.23734.957343.873006@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 17 Jan 2007 12:28:22 -0500
You asked for the case for the defense (of both a and
as top-level division). I am presenting one: users requested it, and
unless we find out that they've changed their minds, that's an
argument to keep them both.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 12:28:26 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:47:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:47:13 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE6F31.4050504@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 17 Jan 2007 18:47:13 +0000
Syd Bauman wrote:
> You asked for the case for the defense (of both a and
> as top-level division). I am presenting one: users requested it, and
> unless we find out that they've changed their minds, that's an
> argument to keep them both.
>
>
What evidence do you have for this? I don't recall any formal or
informal consultation on this specific issue, but maybe that's my memory.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 12:35:08 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:52:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:52:17 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169054542.7389.38.camel@odonned-eng06> Message-ID: <45AE7061.80200@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 17 Jan 2007 18:52:17 +0000
Dan O'Donnell wrote:
> Hi all,
>
> I have a topic that I hesitantly mention: tei:choice. My own conviction
> is that we have too narrow a content model for the element. But I
> understand that it may be too late to revisit the question?
>
> I've been asking around to find a consensus on when an element of P5 has
> been "decided" and only minor modifications are considered possible, but
> we apparently don't have one.
I seem to have missed out on this "asking around": were you seeking
Council's opinion on the procedural issue of when/how element
definitions get fixed, or on the specific technical issue of whether the
current proposal for the content model of needs attention?
>
> If anybody thinks this is worth discussing at this telco or the next, I
> can prepare something.
>
On which topic?

> -dan
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 12:40:12 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 12:40:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 17:40:12 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE5F7C.603@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 17:40:12 +0000
Syd Bauman wrote:
> You asked for the case for the defense (of both a and
> as top-level division). I am presenting one: users requested it, and
> unless we find out that they've changed their minds, that's an
> argument to keep them both.
>
I can see the argument, but I think it does not
hold water, because we have not done
any quantifiable user consultation for many
years; how would we know if they have changed their
minds?
you can test the water on TEI-L, but that's
pretty subjective.

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 12:46:51 EST

From daniel.odonnell at uleth.ca Wed Jan 17 13:21:21 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 11:21:21 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE7061.80200@oucs.ox.ac.uk> Message-ID: <1169058081.13385.15.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 17 Jan 2007 11:21:21 -0700
On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote:
> Dan O'Donnell wrote:
> > Hi all,
> >
> > I have a topic that I hesitantly mention: tei:choice. My own conviction
> > is that we have too narrow a content model for the element. But I
> > understand that it may be too late to revisit the question?
> >
> > I've been asking around to find a consensus on when an element of P5 has
> > been "decided" and only minor modifications are considered possible, but
> > we apparently don't have one.
>
> I seem to have missed out on this "asking around": were you seeking
> Council's opinion on the procedural issue of when/how element
> definitions get fixed, or on the specific technical issue of whether the
> current proposal for the content model of needs attention?
>
> >
> > If anybody thinks this is worth discussing at this telco or the next, I
> > can prepare something.
> >
>
> On which topic?
The one I labelled as "a topic" above: tei:choice. The "asking around"
about procedure, as the expression suggests, was informal and so didn't
involve more than a couple of casual email exchanges with some old TEI
hands in the course of other business: before proposing that we revisit
choice, I thought I better check if it was maybe too late or if there
was a procedure to indicate that certain topics were now closed or open.
The answer I got back each time was that there seemed not to be a formal
process in place covering this at council. It was suggested to me that
the procedural aspect might be worth discussing at council as well,
though that's at best a secondary interest of mine here. We seem to be
doing all right on the whole and I'm just interested in choice.
-dan
>
>
> > -dan
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 13:15:23 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:37:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:37:40 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169058081.13385.15.camel@odonned-eng06> Message-ID: <45AE6CF4.9080201@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 17 Jan 2007 18:37:40 +0000
Well, afaik the procedure for proposing changes to TEI P5 is like this:
You write a feature request and send it to the sourceforge site. The
editors review the list of outstanding requests and make proposals to
council as to their disposition. Council then agrees (or not) and the
change gets made (or not); or council can suggest there should be a new
work item.
Since you say you didnt want to talk about the procedure, but rather
about choice -- why not write that feature request?

Dan O'Donnell wrote:
> On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote:
>
>> Dan O'Donnell wrote:
>>
>>> Hi all,
>>>
>>> I have a topic that I hesitantly mention: tei:choice. My own conviction
>>> is that we have too narrow a content model for the element. But I
>>> understand that it may be too late to revisit the question?
>>>
>>> I've been asking around to find a consensus on when an element of P5 has
>>> been "decided" and only minor modifications are considered possible, but
>>> we apparently don't have one.
>>>
>> I seem to have missed out on this "asking around": were you seeking
>> Council's opinion on the procedural issue of when/how element
>> definitions get fixed, or on the specific technical issue of whether the
>> current proposal for the content model of needs attention?
>>
>>
>>> If anybody thinks this is worth discussing at this telco or the next, I
>>> can prepare something.
>>>
>>>
>> On which topic?
>>
>
> The one I labelled as "a topic" above: tei:choice. The "asking around"
> about procedure, as the expression suggests, was informal and so didn't
> involve more than a couple of casual email exchanges with some old TEI
> hands in the course of other business: before proposing that we revisit
> choice, I thought I better check if it was maybe too late or if there
> was a procedure to indicate that certain topics were now closed or open.
>
> The answer I got back each time was that there seemed not to be a formal
> process in place covering this at council. It was suggested to me that
> the procedural aspect might be worth discussing at council as well,
> though that's at best a secondary interest of mine here. We seem to be
> doing all right on the whole and I'm just interested in choice.
>
> -dan
>
>
>>
>>> -dan
>>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 13:37:45 EST

From daniel.odonnell at uleth.ca Wed Jan 17 13:52:42 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 11:52:42 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE6CF4.9080201@computing-services.oxford.ac.uk> Message-ID: <1169059962.16650.12.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 17 Jan 2007 11:52:42 -0700
On Wed, 2007-17-01 at 18:37 +0000, Lou Burnard wrote:
> Well, afaik the procedure for proposing changes to TEI P5 is like this:
> You write a feature request and send it to the sourceforge site. The
> editors review the list of outstanding requests and make proposals to
> council as to their disposition. Council then agrees (or not) and the
> change gets made (or not); or council can suggest there should be a new
> work item.
>
> Since you say you didnt want to talk about the procedure, but rather
> about choice -- why not write that feature request?
Sure, if that's how we do it. I'll just follow the model used to get the
DIV business we've been discussing added to the agenda (I thought I had
been). Since this is a current topic that has apparently gone through a
similar process, I'll presumably have no trouble taking it as my model.
I also didn't actually say I didn't want to talk about procedure. I
called it a secondary issue for me next to my interest in choice. If
we've got one, then so be it.
-dan

>
>
>
>
>
> Dan O'Donnell wrote:
> > On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote:
> >
> >> Dan O'Donnell wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have a topic that I hesitantly mention: tei:choice. My own conviction
> >>> is that we have too narrow a content model for the element. But I
> >>> understand that it may be too late to revisit the question?
> >>>
> >>> I've been asking around to find a consensus on when an element of P5 has
> >>> been "decided" and only minor modifications are considered possible, but
> >>> we apparently don't have one.
> >>>
> >> I seem to have missed out on this "asking around": were you seeking
> >> Council's opinion on the procedural issue of when/how element
> >> definitions get fixed, or on the specific technical issue of whether the
> >> current proposal for the content model of needs attention?
> >>
> >>
> >>> If anybody thinks this is worth discussing at this telco or the next, I
> >>> can prepare something.
> >>>
> >>>
> >> On which topic?
> >>
> >
> > The one I labelled as "a topic" above: tei:choice. The "asking around"
> > about procedure, as the expression suggests, was informal and so didn't
> > involve more than a couple of casual email exchanges with some old TEI
> > hands in the course of other business: before proposing that we revisit
> > choice, I thought I better check if it was maybe too late or if there
> > was a procedure to indicate that certain topics were now closed or open.
> >
> > The answer I got back each time was that there seemed not to be a formal
> > process in place covering this at council. It was suggested to me that
> > the procedural aspect might be worth discussing at council as well,
> > though that's at best a secondary interest of mine here. We seem to be
> > doing all right on the whole and I'm just interested in choice.
> >
> > -dan
> >
> >
> >>
> >>> -dan
> >>>
> >> _______________________________________________
> >> tei-council mailing list
> >> tei-council_at_lists.village.Virginia.EDU
> >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >>
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 13:46:43 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 14:20:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 19:20:55 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169054542.7389.38.camel@odonned-eng06> Message-ID: <45AE7717.8070903@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 19:20:55 +0000
I think this is a Bug Report on Sourceforge, not a Feature Request. You
are going
to argue that the content model for is wrong, that's all, right?
But it is essential that the reports on SF be dealt with, and closed.
Unclosed feature requests going back to 2004 make us look, er, rather silly.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 14:21:11 EST
From djbpitt+tei at pitt.edu Wed Jan 17 14:23:45 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 17 Jan 2007 14:23:45 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE77C1.3040005@pitt.edu>
From: David J Birnbaum
Date: Wed, 17 Jan 2007 14:23:45 -0500
Dear TEI Council,
> You asked for the case for the defense (of both a and
> as top-level division). I am presenting one: users requested it, and
> unless we find out that they've changed their minds, that's an
> argument to keep them both.
>
The TEI Guidelines strive mightily to be flexible, allowing multiple
ways to do the same thing because different user subcommunities have
different preferences. The arguments for doing what users want are
self-evident and certainly sensible, but we pay a price for this, which
has been brought to our attention recently in the discussion of how
, , and do or do not play well together.
I'd like to suggest that TEI Council not be excessively shy about
expressing a strong opinion (when we can more or less agree on one)
about best practice, and about steering the Guidelines in that
direction. Users who want to do something differently have the ability
to customize, so nobody is suggesting that deviating from out-of-the-box
TEI (to the extent that there is such a thing) means exile from the TEI
community, but to the extent that we prioritize making it easier for
people to do whatever they please, we move toward guidelines that don't
guide as much as they might.
In arguing that we should not be excessively flexible I certainly don't
mean to suggest that we should be capriciously dictatorial. Rather, I
think "some people want to do it this way" is an argument that should be
treated with respect, but it is not something that puts an end to all
argument.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 14:24:33 EST
From daniel.odonnell at uleth.ca Wed Jan 17 16:13:16 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 14:13:16 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE7717.8070903@oucs.ox.ac.uk> Message-ID: <1169068396.24012.3.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 17 Jan 2007 14:13:16 -0700
On Wed, 2007-17-01 at 19:20 +0000, Sebastian Rahtz wrote:
> I think this is a Bug Report on Sourceforge, not a Feature Request. You
> are going
> to argue that the content model for is wrong, that's all, right?
Conceptually wrong. I.e. that it should be much broader in what it can
contain. I don't know if that is best considered a bug, or a feature
request, or anything else.
>
> But it is essential that the reports on SF be dealt with, and closed.
> Unclosed feature requests going back to 2004 make us look, er, rather silly.
Indeed.
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 16:07:16 EST
From James.Cummings at computing-services.oxford.ac.uk Wed Jan 17 17:25:06 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 17 Jan 2007 22:25:06 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE77C1.3040005@pitt.edu> Message-ID: <45AEA242.5000707@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 17 Jan 2007 22:25:06 +0000
David J Birnbaum wrote:
> I'd like to suggest that TEI Council not be excessively shy about
> expressing a strong opinion (when we can more or less agree on one)
> about best practice, and about steering the Guidelines in that
> direction. Users who want to do something differently have the ability
> to customize, so nobody is suggesting that deviating from out-of-the-box
> TEI.
Yes, and this reminds me that I have yet to finish my straw-man rewrite of the
Conformance chapter. Mea Culpa. I will indeed do so, but it got delayed by the
topic re-erupting on TEI-L. I'll try to take the issues mentioned there into
consideration when doing so. Also, I'll not be able to participate in the
upcoming council teleconference, my apologies.
Although I'm much more of a
or if necessary kind of person than a
, I am happy to compromise and support Sebastian's proposal of starting at
by default and needing a (quite easy) customisation to change that if
is preferred.
> In arguing that we should not be excessively flexible I certainly don't
> mean to suggest that we should be capriciously dictatorial. Rather, I
> think "some people want to do it this way" is an argument that should be
> treated with respect, but it is not something that puts an end to all
> argument.
Others' comments on whether switching to default start for those using
numbered divs would seriously inconvenience the TEI community, leads me to a
suggestion. How about I undertake a survey (something like surveymonkey) on
behalf of the TEI which is then publicised on TEI-L to gauge the community's
strength of feeling on this issue. Feel free to suggest questions to ask. If
the council decides this is a good idea, I'll happily do so within the next month.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 17:25:22 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 18:00:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 23:00:52 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEA242.5000707@computing-services.oxford.ac.uk> Message-ID: <45AEAAA4.7080906@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 23:00:52 +0000
James Cummings wrote:
>
> How about I undertake a survey (something like surveymonkey) on
> behalf of the TEI which is then publicised on TEI-L to gauge the
> community's strength of feeling on this issue. Feel free to suggest
> questions to ask. If the council decides this is a good idea, I'll
> happily do so within the next month.
it would be interesting to see what reaction we got, to test such a system.
you could offer a choice between
1. remove all numbered divs from the TEI
2. remove div0 entirely
3. always start with div0
4. allow div0 or div1 as starting point
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 18:00:56 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 18:05:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 23:05:48 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEA242.5000707@computing-services.oxford.ac.uk> Message-ID: <45AEABCC.9020506@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 17 Jan 2007 23:05:48 +0000
James Cummings wrote:
>
> Yes, and this reminds me that I have yet to finish my straw-man
> rewrite of the Conformance chapter. Mea Culpa. I will indeed do so,
> but it got delayed by the topic re-erupting on TEI-L. I'll try to
> take the issues mentioned there into consideration when doing so.
> Also, I'll not be able to participate in the upcoming council
> teleconference, my apologies.
It would be immensely good if we had to draft to discuss a few days
before the
telco next week. Then we could see at the telco whether there was any
kind of consensus.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 18:06:00 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Jan 17 22:33:47 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 12:33:47 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEAAA4.7080906@oucs.ox.ac.uk> Message-ID: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Thu, 18 Jan 2007 12:33:47 +0900
Sebastian Rahtz wrote:
> you could offer a choice between
>
> 1. remove all numbered divs from the TEI
> 2. remove div0 entirely
> 3. always start with div0
> 4. allow div0 or div1 as starting point
>
To which I would like to add
5. numbered divs always start with div1
ince that is what I prefer. Given the (perceived) demographics of the
TEI community, I would expect this to be a popular one. And you should
make it clear that everybody gets to choose only one!
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 22:34:33 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Jan 17 22:39:44 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 12:39:44 +0900 Subject: [tei-council] Agenda item? In-Reply-To: <45AE6CF4.9080201@computing-services.oxford.ac.uk> Message-ID: <45AEEC00.2010406@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Thu, 18 Jan 2007 12:39:44 +0900
Lou Burnard wrote:
> Well, afaik the procedure for proposing changes to TEI P5 is like this:
> You write a feature request and send it to the sourceforge site. The
> editors review the list of outstanding requests and make proposals to
> council as to their disposition. Council then agrees (or not) and the
> change gets made (or not); or council can suggest there should be a new
> work item.
This is how it is supposed to work, however we are not that good at
implementing this protocol. Closing a topic is still something that
rarely happens, viz. div0 vs div1. But there is no obvious way to
improve that...
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 17 2007 - 22:41:36 EST

From Conal.Tuohy at vuw.ac.nz Wed Jan 17 22:54:00 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 18 Jan 2007 16:54:00 +1300 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <[tei-council] solving unnumbered divs (bis)> Message-ID:
From: Conal Tuohy
Date: Thu, 18 Jan 2007 16:54:00 +1300
Christian wrote:
> Sebastian Rahtz wrote:
> > you could offer a choice between
> >
> > 1. remove all numbered divs from the TEI
> > 2. remove div0 entirely
> > 3. always start with div0
> > 4. allow div0 or div1 as starting point
> >
>
> To which I would like to add
> 5. numbered divs always start with div1
Isn't that the same as option 2?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 17 2007 - 22:54:12 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 00:00:45 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 14:00:45 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: Message-ID: <45AEFEFD.10809@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Thu, 18 Jan 2007 14:00:45 +0900
Conal Tuohy wrote:
> Christian wrote:
>>> 2. remove div0 entirely
>> To which I would like to add
>> 5. numbered divs always start with div1
> Isn't that the same as option 2?
Ah, you are right. Sometimes it is better first to think, then to
write. Sorry for the noise. Now I'll try to do some thinking...
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 00:01:34 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:00:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:00:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45AF3713.6070809@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 18 Jan 2007 09:00:03 +0000
Wittern Christian wrote:
>
>>
>> 1. remove all numbered divs from the TEI
>> 2. remove div0 entirely
>> 3. always start with div0
>> 4. allow div0 or div1 as starting point
>>
>
> To which I would like to add
> 5. numbered divs always start with div1
*and* keep div0? I assumed my 2. impluied your 5.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 04:06:48 EST
From lou.burnard at computing-services.oxford.ac.uk Thu Jan 18 04:34:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 18 Jan 2007 09:34:42 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45AF3F32.4080905@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 18 Jan 2007 09:34:42 +0000
Wittern Christian wrote:
> Sebastian Rahtz wrote:
>> you could offer a choice between
>>
>> 1. remove all numbered divs from the TEI
>> 2. remove div0 entirely
>> 3. always start with div0
>> 4. allow div0 or div1 as starting point
>>
>
> To which I would like to add
> 5. numbered divs always start with div1
>
> since that is what I prefer. Given the (perceived) demographics of
> the TEI community, I would expect this to be a popular one. And you
> should make it clear that everybody gets to choose only one!
>
> Christian
>
>
>
Is it wise to base this decision solely on "perceived demographics"?
WHat's the basis for the perception? Where is the evidence?Those chaps
in NZ have barely started their survey yet, let alone produced any results.
I note also that we have in the past made far more radical changes in P5
(id to xml:id, lang to xml:lang) on the basis of other criteria, and
even (in the latter case) in the teeth of voluble opposition from the
"perceived demographic".
Personally I would like to have a good technical argument for making (or
not making) any of these changes.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 04:34:46 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:38:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:38:58 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF4032.9040100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 18 Jan 2007 09:38:58 +0000
Lou Burnard wrote:
>
> Personally I would like to have a good technical argument for making
> (or not making) any of these changes.
The technical argument is simple. If we don't do something about the
content model of //,
the promise of the TEI that you can remove more or less any element and
things will sort themselves
is out the window.
So jump off the fence, and choose your preference:
1. leave things as they are. tell Ron to read Syd's solutions on the wiki
2. rewrite the body content model in such a clever way that it
survives the loss of div0 and div1 in DTD
3. model-ize the divXX things so that things come out in the wash (my
proposal)
4. rewrite the ODD processor to make a clean DTD whatever happens
5. all of 2, 3 and 4 simultaneously
I can't believe that we need more info, and more discussion, we've already
spent what seems like years of my life in this area, publicly or
privately...
Solutions 2. and 4. require resources, so anyone choosing those should
explain who is going to do that work (clue: it aint me...).
You could always call for a vote, Christian :-}
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 04:45:30 EST
From lou.burnard at computing-services.oxford.ac.uk Thu Jan 18 04:55:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 18 Jan 2007 09:55:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF4032.9040100@oucs.ox.ac.uk> Message-ID: <45AF43F7.3060107@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 18 Jan 2007 09:55:03 +0000
Sebastian Rahtz wrote:
> The technical argument is simple. If we don't do something about the
> content model of //,
> the promise of the TEI that you can remove more or less any element
> and things will sort themselves
> is out the window.
>
> So jump off the fence, and choose your preference:
>
> 1. leave things as they are. tell Ron to read Syd's solutions on the
> wiki
> 2. rewrite the body content model in such a clever way that it
> survives the loss of div0 and div1 in DTD
> 3. model-ize the divXX things so that things come out in the wash (my
> proposal)
> 4. rewrite the ODD processor to make a clean DTD whatever happens
> 5. all of 2, 3 and 4 simultaneously
That's quite a different set of proposals from the set that Christian
just presented! Forgive me if too much tropical sun has blunted my
perceptions, but he seemed to be proposing abolition of one or more of
the various flavours of div, not making them into distinct classes.
If the latter is the issue before us, we've already agreed that
references to classes should be preferred above references to elements
wherever possible, so what's the argument about?

>
> I can't believe that we need more info, and more discussion, we've
> already
> spent what seems like years of my life in this area, publicly or
> privately...
>
> Solutions 2. and 4. require resources, so anyone choosing those should
> explain who is going to do that work (clue: it aint me...).
>
> You could always call for a vote, Christian :-}
>
> Sebastian
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 04:55:17 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:53:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:53:27 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF43F7.3060107@computing-services.oxford.ac.uk> Message-ID: <45AF4397.90700@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 18 Jan 2007 09:53:27 +0000
Lou Burnard wrote:
> That's quite a different set of proposals from the set that Christian
> just presented!
eh? thats a different, orthogonal, discussion (and it was my set)
> Forgive me if too much tropical sun has blunted my perceptions, but he
> seemed to be proposing abolition of one or more of the various
> flavours of div, not making them into distinct classes.
the div0 vs div1 debate follows on if you adopt my proposal for classing
divXXXs, but it
can also be had in isolation.
>
> If the latter is the issue before us, we've already agreed that
> references to classes should be preferred above references to elements
> wherever possible, so what's the argument about?
if you class the divXXX things as per my proposal, you end up allowing
... ... in a document, because I
drew the line at separate classes for div0 and div1.
I commend a thorough read of testfand.odd.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 04:59:58 EST
From James.Cummings at oucs.ox.ac.uk Thu Jan 18 05:02:02 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 18 Jan 2007 10:02:02 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF459A.60101@oucs.ox.ac.uk>
From: James Cummings
Date: Thu, 18 Jan 2007 10:02:02 +0000
Lou Burnard wrote:
> Is it wise to base this decision solely on "perceived demographics"?
> What's the basis for the perception? Where is the evidence?
Hence my proposed survey. I suggest I post a survey and give people a month to
answer it. While I wouldn't want to make such a change *solely* on statistical
results of such a survey, since we have a technical need for it, if the survey's
findings point to one of the possible solutions as preferable then at least that
is some evidence. Of course, we should be aware that the survey might produce
information that only complicates the matter. (If for example there is a 60/40
split, do we go with the 60? Surely 40% of respondents would represent a
significant portion of the community and thus we'd be back to trying to
implement both.) Basically the question is whether people want to continue to
support use of both div0 and div1 as a starting element. If people are fine
with numbered divs starting only at div0, then that is fine. If a strong
contingent feel they should also be allowed to start at div1, then it is more
problematic.
> Those chaps
> in NZ have barely started their survey yet, let alone produced any results.
The University of Sydney is in Australia.
> I note also that we have in the past made far more radical changes in P5
> (id to xml:id, lang to xml:lang) on the basis of other criteria, and
> even (in the latter case) in the teeth of voluble opposition from the
> "perceived demographic".
True, and the only reason I'm suggesting the survey is that it might shed some
light on how strongly the community feels about this. (i.e. is this a lone
voice crying in the wilderness or a general consensus)
> Personally I would like to have a good technical argument for making (or
> not making) any of these changes.
I think Sebastian has already made the technical argument for making these
changes (and the argument for not making them being that we're unable to have
people cleanly remove numbered divs should they desire).
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 05:02:14 EST
From arianna.ciula at kcl.ac.uk Thu Jan 18 05:09:10 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 18 Jan 2007 10:09:10 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF459A.60101@oucs.ox.ac.uk> Message-ID: <45AF4746.4000802@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 18 Jan 2007 10:09:10 +0000
Could we have a public summary of the 'technical argument' that people
interested can have a look at before replying to the survey?
James: I am happy to help out with the survey if you like.
Arianna
James Cummings wrote:
> Lou Burnard wrote:
>> Is it wise to base this decision solely on "perceived demographics"?
>> What's the basis for the perception? Where is the evidence?
>
> Hence my proposed survey. I suggest I post a survey and give people a month to
> answer it. While I wouldn't want to make such a change *solely* on statistical
> results of such a survey, since we have a technical need for it, if the survey's
> findings point to one of the possible solutions as preferable then at least that
> is some evidence. Of course, we should be aware that the survey might produce
> information that only complicates the matter. (If for example there is a 60/40
> split, do we go with the 60? Surely 40% of respondents would represent a
> significant portion of the community and thus we'd be back to trying to
> implement both.) Basically the question is whether people want to continue to
> support use of both div0 and div1 as a starting element. If people are fine
> with numbered divs starting only at div0, then that is fine. If a strong
> contingent feel they should also be allowed to start at div1, then it is more
> problematic.
>
>> Those chaps
>> in NZ have barely started their survey yet, let alone produced any results.
>
> The University of Sydney is in Australia.
>
>> I note also that we have in the past made far more radical changes in P5
>> (id to xml:id, lang to xml:lang) on the basis of other criteria, and
>> even (in the latter case) in the teeth of voluble opposition from the
>> "perceived demographic".
>
> True, and the only reason I'm suggesting the survey is that it might shed some
> light on how strongly the community feels about this. (i.e. is this a lone
> voice crying in the wilderness or a general consensus)
>
>> Personally I would like to have a good technical argument for making (or
>> not making) any of these changes.
>
> I think Sebastian has already made the technical argument for making these
> changes (and the argument for not making them being that we're unable to have
> people cleanly remove numbered divs should they desire).
>
> -James
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 05:11:47 EST
From James.Cummings at oucs.ox.ac.uk Thu Jan 18 05:12:11 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 18 Jan 2007 10:12:11 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEABCC.9020506@oucs.ox.ac.uk> Message-ID: <45AF47FB.4020206@oucs.ox.ac.uk>
From: James Cummings
Date: Thu, 18 Jan 2007 10:12:11 +0000
Sebastian Rahtz wrote:
> James Cummings wrote:
>>
>> Yes, and this reminds me that I have yet to finish my straw-man
>> rewrite of the Conformance chapter. Mea Culpa. I will indeed do so,
>> but it got delayed by the topic re-erupting on TEI-L. I'll try to
>> take the issues mentioned there into consideration when doing so.
>> Also, I'll not be able to participate in the upcoming council
>> teleconference, my apologies.
> It would be immensely good if we had to draft to discuss a few days
> before the
> telco next week. Then we could see at the telco whether there was any
> kind of consensus.
I do apologise that this will not happen before the telco. Today and Sunday I
will be preparing for a meeting in Amsterdam. (And said meeting is why I won't
be able to make the telco.) Friday and Saturday I have previous personal
commitments. I am happy to promise to submit a draft to council within a month
(if that) of the telco though.
Apologies,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 05:12:24 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 07:24:51 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 21:24:51 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF6713.1050703@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Thu, 18 Jan 2007 21:24:51 +0900
Lou Burnard wrote:
> Wittern Christian wrote:
>> Sebastian Rahtz wrote:
>>> you could offer a choice between
>>>
>>> 1. remove all numbered divs from the TEI
>>> 2. remove div0 entirely
>>> 3. always start with div0
>>> 4. allow div0 or div1 as starting point
>>>
>>
>> To which I would like to add
>> 5. numbered divs always start with div1
>>
>> since that is what I prefer. Given the (perceived) demographics of
>> the TEI community, I would expect this to be a popular one. And you
>> should make it clear that everybody gets to choose only one!
>>
>> Christian
> Is it wise to base this decision solely on "perceived demographics"?
> WHat's the basis for the perception? Where is the evidence?Those chaps
> in NZ have barely started their survey yet, let alone produced any results.
>
> I note also that we have in the past made far more radical changes in P5
> (id to xml:id, lang to xml:lang) on the basis of other criteria, and
> even (in the latter case) in the teeth of voluble opposition from the
> "perceived demographic".
>
> Personally I would like to have a good technical argument for making (or
> not making) any of these changes.
Well, I guess you noted the tongue in cheek. But as it happens, this is
supposed to go into a questionaire to solicit some answers to this very
questions -- with results that might be quite different from what I
expected. And BTW, the original set originated with Sebastian, it is
not something I made up.
Best, Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 07:25:55 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 10:45:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 15:45:03 +0000 Subject: [tei-council] another content model for body Message-ID: <45AF95FF.3090405@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 18 Jan 2007 15:45:03 +0000
OK, I think is now no longer controversial.
It keeps all the div/div1/div0 distinctions,
and also allows a 4th way, with paragraph-like
objects before optional divisions. It is now
not far off the existing model.
Personally, I think my original iteration
using Schematron was a lot more fun.
Tested for situations with div deleted, div1/div0 deleted,
and all div-like objects removed (testfand, testfand2,
testfand3 in Sourceforge)

































































































































-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 10:45:07 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 19:47:01 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 09:47:01 +0900 Subject: [tei-council] open issues and planning Message-ID: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 19 Jan 2007 09:47:01 +0900
Dear Council members,
In preparation for the telecon, I tried to take a stock of open issues
for P5. The first stop was the Kyoto Declaration:
http://www.tei-c.org/Council/tcw08.xml?style=printable
In the essential department, we have
(1) * chapter review, including review of examples
(2) * decision on module dependency architecture made, and if yes
implemented
(3) * remove instructions on how to invoke TEI DTD from each chapter
(4) * New user needs to have an easy way to generate customization
ODD and generate schemas
(5) * text of prose matches specs
(6) * *Specs frozen! :-)
(7) * Dictionary rewrite completed
(8) * Modification and Conformance chapters rewritten
I was wondering where we stand on these issues and how much work needs
to be done. Since there is some dependency on this, it seems to me that
we should see how much is needed to achieve (6). Also, (1) could
commence on chapters that are already checked off with regards to the spec.
Can someone remind me what we decided with respect to (2)?
Laurent, what is the status of the Dictionary chapter. When can we
expect a draft?
As to (8), that is on James' table now.
It seems to me that we should start (1), which will take a while to
complete, as soon as possible. What are the preconditions to start
here? Who will be in charge of this? These are questions we should adress.
We also need a better way to track the progress -- Maybe we should start
a Wiki page for this?
As to other open issues, I have on my list (from combing the tei-council
@lists and the minutes of our telecons, initials are the lead on for the
item):
* schematron rules (SR?)
* simplifying of dates (SB)
* 'limited phrase' (SB)
* biblItems etc (JW)
* PB followup (MD & DP)
* infrastructure for examples (LB, SB)
* FS request updates (LB, SB)
* div0, div1 decision (SB)
* choice content model
(anything else?)
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 19:47:43 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 19:53:21 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 09:53:21 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Message-ID: <45B01681.4080407@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 19 Jan 2007 09:53:21 +0900
DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at
1200 UTC

Expected to participate:
Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna
Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter,
Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian
Wittern
Sent apologies:
JC
============================================================
How to connect
We will use the highspeedconferencing.com service this time.
Participants can use their skype account (www.skype.com) or regular
phones to call. When calling via skype, *please use a headset*. If
in doubt, it might be better to call via regular phone. Numbers as follow:
Calling from the US...
call # 1-712-432-4000
(long distance charges apply).
Calling from Europe, call:
Austria 0820 400 01562
Belgium 0703 59 984
France 0826 100 266
Germany 01805 00 7620
UK 0870 119 2350
The Conference Room Number is 5877524
============================================================
Please read through the following. Wherever a report is requested, a
brief note to the list before the call is much appreciated and will
help us use the time during the call more effectively.
============================================================
1) Minutes, work items, progress since last meeting:
http://www.tei-c.org.uk/Council/tcm27.xml?style=printable
Please look at the action items and report progress here before the
meeting!
============================================================
2) Workgroups monitoring:
A) PB
Dot & Matthew, please report on developments here.
WG TEI website: http://www.tei-c.org.uk/Activities/PB/index.xml
B) PERS
Matthew, please give us an update on the preparations for the meeting etc.
C) I18N
Sebastian, please give us a brief report on where we stand here.

============================================================
3) Road to P5:
I am circulating a separete message lining out some of the issues I
see. I would like to go away from this telecon with a clearer view of
the road ahead and how we get there.

============================================================
4) Meetings
Council 2007: Berlin, preparations? Do we need more meetings?
next call: Mid to end March 2007
============================================================
5) Other business TBA

============================================================

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 19:54:01 EST

From Syd_Bauman at Brown.edu Thu Jan 18 20:29:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 18 Jan 2007 20:29:09 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17840.7909.19929.739280@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 18 Jan 2007 20:29:09 -0500
Perfect timing, Christian. I was just about to post a "where I am w/
dates" item. I'll intersperse it, below.

> * schematron rules (SR?)
This one is SB.
> * simplifying of dates (SB)
I am working on this issue right now. The results of our TEI-L poll
about and are that absolutely no one except
EpiDoc said they even use them at all, let alone the children we are
going to eliminate. Since EpiDoc is already a significant
customization (P4 at the moment), with significant talent available,
they can easily add whatever they need back. (And I think it likely
that they will actually find other mechanisms when they move to P5.)
Thus I have no problem yanking 'em out. So I am right now in the process
of removing the , , , , ,
, , and elements.
Once done with that, I plan to post a summary of outstanding issues
with some suggestions, probably over the weekend.
> * 'limited phrase' (SB)
> * biblItems etc (JW)
> * PB followup (MD & DP)
> * infrastructure for examples (LB, SB)
Could someone remind me what this means?
> * FS request updates (LB, SB)
> * div0, div1 decision (SB)
Did you really mean me?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jan 18 2007 - 20:29:12 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 22:02:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 12:02:28 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <17840.7909.19929.739280@emt.wwp.brown.edu> Message-ID: <45B034C4.5080306@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 19 Jan 2007 12:02:28 +0900
Syd Bauman wrote:
> Perfect timing, Christian. I was just about to post a "where I am w/
> dates" item. I'll intersperse it, below.
>
Great, thanks. In fact I felt this was terribly late...
>> * schematron rules (SR?)
> This one is SB.
Good.
>
>> * simplifying of dates (SB)
> I am working on this issue right now. The results of our TEI-L poll
> about and are that absolutely no one except
> EpiDoc said they even use them at all, let alone the children we are
> going to eliminate. Since EpiDoc is already a significant
> customization (P4 at the moment), with significant talent available,
> they can easily add whatever they need back. (And I think it likely
> that they will actually find other mechanisms when they move to P5.)
> Thus I have no problem yanking 'em out. So I am right now in the process
> of removing the , , , , ,
> , , and elements.
Great.
>
> Once done with that, I plan to post a summary of outstanding issues
> with some suggestions, probably over the weekend.
>
Fine. It is probably as much as we can get, given the timeframe.
>> * 'limited phrase' (SB)
>> * biblItems etc (JW)
>> * PB followup (MD & DP)
>> * infrastructure for examples (LB, SB)
> Could someone remind me what this means?
That should also be SR here, the issue is how to make multilingual
examples possible -- e.g. where to put them, and what to change in the
toolchain.
>
>> * FS request updates (LB, SB)
>> * div0, div1 decision (SB)
> Did you really mean me?
No, SR as well. It seems I got a bit confused halfway through.
So, the updated and corrected list is
* schematron rules (SB)
* simplifying of dates (SB)
* 'limited phrase' (SB)
* biblItems etc (JW)
* PB followup (MD & DP)
* infrastructure for examples (LB, SR)
* FS request updates (LB, SB)
* div0, div1 decision (SR)
* choice content model (?)
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 22:03:14 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 22:13:12 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 12:13:12 +0900 Subject: [tei-council] Budget news, PERS meeting Message-ID: <45B03748.2080202@kanji.zinbun.kyoto-u.ac.jp>
From: Wittern Christian
Date: Fri, 19 Jan 2007 12:13:12 +0900
Council members,
I just got news from Dan that the Board approved a rollover of unspend
budget of 2006 for 2007. If I understand correctly, we thus have roughly
$4k more than last year to spend , i.e. $28k. This is a one time, no
precedent-setting affair under the assumption that P5 will finally go
out this year and thus needs some additional care. We might be able to
squeeze in a second f2f meeting of the Council or a subcommittee modeled
on the Oxford class meeting if that turns out to be necessary -- this is
assuming that the April meeting in Berlin will be significantly less
expensive than last years Kyoto meeting.
Apart from that, and much more concrete, there has been a request from
Matthew Driscoll to hold the PERS meeting in Vilnius. He expects this
will set us back around $4-5k. This would also go out of this above
mentioned budget. I would like to approve this, but am open to other
opinions from the Council. We will need to act quickly on this, so if
you disagree, please speek up now. I will set the cutoff time for
protests to Sunday evening 23:59 GMT, which will allow me to notify
Matthew of the results Monday morning JST.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 18 2007 - 22:13:52 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 03:54:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 08:54:08 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B08730.40901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 19 Jan 2007 08:54:08 +0000
Wittern Christian wrote:
> (1) * chapter review, including review of examples
> (2) * decision on module dependency architecture made, and if yes
> implemented
> (3) * remove instructions on how to invoke TEI DTD from each chapter
> (4) * New user needs to have an easy way to generate customization
> ODD and generate schemas
> (5) * text of prose matches specs
> (6) * *Specs frozen! :-)
> (7) * Dictionary rewrite completed
> (8) * Modification and Conformance chapters rewritten
>
> I was wondering where we stand on these issues and how much work needs
> to be done. Since there is some dependency on this, it seems to me that
> we should see how much is needed to achieve (6).
One absolute requirement here is to assess all outstanding bug reports
and feature
requests in SF, and deal with them one way or another. If, for example,
Dan is
going to raise issues about , that needs a quick agreement.
With my I18N hat on, there are now five groups translating
descriptions of specs with a delivery date of the autumn
at latest. I am taking it on trust therefore that the specs _are_
frozen to all intents and purposes.
The PERS activity will likely need some Specs adding. and dictionaries
of course.
> Also, (1) could
> commence on chapters that are already checked off with regards to the spec.
> Can someone remind me what we decided with respect to (2)?
>
I (think) we agreed it was unworkable and not probably needed. The immediate
requirement was met by the new model class facility to allow sequences
as well as alternations. I think we should let this one die a natural death
for now
> It seems to me that we should start (1), which will take a while to
> complete, as soon as possible. What are the preconditions to start
> here? Who will be in charge of this? These are questions we should adress.
>
agreed. someone has to drive this in a pretty strict way.
> We also need a better way to track the progress -- Maybe we should start
> a Wiki page for this?
>
I did wonder about running trac (http://trac.edgewall.org/) as an aide.
> * schematron rules (SR?)
>
what about them? support for them is implemented, but
I the reaction I got a few weeks ago seemed to
be against it. As I said then, I'd much rather implement
a div0/div/div1 thing using Schematron if we
accept its serious use
> * infrastructure for examples (LB, SB)
>
In my opinion, we have no resources to
deal with this. I think its a distraction this year.
> * div0, div1 decision (SB)
>
If you accept my model class reimplementation of ,
can we just agree to abide by the results of James and Ariana's
surveymonkey, and simply implement what they find out.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 03:54:21 EST
From Syd_Bauman at Brown.edu Fri Jan 19 10:04:17 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 10:04:17 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B08730.40901@oucs.ox.ac.uk> Message-ID: <17840.56817.452436.521530@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 19 Jan 2007 10:04:17 -0500
> I am taking it on trust therefore that the specs _are_ frozen to
> all intents and purposes.
>
> The PERS activity will likely need some Specs adding. and dictionaries
> of course.
I do not think the specifications are in any way frozen. In addition
to those you've mentioned, just this week we have been discussing
possible significant changes in the , , and
specifications, and we will be discussing the revamping of dating
attributes. There are probably quite a few others, as well.
Not to mention that neither the editors nor the Council has announced
that they can be or are frozen.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 19 2007 - 10:04:20 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 11:17:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 16:17:53 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <17840.56817.452436.521530@emt.wwp.brown.edu> Message-ID: <45B0EF31.7010204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 19 Jan 2007 16:17:53 +0000
Syd Bauman wrote:
>
> I do not think the specifications are in any way frozen.
in any way at all? out of 650, are more than 1% still
gelid?
> In addition
> to those you've mentioned, just this week we have been discussing
> possible significant changes in the , , and
> specifications
those are small details; bug fixes, really. They don't
affect the descriptions or semantics etc
> and we will be discussing the revamping of dating
> attributes.
details. You're zapping half a dozen elements,
and will clean up after you. I count that as frozen.
> There are probably quite a few others, as well.
>
Sorry, "probably quite a few" isn't good enough.
What others, precisely? if they are recorded
issues unresolved, let's list them, and solve them.
Of course there are always more and more issues
to find if we look hard enough, but the process must
end soon if we are to meet our commitments.
"What commitments", someone will ask?
Well, if you (all) don't think we have a *commitment* to deliver
TEI 5.0 completely ready for use by the TEI MM 2007,
then we ain't singing off the same song sheet.
> Not to mention that neither the editors nor the Council has announced
> that they can be or are frozen.
>
I didn't imply that. I said *I* regard them as frozen.
I propose a strawman timetable for us:
1st February: accept no more feature requests for 5.0
1st March: all Sourceforge bug reports and feature requests from before
Feb 1 closed or definitely put off for 5.1
1st April: all implementation resulting from those SF things complete
1st May: (after council meeting) technical freeze of specs, only
serious bug fixes allowed after that
I have a feeling you are all going to get fed up with me saying this,
but I feel very strongly that we cannot carry on in "ready when its ready"
mode. We need at least minimal project management here, and that includes
timetables and deadlines.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 11:18:07 EST
From daniel.odonnell at uleth.ca Fri Jan 19 11:55:12 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Fri, 19 Jan 2007 09:55:12 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B0EF31.7010204@oucs.ox.ac.uk> Message-ID: <1169225712.23841.14.camel@odonned-eng06>
From: Dan O'Donnell
Date: Fri, 19 Jan 2007 09:55:12 -0700
On Fri, 2007-19-01 at 16:17 +0000, Sebastian Rahtz wrote:
> Syd Bauman wrote:
> >
> Sorry, "probably quite a few" isn't good enough.
> What others, precisely? if they are recorded
> issues unresolved, let's list them, and solve them.
> Of course there are always more and more issues
> to find if we look hard enough, but the process must
> end soon if we are to meet our commitments.
>
> "What commitments", someone will ask?
>
> Well, if you (all) don't think we have a *commitment* to deliver
> TEI 5.0 completely ready for use by the TEI MM 2007,
> then we ain't singing off the same song sheet.
> > Not to mention that neither the editors nor the Council has announced
> > that they can be or are frozen.
> >
> I didn't imply that. I said *I* regard them as frozen.
>
> I propose a strawman timetable for us:
>
> 1st February: accept no more feature requests for 5.0
> 1st March: all Sourceforge bug reports and feature requests from before
> Feb 1 closed or definitely put off for 5.1
> 1st April: all implementation resulting from those SF things complete
> 1st May: (after council meeting) technical freeze of specs, only
> serious bug fixes allowed after that
>
> I have a feeling you are all going to get fed up with me saying this,
> but I feel very strongly that we cannot carry on in "ready when its ready"
> mode. We need at least minimal project management here, and that includes
> timetables and deadlines.
I agree. The board was quite serious about getting P5 done this year and
indeed had a "push money" line in the budget. The effort as currently
structured may not be sustainable much after this calendar year either,
as it is starting to take a toll on several major participants--or their
employers' patience. That's why I'd originally asked around to find out
when something is frozen.
Obviously it is a fine line: we also can't put out substandard work
either (not that that's ever been a TEI problem). And the Board and
several TEI partners seem quite interested in stability after P5 (i.e.
we should perhaps not move on to P6 right away if P6 means major
revisioning). Given the nature of what we are up, therefore, to perhaps
we should define "bug" to mean major conceptual issues with finished
work as well. What I mean by this is if somebody discovers a major flaw
in the underlying reasoning--something that would require us to move on
to P6.
I suspect from the above exchange that what we are really looking at is
agreeing on and formalising what we mean by frozen and what makes
something frozen: the things Syd mentions as not frozen fit Sebastian's
definition of frozen. Should process (or project management for the next
ten months--yikes!) be an agenda item after all? It certainly does seem
to me that we need to say "x is done--to propose changes, there needs to
be a serious issue involved."
-dan
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 11:49:03 EST
From daniel.odonnell at uleth.ca Fri Jan 19 12:11:18 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Fri, 19 Jan 2007 10:11:18 -0700 Subject: [tei-council] Budget news, PERS meeting In-Reply-To: <45B03748.2080202@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1169226678.23841.25.camel@odonned-eng06>
From: Dan O'Donnell
Date: Fri, 19 Jan 2007 10:11:18 -0700
As an ex officio member, I believe I can still signal my lack of
protest. Speaking personally, I think it is a good idea.
-dan
On Fri, 2007-19-01 at 12:13 +0900, Wittern Christian wrote:
> Council members,
>
> I just got news from Dan that the Board approved a rollover of unspend
> budget of 2006 for 2007. If I understand correctly, we thus have roughly
> $4k more than last year to spend , i.e. $28k. This is a one time, no
> precedent-setting affair under the assumption that P5 will finally go
> out this year and thus needs some additional care. We might be able to
> squeeze in a second f2f meeting of the Council or a subcommittee modeled
> on the Oxford class meeting if that turns out to be necessary -- this is
> assuming that the April meeting in Berlin will be significantly less
> expensive than last years Kyoto meeting.
>
> Apart from that, and much more concrete, there has been a request from
> Matthew Driscoll to hold the PERS meeting in Vilnius. He expects this
> will set us back around $4-5k. This would also go out of this above
> mentioned budget. I would like to approve this, but am open to other
> opinions from the Council. We will need to act quickly on this, so if
> you disagree, please speek up now. I will set the cutoff time for
> protests to Sunday evening 23:59 GMT, which will allow me to notify
> Matthew of the results Monday morning JST.
>
> All the best,
>
> Christian
>
>
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 12:05:06 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 12:10:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 17:10:24 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <1169225712.23841.14.camel@odonned-eng06> Message-ID: <45B0FB80.4000600@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 19 Jan 2007 17:10:24 +0000
The Birnbaum Declaration agreed last autumn covers
what it means to be P5 1.0, 1.1, 1.2 as opposed to P6,
I think.
My concern is that we are juggling too many
balls at the same time, without resources.
We won't get through the "Steps To P5"
if they all run in parallel, unless someone
here miraculously takes a 6 month sabbatical
and devotes themselves to TEI editing full-time.
So although of course there are circular
dependencies, let's at least try to clear
out things in sequence. In our meetings,
f2f or telco or email, we tend to have far
too many varied things on the agenda
at once....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 12:10:44 EST
From Syd_Bauman at Brown.edu Fri Jan 19 14:20:54 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 14:20:54 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B0EF31.7010204@oucs.ox.ac.uk> Message-ID: <17841.6678.27216.694302@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 19 Jan 2007 14:20:54 -0500
> Well, if you (all) don't think we have a *commitment* to deliver
> TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't
> singing off the same song sheet.
Yes, we are singing off different sheets. Some may wonder, but I
think we are singing the same piece of music, at least, just
different arrangements, to carry the analogy too far.

> 1st February: accept no more feature requests for 5.0
This has already happened twice, and need not be repeated. Feature
requests submitted now would almost assuredly *not* be considered for
the 1.0 releaes of P5. (Sorry, Daniel.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 19 2007 - 14:20:57 EST

From daniel.odonnell at uleth.ca Fri Jan 19 14:26:21 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 19 Jan 2007 12:26:21 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <17841.6678.27216.694302@emt.wwp.brown.edu> Message-ID: <1169234781.5519.5.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 19 Jan 2007 12:26:21 -0700
On Fri, 2007-01-19 at 14:20 -0500, Syd Bauman wrote:
> > Well, if you (all) don't think we have a *commitment* to deliver
> > TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't
> > singing off the same song sheet.
>
> Yes, we are singing off different sheets. Some may wonder, but I
> think we are singing the same piece of music, at least, just
> different arrangements, to carry the analogy too far.
>
>
> > 1st February: accept no more feature requests for 5.0
>
> This has already happened twice, and need not be repeated. Feature
> requests submitted now would almost assuredly *not* be considered for
> the 1.0 releaes of P5. (Sorry, Daniel.)
It's a dog's life! ;)
Frankly I suspected as much. I'm happier to see us progressing to 1.0
release than I am sad at not getting the right way of doing
choice--strong wink--into the release!
-dan
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 19 2007 - 14:26:27 EST
From Syd_Bauman at Brown.edu Fri Jan 19 23:19:30 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 23:19:30 -0500 Subject: [tei-council] , , and Message-ID: <17841.38994.991726.171153@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 19 Jan 2007 23:19:30 -0500
Great minds think alike. (But are they right?)
I am in the midst of yanking out , , etc. from the
Guidelines. In doing so I re-worked several examples that use the
element. I found myself wondering if , which is
pretty much syntactic sugar for , should also be
ditched. Then I came across the following comment:

I don't think Michael ever used "shd", and I know I didn't, so I'm
giving Lou credit for this insight.

But perhaps this one is syntactic sugar sweet enough to keep. Here's
an example.

A week
before
the meeting

(Note that "P07D" is the ISO & W3C format for a period of seven
days.)

A week
before
the meeting

(Note that "d" is the symbol for "day" approved by CIPM for use with
SI units.)
is also used within and for the
same kind of thing, but it does not have the right attributes to
provide a regularized value. Thus I'm in favor of using
instead of for and .
If I had my druthers, I think I'd prefer to use dur= on in
alternation with the other three attributes:
element measure {
(
attribute dur { xsd:duration }?
|
(
attribute unit { data.enumerated }?,
attribute quantity { data.numeric }?,
attribute commodity { data.words }?,
)
),
etc.
}

At the moment I don't think ODD processors can handle that sort of
construct, so if we went this route we would probably want to enforce
it with a Schematron rule.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 19 2007 - 23:19:36 EST

From lou.burnard at computing-services.oxford.ac.uk Sat Jan 20 04:59:58 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 20 Jan 2007 09:59:58 +0000 Subject: [tei-council] , , and In-Reply-To: <17841.38994.991726.171153@emt.wwp.brown.edu> Message-ID: <45B1E81E.6010809@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 20 Jan 2007 09:59:58 +0000
1. If we are getting rid of the substructure of , then we're
getting rid of all of it, so it makes no difference whether you
represent old by or , it's still dead.
The element in particular really really has to go.
2. As it happens, yes we do have a way of representing a choice of
attributes in ODD. See
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html. There
is a (not very good) example at 27.3.3.3 and we use it on eg
and

Syd Bauman wrote:
>
>
> But perhaps this one is syntactic sugar sweet enough to keep. Here's
> an example.
>
>
> A week
> before
> the meeting
>
>
> (Note that "P07D" is the ISO & W3C format for a period of seven
> days.)
>
>
> A week
> before
> the meeting
>
>
> (Note that "d" is the symbol for "day" approved by CIPM for use with
> SI units.)
>
> is also used within and for the
> same kind of thing, but it does not have the right attributes to
> provide a regularized value. Thus I'm in favor of using
> instead of for and .
>
> If I had my druthers, I think I'd prefer to use dur= on in
> alternation with the other three attributes:
>
> element measure {
> (
> attribute dur { xsd:duration }?
> |
> (
> attribute unit { data.enumerated }?,
> attribute quantity { data.numeric }?,
> attribute commodity { data.words }?,
> )
> ),
> etc.
> }
>
> At the moment I don't think ODD processors can handle that sort of
> construct, so if we went this route we would probably want to enforce
> it with a Schematron rule.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 20 2007 - 05:00:10 EST

From Syd_Bauman at Brown.edu Sat Jan 20 07:51:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 07:51:25 -0500 Subject: [tei-council] , , and In-Reply-To: <45B1E81E.6010809@computing-services.oxford.ac.uk> Message-ID: <17842.4173.302963.500608@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 20 Jan 2007 07:51:25 -0500
> 1. If we are getting rid of the substructure of , then we're
> getting rid of all of it, so it makes no difference whether you
> represent old by or , it's still
> dead. The element in particular really really has to go.
No, actually, and were not in the list of
elements to be nuked. (The reasoning was that they are used inside
, too, I believe.)

> 2. As it happens, yes we do have a way of representing a choice of
> attributes in ODD. See
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html.
> There is a (not very good) example at 27.3.3.3 and we use it on eg
> and
Right, but IIRC Sebastian has pointed out that this mechanism can
only be used to alternate two attributes, not one attribute with a
group of others or two groups. I am not sure whether this restriction
existed only back then, exists currently, or will in perpetuity.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 20 2007 - 07:51:28 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 20 09:31:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 20 Jan 2007 14:31:59 +0000 Subject: [tei-council] , , and In-Reply-To: <17842.4173.302963.500608@emt.wwp.brown.edu> Message-ID: <45B227DF.3070906@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 20 Jan 2007 14:31:59 +0000
Syd Bauman wrote:
>> 2. As it happens, yes we do have a way of representing a choice of
>> attributes in ODD. See
>> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html.
>> There is a (not very good) example at 27.3.3.3 and we use it on eg
>> and
>>
>
> Right, but IIRC Sebastian has pointed out that this mechanism can
> only be used to alternate two attributes, not one attribute with a
> group of others or two groups. I am not sure whether this restriction
> existed only back then, exists currently, or will in perpetuity.
>
If you believe the attList specification allows what
you need, then I should implement it. I'm willing
to have a try, if its needed.
On the other hand, restrictions like this are
good candidates for Schematron, as you say.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 20 2007 - 09:32:12 EST
From lou.burnard at computing-services.oxford.ac.uk Sat Jan 20 10:38:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 20 Jan 2007 15:38:23 +0000 Subject: [tei-council] , , and In-Reply-To: <45B227DF.3070906@oucs.ox.ac.uk> Message-ID: <45B2376F.9070404@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 20 Jan 2007 15:38:23 +0000
The specification says that an attList can contain any combination of
attRef, attDef, or attList, and that its org attribute determines
whether its children are to be regarded as forming a group or an
alternation. So I cannot for the life of me see what you might want that
the spec doesn't support.
If the current ODD processor doesn't support it, then it's a bug, and
should be documented.
HOWEVER, before we get all excited about using this wonderful facility,
I'd like to record my profound skepticism about the wisdom of allowing
@dur as an attribute on at all.

Sebastian Rahtz wrote:
> Syd Bauman wrote:
>>> 2. As it happens, yes we do have a way of representing a choice of
>>> attributes in ODD. See
>>> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html.
>>> There is a (not very good) example at 27.3.3.3 and we use it on eg
>>> and
>>>
>>
>> Right, but IIRC Sebastian has pointed out that this mechanism can
>> only be used to alternate two attributes, not one attribute with a
>> group of others or two groups. I am not sure whether this restriction
>> existed only back then, exists currently, or will in perpetuity.
>>
> If you believe the attList specification allows what
> you need, then I should implement it. I'm willing
> to have a try, if its needed.
>
> On the other hand, restrictions like this are
> good candidates for Schematron, as you say.
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 20 2007 - 10:38:37 EST

From Syd_Bauman at Brown.edu Sat Jan 20 10:55:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 10:55:36 -0500 Subject: [tei-council] , , and In-Reply-To: <45B227DF.3070906@oucs.ox.ac.uk> Message-ID: <17842.15224.28276.20873@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 20 Jan 2007 10:55:36 -0500
> If you believe the attList specification allows what you need, then
> I should implement it. I'm willing to have a try, if its needed.
I certainly think the specification allows this:












This states that a must have either both A1= and A2= or both
B1= and B2=, and can't have all four of them (or zero, one, or three
of them).
This could be expressed in RelaxNG as





















which in the compact syntax requires what always looks to me like an
extra layer of parenthesis, but makes sense when you think of the
outer parens as and the inner parens as :
element duck {
(
( attribute A1 { empty }, attribute A2 { empty } )
|
( attribute B1 { empty }, attribute B2 { empty } )
),
empty
}
What I'm not certain of is whether we want to change the
implementation to do what the specification permits, or change the
specification so that you can't do this. I lean towards the former,
but it may be more effort than it's worth.

> On the other hand, restrictions like this are good candidates for
> Schematron, as you say.
True. And although there are some disadvantages with using Schematron
(speed problems jump to mind), it does have the advantage of
providing a check for those who use DTDs.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 20 2007 - 10:55:41 EST

From Syd_Bauman at Brown.edu Sat Jan 20 11:08:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 11:08:56 -0500 Subject: [tei-council] , , and In-Reply-To: <45B2376F.9070404@computing-services.oxford.ac.uk> Message-ID: <17842.16024.499219.282091@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 20 Jan 2007 11:08:56 -0500
> HOWEVER, before we get all excited about using this wonderful
> facility, I'd like to record my profound skepticism about the
> wisdom of allowing @dur as an attribute on at all.
I am also uneasy with putting a dur= on . But
simultaneously, I'm uneasy about expressing a span of time using dur=
if it is a
From lou.burnard at computing-services.oxford.ac.uk Sat Jan 20 11:26:48 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 20 Jan 2007 16:26:48 +0000 Subject: [tei-council] , , and In-Reply-To: <17842.16024.499219.282091@emt.wwp.brown.edu> Message-ID: <45B242C8.8040504@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 20 Jan 2007 16:26:48 +0000
Syd Bauman wrote:
> Perhaps isn't the right alternative to P4's ,
> but rather a(nother) nested
> really want to structure your relative times, you would use
>
> I was able to get online
>
> before
>
>
>
> and the rest of us would just use
>
>
>
>
That would make marginally more sense. But I stand by my original
assertion that we should drop as a child of
From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 20 11:33:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 20 Jan 2007 16:33:52 +0000 Subject: [tei-council] , , and In-Reply-To: <17842.15224.28276.20873@emt.wwp.brown.edu> Message-ID: <45B24470.9060207@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 20 Jan 2007 16:33:52 +0000
It's entirely likely that I have not implemented nested attlists
properly. Does gibberish
come out if you try it?
> nd although there are some disadvantages with using Schematron
>(speed problems jump to mind), it does have the advantage of
> providing a check for those who use DTDs.
I thought the argument was that the TEI mainstream can
cope with neither RELAXNG nor Schematron. If there
are people who can't/won't use RELAXNG but can use
Schematron, I am a little surprised. But maybe I misjudged
the mood. Another question for James/Arianna's monkey?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 20 2007 - 11:33:56 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Jan 21 20:44:37 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 22 Jan 2007 10:44:37 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <17841.6678.27216.694302@emt.wwp.brown.edu> Message-ID: <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 22 Jan 2007 10:44:37 +0900
Syd Bauman wrote:
>> Well, if you (all) don't think we have a *commitment* to deliver
>> TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't
>> singing off the same song sheet.
> Yes, we are singing off different sheets. Some may wonder, but I
> think we are singing the same piece of music, at least, just
> different arrangements, to carry the analogy too far.
>
I hope that does not mean you disagree to the above statement. I also
see us firmly committed to have P5 1.0 working smoothly and to
everybodys delight by MM 2007.
Now, I see that we have disagreement about the details, e.g. what is
meant by specs frozen etc. My message indeed intended to get us closer
to understand how we can do what we have committed ourself to do. As
always, the problems may lie in the details. When we said in Kyoto,
"the specs have to be frozen", this was stating the obvious, namely that
we need to have stable specs in P5 in order to release this. However,
the specs are in fact not monolithic, but come in clusters and
individual items, with mutual dependency. While there is still some
last minute surgery going on in some quarters, I think we have to cordon
off some areas now and start to do the clean-up there, although we can't
declare the whole building finished.
>
>> 1st February: accept no more feature requests for 5.0
>
> This has already happened twice, and need not be repeated. Feature
> requests submitted now would almost assuredly *not* be considered for
> the 1.0 releaes of P5. (Sorry, Daniel.)
But we should not get carried away by sticking to the letter of some
protocol. If there are important issues that prevent from
being uses as it is, this is a bug that has to be fixed for 1.0. If we
decided to ask people to file bug reports through the SF feature request
channel (instead of the available bug report channel), we should still
accept them. In my book, the "call for feature requests" is what the
name suggest, namely a request for enhancements or new features in TEI.
It would be silly if we would stop listen to reports on problems that
exist within our existing framework. In fact, since there has been so
much underground change in P5 it seems likely that people will continue
to discover changes, for example in content models that where not
intended but are a result of the way we re-defined classes.

All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jan 21 2007 - 20:45:23 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Jan 21 20:48:42 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 22 Jan 2007 10:48:42 +0900 Subject: PERS meeting (was Re: [tei-council] Budget news, PERS meeting) In-Reply-To: <45B102CB.3050605@pitt.edu> Message-ID: <45B417FA.9020105@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 22 Jan 2007 10:48:42 +0900
David J Birnbaum wrote:
> Dear Christian (cc Council),
>
> No objection.
Thanks to all of you for supporting this. I hereby announce that the
Council encourages Matthew to go ahead with the planning for the Vilnius
meeting within the budget line of (at most) US$ 5000. Please report to
us on the details of the meeting and, in due time on the progress and
outcome. We all wish you a successfull and productive time.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jan 21 2007 - 20:49:27 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Jan 21 21:34:03 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 22 Jan 2007 11:34:03 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <45B08730.40901@oucs.ox.ac.uk> Message-ID: <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 22 Jan 2007 11:34:03 +0900
Sebastian Rahtz wrote:
> Wittern Christian wrote:
>> (1) * chapter review, including review of examples
>> (2) * decision on module dependency architecture made, and if yes
>> implemented
>> (3) * remove instructions on how to invoke TEI DTD from each chapter
>> (4) * New user needs to have an easy way to generate customization
>> ODD and generate schemas
>> (5) * text of prose matches specs
>> (6) * *Specs frozen! :-)
>> (7) * Dictionary rewrite completed
>> (8) * Modification and Conformance chapters rewritten
>>
>> I was wondering where we stand on these issues and how much work needs
>> to be done. Since there is some dependency on this, it seems to me that
>> we should see how much is needed to achieve (6).
> One absolute requirement here is to assess all outstanding bug reports
> and feature
> requests in SF, and deal with them one way or another. If, for example,
> Dan is
> going to raise issues about , that needs a quick agreement.
>
The editors are supposed to take care of the SF requests, we expect
updates on this in our telcon.
> With my I18N hat on, there are now five groups translating
> descriptions of specs with a delivery date of the autumn
> at latest. I am taking it on trust therefore that the specs _are_
> frozen to all intents and purposes.
In an ideal world, the specs would have the approval from the Council
before being handed for translation. I realize that reality has
overtaken us here, but it still is a situation that worries me. Maybe
we need a status flag on the specs that indicates its state ("proposed",
"implemented", "tested", "approved") to track its status?

> The PERS activity will likely need some Specs adding. and dictionaries
> of course.
For P5 as a whole "frozen" should mean the statement "we have all we
need and it looks like we want it" is true for every individual spec.
Whereas for every individual spec itself, it would suffice to be true
for this one spec to be counted as frozen. So in that sense, I think
(hope!) we should be able to say that more tahn 95% of the specs are
frozen.
>> We also need a better way to track the progress -- Maybe we should start
>> a Wiki page for this?
>>
> I did wonder about running trac (http://trac.edgewall.org/) as an aide.
Do you have experience with this? It certainly looks good, but we can't
throw too much ressources on getting this up and running.
>> * infrastructure for examples (LB, SB)
>>
> In my opinion, we have no resources to
> deal with this. I think its a distraction this year.
BUt we still need to be sure that it fits in our overall infrastructure
and leave a place where this can live.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jan 21 2007 - 21:34:55 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Jan 21 21:41:14 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 22 Jan 2007 11:41:14 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <45B0FB80.4000600@oucs.ox.ac.uk> Message-ID: <45B4244A.5030504@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 22 Jan 2007 11:41:14 +0900
Sebastian Rahtz wrote:
> My concern is that we are juggling too many
> balls at the same time, without resources.
If there are things that could be dropped (or postponed) without
affecting the whole, please indicate them.
> We won't get through the "Steps To P5"
> if they all run in parallel, unless someone
> here miraculously takes a 6 month sabbatical
> and devotes themselves to TEI editing full-time.

> So although of course there are circular
> dependencies, let's at least try to clear
> out things in sequence.
The dependencies are mostly on the sequence of handling individual
items, which should not prevent other things from being dealt with.
> In our meetings,
> f2f or telco or email, we tend to have far
> too many varied things on the agenda
> at once....
Very true. The main purpose of the bimonthly telcon is to track the
status of the various work items, which naturally means that there is a
lot. Maybe we should schedule addtional topical meetings that take care
of specific issues? We won't get more time out of a day, but maybe this
makes the handling more efficient?
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jan 21 2007 - 21:42:07 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 22 01:36:19 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 22 Jan 2007 15:36:19 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <1169225712.23841.14.camel@odonned-eng06> Message-ID: <45B45B63.7010108@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 22 Jan 2007 15:36:19 +0900
Dan O'Donnell wrote:
> Obviously it is a fine line: we also can't put out substandard work
> either (not that that's ever been a TEI problem). And the Board and
> several TEI partners seem quite interested in stability after P5 (i.e.
> we should perhaps not move on to P6 right away if P6 means major
> revisioning). Given the nature of what we are up, therefore, to perhaps
> we should define "bug" to mean major conceptual issues with finished
> work as well. What I mean by this is if somebody discovers a major flaw
> in the underlying reasoning--something that would require us to move on
> to P6.
We did debate this to some degree several times, most extensively in
Kyoto last year. There is an obvious requirement to refine the model,
but we also need stability. Further maintenance of P5 would therefore
occur as subsequent (compatible) releases 1.01, 1.1 etc, whereas a major
new overhaul that might break existing stuff would eventually be
developped as P6 -- but this is not on our screen at the moment. In
fact the whole point behind the document prepared by David Birnbaum on
our request (http://www.tei-c.org/Council/tcw09.xml?style=printable) is
to balance these two conflicting objectives and lay down our view of how
we want to deal with them.
>
> I suspect from the above exchange that what we are really looking at is
> agreeing on and formalising what we mean by frozen and what makes
> something frozen: the things Syd mentions as not frozen fit Sebastian's
> definition of frozen. Should process (or project management for the next
> ten months--yikes!) be an agenda item after all? It certainly does seem
> to me that we need to say "x is done--to propose changes, there needs to
> be a serious issue involved."
yes, so let' try to nail this down, by all means. We did occasionally
try to implement deadlines and milestones, but overall this was not very
successful. The major blame lies with the Chair of the Council, but
there are other bottlenecks as well. There is a document "P5 today:
current state of play
"(http://www.tei-c.org/Drafts/edw81.xml?style=printable), which was
intended as a means to give us a handle to see where we are in the
development. This document classifies each chapter into different
categories according to the type and degree of work that needs to be
done. Unfortunately, this has not been updated for 2 years, so it does
not reflect changes since then. Maybe we should start by confirming the
status of each chapter and see how many of them can be declared frozen.
Again, I think this document would also benefit from being moved to an
environment that allows easier updating to reflect the changes made.
This is part of what I would like to discuss under agenda item 3, road
to P5.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 01:37:08 EST
From daniel.odonnell at uleth.ca Mon Jan 22 07:10:15 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 22 Jan 2007 05:10:15 -0700 Subject: [tei-council] skype # Message-ID: <1169467815.4958.0.camel@caedmon>
From: Daniel O'Donnell
Date: Mon, 22 Jan 2007 05:10:15 -0700
Hi guys,
I must have the wrong skype #: +99008275326922
-dan
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 07:10:34 EST
From daniel.odonnell at uleth.ca Mon Jan 22 07:18:50 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 22 Jan 2007 05:18:50 -0700 Subject: [tei-council] Cancel that! Message-ID: <1169468330.4958.6.camel@caedmon>
From: Daniel O'Donnell
Date: Mon, 22 Jan 2007 05:18:50 -0700
Oops. See you all tomorrow. What is the direct skype number for this
conference room, however? I tried skyping in but couldn't figure out
what to dial before the conference room number listed on the agenda.
-dan
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 07:18:53 EST
From lou.burnard at computing-services.oxford.ac.uk Mon Jan 22 10:23:50 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 22 Jan 2007 15:23:50 +0000 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: <45B01681.4080407@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B4D706.40106@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 22 Jan 2007 15:23:50 +0000
Wittern Christian wrote:
>
> 1) Minutes, work items, progress since last meeting:
> http://www.tei-c.org.uk/Council/tcm27.xml?style=printable
> Please look at the action items and report progress here before the
> meeting!
>
I see two actions on me. One is to write a paper on the
model.header.phrase issue, and the other is to write a paper on the
issues surrounding multilingual examples.
I apologise for the fact that I haven't done either! In mitigation, wrt
the first of these, I agree with Syd
(http://lists.village.virginia.edu/pipermail/tei-council/2006/001986.html)
that he should proceed simply to define the class and make sure that it
works as expected: the issues don't really need re-stating. I see this
as continuing the class work we are already committed. We can refine the
details later.
On multilingual exemplification, as Sebastian has already indicated,
there isn't a lot we *need* do at the moment, which is why I haven't
given the matter a lot of thought. I am willing to do so in due course,
when we have a bit more translation activity underway. In particular, I
don't envisage any need to change the ODD system to support multilingual
examples, or to indicate the status of one example wrt others; if we
wanted to add such things, there is plenty of room for s etc.
within In fact, we probably ought to approach the problem at
a broader level by annotating the source of existing examples in a
consistent way.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 10:24:04 EST

From Syd_Bauman at Brown.edu Mon Jan 22 11:18:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 22 Jan 2007 11:18:45 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17844.58341.865396.934650@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 22 Jan 2007 11:18:45 -0500
This date attribute stuff is turning out to be a pain in the neck, so
only a very hasty few issues here:
* On our "commitment":
I probably missed something, then. I thought we were quite careful
at the MM in Victoria *not* to make a full-fledged commitment to
have P5 done by College Park. Especially with the Board and meeting
committees not sure if they want to have a 'P5 release' event in
Taiwan or not, I thought it was deliberate. Besides, Lou has
suggested, and I think he's right, that an additional face-to-face
meeting over chapter review is probably a good idea. That may (or
may not) make it quite difficult to be done with 1.0 by MM2007.
* On "frozen":
Perhaps Sebastian & I are simply using different definitions,
perhaps we completely disagree. Here's my basic take on the deal.
- "frozen" means r/o, and is a drastic step that is taken
immediately before publication
- none of P5 is currently frozen
- much of it is close -- I like the word SR used "gelid"
- I would guess some 95% of or Spec files are gelid, with a bunch
that are due for significant work, including (off the top of my
head) those affected by:
+ changes to dating attrs
+ limited-phrase decisions
+ handling regularization of names
+ handling spans
+ implementation of feature requests
+ whatever we end up doing about postscripts
+ new stuff on "placeography"
+ addition of Schematron rules
+ the div0, div1, div0|div1, or no numbered divs decision
+ potential changes to bibl, biblStruct, biblItem system
- I see that others have different takes on the definition of
"frozen" and such, and I am not at all insisting that we use
mine; but I wanted you to know where I was coming from and my
take on all this
* On feature requests and :
I do not think Daniel's idea is a bug-fix request at all, but a
feature request. I think we've already made two calls for feature
requests with cut-off dates, and we should *not* make a third. That
does not mean we should stop considering user input (e.g., bug
reports like "neither nor is not allowed between
s"), but that we should not be considering new feature
requests (like making
a permissible child of ). I
realize that in some cases there is a fine line between the two,
and room for disagreement, discussion, etc. But that doesn't change
my basic premise.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 11:18:52 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 12:02:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 17:02:14 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <17844.58341.865396.934650@emt.wwp.brown.edu> Message-ID: <45B4EE16.3020006@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 17:02:14 +0000
Syd Bauman wrote:
> I probably missed something, then. I thought we were quite careful
> at the MM in Victoria *not* to make a full-fledged commitment to
> have P5 done by College Park.
Memories obviously vary. I thought we made an absolute
commitment to do this!
> Taiwan or not, I thought it was deliberate. Besides, Lou has
> suggested, and I think he's right, that an additional face-to-face
> meeting over chapter review is probably a good idea. That may (or
> may not) make it quite difficult to be done with 1.0 by MM2007.
>
why can't we have another f2f before November?
> - "frozen" means r/o, and is a drastic step that is taken
> immediately before publication
> - none of P5 is currently frozen
> - much of it is close -- I like the word SR used "gelid"
>
I agree, none of it is yet definitively r/o. Freezing, not frozen
> - I would guess some 95% of or Spec files are gelid, with a bunch
> that are due for significant work, including (off the top of my
> head) those affected by:
> + changes to dating attrs
> + limited-phrase decisions
>
these are in your ball court right now, correct?
> + handling regularization of names
> + handling spans
>
not sure about these
> + whatever we end up doing about postscripts
>
?
> + new stuff on "placeography"
>
aAgreed, thats dependent on rapid work in the Baltic
> + addition of Schematron rules
>
We don't _need_ to add any of these, do we? The facility
is there, we can use, or not, any time
> + the div0, div1, div0|div1, or no numbered divs decision
>
that's in hand, I hope.
> + potential changes to bibl, biblStruct, biblItem system
>
oh lord, isn't that dead yet ???
Anyway, even your list sounds eminently
doable between now and the Council f2f.
Just needs some hard graft.
We just work out a timetable week by week
for which issues to resolve in that week,
and stick to it. It's not rocket science....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 12:02:27 EST
From lou.burnard at computing-services.oxford.ac.uk Mon Jan 22 12:30:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 22 Jan 2007 17:30:03 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4EE16.3020006@oucs.ox.ac.uk> Message-ID: <45B4F49B.6000104@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 22 Jan 2007 17:30:03 +0000
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> I probably missed something, then. I thought we were quite careful
>> at the MM in Victoria *not* to make a full-fledged commitment to
>> have P5 done by College Park.
> Memories obviously vary. I thought we made an absolute
> commitment to do this!
Me too.
>> Taiwan or not, I thought it was deliberate. Besides, Lou has
>> suggested, and I think he's right, that an additional face-to-face
>> meeting over chapter review is probably a good idea. That may (or
>> may not) make it quite difficult to be done with 1.0 by MM2007.
>>
> why can't we have another f2f before November?
I suggested a FTF meeting to review the state of chapters before
publication, yes. It could be any time before November.

In my opinion, the priorities are (still)
- triage of outstanding SF feature requests
- chapter review

The specific items Syd mentions are all things that could be resolved
quite quickly, I think, once we accept that it's more important to have
a finished product than a perfect one.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 12:30:16 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 13:15:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 18:15:15 +0000 Subject: [tei-council] telco details Message-ID: <45B4FF33.8090403@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 18:15:15 +0000
From Skype call +99008278525675
In the US, call 1-712-432-4000
Calling from Europe, call
In Austria: 0820 400 01562
In Belgium: 0703 59 984
In France: 0826 100 266
In Germany 01805 00 7620
In UK: 0870 119 2350
Enter Conference Room Number : 5326922
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 13:15:29 EST
From Syd_Bauman at Brown.edu Mon Jan 22 14:06:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 22 Jan 2007 14:06:53 -0500 Subject: [tei-council] telco details In-Reply-To: <45B4FF33.8090403@oucs.ox.ac.uk> Message-ID: <17845.2893.511611.763191@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 22 Jan 2007 14:06:53 -0500
CW> The Conference Room Number is 5877524
SR> Enter Conference Room Number : 5326922
Which? (Or do we get to choose?)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 14:06:59 EST
From daniel.odonnell at uleth.ca Mon Jan 22 14:39:40 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 12:39:40 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <17844.58341.865396.934650@emt.wwp.brown.edu> Message-ID: <1169494780.26853.14.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 22 Jan 2007 12:39:40 -0700
On Mon, 2007-22-01 at 11:18 -0500, Syd Bauman wrote:
> * On feature requests and :
> I do not think Daniel's idea is a bug-fix request at all, but a
> feature request. I think we've already made two calls for feature
> requests with cut-off dates, and we should *not* make a third. That
> does not mean we should stop considering user input (e.g., bug
> reports like "neither nor is not allowed between
>
s"), but that we should not be considering new feature
> requests (like making
a permissible child of ). I
> realize that in some cases there is a fine line between the two,
> and room for disagreement, discussion, etc. But that doesn't change
> my basic premise.
Happy to be put in my place. I know a couple of other people are
interested in this specific question, so I'll try to talk to them over
the next week about launching a feature request for 1.x.
-dan

>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 14:33:09 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:12:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:12:36 +0000 Subject: [tei-council] telco details In-Reply-To: <17845.2893.511611.763191@emt.wwp.brown.edu> Message-ID: <45B51AB4.6030709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 20:12:36 +0000
Syd Bauman wrote:
> CW> The Conference Room Number is 5877524
> SR> Enter Conference Room Number : 5326922
>
> Which? (Or do we get to choose?)
>
*my room is definitely 5326922*
Christian, did you register another room?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:12:51 EST
From dporter at uky.edu Mon Jan 22 15:15:25 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 22 Jan 2007 15:15:25 -0500 Subject: [tei-council] telco details In-Reply-To: <17845.2893.511611.763191@emt.wwp.brown.edu> Message-ID: <96f3df640701221215v4f3fd5c6ucd662c73668edd0e@mail.gmail.com>
From: Dot Porter
Date: Mon, 22 Jan 2007 15:15:25 -0500
If we use both rooms, will we get twice as much done?
On 1/22/07, Syd Bauman edu> wrote:
> CW> The Conference Room Number is 5877524
> SR> Enter Conference Room Number : 5326922
>
> Which? (Or do we get to choose?)
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:15:30 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:17:02 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:17:02 +0000 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: <45B4D706.40106@computing-services.oxford.ac.uk> Message-ID: <45B51BBE.2030902@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 20:17:02 +0000
Lou Burnard wrote:
>
> On multilingual exemplification, as Sebastian has already indicated,
> there isn't a lot we *need* do at the moment, which is why I haven't
> given the matter a lot of thought. I am willing to do so in due course,
> when we have a bit more translation activity underway.
bear in mind that we have no example translation
scheduled. the target is descriptions for now. The
urgency would be if we needed to change
the ODD spec, and there is no current
indication that we need to do so. There is a need
for some rules about managing examples,
and processes to be scripted, but do we see
a need for different markup?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:17:15 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:46:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:46:49 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B522B9.1080009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 20:46:49 +0000
Christian Wittern wrote:
> While there is still some last minute surgery going on in some
> quarters, I think we have to cordon off some areas now and start to do
> the clean-up there, although we can't
> declare the whole building finished.
it makes initial sense to me to do this by module. Obviously namesdates
still has scaffolding on it, while textstructure probably just needs
some last bits of painting. If we can declare some modules clean,
we can simultaneously check the prose and do any last minute
screen of the specs.
What we *must* have is a clear schedule of affected areas;
that's why finishing the SF work is so important. We don't
want any unexpected change to msdescription popping
up there. If there are 20 or 30 unresolved things, get them
listed, work on them, kill them one by one. Don't let them
get up again.
> In fact, since there has been so much underground change in P5 it
> seems likely that people will continue to discover changes, for
> example in content models that where not intended but are a result of
> the way we re-defined classes.
>
>
Sure, that'll always be true. We can assume a degree of risk
in anything we do.
If I was drawing up a list of risks which would stop the "Finish P5 by
October 1st" project from completing, unexpected bugs with wide impact
found by users would come in relatively low. A bigger risk is dependency
on volunteer or unscheduled labour; the greatest risk is, I would
say, that no-one uses P5 when we are done. If we were a business, that
would knock us dead, it would like no-one buying Windows Vista.
It might amuse you to know that I used the conversion TEI to XML
as my case study for a course on project management some years ago.
Building up these lists of risks and so on was quite illuminating.
Perhaps I should bore you all with a SWOT analysis?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:47:09 EST
From daniel.odonnell at uleth.ca Mon Jan 22 15:53:25 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 13:53:25 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B522B9.1080009@oucs.ox.ac.uk> Message-ID: <1169499205.26853.78.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 22 Jan 2007 13:53:25 -0700
On Mon, 2007-22-01 at 20:46 +0000, Sebastian Rahtz wrote:
> Perhaps I should bore you all with a SWOT analysis?
Would it be a less useful than boring analysis? I'd like to know!
-dan
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:52:58 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:53:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:53:51 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B5245F.5040704@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 20:53:51 +0000
Christian Wittern wrote:
>
> In an ideal world, the specs would have the approval from the Council
> before being handed for translation. I realize that reality has
> overtaken us here, but it still is a situation that worries me. Maybe
> we need a status flag on the specs that indicates its state ("proposed",
> "implemented", "tested", "approved") to track its status?
>
It worries me a little too; but I am also confident that I can work out
for any given spec which of the translations is out of date
at any given time. It isn't completely easy, but doable.
>
>> I did wonder about running trac (http://trac.edgewall.org/) as an aide.
>>
>
> Do you have experience with this? It certainly looks good, but we can't
> throw too much ressources on getting this up and runnin
>
I could justify a bit of work on this (Lou, as part of assessments for
software palette), but there is one flaw - it can't link to the Subversion
on Sourceforge. I *could* set it up to work for 6 months on
its own Subversion, copied from SF, and keep them in sync, but
I am not keen :-} Or we could use it without Subversion.
Is anyone else interested in mechanical assistance like this?
ie taking 50 open issues and managing them in an adhoc
system until they are fixed?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:54:05 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:56:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:56:38 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4244A.5030504@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B52506.4060804@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 20:56:38 +0000
> Maybe we should schedule addtional topical meetings that take care of
> specific issues?
we could try. but it will not work until we have a firm
culture within our group of accepting actions as
firm commitments with deadlines, and sticking
to them. I think I can say truthfully that we are all
fairly bad at meeting our actions :-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 15:56:43 EST
From daniel.odonnell at uleth.ca Mon Jan 22 16:20:13 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 14:20:13 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B5245F.5040704@oucs.ox.ac.uk> Message-ID: <1169500813.2854.8.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 22 Jan 2007 14:20:13 -0700
If there is a culture problem on council--and I'm a terrible
procrastinator as well--then we need to try and change the culture for
the year. It is relatively imperative, as I understand things, that we
get through to P5 1.0 this year.
I've been going through the board minutes and while there is no magic
phrase--"We absolutely must have P5 out this year"--there is a lot of
discussion about the sustainability of the current efforts beyond 2007
(and not much hope that we will be able to). The pressure is external as
well as internal and affect both funding and cooperation with other
agencies, so it is not simply a matter of finding small amounts of extra
money.
In addition, the Board is currently working on a model for the TEI in a
post P5 world with a relatively clear idea that we are talking about
"starting next year."
I wonder if flagging items along the lines proposed here would not be
doable without taking too much time away from actual guidelines work. It
may be a very good practice as we close in on the end--and save us some
time. I'd imagine editorial judgement is required for a final call, but
we might be able to delegate somebody to go through and do a rough
sorting first?
What say?
-dan

On Mon, 2007-22-01 at 20:53 +0000, Sebastian Rahtz wrote:
> Christian Wittern wrote:
> >
> > In an ideal world, the specs would have the approval from the Council
> > before being handed for translation. I realize that reality has
> > overtaken us here, but it still is a situation that worries me. Maybe
> > we need a status flag on the specs that indicates its state ("proposed",
> > "implemented", "tested", "approved") to track its status?
> >
> It worries me a little too; but I am also confident that I can work out
> for any given spec which of the translations is out of date
> at any given time. It isn't completely easy, but doable.
> >
> >> I did wonder about running trac (http://trac.edgewall.org/) as an aide.
> >>
> >
> > Do you have experience with this? It certainly looks good, but we can't
> > throw too much ressources on getting this up and runnin
> >
> I could justify a bit of work on this (Lou, as part of assessments for
> software palette), but there is one flaw - it can't link to the Subversion
> on Sourceforge. I *could* set it up to work for 6 months on
> its own Subversion, copied from SF, and keep them in sync, but
> I am not keen :-} Or we could use it without Subversion.
>
> Is anyone else interested in mechanical assistance like this?
> ie taking 50 open issues and managing them in an adhoc
> system until they are fixed?
>
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 16:19:45 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 16:23:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 21:23:26 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <1169499205.26853.78.camel@odonned-eng06> Message-ID: <45B52B4E.107@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 21:23:26 +0000
Dan O'Donnell wrote:
>
>> Perhaps I should bore you all with a SWOT analysis?
>>
>
> Would it be a less useful than boring analysis? I'd like to know!
>
>
Actually, I think we already did the SWOT in Victoria, in our
Board meeting, informally.
In summary, for the project "P5 by October 1st":
Strengths: makes it look as if the Consortium can deliver stuff;
allows members to start using it; frees resources for other things
Weaknesses: if it isn't polished and consistent it makes us look bad
if we announce it and fail to finish, we look fools;
if we fall behind, morale suffers badly and volunteer
labour drops out
Opportunities: we can take the TEI to a new level of
interoperability if we get the mechanism right
Threats: The editorial work of the TEI is delegated to two people;
if one or both fall behind schedule we have no backup arranged.
The editors can only do their work based on volunteer labour of
others - this may dry up. The Council may reach deadlock in
discussing an issue and fail to resolve it in time.

and so on. Any ideas on mitigating the threats, or
adding to the strengths and opportunities?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 16:23:47 EST

From Syd_Bauman at Brown.edu Mon Jan 22 17:23:37 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 22 Jan 2007 17:23:37 -0500 (EST) Subject: [tei-council] date attributes: summary, problems, and some suggestions Message-ID: <200701222223.l0MMNblR024839@perseus.services.brown.edu>
From: Syd Bauman
Date: Mon, 22 Jan 2007 17:23:37 -0500 (EST)
First, a listing of the attributes that are directly involved with
dating. ("dating" as in "timing", not as in "courtship" :-)

States of Play, P4
------ -- ----- --
calendar=
certainty=
value=

State of Play, P5
----- -- ----- --
att.datePart ( value=, dur= )
att.editLike ( cert= )
att.datable ( notBefore=, notAfter=, from=, to= )
att.typed ( type=, subtype= )
calendar=
precision=

Problems
--------
* Some are distressed by the fact that attributes that are of the
same datatype (data.temporal) and serve similar functions have
different names, in particular:
value= of ,

Choosing one of these requires some thought and discussion. Up front I
can only say that I don't like the 'attribute level' solution. It's
just too confusing for the average user, most of whom have little or
nothing to gain. I.e., to borrow a phrase from Perl, while it does
make the hard things possible, it does not make the easy things easy.
The others all do, presuming we make simple format dates the default
for the class or datatype level.

Notes
-----
[1] Lou is arguing that we drop the element altogether.
Although I'm interested in arguments for keeping it, it's hard to
see what purpose it serves that couldn't be handled equally well
by typed use of ,

From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 17:55:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 22:55:42 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <1169500813.2854.8.camel@odonned-eng06> Message-ID: <45B540EE.6080504@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 22 Jan 2007 22:55:42 +0000
If you want to see what a new low-cost tracking system
looks like, try http://tei.oucs.ox.ac.uk/trac.cgi
your first name and your first name will get you in
(unless I forgot you..., tell me if so)
report errors to me
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 17:55:59 EST
From Conal.Tuohy at vuw.ac.nz Mon Jan 22 19:41:58 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 23 Jan 2007 13:41:58 +1300 Subject: [tei-council] open issues and planning In-Reply-To: <[tei-council] open issues and planning> Message-ID:
From: Conal Tuohy
Date: Tue, 23 Jan 2007 13:41:58 +1300
We use trac internally @ the NZETC, too. It's a very nice tool, and it
has nice integration with Subversion. What (else) does it offer that
sourceforge's system doesn't?
Con
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU
> [mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On
> Behalf Of Sebastian Rahtz
> Sent: Tuesday, 23 January 2007 11:56
> To: daniel.odonnell_at_uleth.ca
> Cc: TEI Council
> Subject: Re: [tei-council] open issues and planning
>
> If you want to see what a new low-cost tracking system
> looks like, try http://tei.oucs.ox.ac.uk/trac.cgi
>
> your first name and your first name will get you in
> (unless I forgot you..., tell me if so)
>
> report errors to me
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 19:42:13 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 22 20:05:24 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 23 Jan 2007 10:05:24 +0900 Subject: Please use this to call in (Re: [tei-council] telco details) In-Reply-To: <45B4FF33.8090403@oucs.ox.ac.uk> Message-ID: <45B55F54.5080006@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 23 Jan 2007 10:05:24 +0900
Sebastian Rahtz wrote:
> From Skype call +99008278525675
> In the US, call 1-712-432-4000
> Calling from Europe, call
> In Austria: 0820 400 01562
> In Belgium: 0703 59 984
> In France: 0826 100 266
> In Germany 01805 00 7620
> In UK: 0870 119 2350
>
> Enter Conference Room Number : 5326922
>
Well, to avoid the confusion of last time, this time I did set up my own
room and announced it in the agenda. However, since your room looks
much nicer (and has already proved usable), I am happy to be your guest
tonight. So the above is the one we expect to use at high noon GMT today.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 20:06:12 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 22 20:26:24 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 23 Jan 2007 10:26:24 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <45B4F49B.6000104@computing-services.oxford.ac.uk> Message-ID: <45B56440.1020209@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 23 Jan 2007 10:26:24 +0900
Lou Burnard wrote:
> Sebastian Rahtz wrote:
>> Syd Bauman wrote:
>>> I probably missed something, then. I thought we were quite careful
>>> at the MM in Victoria *not* to make a full-fledged commitment to
>>> have P5 done by College Park.
>> Memories obviously vary. I thought we made an absolute
>> commitment to do this!
>
> Me too.
You already know my take on this. Sorry, Syd, but this time its for real!
>>>
>> why can't we have another f2f before November?
>
> I suggested a FTF meeting to review the state of chapters before
> publication, yes. It could be any time before November.
>
As you noticed in the budget note, I am already trying to clear the way
for this. Late August might be a good time for this.
>
> In my opinion, the priorities are (still)
>
> - triage of outstanding SF feature requests
That's on the editors plate
> - chapter review
Do you mean "internal review by Council members" or do you want to farm
it out to external reviewers?
> The specific items Syd mentions are all things that could be resolved
> quite quickly, I think, once we accept that it's more important to have
> a finished product than a perfect one.
Well said. The most important thing for me would be to make sure that we
have got the structure right, so that the upper floors can be built,
decorated and populated in due time, without causing the lower courts to
collapse.
The "I18N example infrastructure" for example is such a case where I
think we might not be able to built it right now, but we do not want to
realize that we have to take some supporting walls down to get there
once it's time has come. (And in my view it does in fact have some
urgency since some people now translating might want to hand us some of
their examples for inclusion in the main source pretty soon -- I18N is
one of the major strengths of P5 and we would be foolish to do this
halfheartedly).
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jan 22 2007 - 20:27:12 EST
From Conal.Tuohy at vuw.ac.nz Mon Jan 22 23:58:27 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 23 Jan 2007 17:58:27 +1300 Subject: [tei-council] egXML and namespaces in TEI Message-ID:
From: Conal Tuohy
Date: Tue, 23 Jan 2007 17:58:27 +1300
Can anyone explain the rationale for the guideline on namespaces in
? I am quite confused as to how (or why) it works. Frankly, it
seems wrong to me, but I'm not sure, since I don't grasp its purpose.
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-egXML.html
"The element's contents should be marked as belonging to the namespace
http://www.tei-c.org/ns/Examples if they are to be validated against the
TEI scheme; if the content is well-formed XML from some other namespace,
it must be enclosed in a CDATA marked section. If the content is not
well-formed XML, the more general element should be used in
preference."
How does the use of the http://www.tei-c.org/ns/Examples namespace help
with validation? It seems odd to me to define another namespace (no pun
intended), because the element names in that namespace are (I assume)
the same as those defined in the namespace http://www.tei-c.org/ns/1.0/
Also, why must non-TEI-namespaced examples be quoted in a CDATA section?

I note also that the source ODD files have the egXML elements in the
example namespace, although the note above says to put the egXML
element's CONTENTS in that namespace. For example, if you look at the
definition of catDesc:
http://tei.svn.sourceforge.net/viewvc/*checkout*/tei/trunk/P5/Source/Spe
cs/catDesc.xml
The parent exemplum element is supposed to contain an element called
egXML in the TEI namespace, but instead it contains an element called
egXML in the "TEI example" namespace. I am pretty sure this is an error.
One final thing: the "TEI example" namespace URL
http://www.tei-c.org/ns/Examples produces a 404. It would be nice to
have a document there, perhaps with a link to the documentation for
egXML.
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 22 2007 - 23:58:46 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 04:23:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 09:23:16 +0000 Subject: [tei-council] open issues and planning In-Reply-To: Message-ID: <45B5D404.8010806@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 09:23:16 +0000
Conal Tuohy wrote:
> We use trac internally @ the NZETC, too. It's a very nice tool, and it
> has nice integration with Subversion. What (else) does it offer that
> sourceforge's system doesn't?
>
don't know. I just wanted to look at an internal thing
we could use to fix up the next 9 months.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 04:23:31 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 05:42:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 10:42:46 +0000 Subject: [tei-council] egXML and namespaces in TEI In-Reply-To: Message-ID: <45B5E6A6.2090103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 10:42:46 +0000
Conal Tuohy wrote:
> "The element's contents should be marked as belonging to the namespace
> http://www.tei-c.org/ns/Examples if they are to be validated against the
> TEI scheme; if the content is well-formed XML from some other namespace,
> it must be enclosed in a CDATA marked section. If the content is not
> well-formed XML, the more general element should be used in
> preference."
>
this may need a rewrite. itself
needs to be in the target namespace, otherwise you
cannot just cut and paste stuff into it.
> How does the use of the http://www.tei-c.org/ns/Examples namespace help
> with validation? It seems odd to me to define another namespace (no pun
> intended), because the element names in that namespace are (I assume)
> the same as those defined in the namespace http://www.tei-c.org/ns/1.0/
>
true. /Examples is just a copy of /1.0 - but how
else do we manage it?
> Also, why must non-TEI-namespaced examples be quoted in a CDATA section?
>
they don't have to be in generality.
>
> I note also that the source ODD files have the egXML elements in the
> example namespace, although the note above says to put the egXML
> element's CONTENTS in that namespace. For example, if you look at the
> definition of catDesc:
> http://tei.svn.sourceforge.net/viewvc/*checkout*/tei/trunk/P5/Source/Spe
> cs/catDesc.xml
> The parent exemplum element is supposed to contain an element called
> egXML in the TEI namespace, but instead it contains an element called
> egXML in the "TEI example" namespace. I am pretty sure this is an error.
>
no. itself is in the examples namespace,
for good or bad
> One final thing: the "TEI example" namespace URL
> http://www.tei-c.org/ns/Examples produces a 404. It would be nice to
> have a document there, perhaps with a link to the documentation for
> egXML.
>
true.
I think what's needed is a better description of
is supposed to work. I guess I should write it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 05:42:58 EST
From dporter at uky.edu Tue Jan 23 06:55:25 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 23 Jan 2007 06:55:25 -0500 Subject: Please use this to call in (Re: [tei-council] telco details) In-Reply-To: <45B55F54.5080006@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <96f3df640701230355y470e1eaaub9d892d9ff2d9708@mail.gmail.com>
From: Dot Porter
Date: Tue, 23 Jan 2007 06:55:25 -0500
Christian and Council, I'm running a bit late and will probably call
in about 10 minutes into the meeting. Sorry for the late notice, talk
to you all soon.
Dot
On 1/22/07, Christian Wittern zinbun.kyoto-u.ac.jp> wrote:
> Sebastian Rahtz wrote:
> > From Skype call +99008278525675
> > In the US, call 1-712-432-4000
> > Calling from Europe, call
> > In Austria: 0820 400 01562
> > In Belgium: 0703 59 984
> > In France: 0826 100 266
> > In Germany 01805 00 7620
> > In UK: 0870 119 2350
> >
> > Enter Conference Room Number : 5326922
> >
>
> Well, to avoid the confusion of last time, this time I did set up my own
> room and announced it in the agenda. However, since your room looks
> much nicer (and has already proved usable), I am happy to be your guest
> tonight. So the above is the one we expect to use at high noon GMT today.
> All the best,
>
> Christian
>
>
> --
>
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 06:55:29 EST

From jawalsh at indiana.edu Tue Jan 23 07:51:02 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 23 Jan 2007 07:51:02 -0500 Subject: [tei-council] updated biblItem document Message-ID: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu>
From: John A. Walsh
Date: Tue, 23 Jan 2007 07:51:02 -0500
Hi Council,
I've updated the biblItem document at http://ella.slis.indiana.edu/
~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/~jawalsh/
tei/biblItem.xml) with some ODD, rnc, and instance examples.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 07:51:16 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 08:47:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 13:47:58 +0000 Subject: [tei-council] egXML Message-ID: <45B6120E.5030901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 13:47:58 +0000
I propose that the long description of this be reworded as
follows:

The element itself is in
the namespace type="ns">http://www.tei-c.org/ns/Examples.
The TEI Guidelines use the same namespace for the body of the
example itself, and they are validated against the TEI scheme by the
production process of the TEI. User extensions or other schemas
may this use this
namespace, or any other, for the content of egXML.
The content may also be well-formed enclosed in a CDATA marked
section. If the content is not well-formed XML, the more general
eg element should be used in preference.


Does this upset anyone? I have committed it to SF, but it
can obviously be changed ad lib.
The reason for having in the funny namespace is to allow
us to say

quoth the Raven, neverore

without having to tinker with the element. It
makes the cut and paste a lot easier.
This setup was done some years ago, for what seemed like
good reasons, and it may be that I am just used to it
despite its madness. It is also implemented, which
is a non-trivial issue at this point :-}
However, if anyone (especially Conal, since he is looking
at it) finds this weird, speak up now.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 08:48:11 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 08:52:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 13:52:08 +0000 Subject: [tei-council] content model of body etc Message-ID: <45B61308.4080001@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 13:52:08 +0000
Does anyone care to discuss this further? otherwise I propose that it
be given to Lou and Syd to make an executive decision on in the near
future, and implement if necessary.
This isn't about div vs div0 vs div1 (we are leaving that with James and
Ariana
to consult The Users), but about model class-ing the existing
setup.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 08:52:20 EST
From Syd_Bauman at Brown.edu Tue Jan 23 09:06:50 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 23 Jan 2007 09:06:50 -0500 Subject: [tei-council] content model of body etc In-Reply-To: <45B61308.4080001@oucs.ox.ac.uk> Message-ID: <17846.5754.722320.172317@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 23 Jan 2007 09:06:50 -0500
> Does anyone care to discuss this further?
Yes, I do. I won't get to it today, but will take a careful look Wed
hopefully post by Thu. At first glance missing a few model.glabals,
and has an extra nesting level, but looks good. (Have you tested it w
non-DIV removals? I remember being vaguely suspicious that removing
macro.component would cause non-determinism, but I can't remember
why and I got too embroiled in dates to test it myself.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 23 2007 - 09:06:56 EST
From lou.burnard at computing-services.oxford.ac.uk Tue Jan 23 10:43:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 23 Jan 2007 15:43:49 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17846.5754.722320.172317@emt.wwp.brown.edu> Message-ID: <45B62D35.5090004@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 23 Jan 2007 15:43:49 +0000
Sorry, I answered Senbastian's note before seeing this. Naturally, I am
perfectly happy to wait for you to resolve your vague suspicions. Any
particular Thursday?
Syd Bauman wrote:
>>Does anyone care to discuss this further?
>
>
> Yes, I do. I won't get to it today, but will take a careful look Wed
> hopefully post by Thu. At first glance missing a few model.glabals,
> and has an extra nesting level, but looks good. (Have you tested it w
> non-DIV removals? I remember being vaguely suspicious that removing
> macro.component would cause non-determinism, but I can't remember
> why and I got too embroiled in dates to test it myself.)
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 23 2007 - 09:32:16 EST
From lou.burnard at computing-services.oxford.ac.uk Tue Jan 23 10:53:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 23 Jan 2007 15:53:12 +0000 Subject: [tei-council] egXML In-Reply-To: <45B6120E.5030901@oucs.ox.ac.uk> Message-ID: <45B62F68.10605@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 23 Jan 2007 15:53:12 +0000
Sebastian Rahtz wrote:
> I propose that the long description of this be reworded as
> follows:
>
>
>

The element itself is in
> the namespace
> type="ns">http://www.tei-c.org/ns/Examples.
> The TEI Guidelines use the same namespace for the body of the
> example itself, and they are validated against the TEI scheme by the
> production process of the TEI. User extensions or other schemas
> may this use this
> namespace, or any other, for the content of egXML.
> The content may also be well-formed enclosed in a CDATA marked
> section. If the content is not well-formed XML, the more general
> eg element should be used in preference.


>
>
>
> Does this upset anyone? I have committed it to SF, but it
> can obviously be changed ad lib.
Stylistically I think this is a whole lot worse. Too many "itself"s, and
the referent of "they" is not there. "this use this"????
are intended for particular usage remarks, not "long
description". What Conall requested was a rewrite of the element,
I think.
I will have a hack at it this evening.
>
> The reason for having in the funny namespace is to allow
> us to say
>
>
> quoth the Raven, neverore
>
>
> without having to tinker with the element. It
> makes the cut and paste a lot easier.
>
> This setup was done some years ago, for what seemed like
> good reasons, and it may be that I am just used to it
> despite its madness. It is also implemented, which
> is a non-trivial issue at this point :-}
It seems completely natural to me now...

>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 23 2007 - 09:41:34 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 10:45:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 15:45:46 +0000 Subject: [tei-council] egXML In-Reply-To: <45B62F68.10605@oucs.ox.ac.uk> Message-ID: <45B62DAA.5000907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 15:45:46 +0000
Lou Burnard wrote:
>
> Stylistically I think this is a whole lot worse. Too many "itself"s,
> and the referent of "they" is not there. "this use this"????
>
> are intended for particular usage remarks, not "long
> description". What Conall requested was a rewrite of the
> element, I think.
>
> I will have a hack at it this evening.
yes pliz.
now I know the technique, "rewrite it in rubbish English to
offend Lou's sensibilities and get him to rewrite it",
I'll use it more often.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 10:46:06 EST
From Syd_Bauman at Brown.edu Tue Jan 23 10:49:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 23 Jan 2007 10:49:09 -0500 Subject: [tei-council] content model of body etc In-Reply-To: <45B62D35.5090004@oucs.ox.ac.uk> Message-ID: <17846.11893.21699.492548@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 23 Jan 2007 10:49:09 -0500
> Sorry, I answered Senbastian's note before seeing this. Naturally,
> I am perfectly happy to wait for you to resolve your vague
> suspicions. Any particular Thursday?
Oh, sorry; I had meant this Thu. :-}
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 23 2007 - 10:49:11 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 23 10:55:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 23 Jan 2007 15:55:47 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17846.5754.722320.172317@emt.wwp.brown.edu> Message-ID: <45B63003.5020103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 23 Jan 2007 15:55:47 +0000
Syd Bauman wrote:
>> Does anyone care to discuss this further?
>>
>
> Yes, I do. I won't get to it today, but will take a careful look Wed
> hopefully post by Thu. At first glance missing a few model.glabals,
> and has an extra nesting level, but looks good.
I think that level of thing, really kicking the tires
of the content model, is for you and Lou in private.
What I meant was whether Council need be bothered
by this any more, until the FAND results come back.
> (Have you tested it w
> non-DIV removals? I remember being vaguely suspicious that removing
> macro.component would cause non-determinism,
>
removing macro.component would cause the world
to fall about our ears, I think, so I suggest you don't
try that :-}
I assumed it was almost beyond belief that a customization
would succeed in making macro.component completely empty.
Now that the content model has blown up to be as big
as the original, it might even be easier to re-use the old
one with a simple substitution of classes. The interesting
part was when it was _much_ simpler and relied on Schematron.
Lou, if you want to start on it, there is some work
to do in the names of the new model classes and their
descriptions, which can be tested in testfand.odd.
When you're happy with that, it can be broken out
into *spec files. At the same time, remove Syd's
macro-based attempt to solve the problem.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 10:55:56 EST
From daniel.odonnell at uleth.ca Tue Jan 23 13:47:56 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 23 Jan 2007 11:47:56 -0700 Subject: [tei-council] updated biblItem document In-Reply-To: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> Message-ID: <1169578076.31094.17.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 23 Jan 2007 11:47:56 -0700
John,
The only question I have from your paper is the type attribute on
related item: this seems to me either a place for a fixed set of options
or an area where users will need to be discursive at times: type="other"
for example seems like it doesn't say very much unless it is part of a
defined set of choices ("other" than what?).
Or do you not think that a desire to be discursive will be an issue?
Would a solution be to have a

or some other element right at the top
where the relationship would be specified?
-dan
On Tue, 2007-23-01 at 07:51 -0500, John A. Walsh wrote:
> Hi Council,
>
> I've updated the biblItem document at http://ella.slis.indiana.edu/
> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/~jawalsh/
> tei/biblItem.xml) with some ODD, rnc, and instance examples.
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 13:47:20 EST

From Syd_Bauman at Brown.edu Tue Jan 23 14:37:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 23 Jan 2007 14:37:59 -0500 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up Message-ID: <17846.25623.799043.846750@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 23 Jan 2007 14:37:59 -0500
I have put up on the web a somewhat fast-and-lousy first draft of the
notes from our teleconference this morning. I missed a bit more than
my usual shoddy job this time because of the tennis match. Thus, each
member of Council should read the entire thing -- it's pretty short
-- paying particular attention to items flagged with his or her
initials, the word "all", or the string "[?". Please post any
corrections, omissions, suggestions, etc., either to the list or send
directly to me.
http://www.tei-c.org/Council/tcm28.xml?style=printable
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 23 2007 - 14:38:03 EST
From daniel.odonnell at uleth.ca Tue Jan 23 15:22:57 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 23 Jan 2007 13:22:57 -0700 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up In-Reply-To: <17846.25623.799043.846750@emt.wwp.brown.edu> Message-ID: <1169583777.6517.6.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 23 Jan 2007 13:22:57 -0700
No changes from me.
On Tue, 2007-23-01 at 14:37 -0500, Syd Bauman wrote:
> I have put up on the web a somewhat fast-and-lousy first draft of the
> notes from our teleconference this morning. I missed a bit more than
> my usual shoddy job this time because of the tennis match. Thus, each
> member of Council should read the entire thing -- it's pretty short
> -- paying particular attention to items flagged with his or her
> initials, the word "all", or the string "[?". Please post any
> corrections, omissions, suggestions, etc., either to the list or send
> directly to me.
>
> http://www.tei-c.org/Council/tcm28.xml?style=printable
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 23 2007 - 15:22:22 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Jan 24 07:03:56 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 24 Jan 2007 21:03:56 +0900 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up In-Reply-To: <17846.25623.799043.846750@emt.wwp.brown.edu> Message-ID: <45B74B2C.5000100@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 24 Jan 2007 21:03:56 +0900
Syd Bauman wrote:
> I have put up on the web a somewhat fast-and-lousy first draft of the
> notes from our teleconference this morning.
Thanks, well done. This is a good candidate for the price for the
shortest ever minutes. While this can't be said for the meeting itself,
I think it was pretty productive.
I missed a bit more than
> my usual shoddy job this time because of the tennis match.
Despite the tennis match (and the fact that everybody sounded like
speaking through a watering can) I could understand much more than
usual. For this reason, I am in favor of continuing on
highspeedconferencing.com for the time being (unless, of course, better
options come along).
> Thus, each
> member of Council should read the entire thing -- it's pretty short
> -- paying particular attention to items flagged with his or her
> initials, the word "all", or the string "[?". Please post any
> corrections, omissions, suggestions, etc., either to the list or send
> directly to me.
I skipped some action items, that were obvious to me, for the record:
DO: inform MD how much money is available to Council
[?...?]
he did report and we allocated the moneys.
SR: report on high speed conferences .com system
he did report (maybe only privately to me) and we did carry out a test
conference on Jan 15 -- without a tennis match, but Laurent had a funny
echo.
Here is one item I forgot to bring up:
eds.: update [SF feature request] doc ?
[?...?]
which refers to http://www.tei-c.org/Drafts/edw93.xml?style=printable, I
think. This will come up again in the road-map list.

All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 24 2007 - 07:04:45 EST

From Conal.Tuohy at vuw.ac.nz Wed Jan 24 18:25:43 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 25 Jan 2007 12:25:43 +1300 Subject: [tei-council] egXML In-Reply-To: <[tei-council] egXML> Message-ID:
From: Conal Tuohy
Date: Thu, 25 Jan 2007 12:25:43 +1300
> The reason for having in the funny namespace is to allow
> us to say
>
>
> quoth the Raven, neverore
>
>
> without having to tinker with the element. It
> makes the cut and paste a lot easier.
>
> This setup was done some years ago, for what seemed like
> good reasons, and it may be that I am just used to it
> despite its madness. It is also implemented, which
> is a non-trivial issue at this point :-}
>
> However, if anyone (especially Conal, since he is looking
> at it) finds this weird, speak up now.
I do find it a bit weird, yes.
I see the point about the convenience of declaring the "example"
namespace as the default namespace on the egXML element rather than on
its child, to allow for slightly easier cut-and-paste. That makes sense.
I don't want to quibble about it, especially given that it actually
works - I just want to understand it. What I haven't grasped is why the
"funny" namespace is needed at all. What I mean is, why can't the egXML
element and its content all just be in the regular TEI namespace?
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 24 2007 - 18:25:56 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 24 18:44:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 24 Jan 2007 23:44:32 +0000 Subject: [tei-council] egXML In-Reply-To: Message-ID: <45B7EF60.3060106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 24 Jan 2007 23:44:32 +0000
Conal Tuohy wrote:
> I don't want to quibble about it, especially given that it actually
> works - I just want to understand it. What I haven't grasped is why the
> "funny" namespace is needed at all. What I mean is, why can't the egXML
> element and its content all just be in the regular TEI namespace?
>
>
practically, because it would play merry hell
with validation and processing. A simple
thing like for processing
will meet the inside the examples. It
may sound lazy, but when we set this up
I couldnt see any other way forward. Its trying
to make it very clear that this is an island
of oddity where normal rules do not apply.
Maybe we were being short-sighted? does
anyone else remember?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 24 2007 - 18:44:45 EST
From Conal.Tuohy at vuw.ac.nz Wed Jan 24 19:18:34 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 25 Jan 2007 13:18:34 +1300 Subject: [tei-council] egXML In-Reply-To: <[tei-council] egXML> Message-ID:
From: Conal Tuohy
Date: Thu, 25 Jan 2007 13:18:34 +1300
> Conal Tuohy wrote:
> > I don't want to quibble about it, especially given that it actually
> > works - I just want to understand it. What I haven't
> grasped is why the
> > "funny" namespace is needed at all. What I mean is, why
> can't the egXML
> > element and its content all just be in the regular TEI namespace?
> >
> >
> practically, because it would play merry hell
> with validation and processing. A simple
> thing like for processing
> will meet the inside the examples. It
> may sound lazy, but when we set this up
> I couldnt see any other way forward. Its trying
> to make it very clear that this is an island
> of oddity where normal rules do not apply.
Hmmm ... I see what you mean. Otherwise you would need to complicate any
such expression like so:

So that makes sense.
What still concerns me a little though is that the ODD language itself
has been slightly weirded in order to gain this simplicity in
processing. Personally I think it'd be better if ODD were simpler, even
at the expense of some extra processing, either by complicating various
XPath expressions (as above), or else by introducing a processing stage
to "denormalise" the ODD before regular processing. e.g. something like:

version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tei="http://www.tei-c.org/ns/1.0/"
xmlns="http://www.tei-c.org/ns/Examples">

name="local-name()"
namespace="http://www.tei-c.org/ns/Examples">









WDYT?
But this is a distraction really ... I understand the point of the
"example" namespace so I will shut up now :-)
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 24 2007 - 19:18:47 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 25 02:40:33 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 25 Jan 2007 16:40:33 +0900 Subject: [tei-council] Proceedings of the TEI Day in Kyoto Message-ID: <45B85EF1.2020500@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Thu, 25 Jan 2007 16:40:33 +0900
Dear Council members, dear Susan, MattZ and Amit,
I now have, finally, the printed copies of the TEI Day 2006 proceedings
in hand.
I would like to send a copy to the contributors, participants and also
to other interested members of the Council. If you are interested,
please send me your shipping adress (not to the list, but to me
personally) so that I can arrange the necessary. There is also a PDF
file for download, which I will announce on TEI-L soon.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jan 25 2007 - 02:41:09 EST

From Syd_Bauman at Brown.edu Fri Jan 26 00:18:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 26 Jan 2007 00:18:56 -0500 Subject: [tei-council] content model of body etc In-Reply-To: <45B63003.5020103@oucs.ox.ac.uk> Message-ID: <17849.36672.912461.821023@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 26 Jan 2007 00:18:56 -0500
OK. Looked a little more carefully at Sebastian's testfand model. As
I said before, looks good. But it permits to occur *before*
model.divWrapper stuff at the top, and does not permit model.global
at the end. Besides, while that first group is pretty simple in what
it does, it has a needlessly complicated structure (and a false
comment -- there is no interleaving).

> removing macro.component would cause the world to fall about our
> ears, I think, so I suggest you don't try that :-}
Yup. I had forgotten (or never realized :-) that model.oddStuff was
in macro.component, so the use-case that floated through my head
(getting rid of

s and allowing only <*Spec> in of an ODD)
is totally bogus. Sorry, false alarm.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 26 2007 - 00:19:03 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 26 02:54:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 26 Jan 2007 07:54:38 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17849.36672.912461.821023@emt.wwp.brown.edu> Message-ID: <45B9B3BE.9050200@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 26 Jan 2007 07:54:38 +0000
Syd Bauman wrote:
> OK. Looked a little more carefully at Sebastian's testfand model. As
> I said before, looks good. But it permits to occur *before*
> model.divWrapper stuff at the top
is that bad?
> and does not permit model.global
> at the end.
no, because it comes in each of the preceding ones.
can you make a test file to demonstrate something
that fails?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jan 26 2007 - 02:54:51 EST
From Syd_Bauman at Brown.edu Fri Jan 26 07:48:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 26 Jan 2007 07:48:38 -0500 Subject: [tei-council] content model of body etc In-Reply-To: <45B9B3BE.9050200@oucs.ox.ac.uk> Message-ID: <17849.63654.420850.730026@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 26 Jan 2007 07:48:38 -0500
Hasty reply, gotta get the kids on the bus ...

> > ... permits to occur *before* model.divWrapper stuff at
> > the top
> is that bad?
Yes. Defeats the purpose of model.divWrapper, which is to come before
the div-type-stuff, of which is one.

> > and does not permit model.global at the end.
> no, because it comes in each of the preceding ones.
So if after the or in my copy of the source text
there is something obliterated by a big coffee stain, I can't use
to encode that? I have to pretend there is something after it?

> can you make a test file to demonstrate something that fails?
Yes; if you haven't already got yourself one by the time I get back
...

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jan 26 2007 - 07:48:43 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 27 06:10:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 27 Jan 2007 11:10:29 +0000 Subject: [tei-council] [Fwd: creating a div.like element] Message-ID: <45BB3325.9060700@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 27 Jan 2007 11:10:29 +0000
Here's a reminder, from a relatively sophisticated TEI-er,
as to why that content model for is a barrier
to normal TEI extension processes.
ebastian
-------- Original Message --------
Subject: creating a div.like element
Date: Fri, 26 Jan 2007 15:09:37 +0000
From: Elena Pierazzo ac.uk>
To: Sebastian Rahtz ox.ac.uk>

Hi Sebastian,

I'm trying to create an element called "bound" that should represent a
semantic sugar for

.
I'm having many problems to do it as I'm unable to locate the model in
which to include it and even which content model to give it. I've tried
with macro.bodyPart.div but it seems that inside the bound I've to
provide a
element... Can you help me please?
-- Elena Pierazzo Associate Researcher Centre for Computing in the Humanities King's College London Kay House 7 Arundel St London WC2R 3DX Phone: 0207-848-1949 Fax: 0207-848-2980 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 27 2007 - 06:10:59 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 27 06:15:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 27 Jan 2007 11:15:35 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17849.63654.420850.730026@emt.wwp.brown.edu> Message-ID: <45BB3457.5000205@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 27 Jan 2007 11:15:35 +0000
Syd Bauman wrote:
> Yes. Defeats the purpose of model.divWrapper, which is to come before
> the div-type-stuff, of which is one.
>
I'll look at that.
> So if after the or in my copy of the source text
> there is something obliterated by a big coffee stain, I can't use
> to encode that? I have to pretend there is something after it?
>
>
you may or may not be surprised to hear that this is
not allowed in the current model either, which ends





needs some more jiggery-pokery.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 27 2007 - 06:15:53 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 27 08:09:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 27 Jan 2007 13:09:21 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17849.63654.420850.730026@emt.wwp.brown.edu> Message-ID: <45BB4F01.90906@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 27 Jan 2007 13:09:21 +0000
If you don't have a headache yet today, read on. I can help you get one...
I have rewritten the body content model as below, to explicitly
model the sequence of
1. global stuff
2. divWrapper; if one occurs, it can be followed by more of itself
interspersed with globals
3. divGen; if one occurs, it can be followed by more of itself
interspersed with globals
4. div*Like things; if one occurs, it can be followed by more of
itself interspersed with globals and divGens
(but you have to choose between divLike, divN1Like and divN0Like
routes and there is no
going back)
4a. or maybe some paragraph-like things.
5. divWrapper; if one occurs, it can be followed by more of itself
interspersed with globals
Which I _believe_ is what we intend. The crucial thing here is that any
stage can end in globals, but not
start with them. This, with the starting globals, allows the beasts to
appear anywhere, so
far as I can tell.































































































































































-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 27 2007 - 09:37:43 EST

From laurent.romary at loria.fr Sat Jan 27 11:30:11 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 27 Jan 2007 17:30:11 +0100 Subject: [tei-council] updated biblItem document In-Reply-To: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> Message-ID:
From: Laurent Romary
Date: Sat, 27 Jan 2007 17:30:11 +0100
Bonjour,
Having gone through John's note, I am close to be convinced by
.
Could we imagine (and have examples thereof) linking micro-components
of ?, like:



The Garden of Proserpine
Swinburne, Algernon Charles







The Poems of Algernon Charles Swinburne

London
Chatto

1
169-172

6 vols.



I guess this is part of the intedended mechanism, isn't it?
Best,
Laurent
PS: to Seb: that was not a real headache, but I deeply think we
should take some strong decisions to simplify the model (div*...)

Le 23 janv. 07 ? 13:51, John A. Walsh a ?crit :
> Hi Council,
>
> I've updated the biblItem document at http://ella.slis.indiana.edu/
> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/
> ~jawalsh/tei/biblItem.xml) with some ODD, rnc, and instance examples.
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 27 2007 - 11:31:37 EST

From laurent.romary at loria.fr Sat Jan 27 11:31:42 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 27 Jan 2007 17:31:42 +0100 Subject: [tei-council] updated biblItem document In-Reply-To: <1169578076.31094.17.camel@odonned-eng06> Message-ID:
From: Laurent Romary
Date: Sat, 27 Jan 2007 17:31:42 +0100
Yes, a

or a could do the trick. I would support this.
Best,
Laurent
Le 23 janv. 07 ? 19:47, Dan O'Donnell a ?crit :
> John,
>
> The only question I have from your paper is the type attribute on
> related item: this seems to me either a place for a fixed set of
> options
> or an area where users will need to be discursive at times:
> type="other"
> for example seems like it doesn't say very much unless it is part of a
> defined set of choices ("other" than what?).
>
> Or do you not think that a desire to be discursive will be an issue?
>
> Would a solution be to have a

or some other element right at
> the top
> where the relationship would be specified?
>
> -dan
>
> On Tue, 2007-23-01 at 07:51 -0500, John A. Walsh wrote:
>> Hi Council,
>>
>> I've updated the biblItem document at http://ella.slis.indiana.edu/
>> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/
>> ~jawalsh/
>> tei/biblItem.xml) with some ODD, rnc, and instance examples.
>>
>> John
>> --
>> | John A. Walsh
>> | Assistant Professor, School of Library and Information Science
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | www:
>> | Voice:812-856-0707 Fax:812-856-2062 edu>
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> --
> Daniel Paul O'Donnell, PhD
> Chair, Text Encoding Initiative
> Director, Digital Medievalist Project
> www.digitalmedievalist.org/>
> Associate Professor and Chair of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox: +1 403 329 2378
> Fax: +1 403 382-7191
> Homepage: http://people.uleth.ca/~daniel.odonnell/
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jan 27 2007 - 11:32:51 EST

From jawalsh at indiana.edu Sat Jan 27 13:42:41 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Sat, 27 Jan 2007 13:42:41 -0500 Subject: [tei-council] updated biblItem document In-Reply-To: <1169578076.31094.17.camel@odonned-eng06> Message-ID: <04CA87AB-CB50-4910-9B4B-06E4C7494F66@indiana.edu>
From: John A. Walsh
Date: Sat, 27 Jan 2007 13:42:41 -0500
Dan,
I shouldn't have used type="other" in my example. It's confusing. I
was imagining the type attribute on relatedItem being populated with
a fixed or user-defined list. MODS (metadata object description
schema; http://www.loc.gov/standards/mods/) has a relatedItem element
with a type attribute, with enumerated values of: preceding,
succeeding, original, host, constituent, series, otherVersion,
otherFormat, isReferencedBy). We could come up with a fixed list or
suggested values.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> On Jan 23, 2007, at 1:47 PM, Dan O'Donnell wrote: > John, > > The only question I have from your paper is the type attribute on > related item: this seems to me either a place for a fixed set of > options > or an area where users will need to be discursive at times: > type="other" > for example seems like it doesn't say very much unless it is part of a > defined set of choices ("other" than what?). > > Or do you not think that a desire to be discursive will be an issue? > > Would a solution be to have a

or some other element right at > the top > where the relationship would be specified? > > -dan > > On Tue, 2007-23-01 at 07:51 -0500, John A. Walsh wrote: >> Hi Council, >> >> I've updated the biblItem document at http://ella.slis.indiana.edu/ >> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/ >> ~jawalsh/ >> tei/biblItem.xml) with some ODD, rnc, and instance examples. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: >> | Voice:812-856-0707 Fax:812-856-2062 edu> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council_at_lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- > Daniel Paul O'Donnell, PhD > Chair, Text Encoding Initiative > Director, Digital Medievalist Project www.digitalmedievalist.org/> > Associate Professor and Chair of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox: +1 403 329 2378 > Fax: +1 403 382-7191 > Homepage: http://people.uleth.ca/~daniel.odonnell/ > _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 27 2007 - 13:42:51 EST

From Syd_Bauman at Brown.edu Sat Jan 27 20:15:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 27 Jan 2007 20:15:24 -0500 Subject: [tei-council] [Fwd: creating a div.like element] In-Reply-To: <45BB3325.9060700@oucs.ox.ac.uk> Message-ID: <17851.63788.141020.628282@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 27 Jan 2007 20:15:24 -0500
> Here's a reminder, from a relatively sophisticated TEI-er, as to
> why that content model for is a barrier to normal TEI
> extension processes.
Indeed, but keep in mind that this particular request demonstrates
only that
should be in a model class.[1] We were all agreed to
this back at the Oxford class meeting in 2005-09, I believe, but it
has not been implemented for a variety of reasons.
Note
---- [1] Alright, not entirely true ... it also demonstrates that it is not a good idea to leave unused specifications lying around in the source tree. _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jan 27 2007 - 20:15:28 EST
From Syd_Bauman at Brown.edu Mon Jan 29 16:11:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 29 Jan 2007 16:11:52 -0500 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up In-Reply-To: <45B74B2C.5000100@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17854.25368.513779.788414@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 29 Jan 2007 16:11:52 -0500
> I skipped some action items, that were obvious to me, for the
> record:
I figured that, but didn't want to be presumptuous.

> DO: inform MD how much money is available to Council
> [?...?]
> he did report and we allocated the moneys.
I've rewritten this; CW & DO (at least) should check this section to
see if I've got it right.

> SR: report on high speed conferences .com system
> he did report (maybe only privately to me) and we did carry out a
> test conference on Jan 15 -- without a tennis match, but Laurent
> had a funny echo.
SR has already updated this section.

> Here is one item I forgot to bring up:
> eds.: update [SF feature request] doc ?
> [?...?]
> which refers to
> http://www.tei-c.org/Drafts/edw93.xml?style=printable, I think.
> This will come up again in the road-map list.
So noted.

I've also fixed a missing URL.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jan 29 2007 - 16:11:56 EST

From James.Cummings at oucs.ox.ac.uk Tue Jan 30 09:53:50 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 30 Jan 2007 14:53:50 +0000 Subject: [tei-council] TEI Numbered Divs Survey Message-ID: <45BF5BFE.3050200@oucs.ox.ac.uk>
From: James Cummings
Date: Tue, 30 Jan 2007 14:53:50 +0000
Very briefly for council's approval I have set up a TEI Numbered Divs survey on
surveymonkey.com This will allow for 100 responses.
The survey is available at:
http://www.surveymonkey.com/s.asp?u=82203219378
and I have discussed the implications of some of the questions and the phrasings
of their answers with Sebastian and Arianna.
Question #4 may seem a little out in left-field but I intend to use it as a
sanity check. (i.e. if lots of people think we should be able to mix numbered
div content with generic divs, then maybe we shouldn't take the survey results
too seriously.)
I'll take any suggestions for changes anyone has until I post a message about it
on TEI-L in the next day or so. Let me know if there are any major typos or
questions I've forgotten.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 09:54:02 EST
From Syd_Bauman at Brown.edu Tue Jan 30 10:38:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 30 Jan 2007 10:38:25 -0500 Subject: [tei-council] time & date model classes: lump 'em? Message-ID: <17855.26225.658719.629980@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 30 Jan 2007 10:38:25 -0500
Since we've removed <(date|time)(Range|Struct)>, we have some leaner
classes.
- The class model.dateLike has one member, .
- The class model.timeLike has one member,
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 30 10:42:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 30 Jan 2007 15:42:33 +0000 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17855.26225.658719.629980@emt.wwp.brown.edu> Message-ID: <45BF6769.4030108@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 30 Jan 2007 15:42:33 +0000
I'd go for the single class. The distinction seems to get increasingly
blurred these days,
and simplification seems good.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 10:42:46 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 30 10:44:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 30 Jan 2007 15:44:10 +0000 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17855.26225.658719.629980@emt.wwp.brown.edu> Message-ID: <45BF67CA.9030402@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 30 Jan 2007 15:44:10 +0000
PS
> Combining them makes the TEI class system 1 quantum less complicated,
> with only the smallest disadvantage in vanilla schemas (
> gets
unequivocally, yes, I'd say...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 10:44:22 EST
From djbpitt+tei at pitt.edu Tue Jan 30 10:49:36 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 30 Jan 2007 10:49:36 -0500 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17855.26225.658719.629980@emt.wwp.brown.edu> Message-ID: <45BF6910.9030603@pitt.edu>
From: David J Birnbaum
Date: Tue, 30 Jan 2007 10:49:36 -0500
Dear Council,
Lump.
Best,
David
Syd Bauman wrote:
> Since we've removed <(date|time)(Range|Struct)>, we have some leaner
> classes.
>
> - The class model.dateLike has one member, .
> - The class model.timeLike has one member,
> - Everywhere one of these model classes is used, so is the other,
> with the one exception of model.recordingPart, which contains only
> model.dateLike, and which itself is only used as the content of
> .
>
> So the question is whether to leave things as they are, with 2 model
> classes with 1 member each, or combine them into 1 model class with 2
> members.
>
> Combining them makes the TEI class system 1 quantum less complicated,
> with only the smallest disadvantage in vanilla schemas (
> gets
> However, leaving 2 classes gives users more flexibility with their
> customizations.
>
> Thoughts?
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 10:49:41 EST
From James.Cummings at computing-services.oxford.ac.uk Tue Jan 30 12:28:15 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 30 Jan 2007 17:28:15 +0000 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17855.26225.658719.629980@emt.wwp.brown.edu> Message-ID: <45BF802F.50208@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 30 Jan 2007 17:28:15 +0000
Syd Bauman wrote:
>
> Combining them makes the TEI class system 1 quantum less complicated,
> with only the smallest disadvantage in vanilla schemas (
> gets
> However, leaving 2 classes gives users more flexibility with their
> customizations.
>
> Thoughts?

I'd argue that time as a child of recording is not a bad idea.
But then I'd be tempted to say get rid of

From Syd_Bauman at Brown.edu Tue Jan 30 12:30:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 30 Jan 2007 12:30:58 -0500 (EST) Subject: [tei-council] limited phrase, take 2 In-Reply-To: <17525.9575.141607.227353@emt.wwp.brown.edu> Message-ID: <200701301730.l0UHUwIf020543@draco.services.brown.edu>
From: Syd Bauman
Date: Tue, 30 Jan 2007 12:30:58 -0500 (EST)
>From a user perspective, the goal of the limited phrase project is to
have a smaller content model for lots of elements -- getting rid of
things like having as a child of .
But from a class-management perspective, how to do this is an
interesting question. As I started setting up a list of model classes
that would need to be changed to implement limited phrases, it
occured to me that perhaps we weren't dividing them up at the right
level of abstraction.
The current proposal boils down to the idea that model.phrase would
remain pretty much as it is -- an amalgamation of subclasses
(although some of those subclasses would be jiggled around a bit),
and a new class, call it 'model.limitedPhrase', would be created that
has as members only a subset of the same amalgamation of subclasses
that belong to model.phrase. (The current proposal is the original
proposal of some months ago modified a bit to take into account the
conversation that followed. This is what Council asked me to
implement on the last con-call.)
But alternatively, we could divide model.phrase into two main
branches: one that is the limited phrase set, and the rest. I.e.,
divide model.phrase at the top level, and use the "limited" subclass
(here called model.phrase.originated -- feel free to suggest a better
name) in contexts where a limited phrase content model is desired.
Here are the details of:
- what we have now
- the current proposal
- a division of model.phrase into 2 main subclasses
Does anyone have reasons why one of these proposals is better than
the other? (BTW, don't get caught up in the names I've come up with
-- in fact, feel free to recommend better ones!)

--------- what we have now ---------
model.phrase =
model.graphicLike = binaryObject eg egXML formula graphic
model.hiLike = distinct emph foreign gloss hi mentioned soCalled term title
model.lPart = caesura rhyme
model.oddPhr = att code gi ident specDesc specList tag val
model.pPart.data = address
model.dateLike = date
model.measureLike = measure num
model.nameLike = geogName lang placeName rs
model.nameLike.agent = name orgName persName
model.timeLike = time
model.pPart.edit = abbr add app choice corr damage del expan orig
reg restore sic space supplied unclear
model.pPart.msdesc = catchwords dimensions handShift heraldry locus
material origDate origPlace secFol signatures watermark
model.ptrLike = ptr ref
model.ptrLike.form = oRef oVar pRef pVar
model.segLike = c cl m phr s seg w

--------- current proposal ---------
model.phrase =
model.graphicLike = binaryObject formula graphic
model.egLike = eg egXML
model.hilighted =
model.hiLike = hi
model.emphLike = distinct emph foreign gloss mentioned soCalled term title code ident
model.lPart = caesura rhyme
model.specDescLike = specDesc specList
model.xmlPhrase = att gi tag val
model.pPart.data = address
model.dateLike = date
model.measureLike = measure num
model.nameLike = geogName lang placeName rs
model.nameLike.agent = name orgName persName
model.timeLike = time
model.pPart.edit =
model.pPart.editorial = abbr choice expan
model.pPart.transcribe = add app corr damage del orig reg restore sic space supplied unclear
model.pPart.msdesc = catchwords dimensions handShift heraldry locus
material origDate origPlace secFol signatures watermark
model.ptrLike = ptr ref
model.ptrLike.form = oRef oVar pRef pVar
model.segLike = c cl m phr s seg w
model.limitedPhrase =
model.egLike = eg egXML
model.xmlPhrase = att gi tag val
model.pPart.data = address
model.dateLike = date
model.measureLike = measure num
model.nameLike = geogName lang placeName rs
model.nameLike.agent = name orgName persName
model.timeLike = time
model.pPart.msdesc = catchwords dimensions handShift heraldry locus
material origDate origPlace secFol signatures watermark
model.ptrLike = ptr ref
model.emphLike = distinct emph foreign gloss mentioned soCalled term title code ident
model.pPart.editorial = abbr choice expan

--------- complete re-arrangement ---------
model.phrase =
model.phrase.transcribe =
model.egLike = eg egXML
model.pPart.transcribe = add damage del restore space unclear
model.pPart.editorial = abbr expan sic
model.hiLike = hi
model.lPart = caesura rhyme
model.ptrLike.form = oRef oVar pRef pVar
model.segLike = c cl m phr s seg w
model.phrase.originate =
model.graphicLike = binaryObject formula graphic
model.pPart.originate = corr orig reg supplied
model.emphLike = distinct emph foreign gloss mentioned soCalled term title code ident
model.xmlPhrase = att gi tag val
model.specDescLike = specDesc specList
model.pPart.data = address
model.dateLike = date
model.measureLike = measure num
model.nameLike = geogName lang placeName rs
model.nameLike.agent = name orgName persName
model.timeLike = time
model.pPart.msdesc = catchwords dimensions handShift heraldry locus
material origDate origPlace secFol signatures watermark
model.ptrLike = ptr ref
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 12:31:00 EST

From daniel.odonnell at uleth.ca Tue Jan 30 13:11:24 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 30 Jan 2007 11:11:24 -0700 Subject: [tei-council] TEI Numbered Divs Survey In-Reply-To: <45BF5BFE.3050200@oucs.ox.ac.uk> Message-ID: <1170180684.6672.58.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 30 Jan 2007 11:11:24 -0700
None from me.
On Tue, 2007-30-01 at 14:53 +0000, James Cummings wrote:
> Very briefly for council's approval I have set up a TEI Numbered Divs survey on
> surveymonkey.com This will allow for 100 responses.
>
> The survey is available at:
> http://www.surveymonkey.com/s.asp?u=82203219378
>
> and I have discussed the implications of some of the questions and the phrasings
> of their answers with Sebastian and Arianna.
>
> Question #4 may seem a little out in left-field but I intend to use it as a
> sanity check. (i.e. if lots of people think we should be able to mix numbered
> div content with generic divs, then maybe we shouldn't take the survey results
> too seriously.)
>
> I'll take any suggestions for changes anyone has until I post a message about it
> on TEI-L in the next day or so. Let me know if there are any major typos or
> questions I've forgotten.
>
> -James
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 13:10:00 EST
From daniel.odonnell at uleth.ca Tue Jan 30 13:18:50 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 30 Jan 2007 11:18:50 -0700 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up In-Reply-To: <17854.25368.513779.788414@emt.wwp.brown.edu> Message-ID: <1170181130.6672.72.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 30 Jan 2007 11:18:50 -0700
On Mon, 2007-29-01 at 16:11 -0500, Syd Bauman wrote:
> > DO: inform MD how much money is available to Council
> > [?...?]
> > he did report and we allocated the moneys.
>
> I've rewritten this; CW & DO (at least) should check this section to
> see if I've got it right.
There's a typo or two, but otherwise it agrees with what I remember.
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 13:17:26 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 30 13:37:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 30 Jan 2007 18:37:10 +0000 Subject: [tei-council] limited phrase, take 2 In-Reply-To: <200701301730.l0UHUwIf020543@draco.services.brown.edu> Message-ID: <45BF9056.6040303@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 30 Jan 2007 18:37:10 +0000
I find the "original proposal" easier to understand,
to be honest. Perhaps I am confused because the
other proposal makes different decisions? eg
re "corr orig reg supplied"? are they supposed
to have the same affect, or have you deliberately
moved some elements around?
But the "new proposal" doesn't seem impossible,
if you really feel its more elegant.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 13:37:28 EST
From lou.burnard at computing-services.oxford.ac.uk Tue Jan 30 16:21:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 30 Jan 2007 21:21:51 +0000 (GMT) Subject: [tei-council] limited phrase, take 2 In-Reply-To: <200701301730.l0UHUwIf020543@draco.services.brown.edu> Message-ID:
From: Lou Burnard
Date: Tue, 30 Jan 2007 21:21:51 +0000 (GMT)
I think I prefer the second of your proposals (i.e. make
model.limited.phrase a superset of existing low level model classes), for
the following reasons
a) it's what we originally decided to do
b) it makes it a little easier for users to decide for themselves what
does into model.limited.phrase: because it works with the existing model
definitions, it's a bit easier to say "I want that kind of thing in my
header too" (or not)
c) it avoids having to rethink all the existing class assignations
Reasons (a) and (c) are purely pragmatic of course and largely conditioned
by the desire to get P5 out sooner rather than later.
Another (third) option, if we do want to reopen this can of worms though,
might be to define a new macro "anorexicPhraseSequence".
Let's remind ourselves of a use case for this. I am (currently) rather
obsessed by the BNC, so forgive me for harping on about that. I want to
be able to say that the

s in my corpus headers have a content model
which is a specific subset of the

s in my corpus texts (only PCDATA,
not PCDATA or , for example). How would each of these proposals help me
with that problem?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 16:22:04 EST

From lou.burnard at computing-services.oxford.ac.uk Tue Jan 30 16:23:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 30 Jan 2007 21:23:03 +0000 (GMT) Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17855.26225.658719.629980@emt.wwp.brown.edu> Message-ID:
From: Lou Burnard
Date: Tue, 30 Jan 2007 21:23:03 +0000 (GMT)
On Tue, 30 Jan 2007, Syd Bauman wrote:
>
> Combining them makes the TEI class system 1 quantum less complicated,
> with only the smallest disadvantage in vanilla schemas (
> gets
> However, leaving 2 classes gives users more flexibility with their
> customizations.
>
> Thoughts?
>

Let them be lumpen.
dates and times is the same anyway, aint they?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 16:23:16 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 30 16:48:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 30 Jan 2007 21:48:26 +0000 Subject: [tei-council] limited phrase, take 2 In-Reply-To: Message-ID: <45BFBD2A.7090900@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 30 Jan 2007 21:48:26 +0000
Lou Burnard wrote:
> I think I prefer the second of your proposals (i.e. make
> model.limited.phrase a superset of existing low level model classes),
can you look again, Lou and check thus? model.limited.phrase is in the
_first_
of Syd's proposals, surely?
>
> Reasons (a) and (c) are purely pragmatic of course and largely
> conditioned by the desire to get P5 out sooner rather than later.
+1
>
> Another (third) option, if we do want to reopen this can of worms
> though, might be to define a new macro "anorexicPhraseSequence".
>
> Let's remind ourselves of a use case for this. I am (currently) rather
> obsessed by the BNC, so forgive me for harping on about that. I want
> to be able to say that the

s in my corpus headers have a content
> model which is a specific subset of the

s in my corpus texts (only
> PCDATA, not PCDATA or , for example). How would each of these
> proposals help me with that problem?
not at all. but was it supposed to?
this is what god gave you Schematron for, though people are
amazing reluctant to make use of it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 16:48:34 EST

From lou.burnard at computing-services.oxford.ac.uk Tue Jan 30 16:50:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 30 Jan 2007 21:50:30 +0000 (GMT) Subject: [tei-council] limited phrase, take 2 In-Reply-To: <45BFBD2A.7090900@oucs.ox.ac.uk> Message-ID:
From: Lou Burnard
Date: Tue, 30 Jan 2007 21:50:30 +0000 (GMT)
On Tue, 30 Jan 2007, Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> I think I prefer the second of your proposals (i.e. make
>> model.limited.phrase a superset of existing low level model classes),
> can you look again, Lou and check thus? model.limited.phrase is in the
> _first_
> of Syd's proposals, surely?
>
Sorry, I meant the second of the things discussed in his message, of
course. The first one was the status quo. So yes, you're right.
It's been a long day, and mostly on trains.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 16:50:34 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Jan 30 18:09:22 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 31 Jan 2007 08:09:22 +0900 Subject: [tei-council] TEI Numbered Divs Survey In-Reply-To: <45BF5BFE.3050200@oucs.ox.ac.uk> Message-ID: <45BFD022.9090408@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 31 Jan 2007 08:09:22 +0900
James Cummings wrote:
> Very briefly for council's approval I have set up a TEI Numbered Divs survey on
> surveymonkey.com This will allow for 100 responses.
>
> The survey is available at:
> http://www.surveymonkey.com/s.asp?u=82203219378
>
> I'll take any suggestions for changes anyone has until I post a message about it
> on TEI-L in the next day or so. Let me know if there are any major typos or
> questions I've forgotten.
I think we should say loudly, that we will not simply count the numbers
and proceed by majority, but rather want to take account as much needs
as possible, while keeping the whole thing as easy as possible.
Christian

> -James
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jan 30 2007 - 18:10:49 EST

From daniel.odonnell at uleth.ca Tue Jan 30 19:06:48 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 30 Jan 2007 17:06:48 -0700 Subject: [tei-council] Planning Subcommittee report Message-ID: <1170202008.10415.15.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 30 Jan 2007 17:06:48 -0700
Hi all,
The planning committee was supposed to finish its worklist by this
coming Friday. We got through the task list a little earlier than we'd
originally estimated, and so have passed this on to the editors for
review and updating (some of the material we had to work with was quite
old).
We also have a process designed in abstract for the work required to get
us from here to P5 on time. As soon as we get the revised version of the
task list back, we'll put the two things together and propose a plan to
get P5 to the church on time. We think this should be done by Monday
Feb. 12, or earlier if we can manage it.
-d
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jan 30 2007 - 19:05:24 EST
From laurent.romary at loria.fr Wed Jan 31 01:23:05 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 31 Jan 2007 07:23:05 +0100 Subject: [tei-council] TEI Numbered Divs Survey In-Reply-To: <1170180684.6672.58.camel@odonned-eng06> Message-ID: <1170224585.45c035c9ceebd@www.loria.fr>
From: Laurent Romary
Date: Wed, 31 Jan 2007 07:23:05 +0100
Fine for me. I have actually tried to fill the form (are the inputs already
recorded? ;-)).
Laurent
Selon Dan O'Donnell ca>:
> None from me.
>
> On Tue, 2007-30-01 at 14:53 +0000, James Cummings wrote:
> > Very briefly for council's approval I have set up a TEI Numbered Divs
> survey on
> > surveymonkey.com This will allow for 100 responses.
> >
> > The survey is available at:
> > http://www.surveymonkey.com/s.asp?u=82203219378
> >
> > and I have discussed the implications of some of the questions and the
> phrasings
> > of their answers with Sebastian and Arianna.
> >
> > Question #4 may seem a little out in left-field but I intend to use it as a
> > sanity check. (i.e. if lots of people think we should be able to mix
> numbered
> > div content with generic divs, then maybe we shouldn't take the survey
> results
> > too seriously.)
> >
> > I'll take any suggestions for changes anyone has until I post a message
> about it
> > on TEI-L in the next day or so. Let me know if there are any major typos
> or
> > questions I've forgotten.
> >
> > -James
> >
> --
> Daniel Paul O'Donnell, PhD
> Chair, Text Encoding Initiative
> Director, Digital Medievalist Project
> Associate Professor and Chair of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox: +1 403 329 2378
> Fax: +1 403 382-7191
> Homepage: http://people.uleth.ca/~daniel.odonnell/
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 01:23:13 EST

From James.Cummings at computing-services.oxford.ac.uk Wed Jan 31 07:46:47 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 31 Jan 2007 12:46:47 +0000 Subject: [tei-council] TEI Numbered Divs Survey In-Reply-To: <1170224585.45c035c9ceebd@www.loria.fr> Message-ID: <45C08FB7.200@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 31 Jan 2007 12:46:47 +0000
Laurent Romary wrote:
> Fine for me. I have actually tried to fill the form (are the inputs already
> recorded? ;-)).
Yup, I was going to clear the results just before posting to TEI-L, but there
have been five votes so far, and they are quite consistent with what I'd expect
council to say. So I don't think I will wipe them. (Voting records IP address,
so you can only vote once (well, once from each computer)).
I will announce on TEI-L today then.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 31 2007 - 07:46:59 EST
From laurent.romary at loria.fr Wed Jan 31 09:12:40 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 31 Jan 2007 15:12:40 +0100 Subject: [tei-council] TEI Numbered Divs Survey In-Reply-To: <45C08FB7.200@computing-services.oxford.ac.uk> Message-ID: <1E0EAF45-DDBB-4DBE-A00E-094038F398A4@loria.fr>
From: Laurent Romary
Date: Wed, 31 Jan 2007 15:12:40 +0100
OK. I'll try to find some other computers...
Le 31 janv. 07 ? 13:46, James Cummings a ?crit :
> Laurent Romary wrote:
>> Fine for me. I have actually tried to fill the form (are the
>> inputs already
>> recorded? ;-)).
>
> Yup, I was going to clear the results just before posting to TEI-L,
> but there have been five votes so far, and they are quite
> consistent with what I'd expect council to say. So I don't think I
> will wipe them. (Voting records IP address, so you can only vote
> once (well, once from each computer)).
>
> I will announce on TEI-L today then.
>
> -James
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 09:14:00 EST
From Syd_Bauman at Brown.edu Wed Jan 31 10:03:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 31 Jan 2007 10:03:57 -0500 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: Message-ID: <17856.45021.632960.175415@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 31 Jan 2007 10:03:57 -0500
SR> I'd go for the single class.
DB> Lump.
LB> Let them be lumpen.
LB> dates and times is the same anyway, aint they?

Sorry folks, but I have mislead you. It's not just that
uses model.dateLike but not model.timeLike, but also ,
, , , and . Are we still
in favor of lumping?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 10:04:01 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 31 10:16:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 31 Jan 2007 15:16:25 +0000 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17856.45021.632960.175415@emt.wwp.brown.edu> Message-ID: <45C0B2C9.6060607@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 31 Jan 2007 15:16:25 +0000
Syd Bauman wrote:
> Sorry folks, but I have mislead you. It's not just that
> uses model.dateLike but not model.timeLike, but also ,
> , , , and . Are we still
> in favor of lumping?
>
hard to see why not. If you imagine using or
for podcasts, time might be needed.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 31 2007 - 10:16:38 EST
From arianna.ciula at kcl.ac.uk Wed Jan 31 10:33:20 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 31 Jan 2007 15:33:20 +0000 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <45C0B2C9.6060607@oucs.ox.ac.uk> Message-ID: <45C0B6C0.8030201@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 31 Jan 2007 15:33:20 +0000
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> Sorry folks, but I have mislead you. It's not just that
>> uses model.dateLike but not model.timeLike, but also ,
>> , , , and . Are we still
>> in favor of lumping?
>>
> hard to see why not. If you imagine using or
> for podcasts, time might be needed.
>
True, same may be valid for , may be less so for
and , but it wouldn't be conceptually wrong anyway, just less
likely. So I would say lump as well.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 31 2007 - 10:35:50 EST
From djbpitt+tei at pitt.edu Wed Jan 31 10:41:15 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 31 Jan 2007 10:41:15 -0500 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <17856.45021.632960.175415@emt.wwp.brown.edu> Message-ID: <45C0B89B.9000006@pitt.edu>
From: David J Birnbaum
Date: Wed, 31 Jan 2007 10:41:15 -0500
Dear Council,
Yep.
Best,
David
Syd Bauman wrote:
> SR> I'd go for the single class.
>
> DB> Lump.
>
> LB> Let them be lumpen.
> LB> dates and times is the same anyway, aint they?
>
>
> Sorry folks, but I have mislead you. It's not just that
> uses model.dateLike but not model.timeLike, but also ,
> , , , and . Are we still
> in favor of lumping?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 10:39:16 EST
From mjd at hum.ku.dk Wed Jan 31 10:49:48 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Wed, 31 Jan 2007 16:49:48 +0100 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <[tei-council] time & date model classes: lump 'em?> Message-ID: <5FA95E40EE2AD51190380090272724BB0E8F3BE1@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Wed, 31 Jan 2007 16:49:48 +0100
Lump-o-rama.
MJD
Syd Bauman wrote:
> SR> I'd go for the single class.
>
> DB> Lump.
>
> LB> Let them be lumpen.
> LB> dates and times is the same anyway, aint they?
>
>
> Sorry folks, but I have mislead you. It's not just that
> uses model.dateLike but not model.timeLike, but also ,
> , , , and . Are we still
> in favor of lumping?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 10:50:06 EST
From daniel.odonnell at uleth.ca Wed Jan 31 11:12:29 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 31 Jan 2007 09:12:29 -0700 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <5FA95E40EE2AD51190380090272724BB0E8F3BE1@humxsrv1.hum.ku.dk> Message-ID: <1170259949.19173.0.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 31 Jan 2007 09:12:29 -0700
TEI Council: The Lumpen proletariat.

On Wed, 2007-31-01 at 16:49 +0100, Matthew James Driscoll wrote:
> Lump-o-rama.
>
> MJD
>
> Syd Bauman wrote:
> > SR> I'd go for the single class.
> >
> > DB> Lump.
> >
> > LB> Let them be lumpen.
> > LB> dates and times is the same anyway, aint they?
> >
> >
> > Sorry folks, but I have mislead you. It's not just that
> > uses model.dateLike but not model.timeLike, but also ,
> > , , , and . Are we still
> > in favor of lumping?
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jan 31 2007 - 11:11:10 EST

From Syd_Bauman at Brown.edu Wed Jan 31 13:04:19 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 31 Jan 2007 13:04:19 -0500 Subject: [tei-council] limited phrase, take 2 In-Reply-To: <1170180176.6672.49.camel@odonned-eng06> Message-ID: <17856.55843.400002.839959@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 31 Jan 2007 13:04:19 -0500
> I think the third version is missing elements--I can't see choice,
> for example.
Yes, is missing from the complete re-design, sorry about
that. But even worse, the membership of model.pPart.editorial and
model.pPart.originate are reversed.
However, so far those who have chimed in prefer what I called the
"current proposal", so this may be a moot point.
--------- complete re-arrangement, updated ---------
model.phrase =
model.phrase.transcribe =
model.egLike = eg egXML
model.pPart.transcribe = add damage del restore space unclear
model.pPart.editorial = corr orig reg supplied
model.hiLike = hi
model.lPart = caesura rhyme
model.ptrLike.form = oRef oVar pRef pVar
model.segLike = c cl m phr s seg w
model.phrase.originate =
model.graphicLike = binaryObject formula graphic
model.pPart.originate = abbr expan sic choice
model.emphLike = distinct emph foreign gloss mentioned soCalled term title code ident
model.xmlPhrase = att gi tag val
model.specDescLike = specDesc specList
model.pPart.data = address
model.dateLike = date
model.measureLike = measure num
model.nameLike = geogName lang placeName rs
model.nameLike.agent = name orgName persName
model.timeLike = time
model.pPart.msdesc = catchwords dimensions handShift heraldry locus
material origDate origPlace secFol signatures watermark
model.ptrLike = ptr ref
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 13:04:31 EST
From Syd_Bauman at Brown.edu Wed Jan 31 13:07:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 31 Jan 2007 13:07:11 -0500 Subject: [tei-council] time & date model classes: lump 'em? In-Reply-To: <1170259949.19173.0.camel@odonned-eng06> Message-ID: <17856.56015.148259.553342@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 31 Jan 2007 13:07:11 -0500
They (model.dateLike & model.timeLike) are now lumped into one class,
model.dateLike.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 13:07:15 EST
From Syd_Bauman at Brown.edu Wed Jan 31 14:18:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 31 Jan 2007 14:18:36 -0500 Subject: [tei-council] limited phrase, take 2 In-Reply-To: <45BFBD2A.7090900@oucs.ox.ac.uk> Message-ID: <17856.60300.631175.957634@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 31 Jan 2007 14:18:36 -0500
> >I want to be able to say that the

s in my corpus headers have a
> >content model which is a specific subset of the

s in my corpus
> >texts (only PCDATA, not PCDATA or , for example). How would
> >each of these proposals help me with that problem?
> not at all. but was it supposed to?
No, it wasn't. Which is why I have, at times, expressed doubt as
to whether or not this particular change is worth the effort. (I've
come to think it is, but if it solved the above problem it would
obviously be worth the effort -- *way* worth the effort, as my
daughter would say.)

> this is what god gave you Schematron for, though people are amazing
> reluctant to make use of it.
I humbly disagree. This is what Mrs Clark & Murata gave us
co-occurrence constraints in Relax NG for.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jan 31 2007 - 14:18:40 EST

From Syd_Bauman at Brown.edu Fri Feb 2 06:11:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 2 Feb 2007 06:11:53 -0500 Subject: [tei–council] action item –– due Tuesday –– reminder Message-ID: <17859.7289.348360.7265@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 2 Feb 2007 06:11:53 -0500
Responsibility: all
Action: read & comment on SB's post "date attributes: summary,
problems, and some suggestions"[1]
Due date: 2006-02-06
Everyone should please read this posting and then post opinions,
corrections, suggestions, agreements, disagreements, etc., here. In
particular, Council needs to decide whether and how to handle
permitting non-Gregorian regularizations or normalizations, and
non-W3C formats. These are discussed in the section headed "Below",
and I provide four main possible solutions from which you might
choose.
This is not easy stuff, folks, and I really don't think the editors
should be deciding this on their own.
Note
---- [1] http://lists.village.virginia.edu/pipermail/tei-council/2007/002164.html _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 02 2007 - 06:11:58 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 2 18:05:29 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 03 Feb 2007 08:05:29 +0900 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <200701222223.l0MMNblR024839@perseus.services.brown.edu> Message-ID: <45C3C3B9.3050903@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sat, 03 Feb 2007 08:05:29 +0900
Thanks for the remainder Syd. Here are my comments.
Syd Bauman wrote:

>
> value= of ,
> date= of , , and
> I am not bothered by this in the least, because I think the
> semantics are clearer with these names, and the combined
> alternative (dateValue=) is at least cumbersome if not misleading
> (i.e., on
> Suggestion: leave names as they are.
fine
>
> * We haven't implemented classes as well as we could.
> Suggestions:
>
> - Put into att.datePart. This has the disadvantage of
> giving a dur= attribute, but I'm not sure it is worth
> making another class just for this one case. Thoughts?
we should not carry the class economy to far, I think. Having
attributes that do not make sense for a certain element should
automatically recommend it for a separate class.
>
> - Create a new attribute class for the date= of , ,
> and . (Any suggestions for the name?)
att.datePart.date?
> - If we keep [1] we may wish to reconsider its class
> membership, as value= is a bit silly on . It needs only
> dur= from att.datePart, making two cases that benefit from
> splitting att.datePart. (See , above.)
ee , above.

> * Users want a method of expressing things like "Oct 27 of 1909, 1910,
> or 1911" or "an Oct 27, but I don't know which one". The W3C format
> that express only a month and day explicitly (xsd:gMonthDay) means
> "a set of one-day long, annually periodic instances". These users
> don't want the entire set, they want only one. ISO 8601:2004 does
> not seem to have even a method to represent the set, let alone a
> singleton. (James, can you verify that? How would one represent
> month & day, no year, in 8601?)
> Suggestion: I haven't got one, thus defer to P5 1.1.
Whats the point of putting this in an attribute anyway?

> * At least one user has expressed a need to express dates in other
> than the [proleptic] Gregorian calendar. He believes this would be a
> requirement of many historians were they to use TEI.
> Solutions: see below
>
> Below
> -----
> Two different suggestions have been floated for trying to get a handle
> on the last three problems, to which I will add two more.
>
> The basic idea is to provide two capabilities:
> * simple date format: conform to W3C spec, easily validatable, software
> support in the world-at-large
> * complex date format: should conform to ISO 8601 if possible
>
> Note that "simple" and "complex" are mostly just labels: it is
> possible to have a W3C date expression that is more complex than some
> other format. The complex date format could be split into two: those
> that conform to ISO 8601 and those that don't; this would give us
> three formats, W3C, ISO, and User-generated.
>
> Note that P4 has only complex format dates. Further note that right
> now our P5 dates are very like the simple date format, except that a
> single complexity has been added: expressing times precise only to the
> minute or hour. This complexity is validatable, but enjoys no support
> in the world of XSLT 2.0. If we go with *any* of the following
> systems, I recommend that our "simple date" formats revert to being
> truly W3C-only, and thus those who need to express times less
> precisely than to the second would be forced to use the "complex date"
> format.
This seems to be quite desirable to me.

> The question is at what level to apportion these capabilities. Here
> are the four possibilities I have come up with. Note: the names are
> ones I have MADE UP on the spot, and are merely stand-ins for whatever
> Council eventually decides they should be named.
>
> attribute level: each of the dating attrs is split into two
> datatype level: we provide one datatype for each date format, user
> chooses which for each attribute
> class level: for each attribute set, we provide two (or more) classes,
> one for each format, user chooses which for each element
> all-in-one: syntax of attribute value differentiates
>
> datatype level
> -------- -----
> We create two or three datatypes, one for each date format.
>
> data.w3cTemporal = xsd:date | xsd:gYear | xsd:gMonth | xsd:gDay |
> xsd:gYearMonth | xsd:gMonthDay | xsd:time |
> xsd:dateTime
>
> data.isoTemporal = [if & when a datatype library is written, plug it
> in here; in the meantime, a bunch of gnarly
> regexes might do the trick.]
>
> data.usrTemporal = xsd:token [3] or whatever user chooses to use
>
> (Latter two could easily be rolled into one 'data.looseTemporal'.)
>
> The user, at schema-creation time (perhaps with easy radio buttons in
> Roma) chooses which datatype to use for any given attribute. (A nice
> UI feature would allow user to select a datatype for *all* dating
> attributes at one shot.)
At the moment, I am inclined to go with this solution. It seems to hide
most of the complexity for standard use cases, but gives the building
blocks for more flexibility, if needed.
What still bothers me is
> The rule in P4 for all of the attributes that held a date/time value
> is pretty simple. It boils down to "if you can use ISO 8601, do so; if
> not, document whatever you do in in the header".
Now in P5, we do everything in the ODDs. Do we still require this
documentation, or do we just assume that the ODD will be available?
This brings us once again to the eternal question of how to link from
the instance to the ODD that governed the creation of the schema
according to which the instance validates (the instance's grandmother,
so to say)?
best, chw
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 02 2007 - 18:06:27 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 4 12:58:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 04 Feb 2007 17:58:18 +0000 Subject: [tei-council] odd manual, updated Message-ID: <45C61EBA.6000603@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 04 Feb 2007 17:58:18 +0000
Dear council (and Greg, since he asked on TEI-L),
I have updated my "TEI customization handbook"
and put it up at http://users.ox.ac.uk/~rahtz/oddmanual.pdf
I'd be grateful for corrections and, more importantly, additions.
Comments too, but I have a very limited amount of time at present,
and can't promise to implement large scale rewrites myself.
Of course, I can send the source to anyone who wants
to edit it (its in our local Subversion repository, so not simple
to just ask you to check it out).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 04 2007 - 12:58:39 EST
From James.Cummings at computing-services.oxford.ac.uk Mon Feb 5 12:23:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 05 Feb 2007 17:23:27 +0000 Subject: [tei–council] action item –– due Tuesday –– reminder In-Reply-To: <17859.7289.348360.7265@emt.wwp.brown.edu> Message-ID: <45C7680F.70209@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 05 Feb 2007 17:23:27 +0000
Comments interspersed
Syd Bauman wrote:
> Responsibility: all
> Action: read & comment on SB's post "date attributes: summary,
> problems, and some suggestions"[1]
> Due date: 2006-02-06
> First, a listing of the attributes that are directly involved with
> dating. ("dating" as in "timing", not as in "courtship" :-)

> Problems
> --------
> * Some are distressed by the fact that attributes that are of the
> same datatype (data.temporal) and serve similar functions have
> different names, in particular:
> value= of ,
> date= of , , and
> I am not bothered by this in the least, because I think the
> semantics are clearer with these names, and the combined
> alternative (dateValue=) is at least cumbersome if not misleading
> (i.e., on
> Suggestion: leave names as they are.
Agreed. It does bother me that it is date/@value but birth/@date; but
birth/@value is misleading and birth/@dateValue just seems silly.
> * We haven't implemented classes as well as we could.
> Suggestions:
>
> - Put into att.datePart. This has the disadvantage of
> giving a dur= attribute, but I'm not sure it is worth
> making another class just for this one case. Thoughts?
Agreed.
> - Create a new attribute class for the date= of , ,
> and . (Any suggestions for the name?)
Is att.dateLike taken?
> - If we keep [1] we may wish to reconsider its class
> membership, as value= is a bit silly on . It needs only
> dur= from att.datePart, making two cases that benefit from
> splitting att.datePart. (See , above.)
Erm. I'm in favour of keeping it, specifically as measure for spatial uses.
two miles It isn't just for temporal distance, remember.
> * The precision= attribute is superfluous, as the precision is
> represented in the value of the value=, dur=, notBefore=, notAfter=,
> from=, or to= attribute(s).
> One might argue that we should instead change this attribute to
> indicate that a time is precise only to the minute or hour (as
> opposed to second or fraction thereof) and thus not require our
> extension to W3C datatypes. However, this may become a non-issue
> depending on outcomes of the items discussed below; besides, I
> wouldn't make this argument, so ...
> Suggestion: delete it.
I could live with that.
> * Users want a method of expressing things like "Oct 27 of 1909, 1910,
> or 1911" or "an Oct 27, but I don't know which one". The W3C format
> that express only a month and day explicitly (xsd:gMonthDay) means
> "a set of one-day long, annually periodic instances". These users
> don't want the entire set, they want only one. ISO 8601:2004 does
> not seem to have even a method to represent the set, let alone a
> singleton. (James, can you verify that? How would one represent
> month & day, no year, in 8601?)
Well early ISO 8601 drafts allowed --12-25 for any Christmas Day... which I
think we've included in our pattern, and isn't that what xsd:gMonthDay does? Or
am I missing something?
> Suggestion: I haven't got one, thus defer to P5 1.1.
The multiple dates thing is a 'choice' if Dan gets an expanded notion of choice
into P5 1.1....

> Choosing one of these requires some thought and discussion. Up front I
> can only say that I don't like the 'attribute level' solution. It's
> just too confusing for the average user, most of whom have little or
> nothing to gain. I.e., to borrow a phrase from Perl, while it does
> make the hard things possible, it does not make the easy things easy.
> The others all do, presuming we make simple format dates the default
> for the class or datatype level.
I don't really like the attribute or the all-in-one solutions proposed, which I
guess leaves me with the Class or Datatype ones. Of these, it seems that the
datatype solution puts the least burden on the user for understanding what is
going on.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Feb 05 2007 - 12:23:41 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 6 06:34:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 06 Feb 2007 11:34:44 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <200701222223.l0MMNblR024839@perseus.services.brown.edu> Message-ID: <45C867D4.3080206@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 06 Feb 2007 11:34:44 +0000
Thoughts on dates
> Problems
> --------
> * Some are distressed by the fact that attributes that are of the
> same datatype (data.temporal) and serve similar functions have
> different names, in particular:
> value= of ,
> date= of , , and
> I am not bothered by this in the least, because I think the
> semantics are clearer with these names, and the combined
> alternative (dateValue=) is at least cumbersome if not misleading
> (i.e., on
> Suggestion: leave names as they are.
>
OK. its a minor annoyance/distress, but not worth arguing about
> * We haven't implemented classes as well as we could.
> Suggestions:
>
> - Put into att.datePart. This has the disadvantage of
> giving a dur= attribute, but I'm not sure it is worth
> making another class just for this one case. Thoughts?
>
no worries. I am sure someone will find an amusing use for @dur
> - Create a new attribute class for the date= of , ,
> and . (Any suggestions for the name?)
>
att.dateValue
> - If we keep [1] we may wish to reconsider its class
> membership, as value= is a bit silly on . It needs only
> dur= from att.datePart, making two cases that benefit from
> splitting att.datePart. (See , above.)
>
kill distance
> * The precision= attribute is superfluous, as the precision is
> ...
> Suggestion: delete it.
>
OK
> * Users want a method of expressing things like "Oct 27 of 1909, 1910,
> or 1911" or "an Oct 27, but I don't know which one". The W3C format
> that express only a month and day explicitly (xsd:gMonthDay) means
> "a set of one-day long, annually periodic instances". These users
> don't want the entire set, they want only one. ISO 8601:2004 does
> not seem to have even a method to represent the set, let alone a
> singleton. (James, can you verify that? How would one represent
> month & day, no year, in 8601?)
> Suggestion: I haven't got one, thus defer to P5 1.1.
>
I agree.
> The basic idea is to provide two capabilities:
> * simple date format: conform to W3C spec, easily validatable, software
> support in the world-at-large
> * complex date format: should conform to ISO 8601 if possible
>
The principle is fine, yes.
I would rule out the attribute level solution, just too confusing
for day to day use.
The class solution is sort of elegant, but falls down
somewhat in implementation problems.
The all-in-one solution is cute, but presumably not
supported by validating software or other standards?
The multiple datatypes are interesting, but "the users chooses which
datatype
to use for any given attribute" is a bit clumsy. If you switch to an ISO
or USER model, would you do it piecemeal? wouldn't it always be a
global decision?
More importantly, this means that when I see coming
at me, I cannot easily deal with it without parsing the ODD in relatively
complex ways. I really don't like the idea of @from and @to changing
their meaning under my feet constantly, or having to refer back to
ad hoc notations in the header.
What to do? I think we should basically go with the class
solution, and accept that elements will gain extra
attributes of the form value.XXX etc.
We implement it as follows:
* make all the relevant elements members of att.datable
* make att.datable a member of att.datable.w3c and att.datable.iso
(att.datable.iso is empty initially)
* att.datable.w3c defines short forms attributes like "value" and "from"
* in a new module (namesdates_complex) define a att.datable.iso
which defines value.iso and from.iso
* if the new module is loaded, all the relevant elements now get extra
attributes
* people who don't want the standard attribute kill the att.datable.w3c
class
* people who want to define att.datable.Etruscan as a new class simply
do so, and change att.datable to be member of that new class
* if desired, individual elements can be made members of
att.datable.Etruscan
* people can redefine att.datable.w3c to use ISO if they want
to freeze in hell forever and ever
We have to set up a new module, of course, for the quick switch.
I believe that the complexity of adding an extra set of attributes
is worth it for the simplicity and extensibility.
The model I am following here is that of att.global, which picks up
extra meaning if you load new modules
If you buy the "module" route, it means that we could add
att.datable.iso at 1.1 if we wanted.
Note: having discussed this with Lou, he says he agrees,
and so won't reply to this thread on his own.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 06 2007 - 06:34:56 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 8 16:18:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 08 Feb 2007 21:18:19 +0000 Subject: [tei-council] tei release Message-ID: <45CB939B.4020201@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 08 Feb 2007 21:18:19 +0000
We are overdue a TEI P5 release. I'd quite like
to target the last day of February; which is doable,
but I'd also greedily like a headline sexy change.
What chance we could show that deletion
of numbered divs is now possible? To
put this in requires that someone other than me
look at the proposed classes and content models
and agrees that they do the right thing. Tempted
as I am to just bang it in, I am also feeble enough
to want a shared scapegoat.
I am hoping from hints that James is dropping
that we will simply end up with divNLike,
not divN0Like and divN1Like, but I think
we get the evidence for that hope soon?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 09 2007 - 17:29:55 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Feb 9 17:41:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 09 Feb 2007 22:41:01 +0000 Subject: [tei-council] tei release In-Reply-To: <45CB939B.4020201@oucs.ox.ac.uk> Message-ID: <45CCF87D.4010401@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 09 Feb 2007 22:41:01 +0000
I agree. More significantly, I expect to have time to spend on it next
week, even.
I aim for
- removable divNs
- q/quote argument resolved
- disposition of a sizeable bunch of outstanding SF requests
by the end of Feb.
L

Sebastian Rahtz wrote:
> We are overdue a TEI P5 release. I'd quite like
> to target the last day of February; which is doable,
> but I'd also greedily like a headline sexy change.
>
> What chance we could show that deletion
> of numbered divs is now possible? To
> put this in requires that someone other than me
> look at the proposed classes and content models
> and agrees that they do the right thing. Tempted
> as I am to just bang it in, I am also feeble enough
> to want a shared scapegoat.
>
> I am hoping from hints that James is dropping
> that we will simply end up with divNLike,
> not divN0Like and divN1Like, but I think
> we get the evidence for that hope soon?
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 09 2007 - 17:41:13 EST

From Syd_Bauman at Brown.edu Fri Feb 9 17:44:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 9 Feb 2007 17:44:45 -0500 Subject: [tei-council] tei release In-Reply-To: <45CB939B.4020201@oucs.ox.ac.uk> Message-ID: <17868.63837.318745.887157@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 9 Feb 2007 17:44:45 -0500
> I am hoping from hints that James is dropping that we will simply
> end up with divNLike, not divN0Like and divN1Like, but I think we
> get the evidence for that hope soon?
IMHO we need not only div0Like and div1Like, we also need div2Like,
div3Like, etc. There isn't really all that much point in having
numbered divs unless each is in its own model class, so that I can
easily say " and are div1Like,
is
div2Like, and , , and are div3Like".
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 09 2007 - 17:44:48 EST
From James.Cummings at oucs.ox.ac.uk Fri Feb 9 19:59:02 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 10 Feb 2007 00:59:02 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. Message-ID: <45CD18D6.60109@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 10 Feb 2007 00:59:02 +0000
Dear Council,
I have closed the TEI Numbered Divs survey and would like to report on the
results. I have made a PDF of the summary report that Survey Monkey provides.
It is available for download at:
http://james.cummingsfamily.org.uk/TEI/survey.pdf

The results are interesting. There were 87 responses total.
For the first question about whether the TEI should contain both numbered and
generic div elements, 44.8% wanted there to be only one type whereas 43.7%
thought the current support for both should be preserved.
For the second question about if the TEI were to support only one of these,
which they would prefer, 18.4% wanted numbered divs, and 75.9% wanted generic divs.
For the third question on where numbered divs should start (div0 vs div1) 13.3%
thought one should always start at div0, 34.9% thought one should always start
at div1, and an identical 34.9% thought that they didn't care as long as there
was a single starting point. 7.2% thought that we should continue support for
div0 or div1 and 9.6% wasn't sure.
The test question, number four of whether you should be allowed to mix numbered
and generic divs 81.2% wanted to continue support for only one at a time and
10.6% wanted to be able to do this. I think this indicates a general level of
trustworthiness of the survey.
Question 5 was a comment question basically indicating two camps as expected,
those who like the simplicity of numbered divs and those who find them
unnecessary. There were some other comments which I found interesting, see the PDF.

Recommendations:
1) There is no clear mandate to get rid of numbered divs, the community is split
basically 50/50 on this issue. I recommend that we maintain support for both.
It is interesting that if we were to only support one type, i.e. if they were
forced to choose, that a clear majority would prefer generic divs. However,
because of the response on the first question, I don't think this is able to be
acted upon.
2) There is a clear majority who want to start at div1 (and this is increased if
we lump in those who don't care but want there to be a single starting point).
My recommendation is that we start numbered divs at div1 only and provide two
example customisations: a) One which changes the start to div0 and another b)
which returns to the current div0|div1 optional start. Sebastian has assured me
that these ODDs would be fairly straightforward. Presenting the community with
these would lessen any negative feelings occurring because of this change.
3) The use of a survey to scope feeling of the TEI community has been generally
positively received, and should be considered for other issues where the Council
feels it might be useful.
I'm sure the Council will want to discuss the results and how we should progress.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 09 2007 - 19:59:20 EST

From Syd_Bauman at Brown.edu Fri Feb 9 20:32:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 9 Feb 2007 20:32:57 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2DD29.8050008@oucs.ox.ac.uk> Message-ID: <17869.8393.173640.515800@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 9 Feb 2007 20:32:57 -0500
I'm sorry, I just realized I never responded to this!

SR> yes, its technically OK. but if you have
SR> (DUMMY | foo), (DUMMY2 | foo)
SR> and you meet just a "foo", where does it come from?
The first parenthetical -- since it is not a it is required
to be a in order to match, as one or the other of the two
element types in the first parenthetical must be matched. But note
that if I meet just a it's not valid (since the model requires
two s in a row, presuming our good sense tells us DUMMY elements
are not allowed).

SR> Anyway, having divLike classes adds the enormous advantage that you
SR> can now easily add your own new object to be a child of .
SR> Don't tell me *that* was easy before!
Yes, absolutely. This is a definite big plus I am all in favor of
(and have always assumed we would do since the class meeting in
Oxford).
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 09 2007 - 20:33:01 EST

From Syd_Bauman at Brown.edu Fri Feb 9 20:33:49 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 9 Feb 2007 20:33:49 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <17869.8445.930274.347152@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 9 Feb 2007 20:33:49 -0500
Thank you so much, James, for putting the effort into this. I think,
while many of us may not like the results, it is *very* useful to
know them.
Given the results, I support all 3 of James' recommendations.

> Sebastian has assured me that these ODDs would be fairly
> straightforward.
Yes, they would be fairly straitforward. But how would a user
incorporate the example into his or her own customization?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 09 2007 - 20:33:53 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Sat Feb 10 00:18:35 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 10 Feb 2007 14:18:35 +0900 Subject: [tei-council] Assessment of Example infrastructure Message-ID: <45CD55AB.5060304@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sat, 10 Feb 2007 14:18:35 +0900
Assessment of Example infrastructure
At the last Council meeting, I was instructed to asses how the current
infrastructure could cope with the internationalization of examples.
Here is the result.
1. The current infrastructure embeds examples into the *spec file of
the thing it is meant to illustrate.
2. Othe I18N features, for example the translation of elements is
handles by embedding the translations into the *spec file. Translations
are identified by their @xml:lang attribute value.
A similar mechanism could be adopted for examples, which would be the
easiest solution, that is using @xml:lang on egXML.
A drawback of the current setup (not limited to I18N) is that there is a
1:1 relationship between example and exemplified feature. This means
that if one and the same example could be used to illustrate multiple
elements, it has to be repeated. A possible solution would be to store
the examples elsewhere and indicate the identity of the thing
illustrated by a @targets element, which should then point to the @ident
value of the thing illustrated. This would require a reshuffling of
bytes in the sourcetree, which if necessary should be undertaken rather
soon.
Christian Wittern

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 00:19:17 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 06:12:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 11:12:25 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CDA899.9070408@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 10 Feb 2007 11:12:25 +0000
I'm aiming to put some work in on this today,
and test James' proposal locally, assuming agreement.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 06:12:43 EST
From dporter at uky.edu Sat Feb 10 07:18:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sat, 10 Feb 2007 07:18:16 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CDA899.9070408@oucs.ox.ac.uk> Message-ID: <96f3df640702100418l1dbf3cb2r7f11d60a4712af85@mail.gmail.com>
From: Dot Porter
Date: Sat, 10 Feb 2007 07:18:16 -0500
I agree.
On 2/10/07, Sebastian Rahtz ox.ac.uk> wrote:
> I'm aiming to put some work in on this today,
> and test James' proposal locally, assuming agreement.
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 07:18:19 EST

From daniel.odonnell at uleth.ca Sat Feb 10 09:38:54 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 07:38:54 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <96f3df640702100418l1dbf3cb2r7f11d60a4712af85@mail.gmail.com> Message-ID: <1171118334.10295.3.camel@caedmon>
From: Daniel O'Donnell
Date: Sat, 10 Feb 2007 07:38:54 -0700
I thought the comments about the library community were the most
convincing reason for keeping both.
-dan
On Sat, 2007-02-10 at 07:18 -0500, Dot Porter wrote:
> I agree.
>
> On 2/10/07, Sebastian Rahtz ox.ac.uk> wrote:
> > I'm aiming to put some work in on this today,
> > and test James' proposal locally, assuming agreement.
> >
> > --
> > Sebastian Rahtz
> >
> > Information Manager, Oxford University Computing Services
> > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> >
> > OSS Watch: JISC Open Source Advisory Service
> > http://www.oss-watch.ac.uk
> >
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 09:38:59 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 09:57:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 14:57:01 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <17869.8445.930274.347152@emt.wwp.brown.edu> Message-ID: <45CDDD3D.8020901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 10 Feb 2007 14:57:01 +0000
Syd Bauman wrote:
> Yes, they would be fairly straitforward. But how would a user
> incorporate the example into his or her own customization?
>
There must be an 80:20 argument here. For some
things, we provide a tick box in Roma, or an exemplar.
For other things, we expect the ODD designer
to be able to read a web page on the wiki or
wherever, and know how to cut and paste.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 09:57:13 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 10:02:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 15:02:32 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CDDE88.9030909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 10 Feb 2007 15:02:32 +0000
comment #27 was mildly interesting, because it is a bit like
the way the TEI Guidelines themselves are marked up
(on which subject I bent Lou's ear on Friday, arguing the
Guidelines are unnecessarily complex in this respect).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 10:02:44 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 10:31:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 15:31:53 +0000 Subject: [tei-council] tei release In-Reply-To: <17868.63837.318745.887157@emt.wwp.brown.edu> Message-ID: <45CDE569.3070004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 10 Feb 2007 15:31:53 +0000
Syd Bauman wrote:
> IMHO we need not only div0Like and div1Like, we also need div2Like,
> div3Like, etc. There isn't really all that much point in having
> numbered divs unless each is in its own model class, so that I can
> easily say " and are div1Like,
is
> div2Like, and , , and are div3Like".
>
It's going to be gruesome, but I can't deny
the strength of the argument.
I have duly implemented all this locally
and am now running a full test. The main
downside so far is that the Guidelines themselves
are no longer valid (since they use div0).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 10:32:04 EST
From lou.burnard at computing-services.oxford.ac.uk Sat Feb 10 12:27:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 10 Feb 2007 17:27:41 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CE008D.6090704@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 10 Feb 2007 17:27:41 +0000
I think James has done a great job here. I assume he'll be posting this
summary along with the decisions arising from it to TEI-L in due course.
For the record, I also agree with his conclusions as follows:
1. we should abolish div0
2. we should retain a choice between div and div1 as the next hierarchic
level within front, body, back
3. this kind of user-consultation can be very effective
However, I feel the need for some reassurance about the way it's
proposed to make all these additional model classes. Two reasons have
been advanced:
a. without them, it is hard or impossible to define a robust content
model for body etc.
b. with them, users can use more "natural" like element names ("chapter"
"section" etc.)
Reason (a) looks plausible -- "robust" here means that you can delete
things from a schema without generating ambiguity, and this will at a
stroke reduce the number of white hairs generated when trying to make
sense of the existing content models
Reason (b) I like less. Why do we have
s at all if we are going to
do this? It is contrary to the original design decision, which was to
apply Occam's razor to this problem (you say "section" and I say "part"
-- let's call the whole thing "div"). Maybe I'm just worried about all
the rewriting that will have to be done if we take this proposal seriously.
Lou

James Cummings wrote:
> Dear Council,
>
> I have closed the TEI Numbered Divs survey and would like to report on
> the results. I have made a PDF of the summary report that Survey
> Monkey provides. It is available for download at:
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Feb 10 2007 - 12:28:05 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 12:37:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 17:37:59 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE008D.6090704@computing-services.oxford.ac.uk> Message-ID: <45CE02F7.5030906@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 10 Feb 2007 17:37:59 +0000
Lou Burnard wrote:
>
> However, I feel the need for some reassurance about the way it's
> proposed to make all these additional model classes. Two reasons have
> been advanced:
>
> a. without them, it is hard or impossible to define a robust content
> model for body etc.
> b. with them, users can use more "natural" like element names
> ("chapter" "section" etc.)
>
> Reason (a) looks plausible -- "robust" here means that you can delete
> things from a schema without generating ambiguity, and this will at a
> stroke reduce the number of white hairs generated when trying to make
> sense of the existing content models
want to bet? the content model for body remains quite complex....
>
> Reason (b) I like less. Why do we have
s at all if we are going
> to do this? It is contrary to the original design decision, which
> was to apply Occam's razor to this problem (you say "section" and I
> say "part" -- let's call the whole thing "div").
> Maybe I'm just worried about all the rewriting that will have to be
> done if we take this proposal seriously.
The ability to name "div1" to "chapter" is already there, its just

what we now have is the ability to add "" _alongside_ "" so that
it behaves in the same manner. Good or bad? who knows. Its a natural fallout
from using classes.
I don't think any serious rewriting is needed by a decision to remove
"div0"; applying
the class struggle to divN does not affect the day to day prose of the
guidelines.
We may note that it will now be much easier to remove div4, div5, div6
and div7.
Anyway, the classification of the div elements is an obvious completion
of the
work started in 2005, and I don't see a real reason to reopen that subject.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 12:38:12 EST
From James.Cummings at oucs.ox.ac.uk Sat Feb 10 13:43:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 10 Feb 2007 18:43:52 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE008D.6090704@computing-services.oxford.ac.uk> Message-ID: <45CE1268.3000401@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 10 Feb 2007 18:43:52 +0000
Lou Burnard wrote:
> I think James has done a great job here. I assume he'll be posting this
> summary along with the decisions arising from it to TEI-L in due course.
Yes, I will, but I will wait until Council agrees overall what should be done,
or a reasonable length of time, whichever happens first.

> For the record, I also agree with his conclusions as follows:
> 1. we should abolish div0
> 2. we should retain a choice between div and div1 as the next hierarchic
> level within front, body, back
> 3. this kind of user-consultation can be very effective
Is there anyone on council who, after reading the survey results, has good
arguments for disagreeing with these proposals? (Please, speak now, I'd prefer
to hear them before announcing such changes to TEI-L).
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 13:44:07 EST

From daniel.odonnell at uleth.ca Sat Feb 10 15:48:17 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 13:48:17 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE1268.3000401@oucs.ox.ac.uk> Message-ID: <1171140497.6077.1.camel@caedmon>
From: Daniel O'Donnell
Date: Sat, 10 Feb 2007 13:48:17 -0700
> > For the record, I also agree with his conclusions as follows:
> > 1. we should abolish div0
> > 2. we should retain a choice between div and div1 as the next hierarchic
> > level within front, body, back
> > 3. this kind of user-consultation can be very effective
>
> Is there anyone on council who, after reading the survey results, has good
> arguments for disagreeing with these proposals? (Please, speak now, I'd prefer
> to hear them before announcing such changes to TEI-L).
My only fear is the DLF people. Do we know if they start with div1 or
div0? Syd has done work with them. Do you know Syd? I can't believe I'm
urging caution on getting rid of any of the divNs ;)
-dan
>
> -James
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 15:48:27 EST
From Syd_Bauman at Brown.edu Sat Feb 10 17:10:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 10 Feb 2007 17:10:47 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <1171140497.6077.1.camel@caedmon> Message-ID: <17870.17127.991283.198786@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 10 Feb 2007 17:10:47 -0500
> My only fear is the DLF people. Do we know if they start with div1
> or div0? Syd has done work with them. Do you know Syd? I can't
> believe I'm urging caution on getting rid of any of the divNs ;)
I don't have any special knowledge in my tiny brain, but I do know
where to look.
* the survey itself -- I believe quite a few librarians responded
* the current "TEI in Libraries" document, which explicitly says "we
prefer that not be used since the TEI Guidelines does not
make it available in or matter"[1]
* the proposed "TEI Tite" document, which lists as one of the
elements that has been excluded[2]
So I think we're pretty safe in ditching (as much as it breaks
my heart!)-:
Notes
-----
[1] http://www.diglib.org/standards/tei.htm
I think I've already pointed out that disagreement in
number to them, but perhaps should mention it again :-)
[2] I just realized that this draft document has not been sent to
Council or the DLF yet, which I thought was supposed to happen
weeks ago. I will send an inquiry to John Unsworth right now.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Feb 10 2007 - 17:10:52 EST
From daniel.odonnell at uleth.ca Sat Feb 10 17:21:50 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 15:21:50 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <17870.17127.991283.198786@emt.wwp.brown.edu> Message-ID: <1171146110.8918.0.camel@caedmon>
From: Daniel O'Donnell
Date: Sat, 10 Feb 2007 15:21:50 -0700
Thanks Syd.
On Sat, 2007-02-10 at 17:10 -0500, Syd Bauman wrote:
> > My only fear is the DLF people. Do we know if they start with div1
> > or div0? Syd has done work with them. Do you know Syd? I can't
> > believe I'm urging caution on getting rid of any of the divNs ;)
>
> I don't have any special knowledge in my tiny brain, but I do know
> where to look.
>
> * the survey itself -- I believe quite a few librarians responded
>
> * the current "TEI in Libraries" document, which explicitly says "we
> prefer that not be used since the TEI Guidelines does not
> make it available in or matter"[1]
>
> * the proposed "TEI Tite" document, which lists as one of the
> elements that has been excluded[2]
>
> So I think we're pretty safe in ditching (as much as it breaks
> my heart!)-:
>
> Notes
> -----
> [1] http://www.diglib.org/standards/tei.htm
> I think I've already pointed out that disagreement in
> number to them, but perhaps should mention it again :-)
> [2] I just realized that this draft document has not been sent to
> Council or the DLF yet, which I thought was supposed to happen
> weeks ago. I will send an inquiry to John Unsworth right now.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 10 2007 - 17:21:55 EST
From Conal.Tuohy at vuw.ac.nz Sun Feb 11 16:47:13 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 12 Feb 2007 10:47:13 +1300 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <[tei-council] TEI Numbered Divs Survey: The Results.> Message-ID:
From: Conal Tuohy
Date: Mon, 12 Feb 2007 10:47:13 +1300
Cheers James!
Interesting results and I agree with your recommendations.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 11 2007 - 16:47:36 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Feb 11 18:13:05 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 12 Feb 2007 08:13:05 +0900 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CDDE88.9030909@oucs.ox.ac.uk> Message-ID: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 12 Feb 2007 08:13:05 +0900
James, Arianna,
Thanks for suggesting the survey and shepherding it along. This
provides and excellent base for our decision.
As I was foolish enough to indicate my expectations before, I am pleased
to see them met here:-) So basically, I think we should go along with
James recommendations.
The only thing that worries me a bit is this:
Sebastian Rahtz wrote:
> comment #27 was mildly interesting, because it is a bit like
> the way the TEI Guidelines themselves are marked up
> (on which subject I bent Lou's ear on Friday, arguing the
> Guidelines are unnecessarily complex in this respect).
>
The comment is

We start with *div1* in almost all cases, but use *div0* where there is
some extraordinary high-level division of a text (say, division of a
work into "book 1" and "book 2"). That way, our navigation structure can
continue to rely on *div1* for user display, but we can still accurately
reflect the true structure of
the work.

If I understand things right, we would not be able to use
above
to accomodate this use case?
We should also make it clear that this was one of the reasons to *not*
use numbered divs in the first case.
(What do you intend to do with the Guidelines themselves? Continue with
numbered divs or ditching them?)
best, chw

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 11 2007 - 18:13:54 EST

From lou.burnard at computing-services.oxford.ac.uk Sun Feb 11 18:19:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 11 Feb 2007 23:19:12 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFA470.10305@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sun, 11 Feb 2007 23:19:12 +0000
Christian Wittern wrote:
>
> (What do you intend to do with the Guidelines themselves? Continue
> with numbered divs or ditching them?)
>
After discussion, Syd and I agreed to convert the Guidelines source from
numbered to vanilla divs, and I have spent most of today implementing
and testing same (along with abolishing div0 per Council decision)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 11 2007 - 18:19:38 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 11 18:23:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 11 Feb 2007 23:23:15 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFA563.5080007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 11 Feb 2007 23:23:15 +0000
Christian Wittern wrote:
>
>
> We start with *div1* in almost all cases, but use *div0* where there
> is some extraordinary high-level division of a text (say, division of
> a work into "book 1" and "book 2"). That way, our navigation structure
> can continue to rely on *div1* for user display, but we can still
> accurately reflect the true structure of
> the work.
>
>
> If I understand things right, we would not be able to use
above
> to accomodate this use case?
> We should also make it clear that this was one of the reasons to *not*
> use numbered divs in the first case.
>
no, but they could put back . There is an example file in the P5
Test area now
to demonstrate this.
> (What do you intend to do with the Guidelines themselves? Continue
> with numbered divs or ditching them?)
>
Lou is working on this as we speak.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 11 2007 - 18:23:18 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 11 18:44:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 11 Feb 2007 23:44:46 +0000 Subject: [tei-council] Assessment of Example infrastructure In-Reply-To: <45CD55AB.5060304@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFAA6E.9090101@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 11 Feb 2007 23:44:46 +0000
> A similar mechanism could be adopted for examples, which would be the
> easiest solution, that is using @xml:lang on egXML.
>
or some type attribute on . is always inside
.
> A drawback of the current setup (not limited to I18N) is that there is a
> 1:1 relationship between example and exemplified feature. This means
> that if one and the same example could be used to illustrate multiple
> elements, it has to be repeated. A possible solution would be to store
> the examples elsewhere and indicate the identity of the thing
> illustrated by a @targets element, which should then point to the @ident
> value of the thing illustrated. This would require a reshuffling of
> bytes in the sourcetree, which if necessary should be undertaken rather
> soon.
>
can be empty, and could use one of the global attributes
(is it @corresp? sorry, its late, am just off to bed) to indicate that
another
example (identified by ID) is equally good here.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 11 2007 - 18:44:50 EST
From arianna.ciula at kcl.ac.uk Tue Feb 13 06:51:03 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 13 Feb 2007 11:51:03 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE1268.3000401@oucs.ox.ac.uk> Message-ID: <45D1A627.7000209@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 13 Feb 2007 11:51:03 +0000
Sorry for replying so late. We had a power failure at King's still
affecting some of our servers.
I agree with all the recommendations James proposed and thanks to him to
have taken charge of this.
Arianna
James Cummings wrote:
> Lou Burnard wrote:
>> I think James has done a great job here. I assume he'll be posting
>> this summary along with the decisions arising from it to TEI-L in due
>> course.
>
> Yes, I will, but I will wait until Council agrees overall what should be
> done, or a reasonable length of time, whichever happens first.
>
>
>> For the record, I also agree with his conclusions as follows:
>> 1. we should abolish div0
>> 2. we should retain a choice between div and div1 as the next
>> hierarchic level within front, body, back
>> 3. this kind of user-consultation can be very effective
>
> Is there anyone on council who, after reading the survey results, has
> good arguments for disagreeing with these proposals? (Please, speak
> now, I'd prefer to hear them before announcing such changes to TEI-L).
>
> -James
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 13 2007 - 06:51:39 EST
From Syd_Bauman at Brown.edu Thu Feb 15 11:03:31 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 11:03:31 -0500 (EST) Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45C867D4.3080206@oucs.ox.ac.uk> Message-ID: <200702151603.l1FG3V2N007860@perseus.services.brown.edu>
From: Syd Bauman
Date: Thu, 15 Feb 2007 11:03:31 -0500 (EST)
> > Problems
> > --------
> > * Some are distressed by the fact that attributes that are of the
> > same datatype (data.temporal) and serve similar functions have
> > different names, in particular:
> > value= of ,
> > date= of , , and
> > I am not bothered by this in the least, because I think the
> > semantics are clearer with these names, and the combined
> > alternative (dateValue=) is at least cumbersome if not misleading
> > (i.e., on
> > Suggestion: leave names as they are.
CW> fine
SR> OK. its a minor annoyance/distress, but not worth arguing about
That was easy.

> > - Put into att.datePart. This has the disadvantage of
> > giving a dur= attribute, but I'm not sure it is worth
> > making another class just for this one case. Thoughts?
CW> we should not carry the class economy to far, I think. Having
CW> attributes that do not make sense for a certain element should
CW> automatically recommend it for a separate class.
SR> no worries. I am sure someone will find an amusing use for @dur
I'm with Christian on this one. (In part because I think Sebastian is
right, and the amusing use of dur= worries me.)

> > - Create a new attribute class for the date= of , ,
> > and . (Any suggestions for the name?)
CW> att.datePart.date?
SR> att.dateValue
Hmmm... how about att.normalizedDate?

> > - If we keep [1] we may wish to reconsider its class
> > membership, as value= is a bit silly on . It needs only
> > dur= from att.datePart, making two cases that benefit from
> > splitting att.datePart. (See , above.)
> kill distance
Is anyone in favor of keeping ? Is anyone besides me, Lou,
and Sebastian in favor of deleting it?

> > * The precision= attribute is superfluous, as the precision is ...
> > Suggestion: delete it.
SR> OK
Going once, ...
going twice ...

> > * Users want a method of expressing [known day & month, unknown
> > year, or specific possible dates within a range]
> > Suggestion: I haven't got one, thus defer to P5 1.1.
SR> I agree.
CW> Whats the point of putting this in an attribute anyway?
I suppose that's a good question, Christian. In any case, it's not
one we're going to directly solve for P5 1.0, it seems. However, when
we instantiate a "user-defined" system, users will, of course, be
permitted to whip up their own systems.

> > The basic idea is to provide two capabilities:
> > * simple date format: conform to W3C spec, easily validatable, software
> > support in the world-at-large
> > * complex date format: should conform to ISO 8601 if possible
SR> The principle is fine, yes.
> > [Including shifting representation of imprecise times to 'complex
> > date' format.]
CW> This seems to be quite desirable to me.
So, we're agreed on the basic idea, that's good.

> > attribute level: each of the dating attrs is split into two
> > datatype level: we provide one datatype for each date format, user
> > chooses which for each attribute
> > class level: for each attribute set, we provide two (or more) classes,
> > one for each format, user chooses which for each element
> > all-in-one: syntax of attribute value differentiates
SB> Up front I can only say that I don't like the 'attribute level'
SB> solution. It's just too confusing for the average user, most of
SB> whom have little or nothing to gain.
SR> I would rule out the attribute level solution, just too confusing
SR> for day to day use.
OK, attribute level is out. One down.

CW> At the moment, I am inclined to go with [datatype level] solution
SR> The multiple datatypes are interesting, but "the users chooses
SR> which datatype to use for any given attribute" is a bit clumsy.
SR> If you switch to an ISO or USER model, would you do it piecemeal?
SR> wouldn't it always be a global decision?
Not at all! Most obviously, I probably want the date= of to
be a simple format date (W3C) even if I need to use the complex date
format for the value= of that is inside my transcription of a
17th century diary.

SR> More importantly, this means that when I see
SR> coming at me, I cannot easily deal with it without parsing the ODD
SR> in relatively complex ways. I really don't like the idea of @from
SR> and @to changing their meaning under my feet constantly, or having
SR> to refer back to ad hoc notations in the header.
I think this is a really compelling argument against the datatype
level solution, even though it's not as bad as Sebastian makes it
sound. (And I don't know what these ad hoc notations in the header
are.) To ascertain what kind of date it is processing, software need
only
* follow the link in the yet-to-be-agreed-upon-let-alone-specified
mechanism in the instance that points to the schema;
* find the declaration for the attribute in question;
* see what kind of datatype it is declared as.
So while it doesn't require parsing the ODD, it is still way too
complex. Besides, it boils down to a situation in which the schema is
adding information to the instance (much the way a DTD can add a
default attribute value), which if not morally abhorrent, is at least
something that should be avoided.
So unless Christian or someone else comes up with a good counter-
argument, I think we should stop considering the datatype-level
solution.

SR> The class solution is sort of elegant, but falls down somewhat in
SR> implementation problems.
I'm confused -- you suggest a quite reasonable implementation below.

SR> The all-in-one solution is cute, but presumably not supported by
SR> validating software or other standards?
I've thought about it a bit more, and I think the all-in-one solution
is more than cute, I think it has a lot to say for it.
A reminder as to how it would work:
One attribute, syntax of value determines what kind of date format:
no prefix = entire value is a simple format (i.e. W3C) date
prefix 'i-' = remainder of value is an ISO 8601 date
prefix 'x-' = remainder of value is a user-defined format date
Thus:





Yes, this system is not supported by validating software or other
standards (although it bears a nice resemblance to RFC 3066 tags, the
two are not related in any way except that TEI might use them as
attribute values), but I think that's a red herring. None of the other
solutions are supported in any way, either.
None of the user-created formats are ever going to have standard
software suite support, so I don't think we should fret much over
that. So the question is, do we think that someone is going to
develop a datatype library for ISO 8601? Because if the answer is
"yes", then we should probably use one of the more complicated
solutions in anticipation that someday we could make use of that
datatype. If there answer is "no", then value="i-2007-02-10T17:58"
seems to be just as useful as value-iso="2007-02-10T17:58", and it
makes the whole system a lot easier on the user, and not particularly
difficult on software.
As to whether or not someone is likely to develop an ISO 8601 or other
useful datatype library, I don't know. I know there has been some
discussion about datatype libraries in general, and that Jenni
Tennison has gone so far as to prototype a declarative language for
defining them[1], but except for Elliotte Rusty Harold's
prime-number-checking example[2], I don't know of any actual datatype
libraries that have been built in the > 5 years that Relax NG has been
around. Does anyone else?

So, IMHO, we are down to either class-level or all-in-one.
SR> I think we should basically go with the class solution, and accept
SR> that elements will gain extra attributes of the form value.XXX
SR>
SR> We implement it as follows:
So, if I understand you correctly, you are suggesting something like
the following (which is different, because I've accommodated renaming
and the need for separate classes for value= and dur=):
When "ISOdate" and "UserDate" modules are loaded:
att.dateTime.w3c = @value
att.duration.w3c = @dur
att.datable.w3c = @notBefore, @notAfter, @from, @to
att.dateTime.iso = @iso-value
att.duration.iso = @iso-dur
att.datable.iso = @iso-notBefore, @iso-notAfter, @iso-from, @iso-to
att.dateTime.usr = @usr-value
att.duration.usr = @usr-dur
att.datable.usr = @usr-notBefore, @usr-notAfter, @usr-from, @usr-to
When those modules are not loaded, all of the .iso and .usr classes
are empty. (BTW, we may well decide the "UserDate" module and thus all
the .usr ones are not needed.)
att.dateTime is a member of all three att.dateTime.[iso,usr,w3c]
att.duration is a member of all three att.duration.[iso,usr,w3c]
att.datable is a member of all three att.datable.[iso,usr,w3c]
By default, the various elements are members of the superclass. I.e.,
and

SR> * people who want to define att.datable.Etruscan as a new class simply
SR> do so, and change att.datable to be member of that new class
SR> * if desired, individual elements can be made members of
SR> att.datable.Etruscan
Right, which is why the "UserDate" module and various .usr classes may
not be needed.

SR> * people can redefine att.datable.w3c to use ISO if they want
SR> to freeze in hell forever and ever
Not sure they'd freeze in hell, but I hope we can craft a definition
of TEI conformance that leaves them out in the cold of non-
conformance.

SR> I believe that the complexity of adding an extra set of attributes
SR> is worth it for the simplicity and extensibility.
Can you elaborate on how this is more simple or more extensible than
the "all-in-one" solution? I think "all-in-one" is simpler for the end
user, and not particularly more complicated for the programmer. And
both seem equally extensible. However, I think the class solution is
cleaner, and permits more flexibility. E.g., a user can choose to have
element have only a plain ("simple date format", aka W3C) value=
attribute, element to have only a "complex date format" (aka ISO)
iso-value= attribute, and element to have both. With the
"all-in-one" the user has no such flexibility: any , , or
has one simple value= attribute, the value of which may be a simple or
complex date format.

SR> The model I am following here is that of att.global, which picks
SR> up extra meaning if you load new modules
Right, makes sense.

SR> If you buy the "module" route, it means that we could add
SR> att.datable.iso at 1.1 if we wanted.
Indeed. Although personally, I'd be inclined to add the .iso class at
1.0, and then work on a datatype to actually constrain it well for
1.1.

Notes
-----
[1] http://www.jenitennison.com/datatypes/
[2] http://www-128.ibm.com/developerworks/xml/library/x-custyp/
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 11:03:34 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 15 11:39:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 15 Feb 2007 16:39:43 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <200702151603.l1FG3V2N007860@perseus.services.brown.edu> Message-ID: <45D48CCF.3010402@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 15 Feb 2007 16:39:43 +0000
Syd Bauman wrote:
> CW> we should not carry the class economy to far, I think. Having
> CW> attributes that do not make sense for a certain element should
> CW> automatically recommend it for a separate class.
>
> SR> no worries. I am sure someone will find an amusing use for @dur
>
> I'm with Christian on this one. (In part because I think Sebastian is
> right, and the amusing use of dur= worries me.)
>
I'll concede that one, not a strong feeling on my part
>
> CW> att.datePart.date?
>
> SR> att.dateValue
>
> Hmmm... how about att.normalizedDate?
>
sure
>
> SR> If you switch to an ISO or USER model, would you do it piecemeal?
> SR> wouldn't it always be a global decision?
>
> Not at all! Most obviously, I probably want the date= of to
> be a simple format date (W3C) even if I need to use the complex date
> format for the value= of that is inside my transcription of a
> 17th century diary.
>
OK, I see the example, but that makes it even more important
not to use the same attribute.
> are.) To ascertain what kind of date it is processing, software need
> only
> * follow the link in the yet-to-be-agreed-upon-let-alone-specified
> mechanism in the instance that points to the schema;
> * find the declaration for the attribute in question;
> * see what kind of datatype it is declared as.
>
IF (a big "if") we mandated the "yet-to-be-agreed-upon-let-alone-specified
mechanism in the instance that points to the schema", I could
sort of go along. But for TEI P5 1.0, I just don't see this
work being completed and implemented by anyone.
> One attribute, syntax of value determines what kind of date format:
>
> no prefix = entire value is a simple format (i.e. W3C) date
> prefix 'i-' = remainder of value is an ISO 8601 date
> prefix 'x-' = remainder of value is a user-defined format date
>
> Thus:
>
>
>
>
>
>
>
I would not actually blow up Parliament in protest
if we adopted that, but I still don't like the idea
of @value sometimes being valid with standard
datatypes and sometimes not.
> None of the user-created formats are ever going to have standard
> software suite support, so I don't think we should fret much over
> that.
agreed. but at least lets isolate them in their own names.
>
> So, IMHO, we are down to either class-level or all-in-one.
>
thats progress.
....
> By default, the various elements are members of the superclass. I.e.,
> and
> user really does not want the plain W3C flavor attributes, she can
> delete att.dateTime.w3c and att.duration.w3c.
>
> On thought on this last bit: why doesn't she just make
> direct members of att.dateTime.iso and att.duration.iso? My gut
> instinct is that this provides more flexibility: I can have be
> a member of att.dateTime.w3c,
> and my new a member of att.dateTime, thus getting both
> attributes.
>
Sure. Thats just a design pattern, though. The underlying
system remains the same. The default is to be a member
of the superclass, right?
>
> SR> * people who want to define att.datable.Etruscan as a new class simply
> SR> do so, and change att.datable to be member of that new class
> SR> * if desired, individual elements can be made members of
> SR> att.datable.Etruscan
>
> Right, which is why the "UserDate" module and various .usr classes may
> not be needed.
>
Yes. It does seem slightly simpler to define each new scheme
as a new class, rather than overload one "usr" class.
> SR> I believe that the complexity of adding an extra set of attributes
> SR> is worth it for the simplicity and extensibility.
>
> Can you elaborate on how this is more simple or more extensible than
> the "all-in-one" solution? I think "all-in-one" is simpler for the end
> user, and not particularly more complicated for the programmer.
out of the box, what would the the datatype of @value be?
how do I indicate that I am happy in a Barbie^H^H^H^H^H^HW3C
world, and I want all the datatype checking my standard
software can provide me? or how do I switch to alternate mode?
my aim would be for the simplest situation to require no
work for the user, and maximum support.
....
> Indeed. Although personally, I'd be inclined to add the .iso class at
> 1.0, and then work on a datatype to actually constrain it well for
> 1.1.
>
sure, no problem
as I read your message, you've more or less
persuaded yourself to agree with my class
proposal a la att.global?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Feb 15 2007 - 11:39:56 EST
From Syd_Bauman at Brown.edu Thu Feb 15 19:04:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 19:04:57 -0500 Subject: [tei–council] what to do with dating attributes –– VOTE! Message-ID: <17876.62761.972180.960950@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 15 Feb 2007 19:04:57 -0500
OK. I realize dating attributes can make your head spin -- heck, I
got so dizzy I had to take breaks while writing that last posting.
But given that we are in pedal-to-the-metal mode to get moving on P5,
I would like to avoid waiting for 2 weeks to see if anyone has
comments on it, only to find they don't.
Christian, Daniel, and Sebastian are working on getting a working
project management system up for P5, which will hopefully include
(among other things) a voting system for Council to use to express
its wishes. But that's at least days away, so in the meantime
Christian has authorized me to use the following far cruder system.
I really want each and every one of us to reply to this posting
within 72 hours having checked off one box for each of the following.

Issue: name of main dating attr (date= vs value=)
Solution: leave 'em as is
Vote:
___ I have considered issue, and agree with proposed solution
___ I have considered issue, and disagree with proposed solution
___ It does not matter to me which solution is chosen, so go
ahead
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

Issue: classes -- @dur and @value in same or different attr classes?
Solution: split 'em into separate classes
Vote:
___ I have considered issue, and agree with proposed solution
___ I have considered issue, and disagree with proposed solution
___ It does not matter to me which solution is chosen, so go
ahead
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

Issue: keep ?
Solution: nuke it
Vote:
___ I have considered issue, and agree with proposed solution
___ I have considered issue, and disagree with proposed solution
___ It does not matter to me which solution is chosen, so go
ahead
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

Issue: keep precision= of
Solution: nuke it
Vote:
___ I have considered issue, and agree with proposed solution
___ I have considered issue, and disagree with proposed solution
___ It does not matter to me which solution is chosen, so go
ahead
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

Issue: method of expressing known day & month, unknown year, or
specific possible dates within a range
Suggestion: defer to P5 1.x.
Vote:
___ I have considered issue, and agree with proposed solution
___ I have considered issue, and disagree with proposed solution
___ It does not matter to me which solution is chosen, so go
ahead
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

Issue: constraint of date-regularization attributes: W3C, ISO, other
Suggestions:
A ("attribute level"): duplicate current attrs for each different system
B ("datatype level"): create duplicate datatype for each different
system
C ("class level"): create classes for each set of attrs from
different systems; possibly implement with a new
module so attrs are added when that module is
loaded (like att.metrical gets added to
att.divLike when verse is loaded)
D ("all-in-one"): differentiate system by value's syntax
Vote:
I have considered issue, and agree with proposed solution:
___ A
___ B
___ C
___ D
I have considered issue, and disagree with proposed solution:
___ A
___ B
___ C
___ D
___ It does not matter to me which solution is chosen, so go
ahead with whatever
___ I have not yet had time to consider the issue sufficiently,
but expect to contribute soon

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 19:05:02 EST

From lou.burnard at computing-services.oxford.ac.uk Thu Feb 15 19:13:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 16 Feb 2007 00:13:12 +0000 Subject: [tei-council] SF FR updates Message-ID: <45D4F718.7060302@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 16 Feb 2007 00:13:12 +0000
I'm working through my open SFFRs and haven't hit too many rocks yet.
1022116: add as child of : Done
1012817, 1561323: fiddle with in various ways: Did one, but
not the other
1022701: add as co-member of new class model.addressLike with
: Done
I'd like Council members to ponder this one though:
1007370: create new element possibly in FT
I think there's a good case for this, but it needs someone to work on
producing documentation for it. If I stop to do that, I won't get
anything else done for a week. So should I just close the ticket and say
"next release"? Could Council members please take a look at the ticket,
and then respond (to me rather than the list) with their choice from
the following:
A: this is a daft idea for the following reasons
B: this is a good idea, but needs more work: we should charter a
workgroup to do it for P5.n
C: this is a good idea and I will send you some material to support it
by St Davids Day




_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 19:13:16 EST

From Syd_Bauman at Brown.edu Thu Feb 15 19:26:48 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 19:26:48 -0500 Subject: [tei-council] SF FR updates In-Reply-To: <45D4F718.7060302@computing-services.oxford.ac.uk> Message-ID: <17876.64072.775222.689910@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 15 Feb 2007 19:26:48 -0500
> Could Council members please take a look at the ticket, and then
> respond (to me rather than the list) with their choice from the
> following:
Is there a reason to keep this discussion private?

> C: this is a good idea and I will send you some material to support
> it by St Davids Day
St David's day is 03-01, yes?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 19:26:52 EST

From lou.burnard at computing-services.oxford.ac.uk Thu Feb 15 19:41:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 16 Feb 2007 00:41:49 +0000 Subject: [tei-council] SF FR updates In-Reply-To: <17876.64072.775222.689910@emt.wwp.brown.edu> Message-ID: <45D4FDCD.7070704@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 16 Feb 2007 00:41:49 +0000
Syd Bauman wrote:
>> Could Council members please take a look at the ticket, and then
>> respond (to me rather than the list) with their choice from the
>> following:
>>
>
> Is there a reason to keep this discussion private?
>
I will summarize the response I get to this list, obviously. I'm just
trying to reduce people's email burden.
>
>
>> C: this is a good idea and I will send you some material to support
>> it by St Davids Day
>>
>
> St David's day is 03-01, yes?
>
>
It's the 1st March, not the 3rd January.

> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 19:42:01 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Feb 15 20:04:50 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 10:04:50 +0900 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D48CCF.3010402@oucs.ox.ac.uk> Message-ID: <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 16 Feb 2007 10:04:50 +0900
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>>
>> Hmmm... how about att.normalizedDate?
>>
> sure
fine
>>
> IF (a big "if") we mandated the "yet-to-be-agreed-upon-let-alone-specified
> mechanism in the instance that points to the schema", I could
> sort of go along. But for TEI P5 1.0, I just don't see this
> work being completed and implemented by anyone.
I will go out on a limb here and suggest a "small" solution: In the
wilderness of the XML universe, there exist already a number of ways to
associate an instance with a non-DTD schema:
XSD uses schemaLocation
oXygen uses a pi "oxygen"
nxml uses a elaborated mechanism which somehow ends in processing a
schemas.xml file
.. there will be others.
How about we just give the users a spot in the header to declare which
one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without
actually implementing our own? The only thing we will have to ponder is
if we want to maintain a registry of values for this list -- I would say
that might be the price we have to pay for this.
To me, this is one of the infrastructural issues we should not lightly
postpone.
Now back to the topic,
>> One attribute, syntax of value determines what kind of date format:
>> no prefix = entire value is a simple format (i.e. W3C) date
>> prefix 'i-' = remainder of value is an ISO 8601 date
>> prefix 'x-' = remainder of value is a user-defined format date
>>
>> Thus:
>>
>>
>>
>>
>>
>>
> I would not actually blow up Parliament in protest
> if we adopted that, but I still don't like the idea
> of @value sometimes being valid with standard
> datatypes and sometimes not.
You will need to check for the type before blindly processing them.
What I like is the self-declaring and on-the-spot expandable property of
this proposal.
>> None of the user-created formats are ever going to have standard
>> software suite support, so I don't think we should fret much over
>> that.
> agreed. but at least lets isolate them in their own names.
Which will put a burden on you if you suddenly discover a new type of
dates in your texts to go back to the schema-drawing-room called Roma
for another round.
>>
>> So, IMHO, we are down to either class-level or all-in-one.
> thats progress.
I'm with you here.
> as I read your message, you've more or less
> persuaded yourself to agree with my class
> proposal a la att.global?

Except that we still have the all-in-one proposal. I might be biased
since I
work more or less daily with xml:lang attributes, but that solution has
the advantage
of being simpler technically.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Feb 15 2007 - 20:05:36 EST

From Conal.Tuohy at vuw.ac.nz Thu Feb 15 20:49:18 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 16 Feb 2007 14:49:18 +1300 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <[tei–council] what to do with dating attributes –– VOTE!> Message-ID:
From: Conal Tuohy
Date: Fri, 16 Feb 2007 14:49:18 +1300
Here's my 2c
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each
> different system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> _X_ A
> ___ B
> ___ C
> _X_ D
>
> I have considered issue, and disagree with proposed solution:
> ___ A
> _X_ B
> _X_ C
> ___ D
>
> ___ It does not matter to me which solution is chosen, so go
> ahead with whatever
>
> _X_ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
That last one is tricky.
I'm not sure, Syd and Sebastian, why you have characterised the
"attribute-level" solution (A) as NOT making the easy things easy, and
"just too confusing for day to day use". Could you clarify where the
confusion might lie please? It seems to me that we could have value="2007">this year and that this is easy. So I must be
missing something.
I think B and C are weaker (if I understand them correctly) in that they
would prohibit mixing calendars in a document (at least, with the same
element, so that date/@value would have to have a consistent type
throughout a document). Is that a correct understanding? Would that be a
problem for historical markup? Maybe not, in which case the objection is
probably moot. However, options A and D would allow mixing calendars. In
some ways I prefer D because it implies that the attributes have
particular semantics which are in a sense independent of the particular
calendrical "syntax" used. But on the other hand I'm not sure that it's
possible to make a hard-and-fast distinction between syntax and
semantics anyway (not in every case at least, since days and years are
pretty standard features of calendars; weeks, months, katuns, etc are
less so). The advantage of A of D would be that the attribute VALUES are
kept "clean" without TEI-imposed prefixes.
All in all, I feel quite ambivalent (multivalent actually!) about these
options.
Incidentally, if option A were favoured (whether as part of option D or
otherwise), one way to implement it might be to use distinct XML
namespaces for the different data types. We could have the default,
W3C-typed, attributes in no namespace (as they are now), and allow
customisations to add date-type attributes in other namespaces. Encoders
could then use whatever namespace prefixes they wanted to e.g. either at
one extreme St David's day or at
the other St David's day depending on
their preference.
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 20:49:42 EST
From Syd_Bauman at Brown.edu Thu Feb 15 21:20:43 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 21:20:43 -0500 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: Message-ID: <17877.5371.694544.449968@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 15 Feb 2007 21:20:43 -0500
> That last one is tricky.
Indeed it is.

> I'm not sure, Syd and Sebastian, why you have characterised the
> "attribute-level" solution (A) as NOT making the easy things easy,
> and "just too confusing for day to day use". Could you clarify
> where the confusion might lie please? It seems to me that we could
> have this year and that this is easy. So
> I must be missing something.
With the attribute-level solution every time any user (who hasn't
removed attributes in her customization) inserts a element,
her XML-aware editor would present here with a slew of possible
attributes:
value=
value.iso=
value.usr=
notBefore=
notBefore.iso=
notBefore.usr=
notAfter=
notAfter.iso=
notAfter.usr=
from=
from.iso=
from.usr=
to=
to.iso=
to.usr=
dur=
dur.iso=
dur.usr=
not to mention the non-date-specific attributes. No simple check-box
style customization could change this. (Although, as I'm fond of
pointing out, it isn't really that hard without the check-box
simplicity.) For the vast majority of users, 2/3 of the above
attributes would never be used, and would just be in the way.

> I think B and C are weaker (if I understand them correctly) in that
> they would prohibit mixing calendars in a document (at least, with
> the same element, so that date/@value would have to have a
> consistent type throughout a document). Is that a correct
> understanding?
Off the top of my head I think that is correct if the user is using
the "simple format" date attributes, regardless of which option we
choose. That's because the simple W3C format is definitionally
Gregorian, and arguably proleptic Gregorian. Things are a little
better with ISO 8601, which is explicitly Gregorian or proleptic
Gregorian, and arguably the syntax could be used for others.
I'm of a mind that, regardless of system, we should define value= and
iso-value= as (proleptic) Gregorian. User-defined values could be of
whatever calendar the user desired. The *content* is in whatever
calendar is specified by calendar=.

> In some ways I prefer D because it implies that the attributes have
> particular semantics which are in a sense independent of the
> particular calendrical "syntax" used.
I'm sorry, I think I'm too tired (or too stupid :-) to understand
this.

> Incidentally, ... use distinct XML namespaces for the different
> data types. ... e.g. ... St David's
> day or ... St David's day
Really interesting idea (that I never thought of) that yields a
very nice syntactic result. But I don't think the implications --
that these attributes somehow belong to some other markup language
than TEI -- are acceptable.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 21:20:50 EST

From Conal.Tuohy at vuw.ac.nz Thu Feb 15 22:17:02 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 16 Feb 2007 16:17:02 +1300 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <[tei–council] what to do with dating attributes –– VOTE!> Message-ID:
From: Conal Tuohy
Date: Fri, 16 Feb 2007 16:17:02 +1300
> With the attribute-level solution every time any user (who hasn't
> removed attributes in her customization) inserts a element,
> her XML-aware editor would present here with a slew of possible
> attributes:
> value=
> value.iso=
> value.usr=
> notBefore=
> notBefore.iso=
> notBefore.usr=
> notAfter=
> notAfter.iso=
> notAfter.usr=
> from=
> from.iso=
> from.usr=
> to=
> to.iso=
> to.usr=
> dur=
> dur.iso=
> dur.usr=
> not to mention the non-date-specific attributes. No simple check-box
> style customization could change this. (Although, as I'm fond of
> pointing out, it isn't really that hard without the check-box
> simplicity.) For the vast majority of users, 2/3 of the above
> attributes would never be used, and would just be in the way.
Would it not be simpler to make the "complex" attribute sets optional?
i.e. the the default TEI schemas would not include the complex dates,
and the user would have to explicitly add them, if they wanted them,
rather than remove them? Since most users would be fine with just
"simple" (W3) dates, for anything else it might be quite reasonable to
require a customization to explicitly add them.
> > I think B and C are weaker (if I understand them correctly) in that
> > they would prohibit mixing calendars in a document (at least, with
> > the same element, so that date/@value would have to have a
> > consistent type throughout a document). Is that a correct
> > understanding?
>
> Off the top of my head I think that is correct if the user is using
> the "simple format" date attributes, regardless of which option we
> choose. That's because the simple W3C format is definitionally
> Gregorian, and arguably proleptic Gregorian. Things are a little
> better with ISO 8601, which is explicitly Gregorian or proleptic
> Gregorian, and arguably the syntax could be used for others.
> I'm of a mind that, regardless of system, we should define value= and
> iso-value= as (proleptic) Gregorian. User-defined values could be of
> whatever calendar the user desired. The *content* is in whatever
> calendar is specified by calendar=.
Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian
calendar in the same document (which seems to me quite reasonable), I
can see how they could do that with A and D, but how to do that with B
and C?
If B (datatype level), then the mixed-calendar encoder would have to
select the "loose" data type for all dates (the "lowest common
denominator" data type), and they wouldn't get the benefit of
W3C-validation of any dates which genuinely were simple Gregorian dates.

If C (class level), then you suggested 2 options:
C(1): classes use different attribute names, hence can be mixed (from
the encoders' perspective this is the same as option A, just implemented
using classes); or
C(2): classes use the same attribute names, hence they can't be mixed
(from the encoders' perspective this is like option B)
> > In some ways I prefer D because it implies that the attributes have
> > particular semantics which are in a sense independent of the
> > particular calendrical "syntax" used.
>
> I'm sorry, I think I'm too tired (or too stupid :-) to understand
> this.
I just meant that it was an attractive idea to have date/@value rather
than date/@iso-value and date/@w3-value (or whatever), since a date, no
matter how you express it, is still just a date.
> > Incidentally, ... use distinct XML namespaces for the different
> > data types. ... e.g. ... St David's
> > day or ... St David's day
>
> Really interesting idea (that I never thought of) that yields a
> very nice syntactic result. But I don't think the implications --
> that these attributes somehow belong to some other markup language
> than TEI -- are acceptable.
I think that's a strange implication to take. cf @xml:lang and @xml:id
which are inarguably (I hope?!) part of the TEI markup language, despite
belonging to a distinct namespace. Remember, too, that all the other
"TEI" attributes are not in fact in any namespace. An XML markup
language is quite a different beast from an XML namespace. But hey, I'm
not fussed about the idea ... it was just a suggestion.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Feb 15 2007 - 22:17:19 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:13:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:13:39 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D583D3.10001@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 10:13:39 +0000
Christian Wittern wrote:
> How about we just give the users a spot in the header to declare which
> one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without
> actually implementing our own? The only thing we will have to ponder
> is if we want to maintain a registry of values for this list -- I
> would say that might be the price we have to pay for this.
>
> To me, this is one of the infrastructural issues we should not lightly
> postpone.
>
I think you need to go over the whole process and explain how it will
work in real life.
Two simple examples
a) I declare my schema to be foo.rnc, in oxygen notation. I am
processing using XSL.
in XSL I cannot read .rnc files (at all easily). how do I access
the datatype info?
b) I am moving hundreds of documents into eXist, and I pull out small
fragments all
the time. for each one, I laboriously find the header, find the
way to referring to the
schema, locate the schema, and look! I have 4 different schemas,
so how now
do I evaluate @value?
>
> You will need to check for the type before blindly processing them.
how? I'm an experienced XML processing person, and I just dread the
thought of considering it. Plus, I want my validation!
>
> Which will put a burden on you if you suddenly discover a new type of
> dates in your texts to go back to the schema-drawing-room called Roma
> for another round.
seems a reasonable price to me!
>
> Except that we still have the all-in-one proposal. I might be biased
> since I
> work more or less daily with xml:lang attributes, but that solution
> has the advantage
> of being simpler technically.
and I claim its not at all simple for validators and processors...
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 05:13:55 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:16:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:16:17 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: Message-ID: <45D58471.8000100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 10:16:17 +0000
Conal Tuohy wrote:
> Incidentally, if option A were favoured (whether as part of option D or
> otherwise), one way to implement it might be to use distinct XML
> namespaces for the different data types.
>
I dread this, practically. namespaces are good,
but they aren't half a pain in real life, having to declare
them all up front and interact with them in editors.
in XML schemas, of course, it means another .xsd file
to carry around.
It does look elegant, but since we are not currently
proposing it for extensions, I'd steer clear if I could.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 05:16:31 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:18:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:18:11 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: Message-ID: <45D584E3.4050205@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 10:18:11 +0000
Conal Tuohy wrote:
>
> Would it not be simpler to make the "complex" attribute sets optional?
>
thats just what the class-based solution would do, if the non-W3C
classes were in a module
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 05:27:24 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 07:30:10 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 21:30:10 +0900 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D583D3.10001@oucs.ox.ac.uk> Message-ID: <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 16 Feb 2007 21:30:10 +0900
Sebastian Rahtz wrote:
> Christian Wittern wrote:
>> How about we just give the users a spot in the header to declare which
>> one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without
>> actually implementing our own? The only thing we will have to ponder
>> is if we want to maintain a registry of values for this list -- I
>> would say that might be the price we have to pay for this.
>>
>> To me, this is one of the infrastructural issues we should not lightly
>> postpone.
>>
> I think you need to go over the whole process and explain how it will
> work in real life.
>
> Two simple examples
>
> a) I declare my schema to be foo.rnc, in oxygen notation. I am
> processing using XSL.
> in XSL I cannot read .rnc files (at all easily). how do I access
> the datatype info?
>
To do that, you only have a choice between XSD and RNG files, really.
> b) I am moving hundreds of documents into eXist, and I pull out small
> fragments all
> the time. for each one, I laboriously find the header, find the way
> to referring to the
> schema, locate the schema, and look! I have 4 different schemas, so
> how now
> do I evaluate @value?
>
This is a usecase where most of our assumptions about files and headers
fall on their face, which is reaonable IMHO, since we define a format
for *interchange*. In your document repository, you are bound to want
to normalize these kinds of things into one standard form, so the
processing required here is done on the import and then your done with it.
>>
>> You will need to check for the type before blindly processing them.
> how? I'm an experienced XML processing person, and I just dread the
> thought of considering it. Plus, I want my validation!
looking at the value of substring-before(., '-') should give you what
you need to decide. And I am sure Syd will come up with a regex that
gives you a reasonable validation on the @value
>>
>> Which will put a burden on you if you suddenly discover a new type of
>> dates in your texts to go back to the schema-drawing-room called Roma
>> for another round.
> seems a reasonable price to me!
Well, maybe. It's a week argument;-)
>>
>> Except that we still have the all-in-one proposal. I might be biased
>> since I
>> work more or less daily with xml:lang attributes, but that solution
>> has the advantage
>> of being simpler technically.
> and I claim its not at all simple for validators and processors...
>
See above.
I will need to give the whole thing a bit more thought, again.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 07:30:56 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 07:45:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 12:45:06 +0000 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D5A752.9060202@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 12:45:06 +0000
Christian Wittern wrote:
>
>> b) I am moving hundreds of documents into eXist, and I pull out
>> small fragments all
>> the time. for each one, I laboriously find the header, find the
>> way to referring to the
>> schema, locate the schema, and look! I have 4 different schemas,
>> so how now
>> do I evaluate @value?
>>
>
> This is a usecase where most of our assumptions about files and
> headers fall on their face, which is reaonable IMHO, since we define a
> format for *interchange*. In your document repository, you are bound
> to want to normalize these kinds of things into one standard form, so
> the processing required here is done on the import and then your done
> with it.
hmm. that looks like a barrier to me.
>
>> how? I'm an experienced XML processing person, and I just dread the
>> thought of considering it. Plus, I want my validation!
>
> looking at the value of substring-before(., '-') should give you what
> you need to decide. And I am sure Syd will come up with a regex that
> gives you a reasonable validation on the @value
but I want my editor to validate my dates...
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 07:47:24 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 07:52:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 21:52:43 +0900 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A752.9060202@oucs.ox.ac.uk> Message-ID: <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 16 Feb 2007 21:52:43 +0900
Sebastian Rahtz wrote:
> Christian Wittern wrote:
>>
>>> b) I am moving hundreds of documents into eXist, and I pull out
>>> small fragments all
>>> the time. for each one, I laboriously find the header, find the
>>> way to referring to the
>>> schema, locate the schema, and look! I have 4 different schemas,
>>> so how now
>>> do I evaluate @value?
>>>
>>
>> This is a usecase where most of our assumptions about files and
>> headers fall on their face, which is reaonable IMHO, since we define a
>> format for *interchange*. In your document repository, you are bound
>> to want to normalize these kinds of things into one standard form, so
>> the processing required here is done on the import and then your done
>> with it.
> hmm. that looks like a barrier to me.
You mean the normalizing process? It seems like a fact of life to me.
>>> how? I'm an experienced XML processing person, and I just dread the
>>> thought of considering it. Plus, I want my validation!
>>
>> looking at the value of substring-before(., '-') should give you what
>> you need to decide. And I am sure Syd will come up with a regex that
>> gives you a reasonable validation on the @value
> but I want my editor to validate my dates...
Oxygen does use the datatype to validate, so that works while you are
editing -- doesnt nxml do the same thing? Of course you will have to
tell them about your schema in a language they understand, thus my
suggestion.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 07:53:32 EST
From Syd_Bauman at Brown.edu Fri Feb 16 08:33:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 16 Feb 2007 08:33:59 -0500 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: Message-ID: <17877.45767.638704.181178@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 16 Feb 2007 08:33:59 -0500
> Would it not be simpler to make the "complex" attribute sets
> optional? ...
Yes, it would, and the plan you outline is quite reasonable I think.
But it's basically the equivalent of C "class level".

> Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian
> calendar in the same document (which seems to me quite reasonable),
> I can see how they could do that with A and D, but how to do that
> with B and C?
With B ("datatype level") the user would
1. create a datatype for the calendar of interest, 'data.myTemporal'
2. either
a) add a new attribute to (or better still, att.datePart)
called myValue= which is declared as data.myTemporal, or
b) add a new element, , whose value= attribute is declared
as data.myTemporal
With C ("class level") the user would
1. create a class for the calendar of interest, 'att.datePart.mine',
which declares the myValue= attribute appropriately
2. either
a) add to att.datePart.mine, or
b) create , and make it a member of att.datePart.mine
In both cases step 1 involves messing with ODD, which some have
suggested we should try hard to avoid. It is more likely that
solution C step 2(a) could be done via check-box in a Roma tool than
any of the other step 2 possibilities.

> If B (datatype level), then the mixed-calendar encoder would have
> to select the "loose" data type for all dates (the "lowest common
> denominator" data type),
Right, unless they created another attribute as above. This is a bit
of a disadvantage of datatype level.

> If C (class level), then you suggested 2 options:
> C(1): classes use different attribute names, hence can be mixed (from
> the encoders' perspective this is the same as option A, just implemented
> using classes); or
> C(2): classes use the same attribute names, hence they can't be mixed
> (from the encoders' perspective this is like option B)
I think that is a reasonable summary. But keep in mind that
* "just implemented using classes" will be, for some users, a
sizable advantage;
* no one has suggested a mechanism for actually implementing C(2).

> I just meant that it was an attractive idea to have date/@value
> rather than date/@iso-value and date/@w3-value (or whatever), since
> a date, no matter how you express it, is still just a date.
Understood.

> I think that's a strange implication to take. cf @xml:lang and
> @xml:id which are inarguably (I hope?!) part of the TEI markup
> language, despite belonging to a distinct namespace. Remember, too,
> that all the other "TEI" attributes are not in fact in any
> namespace. An XML markup language is quite a different beast from
> an XML namespace. But hey, I'm not fussed about the idea ... it was
> just a suggestion.
Good points, although I would argue that xml:lang= and xml:id= are
somehow different. But as long as foo:bar= is in the TEI Guidelines
and TEI schemas, it is in a very real way part, albeit a separated
part, of the TEI language.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 08:34:02 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 08:40:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 13:40:27 +0000 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D5B44B.2030908@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 13:40:27 +0000
Christian Wittern wrote:
>
>> but I want my editor to validate my dates...
>
> Oxygen does use the datatype to validate
but it can't, because the datatype will be .....
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 08:40:33 EST
From Syd_Bauman at Brown.edu Fri Feb 16 16:01:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 16 Feb 2007 16:01:41 -0500 Subject: [tei-council] Re: schema association In-Reply-To: <45D5B44B.2030908@oucs.ox.ac.uk> Message-ID: <17878.7093.457090.669596@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 16 Feb 2007 16:01:41 -0500
I think Christian's suggestion ("just give the users a spot in the
header to declare which [mechanism for instance to point to schema]
they are using") has the right idea in the sense of "let's do
something easy and fast". However, I think it makes the situation more
complicated, not less.
The right thing to do, if we can swing it politically, is to get
OASIS to make a recommendation. If they do, it is very likely that at
least oXygen would use it, and possible that quite a few others would
follow suit.
I just spoke to Norm Walsh who agrees that the way forward is for me
to cross-post the idea with pointers to both previous suggestions
here and to rng-users. I will try to do that this weekend.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Feb 16 2007 - 16:01:45 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:12:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:12:45 +0000 Subject: [tei-council] Re: schema association In-Reply-To: <17878.7093.457090.669596@emt.wwp.brown.edu> Message-ID: <45D61E4D.8060807@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 21:12:45 +0000
Syd Bauman wrote:
> The right thing to do, if we can swing it politically, is to get
> OASIS to make a recommendation. If they do, it is very likely that at
> least oXygen would use it, and possible that quite a few others would
> follow suit.
>
>
that's fine, and it takes it out of our timeline.
we would participate as an interested party,
but would not have a dependency on it for P5.
I hold the OASIS vote for Oxford if you ever need it :-}

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 16:13:03 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:15:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:15:16 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D61EE4.1000704@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 21:15:16 +0000
>
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> X I have considered issue, and agree with proposed solution
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> X I have considered issue, and agree with proposed solution
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> X I have considered issue, and agree with proposed solution
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> X I have considered issue, and agree with proposed solution
>
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> X I have considered issue, and agree with proposed solution
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> X C
> ___ D
>

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 16:15:20 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:16:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:16:37 +0000 Subject: [tei-council] SF FR updates In-Reply-To: <45D4F718.7060302@computing-services.oxford.ac.uk> Message-ID: <45D61F35.6090202@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Feb 2007 21:16:37 +0000
Lou Burnard wrote:
>
>
> B: this is a good idea, but needs more work: we should charter a
> workgroup to do it for P5.n
I'm not happy to proceed with this unless some people
who actually do mathematical texts have commented.
I suggest you raise it on TEI-L,
and explain that the default answer
is to defer to 5.1 if no-one speaks loudly.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 16:16:50 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 18:02:01 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 17 Feb 2007 08:02:01 +0900 Subject: [tei-council] Report of the planning committee Message-ID: <45D637E9.2010702@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sat, 17 Feb 2007 08:02:01 +0900
Dear Council members,
The planning committee has prepared a tracking system that we will use
to work our way towards the release of P5 1.0. You will find it ready
at http://tei.oucs.ox.ac.uk/trac.cgi
We have tried to identify the open issues and work items that have
been floating around, gathered the things from our previous attempts
at organizing the work and also looked at the SF feature requests,
although they are not integrated into the list at the moment.
We have basically organized the tasks ("tickets" in trac-speach) by
chapter; in addition to specific items relevant to the chapters, there
are a number of tasks that apply to all chapters, these include
* Review general structure in line with comments and write missing
prose
* Review datatype and class decisions
* Implement or reject or postpone feature requests
* Check text of prose matches specs
* Proof-read text looking for references to DTDs and P4 architecture
* Proof-read text in general
* Review elements for missing examples (Desirable)
Not all of them apply to everything, and many of the tickets can be
closed pretty quickly, so don't be scared by the number of tickets open.
In addition to these chapter specific tickets, there are some tickets
relevant to the output formatting and other programming tasks.
The trac system allows to organize the tickets by milestones, owned
tickets, etc.
Here is how we plan to manage the P5 development process:
* We will ask Council members to take ownerships of tickets.
The details of this is something we need to discuss. It might make
sense to build smaller groups within the Council, who will look over
groups of tasks like "proofreading", "publication process" etc.
Suggestions welcome.
To make changes to tickets, you will need to log in. I believe
Sebastian has set it up so that your name will work for the login at
both prompts.
* Tickets taken should be readied within 7 days of taking ownership.
If this seems impossible, please either divide up the task or disown
it in time before the desaster.
* Council members should get a SF account (if not yet done) and will
be added as developers to the SF TEi project. We expect everybody
to checkout the source using SVN (cf. P5 Howto) and commit the
changes back to SF. Council members will work on a branch in SF, it
will be the editors responsibility to port the changes over to the
main branch.
* Discussion of items and decisions will be done via the trac wiki,
which is attached to all tickets. This is not a full blown voting
system, but I hope it will still be easier to follow than the
discussions on council-l. This will document the discussion
and decision process right in place where the work is tracked as
well.
* New work items and discussions should take place in the trac
system. It is possible, similar to the SF system, to be alerted to
changes by email (Sebastian, did you set this up?)
As you will see, the timing is crucial and we will need to develop a
habit of keeping promises of commitment once made.
The one big open issue that is not yet covered in the above system is
the list of open feature requests. Lou and Syd are working through
this as we speek, but it will be important that Council members also
participate in the discussion. To do this, please go to
http://sourceforge.net/tracker/?atid=644065&group_id=106328&func=browse
look at the open issues and comment. The plan is to be done with this
by 2007-03-01.
The discussion is open now, suggestions for improvement welcome. If
we can agree on this plan, lets implement it right away.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Feb 16 2007 - 18:02:38 EST

From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 05:41:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 10:41:46 +0000 Subject: [tei-council] Report of the planning committee In-Reply-To: <45D637E9.2010702@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D6DBEA.8010404@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 17 Feb 2007 10:41:46 +0000
Christian Wittern wrote:
> To make changes to tickets, you will need to log in. I believe
> Sebastian has set it up so that your name will work for the login at
> both prompts.
>
if it doesn't work, contact me as soon as possible.
>
> * New work items and discussions should take place in the trac
> system. It is possible, similar to the SF system, to be alerted to
> changes by email (Sebastian, did you set this up?)
>
I am not sure it is working. I will be looking at this today.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 17 2007 - 05:41:59 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 08:41:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 13:41:30 +0000 Subject: [tei-council] trac Message-ID: <45D7060A.8050602@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 17 Feb 2007 13:41:30 +0000
er, I have totally disabled access in every way tei.oucs.ox.ac.uk
(by accident).
I am now dependent on one my colleagues reading his/her email
and being able to poke the machine.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 17 2007 - 08:41:43 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 15:05:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 20:05:09 +0000 Subject: [tei-council] tei trac Message-ID: <45D75FF5.2000306@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 17 Feb 2007 20:05:09 +0000
back in action now. sorry for the temporary screw-up
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 17 2007 - 15:05:24 EST
From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 18:10:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 23:10:25 +0000 Subject: [tei-council] trac usage Message-ID: <45D78B61.4030500@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 17 Feb 2007 23:10:25 +0000
just a note to say that after logging in, you should visit Settings,
and put in your email address. This will let trac email notifications
of ticket changes to you.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 17 2007 - 18:10:37 EST
From Syd_Bauman at Brown.edu Sat Feb 17 19:15:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 17 Feb 2007 19:15:36 -0500 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <17879.39592.981034.559677@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 17 Feb 2007 19:15:36 -0500
24 hours left, and we have votes from
- Sebastian
- Conal
- Lou (sent directly to me)
- Syd (below)

> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
> ___ I have considered issue, and agree with proposed solution

> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
> ___ I have considered issue, and agree with proposed solution

> Issue: keep ?
> Solution: nuke it
> Vote:
> ___ I have considered issue, and agree with proposed solution

> Issue: keep precision= of
> Solution: nuke it
> Vote:
> ___ I have considered issue, and agree with proposed solution
But I'm happy to be swayed by use-cases that require it.

> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
> ___ I have considered issue, and agree with proposed solution
I really don't like this, but see no other choice.

> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each different system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> _X_ C
> _X_ D
>
> I have considered issue, and disagree with proposed solution:
> _X_ A
> ___ B
> ___ C
> ___ D
Currently I rank solutions as C = best, D = pretty good, B =
accceptle, A = a bit nuts.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Feb 17 2007 - 19:15:41 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Sat Feb 17 19:30:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sun, 18 Feb 2007 09:30:43 +0900 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D79E33.2010304@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sun, 18 Feb 2007 09:30:43 +0900
Well, after some more consideration, here is my vote.

Syd Bauman wrote:
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each different system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> _X_ C
(Sebastian has somehow convinced me that D is not really feasible...)
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Feb 17 2007 - 19:31:25 EST

From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 07:19:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 12:19:13 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17879.39592.981034.559677@emt.wwp.brown.edu> Message-ID: <45D84441.1050104@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 18 Feb 2007 12:19:13 +0000
Syd Bauman wrote:
> 24 hours left, and we have votes from
> - Sebastian
> - Conal
> - Lou (sent directly to me)
> - Syd (below)
>
>
>
Well, you're doing slightly better than me. On my consultation
concerning I got precisely three responses : two voting for
option B (seek more input) and one for option C (I will provide more
input by 1 March).
As C doesn't exclude the possibility of B, I suspect that B is the most
appropriate course of action. However, there is still an awful lot of
silence on the subject from council members -- some of whom may want to
vote for A (this is a daft idea which should be stopped now). So I will
wait a further 48 hours before doing anything.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 18 2007 - 07:19:25 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 07:46:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 12:46:44 +0000 Subject: [tei-council] facsimile odd Message-ID: <45D84AB4.9040800@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 12:46:44 +0000
according to the minutes, we were going to have a full-devevloped
ODD for linking text to pages images by the end of January:


finish specifications in ODD
2007-01-27


finish prose in ODD
2007-01-31



read facsimile ODD, test schemata
2007-02-08

Any sign?
I added a ticket to trac about it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 07:47:02 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 07:58:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 12:58:12 +0000 Subject: [tei-council] conformance chapter overdue? Message-ID: <45D84D64.5060106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 12:58:12 +0000
I can't find an action about this from the last minutes, but
I think I recall a fairly tight deadline for a draft being agreed to?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 07:58:15 EST
From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 08:21:02 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 13:21:02 +0000 Subject: [tei-council] conformance chapter overdue? In-Reply-To: <45D84D64.5060106@oucs.ox.ac.uk> Message-ID: <45D852BE.5030003@computing-services.oxford.ac.uk>
From: James Cummings
Date: Sun, 18 Feb 2007 13:21:02 +0000
Sebastian Rahtz wrote:
> I can't find an action about this from the last minutes, but
> I think I recall a fairly tight deadline for a draft being agreed to?
Yes, this is entirely my fault. I was supposed to create a draft for people to
argue more about, and I've not finished it yet. I will definitely have time to
work on it more this week.
-james
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 08:21:09 EST
From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 09:21:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 14:21:23 +0000 Subject: [tei-council] SF FRs update Message-ID: <45D860E3.4080601@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 18 Feb 2007 14:21:23 +0000
I've now closed all the SF tickets assigned to me bar two or three. Most
of them are fairly trivial, though the following may be of particular
interest:
1022539: make global
1551357: loosen content model of
The following 2 are still open:

1007370 ] (see earlier note to Council)
1308688 A new floating embedded text element

(I think I now have a proposal for resolving this one, about which I
will post to TEI-L early next week)
The following are now marked PENDING
1531700 Element for supplied letters within expansion (see earlier note
to TEI-L)
1549974 and 1524523 : placed on agenda for Vilnius meeting next week
1550229: Waiting for input from requestor

I've also had a quick glance through the one's on Syd's pile and made
comments where I have anything to say.
Oh, and in a slightly devious move I assigned two particularly nasty
ones to Sebastian.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 18 2007 - 09:21:36 EST

From dporter at uky.edu Sun Feb 18 12:08:29 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 09:08:29 -0800 Subject: [tei-council] facsimile odd In-Reply-To: <45D84AB4.9040800@oucs.ox.ac.uk> Message-ID: <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com>
From: Dot Porter
Date: Sun, 18 Feb 2007 09:08:29 -0800
I expect the hold up is on my end - I am supposed to be supplying
sample texts to Conal so he can test the ODD (which is probably
finished). I will get the testing materials to him this afternoon.
Sorry for the hold up...
Dot
On 2/18/07, Sebastian Rahtz ox.ac.uk> wrote:
> according to the minutes, we were going to have a full-devevloped
> ODD for linking text to pages images by the end of January:
>
>
>
> finish specifications in ODD
> 2007-01-27
>
>
> finish prose in ODD
> 2007-01-31
>
>
>
> read facsimile ODD, test schemata
> 2007-02-08
>
>
> Any sign?
>
> I added a ticket to trac about it.
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 12:08:32 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 12:14:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 17:14:20 +0000 Subject: [tei-council] actions from tcm28 in trac Message-ID: <45D8896C.5020603@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 17:14:20 +0000
I have transferred, sometimes baldly, the actions from the last
council telco into tickets in trac. I hope some of you are getting emails
about it. Can I stress again that you all need to access the trac
system, go to settings, and put in your email address. Then ticket
notifications will reach you.
I think we agreed, btw, that physical bibliography is unlikely to make
it into 1.0?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 12:14:41 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 12:37:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 17:37:01 +0000 Subject: [tei-council] header element to reference schema Message-ID: <45D88EBD.9040305@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 17:37:01 +0000
We have an outstanding feature
request to extend the TEI header to allow a pointer in the TEI
to the schema (in the loosest sense) against which this document is valid.
(http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065)
The requestor boldly begs " this should be able to cope with different
namespaces... i.e. I should be
able to reference the relaxNG schema for elements starting with rng: the
tei: schema I'm using, the svg: schema I'm using, etc. I should be able
just to point to an ODD, an RNG, etc. or embed my ODD
etc."
My inclination is to say that ISO NVDL is supposed to cope with this,
and that we
could simply document as a technique how to embed NVDL in its namespace
in the header (much
as http://www.w3.org/TR/xml-i18n-bp/#tei-modularization discusses how to
add ITS
to the TEI).
However, YMMV. So, _another_ little survey, please. Answers by next weekend;
if there is no convincing consensus, the default answer will apply.
Regarding the addition of a header element (or PI or whatever) to the TEI
scheme to point to a scheme, choose one of the following:

A. I don't understand the issues and am content to let others decide
B. I think it is really important and the TEI must deal with it by
itself for 1.0
C. It is important, but best left to the industry, and we should simply
encourage OASIS to pick it up
D. It can be dealt with using NVDL and we should document that somewhere
E. We should leave it until after 1.0, and set up a working party then
F. It's not an issue, people should use whatever scheme they like
Since I was handed the ticket to resolve, I choose "C" as the default answer
by which I will deal with the ticket if Council does not give a direction.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 12:37:18 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 13:01:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 18:01:21 +0000 Subject: [tei-council] recording application information in the teiHeader Message-ID: <45D89471.4070809@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 18:01:21 +0000
cf my post to TEI-L
If I get no serious responses, I incline towards saying
to Martin "thanks but no thanks".
If there _are_ positive responses, I will propose that we put
it straight in the header, and not bother with an
extra module. In that case, I will take it as an
action to finish drafting the new elements with Martin
for review by Berlin.
Obviously, this depends on y'll approving that
plan of campaign. I will take silence as assent :-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 13:01:33 EST
From arianna.ciula at kcl.ac.uk Sun Feb 18 13:22:39 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Sun, 18 Feb 2007 18:22:39 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D8996F.5020901@kcl.ac.uk>
From: Arianna Ciula
Date: Sun, 18 Feb 2007 18:22:39 +0000
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> _X_ C
> ___ D
I could have looked at this more, but after the discussion on the list,
I think I am convinced it's the best solution.
Arianna
Syd Bauman wrote:
> OK. I realize dating attributes can make your head spin -- heck, I
> got so dizzy I had to take breaks while writing that last posting.
> But given that we are in pedal-to-the-metal mode to get moving on P5,
> I would like to avoid waiting for 2 weeks to see if anyone has
> comments on it, only to find they don't.
>
> Christian, Daniel, and Sebastian are working on getting a working
> project management system up for P5, which will hopefully include
> (among other things) a voting system for Council to use to express
> its wishes. But that's at least days away, so in the meantime
> Christian has authorized me to use the following far cruder system.
>
> I really want each and every one of us to reply to this posting
> within 72 hours having checked off one box for each of the following.
>
>
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> ___ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> ___ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> ___ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> ___ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> ___ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> ___ It does not matter to me which solution is chosen, so go
> ahead
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each different system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> ___ C
> ___ D
>
> I have considered issue, and disagree with proposed solution:
> ___ A
> ___ B
> ___ C
> ___ D
>
> ___ It does not matter to me which solution is chosen, so go
> ahead with whatever
>
> ___ I have not yet had time to consider the issue sufficiently,
> but expect to contribute soon
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 13:22:50 EST
From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 14:51:49 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 19:51:49 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <200702151603.l1FG3V2N007860@perseus.services.brown.edu> Message-ID: <45D8AE55.1060503@computing-services.oxford.ac.uk>
From: James Cummings
Date: Sun, 18 Feb 2007 19:51:49 +0000
Syd Bauman wrote:
>>> - If we keep [1] we may wish to reconsider its class
>>> membership, as value= is a bit silly on . It needs only
>>> dur= from att.datePart, making two cases that benefit from
>>> splitting att.datePart. (See , above.)
>
>> kill distance
>
> Is anyone in favor of keeping ? Is anyone besides me, Lou,
> and Sebastian in favor of deleting it?
As I stated on 2007-02-05, I am in favour of keeping distance because it is
useful for spatial distance. I don't mind if temporal distance is removed from
it, but as an element it should be considered completely separately from the
discussion of date/times.
-james
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 14:52:03 EST
From dporter at uky.edu Sun Feb 18 14:55:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 11:55:16 -0800 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D8AE55.1060503@computing-services.oxford.ac.uk> Message-ID: <96f3df640702181155t42a5440ag4d62262abb77d71f@mail.gmail.com>
From: Dot Porter
Date: Sun, 18 Feb 2007 11:55:16 -0800
I agree with James that should be kept for spacial
difference and not considered only in a discussion of date/time.
Dot
On 2/18/07, James Cummings
oxford.ac.uk> wrote:
> Syd Bauman wrote:
> >>> - If we keep [1] we may wish to reconsider its class
> >>> membership, as value= is a bit silly on . It needs only
> >>> dur= from att.datePart, making two cases that benefit from
> >>> splitting att.datePart. (See , above.)
> >
> >> kill distance
> >
> > Is anyone in favor of keeping ? Is anyone besides me, Lou,
> > and Sebastian in favor of deleting it?
>
> As I stated on 2007-02-05, I am in favour of keeping distance because it is
> useful for spatial distance. I don't mind if temporal distance is removed from
> it, but as an element it should be considered completely separately from the
> discussion of date/times.
>
> -james
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 14:55:20 EST

From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 15:01:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 20:01:34 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D8B09E.4020900@computing-services.oxford.ac.uk>
From: James Cummings
Date: Sun, 18 Feb 2007 20:01:34 +0000
Syd Bauman wrote:
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> Issue: keep ?
> Solution: nuke it
> Vote:
> _X_ I have considered issue, and disagree with proposed solution
I think this conversation is misplaced in a conversation otherwise solely about
date/time since distance is used spatially as well as temporally.
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X_ I have considered issue, and agree with proposed solution
Though I never had my comments in my message from 2007-02-05 explained viz.
whether W3C gMonthDay datatype allows --25-12 for christmas.
>
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> Vote:
>
> I have considered issue, and agree with proposed solution:
> _X_ A
> _x_ D
I'd vote for A, with possibly a secondary vote for D, but I find both solutions
less than elegant.
> I have considered issue, and disagree with proposed solution:
> _X_ B
> _X_ C
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 15:01:48 EST
From dporter at uky.edu Sun Feb 18 15:21:07 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 12:21:07 -0800 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <96f3df640702181221u327d3e5dud100066d1ed18903@mail.gmail.com>
From: Dot Porter
Date: Sun, 18 Feb 2007 12:21:07 -0800
On 2/15/07, Syd Bauman edu> wrote:
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
> ___ I have considered issue, and disagree with proposed solution
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> _X__ I have considered issue, and disagree with proposed solution
>
As James has already mentioned, is also used for spacial distance.
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each different system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> _x__ C
> ___ D

Dot
-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 15:21:11 EST

From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 18:12:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 23:12:08 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D89471.4070809@oucs.ox.ac.uk> Message-ID: <45D8DD48.4070403@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 18 Feb 2007 23:12:08 +0000
1. I certainly dont think it needs a new module
2. As a tool developer I can report that xaira certainly needs a place
in the header to store quite a lot of data: much more than this proposal
would permit (and with a more complex structure) in fact. Xaira
addresses the need by defining its own additional "XairaDesc" element
(if I were doing this properly it wd be in its own namespace) and adding
same to the encodingDesc, which works just fine. In an earlier version,
xaira also updated the revisionDesc everytime it ran: however this
rapidly became so annoying I took it out again.
So on balance,
3. I am unconvinced that this proposal is sufficiently general or
powerful as yet
Lou

Sebastian Rahtz wrote:
> cf my post to TEI-L
>
> If I get no serious responses, I incline towards saying
> to Martin "thanks but no thanks".
>
> If there _are_ positive responses, I will propose that we put
> it straight in the header, and not bother with an
> extra module. In that case, I will take it as an
> action to finish drafting the new elements with Martin
> for review by Berlin.
>
> Obviously, this depends on y'll approving that
> plan of campaign. I will take silence as assent :-}
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 18 2007 - 18:12:21 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 18:46:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 23:46:09 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8DD48.4070403@computing-services.oxford.ac.uk> Message-ID: <45D8E541.50206@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Feb 2007 23:46:09 +0000
Lou Burnard wrote:
>
> 2. As a tool developer I can report that xaira certainly needs a place
> in the header to store quite a lot of data: much more than this
> proposal would permit (and with a more complex structure) in fact.
> Xaira addresses the need by defining its own additional "XairaDesc"
> element (if I were doing this properly it wd be in its own namespace)
> and adding same to the encodingDesc, which works just fine. In an
> earlier version, xaira also updated the revisionDesc everytime it ran:
> however this rapidly became so annoying I took it out again.
>
OK, having also immediately heard from Peter Boot and Dot, the case is
probably there for it to
exist. The choice is between: a simple extensible mechanism which needs
careful definition
to let Lou use it; and a technique recommendation which says "define
your own vocabulary
in your own namespace".
This business of "when to namespace and when not to namespace" keeps
coming back
to haunt us...
I'll let this stew a bit on TEI-L, and then make you a proposal.
Incidentally, perhaps I am over-influenced by my work for the W3C, but I
like
the separation there between the standard, and the "best practices"
document to go with it. I suppose it is heresy to say that we could do
with that too?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Feb 18 2007 - 18:46:22 EST
From Syd_Bauman at Brown.edu Sun Feb 18 22:58:01 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 18 Feb 2007 22:58:01 -0500 Subject: [tei-council] Re: schema association In-Reply-To: <45D61E4D.8060807@oucs.ox.ac.uk> Message-ID: <17881.8265.966631.335794@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 18 Feb 2007 22:58:01 -0500
> that's fine, and it takes it out of our timeline. we would
> participate as an interested party, but would not have a dependency
> on it for P5.
This is not what I had in mind at all. I think we should try, very
hard, to get this done such that it is included in P5 1.0.

> I hold the OASIS vote for Oxford if you ever need it :-}
Excellent!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 18 2007 - 22:58:07 EST
From Syd_Bauman at Brown.edu Sun Feb 18 23:47:08 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 18 Feb 2007 23:47:08 -0500 Subject: [tei-council] time to really allow instance to name schema? Message-ID: <17881.11212.530001.31343@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 18 Feb 2007 23:47:08 -0500
Dept: re-opening a can of worms :-)
Two straw-man proposals have been put forward to two separate groups
for a PI that would permit an XML document instance to name a schema
or schemas against which it is (supposed to be) valid.
In April 2005 I wrote a document that at the time was circulated only
among the TEI Council members:
http://www.tei-c.org/Drafts/edw89.xml?style=printable
In July 2005 MURATA Makoto wrote a document that at the time was
circulated to the new Relax NG user's mailing list:
http://www.asahi-net.or.jp/~eb2m-mrt/hidden/spec.html
In both cases the documents are just proposals of their authors, not
position papers of the organizations they sometimes represent. In
both cases the syntax of a PI that an XML document may use to point
to a schema is described. In both cases the intent is that the PI
itself is optional and repeatable, and that while processors may want
to make use of the information, they are not required to.
This issue fostered some discussion on the rng-users list back in
summer 2005, with some objecting to the idea of a schema-pointing PI
(Tommie Usdin I recall was among them).
TEI P5 needs to be finished up soon, and it would be a good idea, I
think, to have this particular issue settled well before it is
published. Because TEI is so customizable, it is quite helpful for
the user if an instance can point to its schema. In general, the TEI
would be as happy or happier if someone else (read OASIS) came up
with the specification for this process, so that TEI P5 could refer
to it. My instinct is that a PI is the right place for this
information, but I'm not even sure that is a given.
I don't think there is really that much work to be done in this area
to come up with a unified proposal. Does any one else think it is
worth any effort? Is this something that comes under the jurisdiction
of the OASIS Relax NG Technical Committee?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Feb 18 2007 - 23:47:14 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Feb 19 03:33:09 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Feb 2007 17:33:09 +0900 Subject: [tei-council] time to really allow instance to name schema? In-Reply-To: <17881.11212.530001.31343@emt.wwp.brown.edu> Message-ID: <45D960C5.50007@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 19 Feb 2007 17:33:09 +0900
Syd Bauman wrote:
> Dept: re-opening a can of worms :-)
Ah, right. I had completely forgotten about these.
> TEI P5 needs to be finished up soon, and it would be a good idea, I
> think, to have this particular issue settled well before it is
> published. Because TEI is so customizable, it is quite helpful for
> the user if an instance can point to its schema. In general, the TEI
> would be as happy or happier if someone else (read OASIS) came up
> with the specification for this process, so that TEI P5 could refer
> to it. My instinct is that a PI is the right place for this
> information, but I'm not even sure that is a given.
>
> I don't think there is really that much work to be done in this area
> to come up with a unified proposal. Does any one else think it is
> worth any effort? Is this something that comes under the jurisdiction
> of the OASIS Relax NG Technical Committee?
I am all in favor for this to go to a committee outside the TEI to be
considered, with the TEI providing input and also a community with a
commitment to use the spec, once ready. The only concern is that this
(a) should not take steam out of our effort to concentrate on the
immediate issues for P5 and (b) that it becomes decoupled from P5, so
that we are not being held up if this gets stranded somewhere.
Christian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Feb 19 2007 - 03:34:25 EST
From lou.burnard at computing-services.oxford.ac.uk Mon Feb 19 06:47:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Feb 2007 11:47:03 +0000 Subject: [tei-council] time to really allow instance to name schema? In-Reply-To: <17881.11212.530001.31343@emt.wwp.brown.edu> Message-ID: <45D98E37.7090700@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 19 Feb 2007 11:47:03 +0000
According to the edw89 draft the proposed mechanism
* should be optional, ignorable, and over-ridable
* should not be TEI-specific
If the first is a serious requirement, I cannot see any point in the
proposal at all. Its only possible outcome might be a suggestion that
specifying a schema this way is one amongst the many things you might do
with a PI (but since you might also do the same thing another way, or
other things the same way, why bother to make the suggestion?)
If the second is a serious requirement, then clearly there is littlethe
TEI can do to achieve it!
Given that the proposal has already been discussed and failed to
persuade one expert forum (the rng users group), why resurrect it now?
For the record, I think this is a waste of time. The most I think we
should do in TEI P5 is to add a few sentences to SG (introductory
chapter on XML) explaining how a schema might be associated with an
instance, possibly giving the rationale for not doing it. And I'm not
even sure about that.

Lou

Syd Bauman wrote:
> Dept: re-opening a can of worms :-)
>
> Two straw-man proposals have been put forward to two separate groups
> for a PI that would permit an XML document instance to name a schema
> or schemas against which it is (supposed to be) valid.
>
> In April 2005 I wrote a document that at the time was circulated only
> among the TEI Council members:
> http://www.tei-c.org/Drafts/edw89.xml?style=printable
>
> In July 2005 MURATA Makoto wrote a document that at the time was
> circulated to the new Relax NG user's mailing list:
> http://www.asahi-net.or.jp/~eb2m-mrt/hidden/spec.html
>
> In both cases the documents are just proposals of their authors, not
> position papers of the organizations they sometimes represent. In
> both cases the syntax of a PI that an XML document may use to point
> to a schema is described. In both cases the intent is that the PI
> itself is optional and repeatable, and that while processors may want
> to make use of the information, they are not required to.
>
> This issue fostered some discussion on the rng-users list back in
> summer 2005, with some objecting to the idea of a schema-pointing PI
> (Tommie Usdin I recall was among them).
>
> TEI P5 needs to be finished up soon, and it would be a good idea, I
> think, to have this particular issue settled well before it is
> published. Because TEI is so customizable, it is quite helpful for
> the user if an instance can point to its schema. In general, the TEI
> would be as happy or happier if someone else (read OASIS) came up
> with the specification for this process, so that TEI P5 could refer
> to it. My instinct is that a PI is the right place for this
> information, but I'm not even sure that is a given.
>
> I don't think there is really that much work to be done in this area
> to come up with a unified proposal. Does any one else think it is
> worth any effort? Is this something that comes under the jurisdiction
> of the OASIS Relax NG Technical Committee?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Feb 19 2007 - 06:47:16 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 08:19:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 13:19:41 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45D96342.5000007@kosek.cz> Message-ID: <45D9A3ED.8090308@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Feb 2007 13:19:41 +0000
Jirka Kosek wrote:
>
> Since 2005 there is NVDL which can associate schema with namespace
> indirectly. But this doesn't solve issue of having several different
> vocabularies (read schemas) in the same namespaces -- for example full
> TEI vs. TEI Lite, full DocBook vs. Simplified DocBook, XHTML 1.0 vs.
> XHTML 1.1 vs. XHTML Print.
>
you could embed a stanza of NVDL inside the document?
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Feb 19 2007 - 08:20:00 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 08:21:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 13:21:57 +0000 Subject: [tei-council] Re: schema association In-Reply-To: <17881.8265.966631.335794@emt.wwp.brown.edu> Message-ID: <45D9A475.3080203@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Feb 2007 13:21:57 +0000
Syd Bauman wrote:
>> that's fine, and it takes it out of our timeline. we would
>> participate as an interested party, but would not have a dependency
>> on it for P5.
>>
>
> This is not what I had in mind at all. I think we should try, very
> hard, to get this done such that it is included in P5 1.0.
>
I hope that my request yesterday for the council to
vote on this subject will deal with the issue one way
or another? Note that I have only had one response.....
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Feb 19 2007 - 08:23:44 EST
From James.Cummings at computing-services.oxford.ac.uk Mon Feb 19 09:13:54 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 19 Feb 2007 14:13:54 +0000 Subject: [tei-council] header element to reference schema In-Reply-To: <45D88EBD.9040305@oucs.ox.ac.uk> Message-ID: <45D9B0A2.3020105@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 19 Feb 2007 14:13:54 +0000
Sebastian Rahtz wrote:
> We have an outstanding feature
> request to extend the TEI header to allow a pointer in the TEI
> to the schema (in the loosest sense) against which this document is valid.
> (http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065)
>
>
> The requestor boldly begs " this should be able to cope with different
> namespaces... i.e. I should be
> able to reference the relaxNG schema for elements starting with rng: the
> tei: schema I'm using, the svg: schema I'm using, etc. I should be able
> just to point to an ODD, an RNG, etc. or embed my ODD
> etc."
I didn't think I was being that bold. I just felt that if we implemented a
solution one should be able to embed the schema(s) or point to them. I.e. point
to my ODD, embed its RNG, and point to some other publicly maintained schema
(say the SVG schema). Basically I'm just looking for a point at which to do
this in the header, probably under encodingDesc.
> My inclination is to say that ISO NVDL is supposed to cope with this,
I don't know NVDL well enough, but a quick glance at it seems like it might do
what we want.

> Regarding the addition of a header element (or PI or whatever) to the TEI
> scheme to point to a scheme, choose one of the following:
>
> B. I think it is really important and the TEI must deal with it by
> itself for 1.0
> D. It can be dealt with using NVDL and we should document that somewhere
I don't see these two as mutually exclusive. I think it is important, and TEI
should discuss it and document at least one recommendation on how to do it. I
don't view 'deal with it by itself' as excluding using existing standards. It
may be that NVDL should be the recommendation we choose. The only things I
could find about it that bothered me were that in all the examples in the
'annexes' of the ISO publication, it uses Relax NG Annotations for its
documentation...so that means declaring yet another namespace...
I'm assuming that NVDL has no problem if it points to a schema language or
similar that whatever is processing it doesn't understand. I.e. if I point to my
ODD, then oxygen won't die, just say it doesn't know about that kind of thing.
Similarly, this only partly answers the original spec. This gives us a way to
point to external schemas, but no recommendation on a manner to embed the same
in your instance document. (i.e. Say I want to stick my ODDs, automatically, in
an instance document so that the two are inseparable.)
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Feb 19 2007 - 09:13:58 EST

From arianna.ciula at kcl.ac.uk Mon Feb 19 10:00:28 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 19 Feb 2007 15:00:28 +0000 Subject: [tei-council] header element to reference schema In-Reply-To: <45D88EBD.9040305@oucs.ox.ac.uk> Message-ID: <45D9BB8C.4020809@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 19 Feb 2007 15:00:28 +0000
I think it would highly desirable to have the possibility to point to a
publicly maintained schema in the TeiHeader for 1.0 and, I agree with
James, the encodingDesc element could be the right place.
However, I don't know enough about NVDL to vote with all awareness or to
know how to achieve this in collaboration with the industry.
Arianna
Sebastian Rahtz wrote:
> We have an outstanding feature
> request to extend the TEI header to allow a pointer in the TEI
> to the schema (in the loosest sense) against which this document is valid.
> (http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065)
>
>
> The requestor boldly begs " this should be able to cope with different
> namespaces... i.e. I should be
> able to reference the relaxNG schema for elements starting with rng: the
> tei: schema I'm using, the svg: schema I'm using, etc. I should be able
> just to point to an ODD, an RNG, etc. or embed my ODD
> etc."
>
> My inclination is to say that ISO NVDL is supposed to cope with this,
> and that we
> could simply document as a technique how to embed NVDL in its namespace
> in the header (much
> as http://www.w3.org/TR/xml-i18n-bp/#tei-modularization discusses how to
> add ITS
> to the TEI).
>
> However, YMMV. So, _another_ little survey, please. Answers by next
> weekend;
> if there is no convincing consensus, the default answer will apply.
>
> Regarding the addition of a header element (or PI or whatever) to the TEI
> scheme to point to a scheme, choose one of the following:
>
> A. I don't understand the issues and am content to let others decide
> B. I think it is really important and the TEI must deal with it by
> itself for 1.0
> C. It is important, but best left to the industry, and we should simply
> encourage OASIS to pick it up
> D. It can be dealt with using NVDL and we should document that somewhere
> E. We should leave it until after 1.0, and set up a working party then
> F. It's not an issue, people should use whatever scheme they like
>
> Since I was handed the ticket to resolve, I choose "C" as the default
> answer
> by which I will deal with the ticket if Council does not give a direction.
>
> --
>
> Sebastian Rahtz
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Feb 19 2007 - 10:04:25 EST
From tone.bruvik at aksis.uib.no Mon Feb 19 12:25:49 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Mon, 19 Feb 2007 18:25:49 +0100 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <892343a4888f26993d00424071b68e50@aksis.uib.no>
From: Tone Merete Bruvik
Date: Mon, 19 Feb 2007 18:25:49 +0100
Sorry to be a bit late, but here are my vote:
P? 16. feb. 2007 kl. 01.04 skrev Syd Bauman:
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
>
> Issue: keep ?
> Solution: nuke it
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
> Issue: keep precision= of
> Solution: nuke it
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
>
>
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
>
> _X__ I have considered issue, and agree with proposed solution
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each different
> system
> B ("datatype level"): create duplicate datatype for each different
> system
> C ("class level"): create classes for each set of attrs from
> different systems; possibly implement with a new
> module so attrs are added when that module is
> loaded (like att.metrical gets added to
> att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
>
> Vote:
>
> I have considered issue, and agree with proposed solution:
> ___ A
> ___ B
> _X__ C
> ___ D
>
> _X_ It does not matter to me which solution is chosen, so go
> ahead with whatever
>
Tone Merete Bruvik
Lyshovden 104
5148 Fyllingsdalen
55161123
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Feb 19 2007 - 12:31:17 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 12:58:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 17:58:16 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45D9A899.30500@kosek.cz> Message-ID: <45D9E538.1050300@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Feb 2007 17:58:16 +0000
Jirka Kosek wrote:
>> you could embed a stanza of NVDL inside the document?
>>
>
> But this would modify "information content" of document itself
it seems to me that this is what the proponents of the
idea want to do, they genuinely want to enhance
the document.
> - you will have to ignore NVDL elements during XSLT processing
>
Yes, of course; I don't see that as any big deal; just like I
ignore most metadata elements during daily processing.
Sometimes I want them. Sometimes I also want to consult
the schema, so I will read the NVDL.
And of course it did not stop XSD from adding
their horrible attribute....
The days when you got the "real" content of a document
by stripping out all tags is surely past?
> - how would you implement validation in a streaming mode if you must
> lookahead NVDL snippet first
>
doesn't the same apply to a PI? it has to be inside the root
element, so you have to open the document. and it applies
to the XSD element.
> I think that for situations where schema can't be specified indirectly
> using NVDL or similar technology using PI is the best
> solution -- easy to use, easy to implement, no side-effect in existing
> toolchains.
>
but it does require a new ad hoc agreement, and one which cannot
be checked against a schema, or contain any useful documentation.
I agree it would work (if tool vendors wanted), but I don't think
its as much fun as it could.
Anyway, I tend to agree with Lou that I want different
schemas at different times, and that I'd rather not be
dictated to by the document...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Feb 19 2007 - 12:58:29 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 17:54:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 22:54:42 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45DA22A5.6030202@kosek.cz> Message-ID: <45DA2AB2.5040606@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Feb 2007 22:54:42 +0000
Jirka Kosek wrote:
> I think that we are not agreeing on what is "information content" of
> document. I include elements/attributes/text nodes under this term,
> while I take PIs and comments as something which doesn't convey primary
> information of document, just some stuff which can be used by some
> users/tools as a suplemental information when document is processed in a
> particular way.
>
I probably do agree with you. But I am still prepared to use
elements for metadata; after all, you and I both work on a
W3C scheme (ITS) which is happy to store meta information
about processing information in elements the header....
> Nope, PIs can be before root element, for example
>
>
>

> ...
>

>
ah, OK. true. But you still get at that PI with an XML parser,
don't you? or do you just read the first few hundred bytes
and hope you find it?
> OK, so then you will not use
> this PI. But there are still people who need this functionality.
>
>
If OASIS or W3C want to start a workgroup to standardize
a PI, that's fine, of course. I can't believe the W3C will,
though, because they only recognize the existence of
XSD, which already has its truly horrible attribute.
So how does one start an OASIS activity to look at this?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Feb 19 2007 - 17:54:54 EST

From daniel.odonnell at uleth.ca Tue Feb 20 16:18:53 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:18:53 -0700 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8E541.50206@oucs.ox.ac.uk> Message-ID: <1172006333.11553.70.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 20 Feb 2007 14:18:53 -0700
On Sun, 2007-18-02 at 23:46 +0000, Sebastian Rahtz wrote:
> Lou Burnard wrote:
> >
> > 2. As a tool developer I can report that xaira certainly needs a place
> > in the header to store quite a lot of data: much more than this
> > proposal would permit (and with a more complex structure) in fact.
> > Xaira addresses the need by defining its own additional "XairaDesc"
> > element (if I were doing this properly it wd be in its own namespace)
> > and adding same to the encodingDesc, which works just fine. In an
> > earlier version, xaira also updated the revisionDesc everytime it ran:
> > however this rapidly became so annoying I took it out again.
> >
> OK, having also immediately heard from Peter Boot and Dot, the case is
> probably there for it to
> exist. The choice is between: a simple extensible mechanism which needs
> careful definition
> to let Lou use it; and a technique recommendation which says "define
> your own vocabulary
> in your own namespace".
>
> This business of "when to namespace and when not to namespace" keeps
> coming back
> to haunt us...
>
> I'll let this stew a bit on TEI-L, and then make you a proposal.
>
> Incidentally, perhaps I am over-influenced by my work for the W3C, but I
> like
> the separation there between the standard, and the "best practices"
> document to go with it. I suppose it is heresy to say that we could do
> with that too?
Doesn't that keep coming back as well? I think this is probably a post
partum desideratum--though obviously we think about best practice as we
discuss the final spec all the time. I.e. not quite 1.1 but post 1.0.
Perhaps a separate project?
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 16:15:03 EST
From daniel.odonnell at uleth.ca Tue Feb 20 16:21:51 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:21:51 -0700 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8DD48.4070403@computing-services.oxford.ac.uk> Message-ID: <1172006511.11553.74.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 20 Feb 2007 14:21:51 -0700
We've been coming up on this idea of multiple namespaces a lot as well.
Was James C not dealing with this question as part of the conformance
proposals?
I'm happy with Sebastian's proposal for a method of working, but I'm
wondering if what we aren't talking about here is not something that
should be cast off as a separate namespace question--each tool will
presumably have a number of different things it wants to say about
itself and it seems to me to be a mugs game to predict them.
-dan
On Sun, 2007-18-02 at 23:12 +0000, Lou Burnard wrote:
> 1. I certainly dont think it needs a new module
>
> 2. As a tool developer I can report that xaira certainly needs a place
> in the header to store quite a lot of data: much more than this proposal
> would permit (and with a more complex structure) in fact. Xaira
> addresses the need by defining its own additional "XairaDesc" element
> (if I were doing this properly it wd be in its own namespace) and adding
> same to the encodingDesc, which works just fine. In an earlier version,
> xaira also updated the revisionDesc everytime it ran: however this
> rapidly became so annoying I took it out again.
>
> So on balance,
>
> 3. I am unconvinced that this proposal is sufficiently general or
> powerful as yet
>
> Lou
>
>
> Sebastian Rahtz wrote:
> > cf my post to TEI-L
> >
> > If I get no serious responses, I incline towards saying
> > to Martin "thanks but no thanks".
> >
> > If there _are_ positive responses, I will propose that we put
> > it straight in the header, and not bother with an
> > extra module. In that case, I will take it as an
> > action to finish drafting the new elements with Martin
> > for review by Berlin.
> >
> > Obviously, this depends on y'll approving that
> > plan of campaign. I will take silence as assent :-}
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 16:18:02 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 16:24:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 21:24:42 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <1172006333.11553.70.camel@odonned-eng06> Message-ID: <45DB671A.6020209@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 20 Feb 2007 21:24:42 +0000
Dan O'Donnell wrote:
> Doesn't that keep coming back as well? I think this is probably a post
> partum desideratum--though obviously we think about best practice as we
> discuss the final spec all the time. I.e. not quite 1.1 but post 1.0.
> Perhaps a separate project?
>
>
I can see the counter argument, that if we know something
we should put it in the Guidelines; but still I can imagine
the "Big Book Of TEI Fun" as a community project where
people document how they really proceed. As you say,
a different project.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 16:24:55 EST

From daniel.odonnell at uleth.ca Tue Feb 20 16:29:50 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:29:50 -0700 Subject: [tei-council] actions from tcm28 in trac In-Reply-To: <45D8896C.5020603@oucs.ox.ac.uk> Message-ID: <1172006990.11553.79.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 20 Feb 2007 14:29:50 -0700
On Sun, 2007-18-02 at 17:14 +0000, Sebastian Rahtz wrote:
> I have transferred, sometimes baldly, the actions from the last
> council telco into tickets in trac. I hope some of you are getting emails
> about it. Can I stress again that you all need to access the trac
> system, go to settings, and put in your email address. Then ticket
> notifications will reach you.
>
> I think we agreed, btw, that physical bibliography is unlikely to make
> it into 1.0?
This is what I remember. Unfortunately.
-dan
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 16:26:00 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 16:35:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 21:35:03 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <1172006511.11553.74.camel@odonned-eng06> Message-ID: <45DB6987.1040502@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 20 Feb 2007 21:35:03 +0000
Dan O'Donnell wrote:
> We've been coming up on this idea of multiple namespaces a lot as well.
> Was James C not dealing with this question as part of the conformance
> proposals?
>
> I'm happy with Sebastian's proposal for a method of working, but I'm
> wondering if what we aren't talking about here is not something that
> should be cast off as a separate namespace question--each tool will
> presumably have a number of different things it wants to say about
> itself and it seems to me to be a mugs game to predict them.
>
Yes, that's probably the path of least resistance,
simply to document how to add another namespaced
element to the appropriate point in the header,
to give the technique a feeling of encouragement
and approval, without codifying the details.
If I was an RDF nut, I'd point out that you can likely
do everything with that.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 16:35:16 EST
From daniel.odonnell at uleth.ca Tue Feb 20 17:16:12 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 15:16:12 -0700 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <17877.5371.694544.449968@emt.wwp.brown.edu> Message-ID: <1172009772.11553.99.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 20 Feb 2007 15:16:12 -0700
On Thu, 2007-15-02 at 21:20 -0500, Syd Bauman wrote:
On this issue I must confess, I like D better than anything presented;
and think the namespace idea is sooper. We already use namespaced
attributes, of course, so could we do it?
-dan

> > That last one is tricky.
>
> Indeed it is.
>
>
> > I'm not sure, Syd and Sebastian, why you have characterised the
> > "attribute-level" solution (A) as NOT making the easy things easy,
> > and "just too confusing for day to day use". Could you clarify
> > where the confusion might lie please? It seems to me that we could
> > have this year and that this is easy. So
> > I must be missing something.
>
> With the attribute-level solution every time any user (who hasn't
> removed attributes in her customization) inserts a element,
> her XML-aware editor would present here with a slew of possible
> attributes:
> value=
> value.iso=
> value.usr=
> notBefore=
> notBefore.iso=
> notBefore.usr=
> notAfter=
> notAfter.iso=
> notAfter.usr=
> from=
> from.iso=
> from.usr=
> to=
> to.iso=
> to.usr=
> dur=
> dur.iso=
> dur.usr=
> not to mention the non-date-specific attributes. No simple check-box
> style customization could change this. (Although, as I'm fond of
> pointing out, it isn't really that hard without the check-box
> simplicity.) For the vast majority of users, 2/3 of the above
> attributes would never be used, and would just be in the way.
>
>
> > I think B and C are weaker (if I understand them correctly) in that
> > they would prohibit mixing calendars in a document (at least, with
> > the same element, so that date/@value would have to have a
> > consistent type throughout a document). Is that a correct
> > understanding?
>
> Off the top of my head I think that is correct if the user is using
> the "simple format" date attributes, regardless of which option we
> choose. That's because the simple W3C format is definitionally
> Gregorian, and arguably proleptic Gregorian. Things are a little
> better with ISO 8601, which is explicitly Gregorian or proleptic
> Gregorian, and arguably the syntax could be used for others.
>
> I'm of a mind that, regardless of system, we should define value= and
> iso-value= as (proleptic) Gregorian. User-defined values could be of
> whatever calendar the user desired. The *content* is in whatever
> calendar is specified by calendar=.
>
>
> > In some ways I prefer D because it implies that the attributes have
> > particular semantics which are in a sense independent of the
> > particular calendrical "syntax" used.
>
> I'm sorry, I think I'm too tired (or too stupid :-) to understand
> this.
>
>
> > Incidentally, ... use distinct XML namespaces for the different
> > data types. ... e.g. ... St David's
> > day or ... St David's day
>
> Really interesting idea (that I never thought of) that yields a
> very nice syntactic result. But I don't think the implications --
> that these attributes somehow belong to some other markup language
> than TEI -- are acceptable.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 17:12:23 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 17:42:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 22:42:48 +0000 Subject: [tei–council] what to do with dating attributes –– VOTE! In-Reply-To: <1172009772.11553.99.camel@odonned-eng06> Message-ID: <45DB7968.7050408@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 20 Feb 2007 22:42:48 +0000
Dan O'Donnell wrote:
> On this issue I must confess, I like D better than anything presented;
> and think the namespace idea is sooper. We already use namespaced
> attributes, of course, so could we do it?
>
Technically, yes. But if they were in the core, we'd
have a choice of too many attributes; if it was in a
loadable module, what's the advantage over another
name, really?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 20 2007 - 17:43:04 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Feb 20 20:10:48 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 21 Feb 2007 10:10:48 +0900 Subject: [tei-council] actions from tcm28 in trac In-Reply-To: <1172006990.11553.79.camel@odonned-eng06> Message-ID: <45DB9C18.5050308@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 21 Feb 2007 10:10:48 +0900
Dan O'Donnell wrote:
> On Sun, 2007-18-02 at 17:14 +0000, Sebastian Rahtz wrote:
>> I think we agreed, btw, that physical bibliography is unlikely to make
>> it into 1.0?
>
> This is what I remember. Unfortunately.
>
Right. And I guess it will fall on me to inform Murray and the group
about this state of affairs.
Christian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Feb 20 2007 - 20:12:08 EST
From lou.burnard at computing-services.oxford.ac.uk Tue Feb 27 09:34:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 27 Feb 2007 14:34:19 +0000 Subject: [tei-council] P5 internal structure Message-ID: <45E4416B.70500@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 27 Feb 2007 14:34:19 +0000
Sebastian and I were actioned to determine what to do about the
formatting problems in generating HTML from the newly vanilla-div
structured P5 whilst in Lithuania.
We discussed the following options:
0. Top level divs are numbered I to VIII; second level divs are numbered
1 to 39. what is currently the first chapter of part II (numbered 4)
remains numbered 4.
1. Combine top and subsequent level divs: what is currently the first
chapter of part II (numbered 4) becomes II.1
2. Forget about the part numbers: what is currently the first chapter of
part II (numbered 4) remains numbered 4.
3. Special case the first chapter in each part so that it does something
magical to produce an extra blank page, possibly with an extra heading
or something.
We observed that:
(a) the current structure is in need of overhaul -- some of the chapters
are very small and others very large; some closely related material
(e.g. CH and WD) is widely separated; the distinction between "core" and
"additional" tagsets is defunct.
(b) the chapters that define modules should probably be separated from
those which don't, both by numbering and form of title. Some of the
current introductory material could move into the ; some of the
current "technical material" could move into the .
We concluded:
We will begin by adopting option 2 above. This is by far the simplest
solution if we want to get out reasonable looking and accessible HTML in
the near future. It also leaves room for us to group and regroup
chapters without major upheaval.
The downside is that those who have got accustomed to thinking of
chapter CH as chapter 4 will have to get reprogrammed. But they have
quite a lot of reprogramming to endure anyway.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Feb 27 2007 - 09:34:24 EST
From laurent.romary at loria.fr Tue Feb 27 09:57:06 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 27 Feb 2007 15:57:06 +0100 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Tue, 27 Feb 2007 15:57:06 +0100
Since I missed the preceding vote (vacances...), I anticipate on this
one and fully support Lou's proposal.
Laurent
Le 27 f?vr. 07 ? 15:34, Lou Burnard a ?crit :
> Sebastian and I were actioned to determine what to do about the
> formatting problems in generating HTML from the newly vanilla-div
> structured P5 whilst in Lithuania.
>
> We discussed the following options:
>
> 0. Top level divs are numbered I to VIII; second level divs are
> numbered 1 to 39. what is currently the first chapter of part II
> (numbered 4) remains numbered 4.
>
> 1. Combine top and subsequent level divs: what is currently the
> first chapter of part II (numbered 4) becomes II.1
>
> 2. Forget about the part numbers: what is currently the first
> chapter of part II (numbered 4) remains numbered 4.
>
> 3. Special case the first chapter in each part so that it does
> something magical to produce an extra blank page, possibly with an
> extra heading or something.
>
> We observed that:
>
> (a) the current structure is in need of overhaul -- some of the
> chapters are very small and others very large; some closely related
> material (e.g. CH and WD) is widely separated; the distinction
> between "core" and "additional" tagsets is defunct.
>
> (b) the chapters that define modules should probably be separated
> from those which don't, both by numbering and form of title. Some
> of the current introductory material could move into the ;
> some of the current "technical material" could move into the .
>
> We concluded:
>
> We will begin by adopting option 2 above. This is by far the
> simplest solution if we want to get out reasonable looking and
> accessible HTML in the near future. It also leaves room for us to
> group and regroup chapters without major upheaval.
>
> The downside is that those who have got accustomed to thinking of
> chapter CH as chapter 4 will have to get reprogrammed. But they
> have quite a lot of reprogramming to endure anyway.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Feb 27 2007 - 09:58:22 EST
From arianna.ciula at kcl.ac.uk Tue Feb 27 12:39:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Feb 2007 17:39:56 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: <45E46CEC.6000203@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 27 Feb 2007 17:39:56 +0000
It is a pity to loose the old chapters references, but if the overall
HTML structure can benefit and be improved the modifications are more
than welcome.
Arianna
Lou Burnard wrote:
> Sebastian and I were actioned to determine what to do about the
> formatting problems in generating HTML from the newly vanilla-div
> structured P5 whilst in Lithuania.
>
> We discussed the following options:
>
> 0. Top level divs are numbered I to VIII; second level divs are numbered
> 1 to 39. what is currently the first chapter of part II (numbered 4)
> remains numbered 4.
>
> 1. Combine top and subsequent level divs: what is currently the first
> chapter of part II (numbered 4) becomes II.1
>
> 2. Forget about the part numbers: what is currently the first chapter of
> part II (numbered 4) remains numbered 4.
>
> 3. Special case the first chapter in each part so that it does something
> magical to produce an extra blank page, possibly with an extra heading
> or something.
>
> We observed that:
>
> (a) the current structure is in need of overhaul -- some of the chapters
> are very small and others very large; some closely related material
> (e.g. CH and WD) is widely separated; the distinction between "core" and
> "additional" tagsets is defunct.
>
> (b) the chapters that define modules should probably be separated from
> those which don't, both by numbering and form of title. Some of the
> current introductory material could move into the ; some of the
> current "technical material" could move into the .
>
> We concluded:
>
> We will begin by adopting option 2 above. This is by far the simplest
> solution if we want to get out reasonable looking and accessible HTML in
> the near future. It also leaves room for us to group and regroup
> chapters without major upheaval.
>
> The downside is that those who have got accustomed to thinking of
> chapter CH as chapter 4 will have to get reprogrammed. But they have
> quite a lot of reprogramming to endure anyway.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 27 2007 - 12:47:30 EST
From dporter at uky.edu Tue Feb 27 12:58:19 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 27 Feb 2007 12:58:19 -0500 Subject: [tei-council] P5 internal structure In-Reply-To: Message-ID: <96f3df640702270958g76b888a3y57f6563b3fd940e@mail.gmail.com>
From: Dot Porter
Date: Tue, 27 Feb 2007 12:58:19 -0500
I support this proposal as well.
Dot
On 2/27/07, Laurent Romary fr> wrote:
> Since I missed the preceding vote (vacances...), I anticipate on this
> one and fully support Lou's proposal.
> Laurent
>
> Le 27 f?vr. 07 ? 15:34, Lou Burnard a ?crit :
>
> > Sebastian and I were actioned to determine what to do about the
> > formatting problems in generating HTML from the newly vanilla-div
> > structured P5 whilst in Lithuania.
> >
> > We discussed the following options:
> >
> > 0. Top level divs are numbered I to VIII; second level divs are
> > numbered 1 to 39. what is currently the first chapter of part II
> > (numbered 4) remains numbered 4.
> >
> > 1. Combine top and subsequent level divs: what is currently the
> > first chapter of part II (numbered 4) becomes II.1
> >
> > 2. Forget about the part numbers: what is currently the first
> > chapter of part II (numbered 4) remains numbered 4.
> >
> > 3. Special case the first chapter in each part so that it does
> > something magical to produce an extra blank page, possibly with an
> > extra heading or something.
> >
> > We observed that:
> >
> > (a) the current structure is in need of overhaul -- some of the
> > chapters are very small and others very large; some closely related
> > material (e.g. CH and WD) is widely separated; the distinction
> > between "core" and "additional" tagsets is defunct.
> >
> > (b) the chapters that define modules should probably be separated
> > from those which don't, both by numbering and form of title. Some
> > of the current introductory material could move into the ;
> > some of the current "technical material" could move into the .
> >
> > We concluded:
> >
> > We will begin by adopting option 2 above. This is by far the
> > simplest solution if we want to get out reasonable looking and
> > accessible HTML in the near future. It also leaves room for us to
> > group and regroup chapters without major upheaval.
> >
> > The downside is that those who have got accustomed to thinking of
> > chapter CH as chapter 4 will have to get reprogrammed. But they
> > have quite a lot of reprogramming to endure anyway.
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 27 2007 - 12:58:23 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 27 15:39:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Feb 2007 20:39:47 +0000 Subject: [tei-council] a chance in a million for a lucky Council member Message-ID: <45E49713.9040501@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 27 Feb 2007 20:39:47 +0000
Who would like to step up to the plate
and pick one of the plum jobs from the list?
The task is nothing less than to design the
layout of the Guidelines. The first requirement
is to do the web version, then look at print
if it is going well.
The input is XHTML coming an XSLT
transform of P5; you can change that XSLT too,
but the first task is probably just to
take over the CSS and make better-looking pages.
Obviously whoever takes this on has to be prepared
to defend the results to a sceptical Council,
so a certain amount of hard-heartedness is required.
You also have to be prepared to work through
the nitty grit of what information is in an ODD
and how best to present it.
Only one caveat - the result cannot just be a lovely
HTML page, with an instruction saying "go make
it look like that". Finished product required.
Go on, someone on the Council wants this task.
Step forward and claim it!
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 27 2007 - 15:39:54 EST
From dporter at uky.edu Tue Feb 27 16:47:08 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 27 Feb 2007 16:47:08 -0500 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E49713.9040501@oucs.ox.ac.uk> Message-ID: <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com>
From: Dot Porter
Date: Tue, 27 Feb 2007 16:47:08 -0500
Hi Council,
James and I volunteer for this task. We feel that we'll be more
effective working together than either of us would be separately (that
and James still need to finish up an initial draft of Conformance).
Dot
On 2/27/07, Sebastian Rahtz ox.ac.uk> wrote:
> Who would like to step up to the plate
> and pick one of the plum jobs from the list?
>
> The task is nothing less than to design the
> layout of the Guidelines. The first requirement
> is to do the web version, then look at print
> if it is going well.
>
> The input is XHTML coming an XSLT
> transform of P5; you can change that XSLT too,
> but the first task is probably just to
> take over the CSS and make better-looking pages.
>
> Obviously whoever takes this on has to be prepared
> to defend the results to a sceptical Council,
> so a certain amount of hard-heartedness is required.
> You also have to be prepared to work through
> the nitty grit of what information is in an ODD
> and how best to present it.
>
> Only one caveat - the result cannot just be a lovely
> HTML page, with an instruction saying "go make
> it look like that". Finished product required.
>
> Go on, someone on the Council wants this task.
> Step forward and claim it!
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Feb 27 2007 - 16:47:12 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Feb 27 19:30:55 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 28 Feb 2007 08:30:55 +0800 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: <45E4CD3F.9050305@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 28 Feb 2007 08:30:55 +0800
Lou Burnard wrote:
> Sebastian and I were actioned to determine what to do about the
> formatting problems in generating HTML from the newly vanilla-div
> structured P5 whilst in Lithuania.
>
> We discussed the following options:
>
> 0. Top level divs are numbered I to VIII; second level divs are numbered
> 1 to 39. what is currently the first chapter of part II (numbered 4)
> remains numbered 4.
>
> 1. Combine top and subsequent level divs: what is currently the first
> chapter of part II (numbered 4) becomes II.1
>
> 2. Forget about the part numbers: what is currently the first chapter of
> part II (numbered 4) remains numbered 4.
If I understand this correctly, this just means that we get a sequential
numbering of chapters? This seems to be exactly what was up as P5 HTML
up to now. On http://www.tei-c.org/release/doc/tei-p5-doc/html/ for
example, there are no part numbers, at least not at some visible place,
i.e. in the left sidebar.
This seems to be the least intrusive option to me, so you have my
support for it.
> We concluded:
>
> We will begin by adopting option 2 above. This is by far the simplest
> solution if we want to get out reasonable looking and accessible HTML in
> the near future. It also leaves room for us to group and regroup
> chapters without major upheaval.
>
> The downside is that those who have got accustomed to thinking of
> chapter CH as chapter 4 will have to get reprogrammed. But they have
> quite a lot of reprogramming to endure anyway.
This does not seems to be a conclusion of Option 2, but rather of the
further action you proposed. Since that is not spelled out here, I take
it that you will present your plans on this in more details later.

Christian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Feb 27 2007 - 19:31:49 EST

From daniel.odonnell at uleth.ca Wed Feb 28 01:48:58 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 27 Feb 2007 23:48:58 -0700 Subject: [tei-council] P5 internal structure In-Reply-To: <45E46CEC.6000203@kcl.ac.uk> Message-ID: <1172645339.11179.28.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 27 Feb 2007 23:48:58 -0700
I'm in favour of option 2 as well, but agree with Christian that in
principle it doesn't seem to me to involve massive changes from the
current output as it is visible to the user unless we start messing with
the order of the chapters as well... which seems to me to be a different
issue.
The immediate question for the milestone is the part vs./+ chapter
division, not the order of the chapters IMO. Once we know the level
issue, the HTML/PDF output teams can start work on the stylesheets and
design, regardless of the editorial order (which seems to me to be an
editorial issue).
-d
On Tue, 2007-02-27 at 17:39 +0000, Arianna Ciula wrote:
> It is a pity to loose the old chapters references, but if the overall
> HTML structure can benefit and be improved the modifications are more
> than welcome.
>
> Arianna
>
> Lou Burnard wrote:
> > Sebastian and I were actioned to determine what to do about the
> > formatting problems in generating HTML from the newly vanilla-div
> > structured P5 whilst in Lithuania.
> >
> > We discussed the following options:
> >
> > 0. Top level divs are numbered I to VIII; second level divs are numbered
> > 1 to 39. what is currently the first chapter of part II (numbered 4)
> > remains numbered 4.
> >
> > 1. Combine top and subsequent level divs: what is currently the first
> > chapter of part II (numbered 4) becomes II.1
> >
> > 2. Forget about the part numbers: what is currently the first chapter of
> > part II (numbered 4) remains numbered 4.
> >
> > 3. Special case the first chapter in each part so that it does something
> > magical to produce an extra blank page, possibly with an extra heading
> > or something.
> >
> > We observed that:
> >
> > (a) the current structure is in need of overhaul -- some of the chapters
> > are very small and others very large; some closely related material
> > (e.g. CH and WD) is widely separated; the distinction between "core" and
> > "additional" tagsets is defunct.
> >
> > (b) the chapters that define modules should probably be separated from
> > those which don't, both by numbering and form of title. Some of the
> > current introductory material could move into the ; some of the
> > current "technical material" could move into the .
> >
> > We concluded:
> >
> > We will begin by adopting option 2 above. This is by far the simplest
> > solution if we want to get out reasonable looking and accessible HTML in
> > the near future. It also leaves room for us to group and regroup
> > chapters without major upheaval.
> >
> > The downside is that those who have got accustomed to thinking of
> > chapter CH as chapter 4 will have to get reprogrammed. But they have
> > quite a lot of reprogramming to endure anyway.
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Feb 28 2007 - 01:49:08 EST
From daniel.odonnell at uleth.ca Wed Feb 28 01:54:41 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 27 Feb 2007 23:54:41 -0700 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> Message-ID: <1172645681.11179.35.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 27 Feb 2007 23:54:41 -0700
I wonder if this might not need more than just two people: there are a
number of issues here: information design, layout, output formats (HTML
+/or PDF), stylesheet design, etc., etc., etc.
It seems to me that this might profitably be seen as a group of people
working under a lead who take complete ownership of the problem and
deliver by the milestone.
There are other groups/deadlines coming. You can see them at the Trac
site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap
If Dot and James want to lead this that would be superb. But perhaps we
could put together a larger workgroup?
-dan
On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote:
> Hi Council,
>
> James and I volunteer for this task. We feel that we'll be more
> effective working together than either of us would be separately (that
> and James still need to finish up an initial draft of Conformance).
>
> Dot
>
> On 2/27/07, Sebastian Rahtz ox.ac.uk> wrote:
> > Who would like to step up to the plate
> > and pick one of the plum jobs from the list?
> >
> > The task is nothing less than to design the
> > layout of the Guidelines. The first requirement
> > is to do the web version, then look at print
> > if it is going well.
> >
> > The input is XHTML coming an XSLT
> > transform of P5; you can change that XSLT too,
> > but the first task is probably just to
> > take over the CSS and make better-looking pages.
> >
> > Obviously whoever takes this on has to be prepared
> > to defend the results to a sceptical Council,
> > so a certain amount of hard-heartedness is required.
> > You also have to be prepared to work through
> > the nitty grit of what information is in an ODD
> > and how best to present it.
> >
> > Only one caveat - the result cannot just be a lovely
> > HTML page, with an instruction saying "go make
> > it look like that". Finished product required.
> >
> > Go on, someone on the Council wants this task.
> > Step forward and claim it!
> >
> > --
> > Sebastian Rahtz
> >
> > Information Manager, Oxford University Computing Services
> > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> >
> > OSS Watch: JISC Open Source Advisory Service
> > http://www.oss-watch.ac.uk
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Feb 28 2007 - 01:54:45 EST
From James.Cummings at computing-services.oxford.ac.uk Wed Feb 28 03:01:01 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 28 Feb 2007 08:01:01 +0000 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <1172645681.11179.35.camel@localhost> Message-ID: <45E536BD.1050801@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 28 Feb 2007 08:01:01 +0000
Daniel O'Donnell wrote:
> I wonder if this might not need more than just two people: there are a
> number of issues here: information design, layout, output formats (HTML
> +/or PDF), stylesheet design, etc., etc., etc.
>
> It seems to me that this might profitably be seen as a group of people
> working under a lead who take complete ownership of the problem and
> deliver by the milestone.
>
> There are other groups/deadlines coming. You can see them at the Trac
> site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap
>
> If Dot and James want to lead this that would be superb. But perhaps we
> could put together a larger workgroup?
I think that this already is the case in some ways. The council as a whole is
the larger workgroup. If Dot and I work in a focused fashion to produce
something and then report back to Council, for opinions, etc., then revise what
we've produced with those suggestions in mind, then that has the same effect in
many ways. Rather than splintering the task amongst a larger number of people,
I wanted to keep it fairly tightly-knit. As you say there are lots of other
milestones that need working on, and if Dot and I take away this one, then some
of the other council members can work on the more important ones! But of course
we're happy to do this however council feels, or let someone else do it if there
are other volunteers, etc.
-James

>
> -dan
> On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote:
>> Hi Council,
>>
>> James and I volunteer for this task. We feel that we'll be more
>> effective working together than either of us would be separately (that
>> and James still need to finish up an initial draft of Conformance).
>>
>> Dot
>>
>> On 2/27/07, Sebastian Rahtz ox.ac.uk> wrote:
>>> Who would like to step up to the plate
>>> and pick one of the plum jobs from the list?
>>>
>>> The task is nothing less than to design the
>>> layout of the Guidelines. The first requirement
>>> is to do the web version, then look at print
>>> if it is going well.
>>>
>>> The input is XHTML coming an XSLT
>>> transform of P5; you can change that XSLT too,
>>> but the first task is probably just to
>>> take over the CSS and make better-looking pages.
>>>
>>> Obviously whoever takes this on has to be prepared
>>> to defend the results to a sceptical Council,
>>> so a certain amount of hard-heartedness is required.
>>> You also have to be prepared to work through
>>> the nitty grit of what information is in an ODD
>>> and how best to present it.
>>>
>>> Only one caveat - the result cannot just be a lovely
>>> HTML page, with an instruction saying "go make
>>> it look like that". Finished product required.
>>>
>>> Go on, someone on the Council wants this task.
>>> Step forward and claim it!
>>>
>>> --
>>> Sebastian Rahtz
>>>
>>> Information Manager, Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> OSS Watch: JISC Open Source Advisory Service
>>> http://www.oss-watch.ac.uk
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Feb 28 2007 - 03:01:08 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 28 06:02:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Feb 2007 11:02:58 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <1172645339.11179.28.camel@localhost> Message-ID: <45E56162.30901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 28 Feb 2007 11:02:58 +0000
Daniel O'Donnell wrote:
> I'm in favour of option 2 as well, but agree with Christian that in
> principle it doesn't seem to me to involve massive changes from the
> current output as it is visible to the user unless we start messing with
> the order of the chapters as well... which seems to me to be a different
> issue.
>
I think it is almost inconceivable that the list of chapters
will remain the same as it is today, and very likely the order
will change too. It only takes 5 minutes staring at
the current TOC to see it can be bettered....
> The immediate question for the milestone is the part vs./+ chapter
> division
I have not yet heard a dissenting voice which wants
to keep the "Part" structure.
anyway, whatever happens, the chapter is the main unit,
for design purposes.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Feb 28 2007 - 06:03:03 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 28 06:04:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Feb 2007 11:04:19 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4CD3F.9050305@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45E561B3.60407@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 28 Feb 2007 11:04:19 +0000
Christian Wittern wrote:
>
> This does not seems to be a conclusion of Option 2, but rather of the
> further action you proposed. Since that is not spelled out here, I
> take it that you will present your plans on this in more details later.
since we have already deleted chapters, it is foregone conclusion that
chapter numbering will not be the same as P4...
Sebasstian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Feb 28 2007 - 06:04:23 EST
From daniel.odonnell at uleth.ca Wed Feb 28 14:45:46 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 28 Feb 2007 12:45:46 -0700 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E536BD.1050801@computing-services.oxford.ac.uk> Message-ID: <1172691946.12701.27.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 28 Feb 2007 12:45:46 -0700
Sounds fine. If I've learned anything it's not to get between tasks and
volunteers ;)
-dan
On Wed, 2007-28-02 at 08:01 +0000, James Cummings wrote:
> Daniel O'Donnell wrote:
> > I wonder if this might not need more than just two people: there are a
> > number of issues here: information design, layout, output formats (HTML
> > +/or PDF), stylesheet design, etc., etc., etc.
> >
> > It seems to me that this might profitably be seen as a group of people
> > working under a lead who take complete ownership of the problem and
> > deliver by the milestone.
> >
> > There are other groups/deadlines coming. You can see them at the Trac
> > site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap
> >
> > If Dot and James want to lead this that would be superb. But perhaps we
> > could put together a larger workgroup?
>
> I think that this already is the case in some ways. The council as a whole is
> the larger workgroup. If Dot and I work in a focused fashion to produce
> something and then report back to Council, for opinions, etc., then revise what
> we've produced with those suggestions in mind, then that has the same effect in
> many ways. Rather than splintering the task amongst a larger number of people,
> I wanted to keep it fairly tightly-knit. As you say there are lots of other
> milestones that need working on, and if Dot and I take away this one, then some
> of the other council members can work on the more important ones! But of course
> we're happy to do this however council feels, or let someone else do it if there
> are other volunteers, etc.
>
> -James
>
>
> >
> > -dan
> > On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote:
> >> Hi Council,
> >>
> >> James and I volunteer for this task. We feel that we'll be more
> >> effective working together than either of us would be separately (that
> >> and James still need to finish up an initial draft of Conformance).
> >>
> >> Dot
> >>
> >> On 2/27/07, Sebastian Rahtz ox.ac.uk> wrote:
> >>> Who would like to step up to the plate
> >>> and pick one of the plum jobs from the list?
> >>>
> >>> The task is nothing less than to design the
> >>> layout of the Guidelines. The first requirement
> >>> is to do the web version, then look at print
> >>> if it is going well.
> >>>
> >>> The input is XHTML coming an XSLT
> >>> transform of P5; you can change that XSLT too,
> >>> but the first task is probably just to
> >>> take over the CSS and make better-looking pages.
> >>>
> >>> Obviously whoever takes this on has to be prepared
> >>> to defend the results to a sceptical Council,
> >>> so a certain amount of hard-heartedness is required.
> >>> You also have to be prepared to work through
> >>> the nitty grit of what information is in an ODD
> >>> and how best to present it.
> >>>
> >>> Only one caveat - the result cannot just be a lovely
> >>> HTML page, with an instruction saying "go make
> >>> it look like that". Finished product required.
> >>>
> >>> Go on, someone on the Council wants this task.
> >>> Step forward and claim it!
> >>>
> >>> --
> >>> Sebastian Rahtz
> >>>
> >>> Information Manager, Oxford University Computing Services
> >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> >>>
> >>> OSS Watch: JISC Open Source Advisory Service
> >>> http://www.oss-watch.ac.uk
> >>>
> >>> _______________________________________________
> >>> tei-council mailing list
> >>> tei-council_at_lists.village.Virginia.EDU
> >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >>>
> >>
>
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Feb 28 2007 - 14:41:06 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Feb 28 19:41:18 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 01 Mar 2007 08:41:18 +0800 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E536BD.1050801@computing-services.oxford.ac.uk> Message-ID: <45E6212E.5090907@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Thu, 01 Mar 2007 08:41:18 +0800
James Cummings wrote:
> Daniel O'Donnell wrote:
>> I wonder if this might not need more than just two people: there are a
>> number of issues here: information design, layout, output formats (HTML
>> +/or PDF), stylesheet design, etc., etc., etc.
>>
>> It seems to me that this might profitably be seen as a group of people
>> working under a lead who take complete ownership of the problem and
>> deliver by the milestone.
>>
>> There are other groups/deadlines coming. You can see them at the Trac
>> site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap
>>
>> If Dot and James want to lead this that would be superb. But perhaps we
>> could put together a larger workgroup?
>
> I think that this already is the case in some ways. The council as a
> whole is the larger workgroup. If Dot and I work in a focused fashion
> to produce something and then report back to Council, for opinions,
> etc., then revise what we've produced with those suggestions in mind,
> then that has the same effect in many ways. Rather than splintering the
> task amongst a larger number of people, I wanted to keep it fairly
> tightly-knit. As you say there are lots of other milestones that need
> working on, and if Dot and I take away this one, then some of the other
> council members can work on the more important ones! But of course
> we're happy to do this however council feels, or let someone else do it
> if there are other volunteers, etc.
Well said.
Now, the next step would be to go to trac
http://tei.oucs.ox.ac.uk/trac.cgi/ and take ownership of the relevant
tickets.
At this point,
"Milestone Decide on final output format (especially for reference
section)" looks like the right one to me, but you might check that with
Sebastian. If you have a more detailed plan of the issues involved,
and the way you want to proceed, we would appreciate if you also tell
trac about it and let us see it.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Feb 28 2007 - 19:41:33 EST

From James.Cummings at computing-services.oxford.ac.uk Thu Mar 1 04:18:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 01 Mar 2007 09:18:48 +0000 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E6212E.5090907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45E69A78.3060209@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 01 Mar 2007 09:18:48 +0000
Christian Wittern wrote:
> Now, the next step would be to go to trac
> http://tei.oucs.ox.ac.uk/trac.cgi/ and take ownership of the relevant
> tickets.
> At this point,
> "Milestone Decide on final output format (especially for reference
> section)" looks like the right one to me, but you might check that with
> Sebastian. If you have a more detailed plan of the issues involved,
> and the way you want to proceed, we would appreciate if you also tell
> trac about it and let us see it.
I've reassigned that one to me for now. No detailed plan of attack yet.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 01 2007 - 04:22:08 EST
From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 05:59:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 10:59:16 +0000 Subject: [tei-council] release 0.6 looming Message-ID: <45E6B204.8040008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 01 Mar 2007 10:59:16 +0000
I'd like to make a new release of P5 in a couple of weeks.
If anyone feels this would be a bad idea, or is desparate
to finish something off to get it in now, please speak now.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 01 2007 - 05:59:18 EST
From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 07:30:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 12:30:32 +0000 Subject: [tei-council] work for March Message-ID: <45E6C768.1080400@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 01 Mar 2007 12:30:32 +0000
Happy St David's Day.
Looking at the plan of work scheduled for March, it goes as follows:
* (end of tasks relating to feature requests, 12 hours to go)
* design output format (JC and DP now on case)
* review datatype and class decisions
* proofread text looking for DTD and P4 language
the latter two involve taking each chapter, looking
for problems and ideally dealing with them. In most
cases it will just a matter of someone signing off a
chapter as having a clean bill of health. If something
comes out which cannot be dealt with in (say)
an hours work rewriting a paragraph, or making
a simple decision about a datatype, then it should
be broken out to a new task which can assigned its
own deadline and so on.
I think its "adopt a chapter" day again.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 01 2007 - 07:30:36 EST
From Syd_Bauman at Brown.edu Thu Mar 1 15:51:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 15:51:57 -0500 Subject: [tei-council] data.multipleEnumerated Message-ID: <17895.15597.17871.698362@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 1 Mar 2007 15:51:57 -0500
Sebastian --
Is there any chance of implementing a repeatable enumeration?

This would be a change to ODD such that there is some mechanism
(e.g., a 'repeatable="yes"' attribute on ) to define an
enumeration of possible attribute values which could be repeated,
i.e. instead of boiling down to
( "list" | "of" | "valItem" | "idents" )
would boil down to
list { ( "list" | "of" | "valItem" | "idents")+ }
This would permit one or more of the listed values to be specified
(with repetition possible), but still flag as invalid any value not
in the list. Thus, given the above declarations the values
"idents"
"valItem idents"
"of list of idents"
are valid, but
"valitem"
"List of"
"1724"
are not.
This mechanism would be very useful in the declaration of several
attributes. E.g., type= of , which currently has a fragment
of Relax NG in the , could be re-written declaratively:





Although TEI would not use it for vanilla P5, one could well imagine
users creating ODDs for their projects taking advantage of this
mechanism for their local constraint of rend=:





italics
boldface
small caps
larger than surrounding text
smaller than surrounding text


Council --
Is there any reason to avoid doing so?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 01 2007 - 15:52:21 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 16:14:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 21:14:22 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.15597.17871.698362@emt.wwp.brown.edu> Message-ID: <45E7422E.1080304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 01 Mar 2007 21:14:22 +0000
Syd Bauman wrote:
> Is there any chance of implementing a repeatable enumeration?
>
from my point of view, no real problem (though surely repeatable='true' not
repeatable='yes'?)
> would boil down to
>
> list { ( "list" | "of" | "valItem" | "idents")+ }
>
though I note that this _isnt_ the implementation
you use in the example.
Have you experimented to see what happens
when you run trang on such an RNG to make an XSD?
Does XSD support the idea?
Why don't you send me a self-contained .odd
using the feature, and we can see what happens.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 01 2007 - 16:14:32 EST
From Syd_Bauman at Brown.edu Thu Mar 1 16:41:33 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 16:41:33 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E7422E.1080304@oucs.ox.ac.uk> Message-ID: <17895.18573.501993.355439@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 1 Mar 2007 16:41:33 -0500
> from my point of view, no real problem (though surely repeatable='true' not
> repeatable='yes'?)
Sure. I don't care. Whatever data.truthValue uses.

> > would boil down to
> > list { ( "list" | "of" | "valItem" | "idents")+ }
> though I note that this _isnt_ the implementation
> you use in the example.
It isn't? (I thought the example did not provide an
implementation, just a fragment of ODD; the current element
specification does exactly this with a fragment of Relax NG, I
thought.)

> Have you experimented to see what happens when you run trang on
> such an RNG to make an XSD? Does XSD support the idea?
No, and I don't know.

> Why don't you send me a self-contained .odd
> using the feature, and we can see what happens.
Just to double-check that I understand what you mean -- you want an
ODD file that pretends repeatable="true" is available?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 01 2007 - 16:41:37 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 17:00:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 22:00:24 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.18573.501993.355439@emt.wwp.brown.edu> Message-ID: <45E74CF8.80709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 01 Mar 2007 22:00:24 +0000
Syd Bauman wrote:
>> though I note that this _isnt_ the implementation
>> you use in the example.
>>
>
> It isn't? (I thought the example did not provide an
> implementation, just a fragment of ODD; the current element
> specification does exactly this with a fragment of Relax NG, I
> thought.)
>
I may be misunderstanding. You want me to generate
RELAXNG comparable to that in ? I vaguely
thought you want a relaxng-specific lists of lists.
> Just to double-check that I understand what you mean -- you want an
> ODD file that pretends repeatable="true" is available?
>
yes, and a test file so that we can see if it fires.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 01 2007 - 17:00:29 EST
From Syd_Bauman at Brown.edu Thu Mar 1 21:33:00 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 21:33:00 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E74CF8.80709@oucs.ox.ac.uk> Message-ID: <17895.36060.877962.886648@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 1 Mar 2007 21:33:00 -0500
> I may be misunderstanding. You want me to generate RELAXNG
> comparable to that in ? I vaguely thought you want a
> relaxng-specific lists of lists.
I don't know if it's Relax NG specific or not, but it's a list of
alternate values (repeatable), not a list of lists. Yes, I think it
is exactly like what has.

> > Just to double-check that I understand what you mean -- you want an
> > ODD file that pretends repeatable="true" is available?
> >
> yes, and a test file so that we can see if it fires.
OK. The file
http://bauman.zapto.org/~syd/temp/multipleEnumerated.tgz
contains:
multipleEnumerated/tei_rep_enu.odd:
ODD file with repeatable="true" on type= of
multipleEnumerated/tei_rep_enu.xml
XML instance that should be valid against schemas generated
from the above ODD *except* for those elements
that have "invalid" in their type= values.
Plus the following two schemas, which were generated from
command-line roma[1] without repeatable="true" and then tweaked
by hand to do the right thing:
multipleEnumerated/tei_rep_enu.rnc
multipleEnumerated/tei_rep_enu.rng
Note
---- [1] When I tried to use web-Roma to generate output schemas by uploading the ODD, I got Fatal error: Call to a member function hasChildNodes() on a non-object in /usr/share/tei-roma/roma/romadom.php on line 1851 as soon as I clicked "Submit" on the "Set your parameters" page. _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 01 2007 - 21:33:06 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 2 04:39:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 02 Mar 2007 09:39:45 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.36060.877962.886648@emt.wwp.brown.edu> Message-ID: <45E7F0E1.3000202@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 02 Mar 2007 09:39:45 +0000
Duly implemented and minimally tested; XSD and RELAXNG give right result,
DTD falls back to CDATA
See new P5/Test/testmultenu.* files
changes to XSL committed to Subversion.
Am running full test now.
Assuming no backlash or problem, Syd, you'll
need to hack the ODD to add the new attribute
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 02 2007 - 04:39:48 EST
From Syd_Bauman at Brown.edu Fri Mar 2 09:41:51 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 2 Mar 2007 09:41:51 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E7F0E1.3000202@oucs.ox.ac.uk> Message-ID: <17896.14255.131808.963811@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 2 Mar 2007 09:41:51 -0500
> Duly implemented and minimally tested; XSD and RELAXNG give right
> result, DTD falls back to CDATA
> See new P5/Test/testmultenu.* files
> changes to XSL committed to Subversion.
> Am running full test now.
Excellent, thank you Sebastian. So if anyone has any objection to
this, the time to speak up is NOW.
I'm running `make dist` in Stylesheets now, will test shortly.

> Assuming no backlash or problem, Syd, you'll need to hack the
> ODD to add the new attribute
OK.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 02 2007 - 09:41:54 EST

From arianna.ciula at kcl.ac.uk Mon Mar 5 07:51:33 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 05 Mar 2007 12:51:33 +0000 Subject: [tei-council] Digital Diplomatics conference Message-ID: <45EC1255.1060303@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 05 Mar 2007 12:51:33 +0000
Dear council,
For whom is interested, I just wanted to report briefly on the
conference I came back from on Saturday: Digital Diplomatics
http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
The international attendance was quite good with a majority of Germans
of course.
The majority of presented projects deal with a combination of relational
database and use of XML (lots of TEI!).
Few things to mention as far as TEI regards:
Interesting presentations
- good work done by two Italian students using TEI P5 (poster: Viviana
Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
del 1264)
- presentation of ODD by Gautier Poupeau
- integration TEI-CIDOC presented by Christian-Emil Ore
TEI/CEI
As you may know already, the objective of the conference was to give a
glimpse on digital projects related to medieval documents (it succeeded
on this) and to work on the improvements of the CEI (Charter Encoding
Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
standard to encode these documents in XML. Unfortunately, despite the
good work of synthesis and conceptual modelling done by Patrick Sahle
and Gautier Poupeau, we didn't go very far on the latter, but it seems
to me that
- despite some more or less funded complains on the inability of TEI to
represented the archival community and its objectives, all the CEI
recommendations as they stand could easily been translated and/or
represented in TEI P5
- I will keep an eye on how the community is going to develop the
standard and see what comes up
Happy to give more details to whom is interested.
All the best,
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 05 2007 - 07:54:36 EST
From daniel.odonnell at uleth.ca Mon Mar 5 13:03:58 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 05 Mar 2007 11:03:58 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45EC1255.1060303@kcl.ac.uk> Message-ID: <1173117838.11758.7.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 05 Mar 2007 11:03:58 -0700
Thank you very much for this, Arianna. These kind of reports are always
very interesting.
-dan
On Mon, 2007-05-03 at 12:51 +0000, Arianna Ciula wrote:
> Dear council,
>
> For whom is interested, I just wanted to report briefly on the
> conference I came back from on Saturday: Digital Diplomatics
> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
>
> The international attendance was quite good with a majority of Germans
> of course.
>
> The majority of presented projects deal with a combination of relational
> database and use of XML (lots of TEI!).
>
> Few things to mention as far as TEI regards:
>
> Interesting presentations
> - good work done by two Italian students using TEI P5 (poster: Viviana
> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
> del 1264)
> - presentation of ODD by Gautier Poupeau
> - integration TEI-CIDOC presented by Christian-Emil Ore
>
> TEI/CEI
> As you may know already, the objective of the conference was to give a
> glimpse on digital projects related to medieval documents (it succeeded
> on this) and to work on the improvements of the CEI (Charter Encoding
> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
> standard to encode these documents in XML. Unfortunately, despite the
> good work of synthesis and conceptual modelling done by Patrick Sahle
> and Gautier Poupeau, we didn't go very far on the latter, but it seems
> to me that
> - despite some more or less funded complains on the inability of TEI to
> represented the archival community and its objectives, all the CEI
> recommendations as they stand could easily been translated and/or
> represented in TEI P5
> - I will keep an eye on how the community is going to develop the
> standard and see what comes up
>
> Happy to give more details to whom is interested.
> All the best,
>
> Arianna
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 05 2007 - 12:58:41 EST
From lou.burnard at computing-services.oxford.ac.uk Mon Mar 5 18:03:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 05 Mar 2007 23:03:35 +0000 Subject: [tei-council] SFFR 1007370 Theorem Message-ID: <45ECA1C7.9080000@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 05 Mar 2007 23:03:35 +0000
I believe I have already asked for input from Council about this item.
On the one hand, I think the proposal has some interesting merits. On
the other, I am not sure that the proposal is sufficiently mature and
worked out to be easily integrated into P5 1.0 -- which means that I
need guidance from the Council as to whether or not it should be
prioritized above (say) floating texts, ms abbreviations/expansions, or
the generic place element.
Unless I hear otherwise within the next 48 hours therefore, I will
close this ticket off with a note to the effect that it's scheduled for
consideration at release 1.1 but not before.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 05 2007 - 18:03:40 EST
From dporter at uky.edu Mon Mar 5 18:42:41 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 5 Mar 2007 15:42:41 -0800 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45EC1255.1060303@kcl.ac.uk> Message-ID: <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com>
From: Dot Porter
Date: Mon, 5 Mar 2007 15:42:41 -0800
Hi Arianna,
At the TEI member's meeting, you and I and a few other people were
talking about reviving the Transcription SIG, which seems to have
faded a way for a while. Are you interested? The CEI might be a good
point to start off on - will you be at the DH conference this summer?
Dot
On 3/5/07, Arianna Ciula ac.uk> wrote:
> Dear council,
>
> For whom is interested, I just wanted to report briefly on the
> conference I came back from on Saturday: Digital Diplomatics
> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
>
> The international attendance was quite good with a majority of Germans
> of course.
>
> The majority of presented projects deal with a combination of relational
> database and use of XML (lots of TEI!).
>
> Few things to mention as far as TEI regards:
>
> Interesting presentations
> - good work done by two Italian students using TEI P5 (poster: Viviana
> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
> del 1264)
> - presentation of ODD by Gautier Poupeau
> - integration TEI-CIDOC presented by Christian-Emil Ore
>
> TEI/CEI
> As you may know already, the objective of the conference was to give a
> glimpse on digital projects related to medieval documents (it succeeded
> on this) and to work on the improvements of the CEI (Charter Encoding
> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
> standard to encode these documents in XML. Unfortunately, despite the
> good work of synthesis and conceptual modelling done by Patrick Sahle
> and Gautier Poupeau, we didn't go very far on the latter, but it seems
> to me that
> - despite some more or less funded complains on the inability of TEI to
> represented the archival community and its objectives, all the CEI
> recommendations as they stand could easily been translated and/or
> represented in TEI P5
> - I will keep an eye on how the community is going to develop the
> standard and see what comes up
>
> Happy to give more details to whom is interested.
> All the best,
>
> Arianna
> --
> Dr Arianna Ciula
> Research Associate
> Centre for Computing in the Humanities
> King's College London
> Strand
> London WC2R 2LS (UK)
> Tel: +44 (0)20 78481945
> http://www.kcl.ac.uk/cch
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 05 2007 - 18:42:44 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Mar 6 02:33:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 06 Mar 2007 15:33:43 +0800 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ECA1C7.9080000@computing-services.oxford.ac.uk> Message-ID: <45ED1957.501@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 06 Mar 2007 15:33:43 +0800
Lou Burnard wrote:
> I believe I have already asked for input from Council about this item.
> On the one hand, I think the proposal has some interesting merits. On
> the other, I am not sure that the proposal is sufficiently mature and
> worked out to be easily integrated into P5 1.0 -- which means that I
> need guidance from the Council as to whether or not it should be
> prioritized above (say) floating texts, ms abbreviations/expansions, or
> the generic place element.
in my book, theorem would come after the above mentioned in terms of
priority.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 06 2007 - 03:03:41 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 6 04:37:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 6 Mar 2007 09:37:29 +0000 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ECA1C7.9080000@computing-services.oxford.ac.uk> Message-ID: <20070306093729.GD31263@raven.linux.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 6 Mar 2007 09:37:29 +0000
> worked out to be easily integrated into P5 1.0 -- which means that I
> need guidance from the Council as to whether or not it should be
> prioritized above (say) floating texts, ms abbreviations/expansions, or
> the generic place element.
no contest. put theorem on the backburner
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Mar 06 2007 - 04:37:32 EST
From arianna.ciula at kcl.ac.uk Tue Mar 6 04:57:28 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 06 Mar 2007 09:57:28 +0000 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> Message-ID: <45ED3B08.8090107@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 06 Mar 2007 09:57:28 +0000
Hi Dot,
I remember talking about the Manuscript SIG. Is this what you mean by
Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about
the former and I gave a sort of availability in case nobody was prepared
to chair it.
Should we discuss this out of list with Roberto as well and see what we
could do and report back?
Arianna
Dot Porter wrote:
> Hi Arianna,
>
> At the TEI member's meeting, you and I and a few other people were
> talking about reviving the Transcription SIG, which seems to have
> faded a way for a while. Are you interested? The CEI might be a good
> point to start off on - will you be at the DH conference this summer?
>
> Dot
>
> On 3/5/07, Arianna Ciula ac.uk> wrote:
>> Dear council,
>>
>> For whom is interested, I just wanted to report briefly on the
>> conference I came back from on Saturday: Digital Diplomatics
>> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
>>
>> The international attendance was quite good with a majority of Germans
>> of course.
>>
>> The majority of presented projects deal with a combination of relational
>> database and use of XML (lots of TEI!).
>>
>> Few things to mention as far as TEI regards:
>>
>> Interesting presentations
>> - good work done by two Italian students using TEI P5 (poster: Viviana
>> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
>> del 1264)
>> - presentation of ODD by Gautier Poupeau
>> - integration TEI-CIDOC presented by Christian-Emil Ore
>>
>> TEI/CEI
>> As you may know already, the objective of the conference was to give a
>> glimpse on digital projects related to medieval documents (it succeeded
>> on this) and to work on the improvements of the CEI (Charter Encoding
>> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
>> standard to encode these documents in XML. Unfortunately, despite the
>> good work of synthesis and conceptual modelling done by Patrick Sahle
>> and Gautier Poupeau, we didn't go very far on the latter, but it seems
>> to me that
>> - despite some more or less funded complains on the inability of TEI to
>> represented the archival community and its objectives, all the CEI
>> recommendations as they stand could easily been translated and/or
>> represented in TEI P5
>> - I will keep an eye on how the community is going to develop the
>> standard and see what comes up
>>
>> Happy to give more details to whom is interested.
>> All the best,
>>
>> Arianna
>> --
>> Dr Arianna Ciula
>> Research Associate
>> Centre for Computing in the Humanities
>> King's College London
>> Strand
>> London WC2R 2LS (UK)
>> Tel: +44 (0)20 78481945
>> http://www.kcl.ac.uk/cch
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 06 2007 - 04:57:38 EST
From James.Cummings at computing-services.oxford.ac.uk Tue Mar 6 05:19:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 06 Mar 2007 10:19:21 +0000 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <20070306093729.GD31263@raven.linux.ox.ac.uk> Message-ID: <45ED4029.7000403@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 06 Mar 2007 10:19:21 +0000
Sebastian Rahtz wrote:
>> worked out to be easily integrated into P5 1.0 -- which means that I
>> need guidance from the Council as to whether or not it should be
>> prioritized above (say) floating texts, ms abbreviations/expansions, or
>> the generic place element.
>
> no contest. put theorem on the backburner
Ditto what Sebastian and Christian said.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 06 2007 - 05:19:25 EST
From dporter at uky.edu Tue Mar 6 06:06:13 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 6 Mar 2007 03:06:13 -0800 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45ED3B08.8090107@kcl.ac.uk> Message-ID: <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com>
From: Dot Porter
Date: Tue, 6 Mar 2007 03:06:13 -0800
Hi Arianna,
Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my
"TEI Chapter on Transcription of Primary Sources"). Any objections if
Arianna and I take our discussion off-list? Any other takers?
Dot
On 3/6/07, Arianna Ciula ac.uk> wrote:
> Hi Dot,
>
> I remember talking about the Manuscript SIG. Is this what you mean by
> Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about
> the former and I gave a sort of availability in case nobody was prepared
> to chair it.
>
> Should we discuss this out of list with Roberto as well and see what we
> could do and report back?
>
> Arianna
>
> Dot Porter wrote:
> > Hi Arianna,
> >
> > At the TEI member's meeting, you and I and a few other people were
> > talking about reviving the Transcription SIG, which seems to have
> > faded a way for a while. Are you interested? The CEI might be a good
> > point to start off on - will you be at the DH conference this summer?
> >
> > Dot
> >
> > On 3/5/07, Arianna Ciula ac.uk> wrote:
> >> Dear council,
> >>
> >> For whom is interested, I just wanted to report briefly on the
> >> conference I came back from on Saturday: Digital Diplomatics
> >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
> >>
> >> The international attendance was quite good with a majority of Germans
> >> of course.
> >>
> >> The majority of presented projects deal with a combination of relational
> >> database and use of XML (lots of TEI!).
> >>
> >> Few things to mention as far as TEI regards:
> >>
> >> Interesting presentations
> >> - good work done by two Italian students using TEI P5 (poster: Viviana
> >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
> >> del 1264)
> >> - presentation of ODD by Gautier Poupeau
> >> - integration TEI-CIDOC presented by Christian-Emil Ore
> >>
> >> TEI/CEI
> >> As you may know already, the objective of the conference was to give a
> >> glimpse on digital projects related to medieval documents (it succeeded
> >> on this) and to work on the improvements of the CEI (Charter Encoding
> >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
> >> standard to encode these documents in XML. Unfortunately, despite the
> >> good work of synthesis and conceptual modelling done by Patrick Sahle
> >> and Gautier Poupeau, we didn't go very far on the latter, but it seems
> >> to me that
> >> - despite some more or less funded complains on the inability of TEI to
> >> represented the archival community and its objectives, all the CEI
> >> recommendations as they stand could easily been translated and/or
> >> represented in TEI P5
> >> - I will keep an eye on how the community is going to develop the
> >> standard and see what comes up
> >>
> >> Happy to give more details to whom is interested.
> >> All the best,
> >>
> >> Arianna
> >> --
> >> Dr Arianna Ciula
> >> Research Associate
> >> Centre for Computing in the Humanities
> >> King's College London
> >> Strand
> >> London WC2R 2LS (UK)
> >> Tel: +44 (0)20 78481945
> >> http://www.kcl.ac.uk/cch
> >> _______________________________________________
> >> tei-council mailing list
> >> tei-council_at_lists.village.Virginia.EDU
> >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >>
> >
> >
>
> --
> Dr Arianna Ciula
> Research Associate
> Centre for Computing in the Humanities
> King's College London
> Strand
> London WC2R 2LS (UK)
> Tel: +44 (0)20 78481945
> http://www.kcl.ac.uk/cch
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 06 2007 - 06:06:17 EST

From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 07:25:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 12:25:11 +0000 Subject: [tei-council] Berlin meeting Message-ID: <45EEAF27.8000402@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 07 Mar 2007 12:25:11 +0000
Two quick timetabling questions:
(a) Will the Council meeting also be held in the Harnackhaus ("Zentrum
des "deutschen Oxford" :-))? if not, where?
(b) When do we expect that the Council meeting will end?
I am mostly concerned about the latter, as I need to book train tickets
soonish, either for the Friday or for the Saturday afternoon.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 07:25:30 EST

From laurent.romary at loria.fr Wed Mar 7 07:32:34 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 7 Mar 2007 13:32:34 +0100 Subject: [tei-council] Berlin meeting In-Reply-To: <45EEAF27.8000402@oucs.ox.ac.uk> Message-ID: <0F2BA1EB-05EC-402C-B1EE-2A5F1F7AD48B@loria.fr>
From: Laurent Romary
Date: Wed, 7 Mar 2007 13:32:34 +0100
The council meeting will take place at the BBAW, that is in the
center of Berlin. I will disseminate a list of hotels soon (I have a
flight in a few minutes, please be all patient until Friday...).
Laurent
Le 7 mars 07 ? 13:25, Lou Burnard a ?crit :
> Two quick timetabling questions:
>
> (a) Will the Council meeting also be held in the Harnackhaus
> ("Zentrum des "deutschen Oxford" :-))? if not, where?
>
> (b) When do we expect that the Council meeting will end?
>
> I am mostly concerned about the latter, as I need to book train
> tickets soonish, either for the Friday or for the Saturday afternoon.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 07:35:26 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 08:00:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 13:00:12 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] Message-ID: <45EEB75C.4010608@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 07 Mar 2007 13:00:12 +0000
This response from Laurent seems to have been bounced by the server for
some reason:

> Dear all,
> OK. I take a few extra minutes... here's a hotel list for our
> meetings in Berlin. I would suggest to try to pack all issues on
> Thu-Fri.
> Best,
> Laurent
>
>
> Hotel
> Lage
> EZ-Preis
> DZ-Preis
> Sonstiges
> Albrechtshof/Allegra***
>
> Albrechtstr. 8/17
> Hotels liegen vis ? vis
> U-/S-Bahn Friedrichstr. 2min,
>
> 15min zu Fu? zur BBAW
> 95/89 EUR
>
> 115/105 EUR
>
> inkl. Fr?hst?ck
>
> http://www.hotel-albrechtshof.de/
>
> http://www.hotel-allegra.de/
>
> Angleterre****
>
> Friedrichstra?e 31
>
>
>
> U-Bhf. Kochstr.
>
> 12min zu Fu? zur BBAW
>
> 80 EUR
>
> 104 EUR
>
> inkl. Fr?hst?ck
>
> http://www.gold-inn.de/
>
> Dietrich-Bonhoeffer-Haus***
>
> Ziegelstr. 30
>
> U6 Oranienburger Tor ca. 3min,
> U-/S-Bahn Friedrichstr. 5min
>
> 75 EUR
>
> 115 EUR
>
> inkl. Fr?hst?ck
>
> http://www.hotel-dbh.de/
>
> G?stehaus der Humboldt-Uni
>
> Ziegelstr. 13 a/b
> U6 Oranienburger Tor ca. 3min,
> U-/S-Bahn Friedrichstr. 5min
>
> 30 ? 35 EUR
>
> 60 EUR
>
> exkl. Fr?hst?ck
>
> Gendarm****
>
> Charlottenstr. 60/61
> U6 Stadtmitte 2min,
>
> U2 Stadtmitte 3min,
> 4min zu Fu?
> 112 EUR
>
> 132 EUR
>
> inkl. Fr?hst?ck
>
> http://www.hotel-gendarm-berlin.de/
>
> Mercure***
>
> Sch?tzenstr. 11
>
> U6 Kochstr. 4min,
>
> U6 Stadtmitte 5min
> 82 EUR
>
> 112 EUR
>
> inkl. Fr?hst?ck
>
> http://www.mercure.de/
> NH-Hotel**** (ehem. Astron)
>
> Leipziger Str. 106-111
> U6 Stadtmitte 2min,
>
> U2 Stadtmitte 4min,
> 8min zu Fu?
> 86 EUR
>
> 102 EUR
>
> inkl. Fr?hst?ck
>
> http://www.nh-hotels.com/
>
> Novotel***
>
> Fischerinsel 12
> U2 Spittelmarkt 3min,
>
> 15min zu Fu?
> 82 EUR
>
>
>
> 112 EUR
>
>
>
> inkl. Fr?hst?ck
>
> http://www.novotel.de/
>

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 08:00:30 EST

From dporter at uky.edu Wed Mar 7 08:12:44 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 7 Mar 2007 05:12:44 -0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEB75C.4010608@oucs.ox.ac.uk> Message-ID: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com>
From: Dot Porter
Date: Wed, 7 Mar 2007 05:12:44 -0800
Is there interest in coordinating hotel arrangements? I not terribly
keen on trying to make it around Berlin all on my lonesome :-)
Dot
On 3/7/07, Lou Burnard oxford.ac.uk> wrote:
> This response from Laurent seems to have been bounced by the server for
> some reason:
>
>
>
> > Dear all,
> > OK. I take a few extra minutes... here's a hotel list for our
> > meetings in Berlin. I would suggest to try to pack all issues on
> > Thu-Fri.
> > Best,
> > Laurent
> >
> >
> > Hotel
> > Lage
> > EZ-Preis
> > DZ-Preis
> > Sonstiges
> > Albrechtshof/Allegra***
> >
> > Albrechtstr. 8/17
> > Hotels liegen vis ? vis
> > U-/S-Bahn Friedrichstr. 2min,
> >
> > 15min zu Fu? zur BBAW
> > 95/89 EUR
> >
> > 115/105 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.hotel-albrechtshof.de/
> >
> > http://www.hotel-allegra.de/
> >
> > Angleterre****
> >
> > Friedrichstra?e 31
> >
> >
> >
> > U-Bhf. Kochstr.
> >
> > 12min zu Fu? zur BBAW
> >
> > 80 EUR
> >
> > 104 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.gold-inn.de/
> >
> > Dietrich-Bonhoeffer-Haus***
> >
> > Ziegelstr. 30
> >
> > U6 Oranienburger Tor ca. 3min,
> > U-/S-Bahn Friedrichstr. 5min
> >
> > 75 EUR
> >
> > 115 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.hotel-dbh.de/
> >
> > G?stehaus der Humboldt-Uni
> >
> > Ziegelstr. 13 a/b
> > U6 Oranienburger Tor ca. 3min,
> > U-/S-Bahn Friedrichstr. 5min
> >
> > 30 ? 35 EUR
> >
> > 60 EUR
> >
> > exkl. Fr?hst?ck
> >
> > Gendarm****
> >
> > Charlottenstr. 60/61
> > U6 Stadtmitte 2min,
> >
> > U2 Stadtmitte 3min,
> > 4min zu Fu?
> > 112 EUR
> >
> > 132 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.hotel-gendarm-berlin.de/
> >
> > Mercure***
> >
> > Sch?tzenstr. 11
> >
> > U6 Kochstr. 4min,
> >
> > U6 Stadtmitte 5min
> > 82 EUR
> >
> > 112 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.mercure.de/
> > NH-Hotel**** (ehem. Astron)
> >
> > Leipziger Str. 106-111
> > U6 Stadtmitte 2min,
> >
> > U2 Stadtmitte 4min,
> > 8min zu Fu?
> > 86 EUR
> >
> > 102 EUR
> >
> > inkl. Fr?hst?ck
> >
> > http://www.nh-hotels.com/
> >
> > Novotel***
> >
> > Fischerinsel 12
> > U2 Spittelmarkt 3min,
> >
> > 15min zu Fu?
> > 82 EUR
> >
> >
> >
> > 112 EUR
> >
> >
> >
> > inkl. Fr?hst?ck
> >
> > http://www.novotel.de/
> >
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 08:12:49 EST

From arianna.ciula at kcl.ac.uk Wed Mar 7 08:27:00 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 07 Mar 2007 13:27:00 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> Message-ID: <45EEBDA4.4040900@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 07 Mar 2007 13:27:00 +0000
I was going to ask the same.
Arianna
Dot Porter wrote:
> Is there interest in coordinating hotel arrangements? I not terribly
> keen on trying to make it around Berlin all on my lonesome :-)
>
> Dot
>
> On 3/7/07, Lou Burnard oxford.ac.uk> wrote:
>> This response from Laurent seems to have been bounced by the server for
>> some reason:
>>
>>
>>
>> > Dear all,
>> > OK. I take a few extra minutes... here's a hotel list for our
>> > meetings in Berlin. I would suggest to try to pack all issues on
>> > Thu-Fri.
>> > Best,
>> > Laurent
>> >
>> >
>> > Hotel
>> > Lage
>> > EZ-Preis
>> > DZ-Preis
>> > Sonstiges
>> > Albrechtshof/Allegra***
>> >
>> > Albrechtstr. 8/17
>> > Hotels liegen vis ?? vis
>> > U-/S-Bahn Friedrichstr. 2min,
>> >
>> > 15min zu Fu?? zur BBAW
>> > 95/89 EUR
>> >
>> > 115/105 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.hotel-albrechtshof.de/
>> >
>> > http://www.hotel-allegra.de/
>> >
>> > Angleterre****
>> >
>> > Friedrichstra??e 31
>> >
>> >
>> >
>> > U-Bhf. Kochstr.
>> >
>> > 12min zu Fu?? zur BBAW
>> >
>> > 80 EUR
>> >
>> > 104 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.gold-inn.de/
>> >
>> > Dietrich-Bonhoeffer-Haus***
>> >
>> > Ziegelstr. 30
>> >
>> > U6 Oranienburger Tor ca. 3min,
>> > U-/S-Bahn Friedrichstr. 5min
>> >
>> > 75 EUR
>> >
>> > 115 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.hotel-dbh.de/
>> >
>> > G??stehaus der Humboldt-Uni
>> >
>> > Ziegelstr. 13 a/b
>> > U6 Oranienburger Tor ca. 3min,
>> > U-/S-Bahn Friedrichstr. 5min
>> >
>> > 30 ??? 35 EUR
>> >
>> > 60 EUR
>> >
>> > exkl. Fr??hst??ck
>> >
>> > Gendarm****
>> >
>> > Charlottenstr. 60/61
>> > U6 Stadtmitte 2min,
>> >
>> > U2 Stadtmitte 3min,
>> > 4min zu Fu??
>> > 112 EUR
>> >
>> > 132 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.hotel-gendarm-berlin.de/
>> >
>> > Mercure***
>> >
>> > Sch??tzenstr. 11
>> >
>> > U6 Kochstr. 4min,
>> >
>> > U6 Stadtmitte 5min
>> > 82 EUR
>> >
>> > 112 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.mercure.de/
>> > NH-Hotel**** (ehem. Astron)
>> >
>> > Leipziger Str. 106-111
>> > U6 Stadtmitte 2min,
>> >
>> > U2 Stadtmitte 4min,
>> > 8min zu Fu??
>> > 86 EUR
>> >
>> > 102 EUR
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.nh-hotels.com/
>> >
>> > Novotel***
>> >
>> > Fischerinsel 12
>> > U2 Spittelmarkt 3min,
>> >
>> > 15min zu Fu??
>> > 82 EUR
>> >
>> >
>> >
>> > 112 EUR
>> >
>> >
>> >
>> > inkl. Fr??hst??ck
>> >
>> > http://www.novotel.de/
>> >
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 08:27:55 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 08:35:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 13:35:24 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEBDA4.4040900@kcl.ac.uk> Message-ID: <45EEBF9C.20207@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 07 Mar 2007 13:35:24 +0000
I propose the http://www.hotel-albrechtshof.de/

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 08:35:28 EST

From tone.bruvik at aksis.uib.no Wed Mar 7 08:58:01 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Wed, 7 Mar 2007 14:58:01 +0100 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> Message-ID: <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no>
From: Tone Merete Bruvik
Date: Wed, 7 Mar 2007 14:58:01 +0100
A coordinating hotel arrangements would be nice, or at leased would
it be nice to stay at the same hotel as some of you (nice to have
company at the way back at night). I like to stay somewhere in
walking distance from the meeting, but most of Laurent's suggestions
seams to meet that criteria, so any suggestion on which hotel to
choose would be welcome.
I need to book my tickets in a few days. I guess that we have to
arrive on the afternoon of April 24, but as Lou also mentioned, I
need to know when the meeting will end on Friday, as I have an option
to leave Friday night.
Tone Merete
Den 7. mar. 2007 kl. 14.12 skrev Dot Porter:
> Is there interest in coordinating hotel arrangements? I not terribly
> keen on trying to make it around Berlin all on my lonesome :-)
>
> Dot
>
> On 3/7/07, Lou Burnard
> services.oxford.ac.uk> wrote:
>> This response from Laurent seems to have been bounced by the
>> server for
>> some reason:
>>
>>
>>
>> > Dear all,
>> > OK. I take a few extra minutes... here's a hotel list for our
>> > meetings in Berlin. I would suggest to try to pack all issues on
>> > Thu-Fri.
>> > Best,
>> > Laurent
>> >
>> >
>> > Hotel
>> > Lage
>> > EZ-Preis
>> > DZ-Preis
>> > Sonstiges
>> > Albrechtshof/Allegra***
>> >
>> > Albrechtstr. 8/17
>> > Hotels liegen vis ? vis
>> > U-/S-Bahn Friedrichstr. 2min,
>> >
>> > 15min zu Fu? zur BBAW
>> > 95/89 EUR
>> >
>> > 115/105 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.hotel-albrechtshof.de/
>> >
>> > http://www.hotel-allegra.de/
>> >
>> > Angleterre****
>> >
>> > Friedrichstra?e 31
>> >
>> >
>> >
>> > U-Bhf. Kochstr.
>> >
>> > 12min zu Fu? zur BBAW
>> >
>> > 80 EUR
>> >
>> > 104 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.gold-inn.de/
>> >
>> > Dietrich-Bonhoeffer-Haus***
>> >
>> > Ziegelstr. 30
>> >
>> > U6 Oranienburger Tor ca. 3min,
>> > U-/S-Bahn Friedrichstr. 5min
>> >
>> > 75 EUR
>> >
>> > 115 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.hotel-dbh.de/
>> >
>> > G?stehaus der Humboldt-Uni
>> >
>> > Ziegelstr. 13 a/b
>> > U6 Oranienburger Tor ca. 3min,
>> > U-/S-Bahn Friedrichstr. 5min
>> >
>> > 30 ? 35 EUR
>> >
>> > 60 EUR
>> >
>> > exkl. Fr?hst?ck
>> >
>> > Gendarm****
>> >
>> > Charlottenstr. 60/61
>> > U6 Stadtmitte 2min,
>> >
>> > U2 Stadtmitte 3min,
>> > 4min zu Fu?
>> > 112 EUR
>> >
>> > 132 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.hotel-gendarm-berlin.de/
>> >
>> > Mercure***
>> >
>> > Sch?tzenstr. 11
>> >
>> > U6 Kochstr. 4min,
>> >
>> > U6 Stadtmitte 5min
>> > 82 EUR
>> >
>> > 112 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.mercure.de/
>> > NH-Hotel**** (ehem. Astron)
>> >
>> > Leipziger Str. 106-111
>> > U6 Stadtmitte 2min,
>> >
>> > U2 Stadtmitte 4min,
>> > 8min zu Fu?
>> > 86 EUR
>> >
>> > 102 EUR
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.nh-hotels.com/
>> >
>> > Novotel***
>> >
>> > Fischerinsel 12
>> > U2 Spittelmarkt 3min,
>> >
>> > 15min zu Fu?
>> > 82 EUR
>> >
>> >
>> >
>> > 112 EUR
>> >
>> >
>> >
>> > inkl. Fr?hst?ck
>> >
>> > http://www.novotel.de/
>> >
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
> --
> ***************************************
> Dot Porter, University of Kentucky
> #####
> Program Coordinator
> Collaboratory for Research in Computing for Humanities
> dporter_at_uky.edu 859-257-9549
> #####
> Editorial Assistant, REVEAL Project
> Center for Visualization and Virtual Environments
> porter_at_vis.uky.edu
> ***************************************
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 08:58:10 EST
From laurent.romary at loria.fr Wed Mar 7 09:03:31 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 7 Mar 2007 15:03:31 +0100 Subject: !SPAM? Re: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEBF9C.20207@oucs.ox.ac.uk> Message-ID: <457A2C60-56CC-40EE-85C6-F1D06079049E@loria.fr>
From: Laurent Romary
Date: Wed, 7 Mar 2007 15:03:31 +0100
Dear all,
You may also interested on having a pointer to the online map of
Berlin: see http://www.berlin.de/stadtplan/_html/index.html
Best,
Laurent

Le 7 mars 07 ? 14:35, Sebastian Rahtz a ?crit :
> I propose the http://www.hotel-albrechtshof.de/
>
>
> --
> Sebastian Rahtz Information Manager, Oxford University
> Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 09:05:17 EST

From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:12:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:12:29 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> Message-ID: <45EEC84D.6020409@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 07 Mar 2007 14:12:29 +0000
I suggest we appoint a hotel booking workgroup, and propose Ariana and
Dot as co-chairs!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 09:12:32 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:14:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:14:09 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEC84D.6020409@computing-services.oxford.ac.uk> Message-ID: <45EEC8B1.8080705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 07 Mar 2007 14:14:09 +0000
Lou Burnard wrote:
> I suggest we appoint a hotel booking workgroup, and propose Ariana and
> Dot as co-chairs!
>
with a rider that anything which is an international chain like Novotel
is ruled out....?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 09:14:14 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:27:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:27:29 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEC8B1.8080705@oucs.ox.ac.uk> Message-ID: <45EECBD1.7030308@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 07 Mar 2007 14:27:29 +0000
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> I suggest we appoint a hotel booking workgroup, and propose Ariana and
>> Dot as co-chairs!
>>
> with a rider that anything which is an international chain like Novotel
> is ruled out....?
>
How about international chains like Accor/Mercure etc. ? (I have a
loyalty card with them)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 09:27:47 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:29:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:29:13 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECBD1.7030308@oucs.ox.ac.uk> Message-ID: <45EECC39.2000001@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 07 Mar 2007 14:29:13 +0000
Lou Burnard wrote:
>
>>> I suggest we appoint a hotel booking workgroup, and propose Ariana
>>> and Dot as co-chairs!
>>>
>> with a rider that anything which is an international chain like
>> Novotel is ruled out....?
>>
>
> How about international chains like Accor/Mercure etc. ? (I have a
> loyalty card with them)
>
pah. have you no shame?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 09:29:16 EST

From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:32:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:32:10 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECC39.2000001@oucs.ox.ac.uk> Message-ID: <45EECCEA.8050400@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 07 Mar 2007 14:32:10 +0000
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>>
>>>> I suggest we appoint a hotel booking workgroup, and propose Ariana
>>>> and Dot as co-chairs!
>>>>
>>> with a rider that anything which is an international chain like
>>> Novotel is ruled out....?
>>>
>>
>> How about international chains like Accor/Mercure etc. ? (I have a
>> loyalty card with them)
>>
> pah. have you no shame?
>
>
They made me do it (and it got me discounted wifi). But seriously, if we
are going to delegate this task, I propose we let the Hotel Booking
WorkGroup decide TEI policy on the matter.
My criteria are simple: easy access to the Hauptbahnhof and the Meeting
Location; wifi; price.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 09:32:29 EST

From dporter at uky.edu Wed Mar 7 09:38:02 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 7 Mar 2007 09:38:02 -0500 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECCEA.8050400@oucs.ox.ac.uk> Message-ID: <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com>
From: Dot Porter
Date: Wed, 7 Mar 2007 09:38:02 -0500
I'm happy to co-chair, I guess that's what I get for being the first
to speak up :-)
Dot
On 3/7/07, Lou Burnard oxford.ac.uk> wrote:
> Sebastian Rahtz wrote:
> > Lou Burnard wrote:
> >>
> >>>> I suggest we appoint a hotel booking workgroup, and propose Ariana
> >>>> and Dot as co-chairs!
> >>>>
> >>> with a rider that anything which is an international chain like
> >>> Novotel is ruled out....?
> >>>
> >>
> >> How about international chains like Accor/Mercure etc. ? (I have a
> >> loyalty card with them)
> >>
> > pah. have you no shame?
> >
> >
>
> They made me do it (and it got me discounted wifi). But seriously, if we
> are going to delegate this task, I propose we let the Hotel Booking
> WorkGroup decide TEI policy on the matter.
>
> My criteria are simple: easy access to the Hauptbahnhof and the Meeting
> Location; wifi; price.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 09:38:06 EST

From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:48:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:48:52 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECCEA.8050400@oucs.ox.ac.uk> Message-ID: <45EED0D4.2010005@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 07 Mar 2007 14:48:52 +0000
Lou Burnard wrote:
>
> My criteria are simple: easy access to the Hauptbahnhof and the
> Meeting Location; wifi; price.
and I just want somewhere cute.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 09:48:56 EST
From arianna.ciula at kcl.ac.uk Wed Mar 7 12:45:54 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 07 Mar 2007 17:45:54 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> Message-ID: <45EEFA52.4040000@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 07 Mar 2007 17:45:54 +0000
I am happy to co-chair as well, but need to add another criterion:
- if I need to book we have to decide before Friday, because after that
I'll be on holiday for a week.
Arianna
Dot Porter wrote:
> I'm happy to co-chair, I guess that's what I get for being the first
> to speak up :-)
>
> Dot
>
> On 3/7/07, Lou Burnard oxford.ac.uk> wrote:
>> Sebastian Rahtz wrote:
>> > Lou Burnard wrote:
>> >>
>> >>>> I suggest we appoint a hotel booking workgroup, and propose Ariana
>> >>>> and Dot as co-chairs!
>> >>>>
>> >>> with a rider that anything which is an international chain like
>> >>> Novotel is ruled out....?
>> >>>
>> >>
>> >> How about international chains like Accor/Mercure etc. ? (I have a
>> >> loyalty card with them)
>> >>
>> > pah. have you no shame?
>> >
>> >
>>
>> They made me do it (and it got me discounted wifi). But seriously, if we
>> are going to delegate this task, I propose we let the Hotel Booking
>> WorkGroup decide TEI policy on the matter.
>>
>> My criteria are simple: easy access to the Hauptbahnhof and the Meeting
>> Location; wifi; price.
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 12:46:13 EST
From daniel.odonnell at uleth.ca Wed Mar 7 13:25:44 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 11:25:44 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> Message-ID: <1173291945.20729.54.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 07 Mar 2007 11:25:44 -0700
I'd made a couple of steps towards moving this forward. I was asked to
contact Fotis Jannis about this but heard nothing back from him. I'll
bug him again.
-dan
On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote:
> Hi Arianna,
>
> Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my
> "TEI Chapter on Transcription of Primary Sources"). Any objections if
> Arianna and I take our discussion off-list? Any other takers?
>
> Dot
>
> On 3/6/07, Arianna Ciula ac.uk> wrote:
> > Hi Dot,
> >
> > I remember talking about the Manuscript SIG. Is this what you mean by
> > Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about
> > the former and I gave a sort of availability in case nobody was prepared
> > to chair it.
> >
> > Should we discuss this out of list with Roberto as well and see what we
> > could do and report back?
> >
> > Arianna
> >
> > Dot Porter wrote:
> > > Hi Arianna,
> > >
> > > At the TEI member's meeting, you and I and a few other people were
> > > talking about reviving the Transcription SIG, which seems to have
> > > faded a way for a while. Are you interested? The CEI might be a good
> > > point to start off on - will you be at the DH conference this summer?
> > >
> > > Dot
> > >
> > > On 3/5/07, Arianna Ciula ac.uk> wrote:
> > >> Dear council,
> > >>
> > >> For whom is interested, I just wanted to report briefly on the
> > >> conference I came back from on Saturday: Digital Diplomatics
> > >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
> > >>
> > >> The international attendance was quite good with a majority of Germans
> > >> of course.
> > >>
> > >> The majority of presented projects deal with a combination of relational
> > >> database and use of XML (lots of TEI!).
> > >>
> > >> Few things to mention as far as TEI regards:
> > >>
> > >> Interesting presentations
> > >> - good work done by two Italian students using TEI P5 (poster: Viviana
> > >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
> > >> del 1264)
> > >> - presentation of ODD by Gautier Poupeau
> > >> - integration TEI-CIDOC presented by Christian-Emil Ore
> > >>
> > >> TEI/CEI
> > >> As you may know already, the objective of the conference was to give a
> > >> glimpse on digital projects related to medieval documents (it succeeded
> > >> on this) and to work on the improvements of the CEI (Charter Encoding
> > >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
> > >> standard to encode these documents in XML. Unfortunately, despite the
> > >> good work of synthesis and conceptual modelling done by Patrick Sahle
> > >> and Gautier Poupeau, we didn't go very far on the latter, but it seems
> > >> to me that
> > >> - despite some more or less funded complains on the inability of TEI to
> > >> represented the archival community and its objectives, all the CEI
> > >> recommendations as they stand could easily been translated and/or
> > >> represented in TEI P5
> > >> - I will keep an eye on how the community is going to develop the
> > >> standard and see what comes up
> > >>
> > >> Happy to give more details to whom is interested.
> > >> All the best,
> > >>
> > >> Arianna
> > >> --
> > >> Dr Arianna Ciula
> > >> Research Associate
> > >> Centre for Computing in the Humanities
> > >> King's College London
> > >> Strand
> > >> London WC2R 2LS (UK)
> > >> Tel: +44 (0)20 78481945
> > >> http://www.kcl.ac.uk/cch
> > >> _______________________________________________
> > >> tei-council mailing list
> > >> tei-council_at_lists.village.Virginia.EDU
> > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> > >>
> > >
> > >
> >
> > --
> > Dr Arianna Ciula
> > Research Associate
> > Centre for Computing in the Humanities
> > King's College London
> > Strand
> > London WC2R 2LS (UK)
> > Tel: +44 (0)20 78481945
> > http://www.kcl.ac.uk/cch
> >
>
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 13:20:14 EST
From daniel.odonnell at uleth.ca Wed Mar 7 13:29:18 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 11:29:18 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <1173291945.20729.54.camel@odonned-eng06> Message-ID: <1173292158.20729.57.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 07 Mar 2007 11:29:18 -0700
Apologies for a public email to the list. And spelling Fotis Jannidis's
name wrong.
On Wed, 2007-07-03 at 11:25 -0700, Dan O'Donnell wrote:
> I'd made a couple of steps towards moving this forward. I was asked to
> contact Fotis Jannis about this but heard nothing back from him. I'll
> bug him again.
>
> -dan
>
> On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote:
> > Hi Arianna,
> >
> > Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my
> > "TEI Chapter on Transcription of Primary Sources"). Any objections if
> > Arianna and I take our discussion off-list? Any other takers?
> >
> > Dot
> >
> > On 3/6/07, Arianna Ciula ac.uk> wrote:
> > > Hi Dot,
> > >
> > > I remember talking about the Manuscript SIG. Is this what you mean by
> > > Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about
> > > the former and I gave a sort of availability in case nobody was prepared
> > > to chair it.
> > >
> > > Should we discuss this out of list with Roberto as well and see what we
> > > could do and report back?
> > >
> > > Arianna
> > >
> > > Dot Porter wrote:
> > > > Hi Arianna,
> > > >
> > > > At the TEI member's meeting, you and I and a few other people were
> > > > talking about reviving the Transcription SIG, which seems to have
> > > > faded a way for a while. Are you interested? The CEI might be a good
> > > > point to start off on - will you be at the DH conference this summer?
> > > >
> > > > Dot
> > > >
> > > > On 3/5/07, Arianna Ciula ac.uk> wrote:
> > > >> Dear council,
> > > >>
> > > >> For whom is interested, I just wanted to report briefly on the
> > > >> conference I came back from on Saturday: Digital Diplomatics
> > > >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
> > > >>
> > > >> The international attendance was quite good with a majority of Germans
> > > >> of course.
> > > >>
> > > >> The majority of presented projects deal with a combination of relational
> > > >> database and use of XML (lots of TEI!).
> > > >>
> > > >> Few things to mention as far as TEI regards:
> > > >>
> > > >> Interesting presentations
> > > >> - good work done by two Italian students using TEI P5 (poster: Viviana
> > > >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza
> > > >> del 1264)
> > > >> - presentation of ODD by Gautier Poupeau
> > > >> - integration TEI-CIDOC presented by Christian-Emil Ore
> > > >>
> > > >> TEI/CEI
> > > >> As you may know already, the objective of the conference was to give a
> > > >> glimpse on digital projects related to medieval documents (it succeeded
> > > >> on this) and to work on the improvements of the CEI (Charter Encoding
> > > >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm)
> > > >> standard to encode these documents in XML. Unfortunately, despite the
> > > >> good work of synthesis and conceptual modelling done by Patrick Sahle
> > > >> and Gautier Poupeau, we didn't go very far on the latter, but it seems
> > > >> to me that
> > > >> - despite some more or less funded complains on the inability of TEI to
> > > >> represented the archival community and its objectives, all the CEI
> > > >> recommendations as they stand could easily been translated and/or
> > > >> represented in TEI P5
> > > >> - I will keep an eye on how the community is going to develop the
> > > >> standard and see what comes up
> > > >>
> > > >> Happy to give more details to whom is interested.
> > > >> All the best,
> > > >>
> > > >> Arianna
> > > >> --
> > > >> Dr Arianna Ciula
> > > >> Research Associate
> > > >> Centre for Computing in the Humanities
> > > >> King's College London
> > > >> Strand
> > > >> London WC2R 2LS (UK)
> > > >> Tel: +44 (0)20 78481945
> > > >> http://www.kcl.ac.uk/cch
> > > >> _______________________________________________
> > > >> tei-council mailing list
> > > >> tei-council_at_lists.village.Virginia.EDU
> > > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> > > >>
> > > >
> > > >
> > >
> > > --
> > > Dr Arianna Ciula
> > > Research Associate
> > > Centre for Computing in the Humanities
> > > King's College London
> > > Strand
> > > London WC2R 2LS (UK)
> > > Tel: +44 (0)20 78481945
> > > http://www.kcl.ac.uk/cch
> > >
> >
> >
> --
> Daniel Paul O'Donnell, PhD
> Chair, Text Encoding Initiative
> Director, Digital Medievalist Project
> Associate Professor and Chair of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox: +1 403 329 2378
> Fax: +1 403 382-7191
> Homepage: http://people.uleth.ca/~daniel.odonnell/
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 13:23:45 EST
From daniel.odonnell at uleth.ca Wed Mar 7 14:06:25 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 12:06:25 -0700 Subject: [tei-council] work for March In-Reply-To: <45E6C768.1080400@oucs.ox.ac.uk> Message-ID: <1173294385.20729.89.camel@odonned-eng06>
From: Dan O'Donnell
Date: Wed, 07 Mar 2007 12:06:25 -0700
Sebastian,
I'm about to sign up for my chapters. Are you actively working on any of
the ones assigned to you?
Do you have a recommendation for how many each member of council should
take? I was thinking of signing up for five to start and see what I
could do over the weekend. Howzat sound?
-dan
On Thu, 2007-01-03 at 12:30 +0000, Sebastian Rahtz wrote:
> Happy St David's Day.
>
> Looking at the plan of work scheduled for March, it goes as follows:
>
> * (end of tasks relating to feature requests, 12 hours to go)
> * design output format (JC and DP now on case)
> * review datatype and class decisions
> * proofread text looking for DTD and P4 language
>
> the latter two involve taking each chapter, looking
> for problems and ideally dealing with them. In most
> cases it will just a matter of someone signing off a
> chapter as having a clean bill of health. If something
> comes out which cannot be dealt with in (say)
> an hours work rewriting a paragraph, or making
> a simple decision about a datatype, then it should
> be broken out to a new task which can assigned its
> own deadline and so on.
>
> I think its "adopt a chapter" day again.
>
> Sebastian
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 14:00:52 EST
From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 14:12:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 19:12:10 +0000 Subject: [tei-council] work for March In-Reply-To: <1173294385.20729.89.camel@odonned-eng06> Message-ID: <45EF0E8A.4030300@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 07 Mar 2007 19:12:10 +0000
Daniel,
I am getting
daniel.odonnell_at_uleth.ca
SMTP error from remote mail server after RCPT TO:ca>:
host bellatrix.uleth.ca [142.66.3.43]: 550 Refused:
Unknown local recipient

maybe this list one will get through to warn you?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 07 2007 - 14:12:19 EST

From Syd_Bauman at Brown.edu Wed Mar 7 19:49:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 7 Mar 2007 19:49:42 -0500 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ED4029.7000403@computing-services.oxford.ac.uk> Message-ID: <17903.23974.159737.236505@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 7 Mar 2007 19:49:42 -0500
I think since users can, if necessary, make use of and to
encode theorems for now, this can safely be deferred to 1.1.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 07 2007 - 19:49:46 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 00:45:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 13:45:11 +0800 Subject: [tei-council] Berlin meeting In-Reply-To: <45EEAF27.8000402@oucs.ox.ac.uk> Message-ID: <45EFA2E7.5090308@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Thu, 08 Mar 2007 13:45:11 +0800
Lou Burnard wrote:
> Two quick timetabling questions:
>
> (a) Will the Council meeting also be held in the Harnackhaus ("Zentrum
> des "deutschen Oxford" :-))? if not, where?
>
Im "Zentrum des deutschen Berlin", apparently:-)
> (b) When do we expect that the Council meeting will end?
>
Judging from previous years' experience, I would think we need full 2
days 9 to 5; it seems unlikely that we are done before 5 pm on Friday.
I also do not think a meeting is productive, where half the participants
have to run to a train midway through. I would recommend therefore to
book for the late evening or Saturday.
We used to keep Saturday 'just in case' but never made use of it, so I
am prepared to get rid of that part.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 08 2007 - 01:11:10 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 00:48:03 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 13:48:03 +0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEFA52.4040000@kcl.ac.uk> Message-ID: <45EFA393.9060407@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Thu, 08 Mar 2007 13:48:03 +0800
Arianna Ciula wrote:
> I am happy to co-chair as well, but need to add another criterion:
>
> - if I need to book we have to decide before Friday, because after that
> I'll be on holiday for a week.
>
Not sure if trying to do the booking would be effective; you would need
to trac(k) everybody's schedule etc. Maybe you can just figure out what
seems to be reasonable given our preferences and post it to the list?
Participants could then make their own informed decisions.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 08 2007 - 01:11:17 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 03:53:30 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 16:53:30 +0800 Subject: [tei-council] work for March In-Reply-To: <1173294385.20729.89.camel@odonned-eng06> Message-ID: <45EFCF0A.4080807@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Thu, 08 Mar 2007 16:53:30 +0800
Dan O'Donnell wrote:
> Sebastian,
>
> I'm about to sign up for my chapters. Are you actively working on any of
> the ones assigned to you?
>
> Do you have a recommendation for how many each member of council should
> take? I was thinking of signing up for five to start and see what I
> could do over the weekend. Howzat sound?
That's great. You will submit your changes to the P5-Council branch, I
hope?
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 08 2007 - 04:41:46 EST
From dporter at uky.edu Thu Mar 8 06:56:28 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 8 Mar 2007 03:56:28 -0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EFA393.9060407@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <96f3df640703080356v15f041deh9bc59cc10f93809f@mail.gmail.com>
From: Dot Porter
Date: Thu, 8 Mar 2007 03:56:28 -0800
Arianna, I agree with Christian. There's no need to book a group of
rooms together, but we can make a recommendation. I just want to make
sure I'm not alone in my hotel, don't want to get lost getting to and
from the meetings.
Of course folks are free to choose another hotel if the one we
recommend isn't cute enough.
Dot
On 3/7/07, Christian Wittern zinbun.kyoto-u.ac.jp> wrote:
> Arianna Ciula wrote:
> > I am happy to co-chair as well, but need to add another criterion:
> >
> > - if I need to book we have to decide before Friday, because after that
> > I'll be on holiday for a week.
> >
>
> Not sure if trying to do the booking would be effective; you would need
> to trac(k) everybody's schedule etc. Maybe you can just figure out what
> seems to be reasonable given our preferences and post it to the list?
>
> Participants could then make their own informed decisions.
>
> Christian
>
>
> --
>
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 08 2007 - 06:56:33 EST

From laurent.romary at loria.fr Thu Mar 8 07:58:05 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 8 Mar 2007 13:58:05 +0100 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <1173292158.20729.57.camel@odonned-eng06> Message-ID: <101D63BA-1E66-4869-B4ED-431387C90D59@loria.fr>
From: Laurent Romary
Date: Thu, 8 Mar 2007 13:58:05 +0100
Never mind. I actually see Fotis next week and czn put pressure on
him if you want.
Laurent

Le 7 mars 07 ? 19:29, Dan O'Donnell a ?crit :
> Apologies for a public email to the list. And spelling Fotis
> Jannidis's
> name wrong.
>
> On Wed, 2007-07-03 at 11:25 -0700, Dan O'Donnell wrote:
>> I'd made a couple of steps towards moving this forward. I was
>> asked to
>> contact Fotis Jannis about this but heard nothing back from him. I'll
>> bug him again.
>>
>> -dan
>>
>> On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote:
>>> Hi Arianna,
>>>
>>> Yes, that's what I meant (I was confusing my "Manuscripts SIG"
>>> with my
>>> "TEI Chapter on Transcription of Primary Sources"). Any
>>> objections if
>>> Arianna and I take our discussion off-list? Any other takers?
>>>
>>> Dot
>>>
>>> On 3/6/07, Arianna Ciula ac.uk> wrote:
>>>> Hi Dot,
>>>>
>>>> I remember talking about the Manuscript SIG. Is this what you
>>>> mean by
>>>> Transcription SIG? Dan and Roberto Rosselli del Turco contacted
>>>> me about
>>>> the former and I gave a sort of availability in case nobody was
>>>> prepared
>>>> to chair it.
>>>>
>>>> Should we discuss this out of list with Roberto as well and see
>>>> what we
>>>> could do and report back?
>>>>
>>>> Arianna
>>>>
>>>> Dot Porter wrote:
>>>>> Hi Arianna,
>>>>>
>>>>> At the TEI member's meeting, you and I and a few other people were
>>>>> talking about reviving the Transcription SIG, which seems to have
>>>>> faded a way for a while. Are you interested? The CEI might be a
>>>>> good
>>>>> point to start off on - will you be at the DH conference this
>>>>> summer?
>>>>>
>>>>> Dot
>>>>>
>>>>> On 3/5/07, Arianna Ciula ac.uk> wrote:
>>>>>> Dear council,
>>>>>>
>>>>>> For whom is interested, I just wanted to report briefly on the
>>>>>> conference I came back from on Saturday: Digital Diplomatics
>>>>>> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html
>>>>>>
>>>>>> The international attendance was quite good with a majority of
>>>>>> Germans
>>>>>> of course.
>>>>>>
>>>>>> The majority of presented projects deal with a combination of
>>>>>> relational
>>>>>> database and use of XML (lots of TEI!).
>>>>>>
>>>>>> Few things to mention as far as TEI regards:
>>>>>>
>>>>>> Interesting presentations
>>>>>> - good work done by two Italian students using TEI P5 (poster:
>>>>>> Viviana
>>>>>> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di
>>>>>> Vicenza
>>>>>> del 1264)
>>>>>> - presentation of ODD by Gautier Poupeau
>>>>>> - integration TEI-CIDOC presented by Christian-Emil Ore
>>>>>>
>>>>>> TEI/CEI
>>>>>> As you may know already, the objective of the conference was
>>>>>> to give a
>>>>>> glimpse on digital projects related to medieval documents (it
>>>>>> succeeded
>>>>>> on this) and to work on the improvements of the CEI (Charter
>>>>>> Encoding
>>>>>> Initiative: funded three years ago - http://www.cei.lmu.de/
>>>>>> index.htm)
>>>>>> standard to encode these documents in XML. Unfortunately,
>>>>>> despite the
>>>>>> good work of synthesis and conceptual modelling done by
>>>>>> Patrick Sahle
>>>>>> and Gautier Poupeau, we didn't go very far on the latter, but
>>>>>> it seems
>>>>>> to me that
>>>>>> - despite some more or less funded complains on the inability
>>>>>> of TEI to
>>>>>> represented the archival community and its objectives, all the
>>>>>> CEI
>>>>>> recommendations as they stand could easily been translated and/or
>>>>>> represented in TEI P5
>>>>>> - I will keep an eye on how the community is going to develop the
>>>>>> standard and see what comes up
>>>>>>
>>>>>> Happy to give more details to whom is interested.
>>>>>> All the best,
>>>>>>
>>>>>> Arianna
>>>>>> --
>>>>>> Dr Arianna Ciula
>>>>>> Research Associate
>>>>>> Centre for Computing in the Humanities
>>>>>> King's College London
>>>>>> Strand
>>>>>> London WC2R 2LS (UK)
>>>>>> Tel: +44 (0)20 78481945
>>>>>> http://www.kcl.ac.uk/cch
>>>>>> _______________________________________________
>>>>>> tei-council mailing list
>>>>>> tei-council_at_lists.village.Virginia.EDU
>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Dr Arianna Ciula
>>>> Research Associate
>>>> Centre for Computing in the Humanities
>>>> King's College London
>>>> Strand
>>>> London WC2R 2LS (UK)
>>>> Tel: +44 (0)20 78481945
>>>> http://www.kcl.ac.uk/cch
>>>>
>>>
>>>
>> --
>> Daniel Paul O'Donnell, PhD
>> Chair, Text Encoding Initiative
>> Director, Digital Medievalist Project
>> www.digitalmedievalist.org/>
>> Associate Professor and Chair of English
>> University of Lethbridge
>> Lethbridge AB T1K 3M4
>> Vox: +1 403 329 2378
>> Fax: +1 403 382-7191
>> Homepage: http://people.uleth.ca/~daniel.odonnell/
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> --
> Daniel Paul O'Donnell, PhD
> Chair, Text Encoding Initiative
> Director, Digital Medievalist Project
> www.digitalmedievalist.org/>
> Associate Professor and Chair of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox: +1 403 329 2378
> Fax: +1 403 382-7191
> Homepage: http://people.uleth.ca/~daniel.odonnell/
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 08 2007 - 07:59:40 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 9 04:39:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 09 Mar 2007 09:39:22 +0000 Subject: [tei-council] TEI P5 trac server Message-ID: <45F12B4A.3080902@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 09 Mar 2007 09:39:22 +0000
this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5,
instead of http://tei.oucs.ox.ac.uk/trac.cgi
This lets me support multiple projects, and do it properly
with mod_python.
Shout at me if anything is not working
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 09 2007 - 04:39:27 EST
From dporter at uky.edu Fri Mar 9 17:30:38 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 9 Mar 2007 17:30:38 -0500 Subject: [tei-council] Hotels Message-ID: <96f3df640703091430u7574ace0pc0d52701431c6de5@mail.gmail.com>
From: Dot Porter
Date: Fri, 9 Mar 2007 17:30:38 -0500
Hi Everyone,
I've checked out the hotel list that Laurent sent and I'm drawn to the
Angleterre (http://www.gold-inn.de). Room charge for a single ranges
from 100-124 EUR (472 EUR for April 25-29), 10 EUR more per night for
a double. DSL connections in each room appear to be included in the
price. Breakfast is not included (15 EUR/day, which seems steep)
neither is the fitness area (9.50 EUR/day). 12 minute walk to the
BBAW. And it's cute!
http://www.gold-inn.de/angleterre/galerie_hotel.php
This is a good choice especially if you expect to take breakfast some
days outside the hotel, and/or if you don't exercise. So, this one is
my recommendation.
To the others...
******
The Albrechtshof and Allegra in Mitte both look nice, too
(http://www.hotel-albrechtshof.de/; http://www.hotel-allegra.de/). I
couldn't find anything on the websites about Internet access, I've
written messages to both and I'll report back what I find. I checked
the online booking system to see what the costs would be for April
25-29 and both claim to be unavailable. That seemed kind of strange so
I've contacted the hotels about that as well. Actually I don't have
much to say about these two until I hear back from them. 15 minute
walk to the BBAW.
The Dietrich-Bonhoeffer-Hotel (http://www.hotel-dbh.de/) is less
expensive but not as attractive as the first three. Room charge for a
single is 105 EUR, for a double 145 EUR. This includes Internet
connection and breakfast. The website is entirely in German which I
haven't studied in a long, long time, but I think I have the correct
information. The online booking system is not working. Pictures here:
http://www.dietrich-bonhoeffer-hotel.de/galerie.html. Short ride to
the BBAW.
The Hotel Gendarm is quite nice and private (only 21 rooms), but more
expensive at 135 EUR for a single and 160 EUR for double. Breakfast
buffet is 13 EUR; I've sent them a message asking about Internet
access. http://www.hotel-gendarm-berlin.de/. It's very close to the
BBAW, just a 4 minute walk.
On to the chains...
******
Mercure Checkpoint Charlie
(http://www.mercure.com/mercure/fichehotel/gb/mer/3120/fiche_hotel.shtml)
has both wifi access and highspeed Internet connections in the room,
though "extra charges may apply". Room rates range from 92-122 EUR for
a single (rate depends on whether you pay at time of booking or wait
until you get to the hotel). Breakfast is 16 EUR/day. Short ride to
the BBAW.
Hotel NH Berlin-Mitte is 124-134 EUR average per night for a single.
Wireless Internet is available in-room but it isn't clear whether an
extra cost is involved. Breakfast is 13 EUR/day. 8 minute walk to
BBAW.
Hotel Dorint Novotel Berlin Mitte (http://www.nh-hotels.com/) averages
139 EUR per night for a single. Wireless Internet is available but
watch for those extra charges. Breakfast is 15 EUR. 15 minute walk to
BBAW.
And finally...
*****
Then there is the Humboldt University guest housing
(http://www.ta.hu-berlin.de/index.php4?fd=502). These are small
apartments including small kitchens, ranging from 35 EUR for a single,
60 EUR for a double (sharing a bedroom), 25 EUR/person for a triple
(three bedrooms) and 30/35 EUR for a double (two bedrooms). The
multiple-bedroom apartments can only be shared by people of the same
gender. Breakfast is not included or available on-site. Short ride to
the BBAW.
Hope this information is helpful. I think I'll be booking at Angleterre.
Have a good weekend!
Dot
-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 09 2007 - 17:30:42 EST
From daniel.odonnell at uleth.ca Mon Mar 12 13:30:16 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 12 Mar 2007 12:30:16 -0600 Subject: [tei-council] TEI P5 trac server In-Reply-To: <45F12B4A.3080902@oucs.ox.ac.uk> Message-ID: <1173724216.28369.69.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 12 Mar 2007 12:30:16 -0600
Seems O.K.
I'd asked about whether we could just grab chapters for reviewing for
reference to DTDs and P4--I'm not sure if there was a policy, but I
assigned myself five for this week. Let me encourage others on council
to do the same so we can hit this deadline.
-dan
On Fri, 2007-09-03 at 09:39 +0000, Sebastian Rahtz wrote:
> this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5,
> instead of http://tei.oucs.ox.ac.uk/trac.cgi
>
> This lets me support multiple projects, and do it properly
> with mod_python.
>
> Shout at me if anything is not working
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 13:24:08 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 12 15:22:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 12 Mar 2007 20:22:30 +0000 Subject: [tei-council] p5 release 0.6 Message-ID: <45F5B686.9010604@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 12 Mar 2007 20:22:30 +0000
If any of you have some energy to look at http://tei.oucs.ox.ac.uk/Roma/,
you'll find it delivers a pre-release of 0.6. Please report any funnies
to me.
If you feel strong, you'll see that you can now specify a min
and max for the space-separated values of an attribute. Roma
supports this, but it is not much tested.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 15:22:39 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 21:54:15 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 10:54:15 +0800 Subject: [tei-council] facsimile odd In-Reply-To: <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> Message-ID: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 13 Mar 2007 10:54:15 +0800
Dot Porter wrote:
> I expect the hold up is on my end - I am supposed to be supplying
> sample texts to Conal so he can test the ODD (which is probably
> finished). I will get the testing materials to him this afternoon.
> Sorry for the hold up...
>
Dot, any news about this?
> Sebastian Rahtz wrote:
>> Any sign?
>>
>> I added a ticket to trac about it.
>>
I can't find the ticket in trac, neither by looking at active tickets by
owner, nor by searching globally.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 21:54:24 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 21:28:08 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 10:28:08 +0800 Subject: [tei-council] TEI P5 trac server In-Reply-To: <45F12B4A.3080902@oucs.ox.ac.uk> Message-ID: <45F60C38.3070000@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 13 Mar 2007 10:28:08 +0800
Sebastian Rahtz wrote:
> this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5,
> Shout at me if anything is not working
Thanks, this works excellent, the response time is much better than the
previous version.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 22:00:28 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 22:06:29 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 11:06:29 +0800 Subject: [tei-council] editing the guidelines Message-ID: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 13 Mar 2007 11:06:29 +0800
Dear Council members,
The way we (the planning committee) are imaging changes necessary in the
proofreading and foolproofing process about to commence is that
1) Every Council member checks out a branch (P5-Council) from the SF
repository.
2) She then marks the Chapters she wants to work with in trac, and
3) goes about editing them in the working copy.
4) Occasionally, she commits this back to the repository.
5) When done, she does the last commit and ticks the ticket in trac off.
6) The editors look over this and merge the stuff with the trunk.

I would like to see if we can agree to this procedure and put it in
effect as soon as possible.
Comments welcome. Please speak up soon if you find problems with this
procedure, I would like to start using it after the telecon next week.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 22:06:38 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 22:09:55 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 11:09:55 +0800 Subject: [tei-council] call for agenda items (cfa) for the teleconference next monday, march 19 at 1200 gmt Message-ID: <45F61603.9070804@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 13 Mar 2007 11:09:55 +0800
Dear Council members,
another telecon is dragging closer, giving us an opportunity with
catching up on ourselves with regard to the various work items we are
obsessed with.
As usual, this is a wake-up call, please look at
http://www.tei-c.org/Council/tcm28.xml?style=printable to find out what
work items assigned to you might yet be open.
Our main task on this telecon will again be the workplan for the next
months, this time we would try to iron out the procedures in a way that
we can start doing the necessary work immediately.
Before the conference, please look at the trac pages at
http://tei.oucs.ox.ac.uk/trac/TEIP5/ and see if you find any flaws with
the overall plan, especially with respect for the timeline of items you
are involved with.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 12 2007 - 22:10:04 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 04:50:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 09:50:54 +0000 Subject: [tei-council] facsimile odd In-Reply-To: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45F673FE.4070103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 13 Mar 2007 09:50:54 +0000
Christian Wittern wrote:
>
> I can't find the ticket in trac, neither by looking at active tickets
> by owner, nor by searching globally.
>
> Christian
>
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/291
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 13 2007 - 04:51:02 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 13:58:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 18:58:56 +0000 Subject: [tei-council] editing the guidelines In-Reply-To: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45F6F470.2090102@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 13 Mar 2007 18:58:56 +0000
Christian Wittern wrote:
> 1) Every Council member checks out a branch (P5-Council) from the SF
> repository.
>
> 2) She then marks the Chapters she wants to work with in trac, and
>
> 3) goes about editing them in the working copy.
>
> 4) Occasionally, she commits this back to the repository.
>
> 5) When done, she does the last commit and ticks the ticket in trac off.
>
> 6) The editors look over this and merge the stuff with the trunk.
>
that's just how I imagined things would work.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 13 2007 - 13:59:02 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 18:07:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 23:07:36 +0000 Subject: [tei-council] Hotels In-Reply-To: <96f3df640703091430u7574ace0pc0d52701431c6de5@mail.gmail.com> Message-ID: <45F72EB8.5010302@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 13 Mar 2007 23:07:36 +0000
Just for the record, Lou and I are booked in the Angleterre for Wed,
Thur and Fri night;
arriving by train 8.30 am Wednesday. Both leaving after lunch
on Saturday (so allowing for an overrun on Saturday am if needed).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 13 2007 - 18:07:46 EST
From dporter at uky.edu Tue Mar 13 19:34:51 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 13 Mar 2007 16:34:51 -0800 Subject: [tei-council] editing the guidelines In-Reply-To: <45F6F470.2090102@oucs.ox.ac.uk> Message-ID: <96f3df640703131734p4f3b6a7eqcede9a5a93bacbde@mail.gmail.com>
From: Dot Porter
Date: Tue, 13 Mar 2007 16:34:51 -0800
In order to check out the P5-Council branch from the Subversion, it
looks like we need to be Developers - at least, I can get into SF and
view the SVN, but I can't check the branch out. It's also possible
that I just don't know what I'm doing. Can someone help, please?
Thanks,
Dot
On 3/13/07, Sebastian Rahtz ox.ac.uk> wrote:
> Christian Wittern wrote:
> > 1) Every Council member checks out a branch (P5-Council) from the SF
> > repository.
> >
> > 2) She then marks the Chapters she wants to work with in trac, and
> >
> > 3) goes about editing them in the working copy.
> >
> > 4) Occasionally, she commits this back to the repository.
> >
> > 5) When done, she does the last commit and ticks the ticket in trac off.
> >
> > 6) The editors look over this and merge the stuff with the trunk.
> >
> that's just how I imagined things would work.
>
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> OSS Watch: JISC Open Source Advisory Service
> http://www.oss-watch.ac.uk
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 13 2007 - 19:34:54 EST

From Syd_Bauman at Brown.edu Tue Mar 13 19:50:03 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 13 Mar 2007 20:50:03 -0400 Subject: [tei-council] editing the guidelines In-Reply-To: <96f3df640703131734p4f3b6a7eqcede9a5a93bacbde@mail.gmail.com> Message-ID: <17911.18107.984674.355574@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 13 Mar 2007 20:50:03 -0400
> In order to check out the P5-Council branch from the Subversion, it
> looks like we need to be Developers - at least, I can get into SF
> and view the SVN, but I can't check the branch out. It's also
> possible that I just don't know what I'm doing. Can someone help,
> please?
>From a Mac OS X or GNU/Linux commandline issue:
svn co https://tei.svn.sourceforge.net/svnroot/tei/branches/P5-Council
and a new directory named "P5-Council/" will be crated and populated.
Checking in is a different story.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Mar 13 2007 - 19:50:08 EST

From daniel.odonnell at uleth.ca Thu Mar 15 13:35:02 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 15 Mar 2007 12:35:02 -0600 Subject: [tei-council] Test Message-ID: <1173983702.25173.15.camel@odonned-eng06>
From: Dan O'Donnell
Date: Thu, 15 Mar 2007 12:35:02 -0600
I think this might be working now.
-dan
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 15 2007 - 13:28:35 EST
From daniel.odonnell at uleth.ca Thu Mar 15 15:25:13 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 15 Mar 2007 14:25:13 -0600 Subject: [tei-council] Re: TEI Council: temporary mail list/ conformance draft In-Reply-To: <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1173990313.3745.0.camel@odonned-eng06>
From: Dan O'Donnell
Date: Thu, 15 Mar 2007 14:25:13 -0600
I'm guessing this is now an hour earlier (4 am, gulp, for me) for North
Americans due to the earlier DST?
-dan
On Thu, 2007-15-03 at 19:53 +0800, Christian Wittern wrote:
> Lou Burnard wrote:
> > Since we have a Council telecon scheduled for next week, and the
> > weekend is upon us, I've repurposed the tei-chars mailing list here as a
> > temporary substitute. All members of the council are now signed up to
> > this list, and should also be able to send mail to it.
>
> Thanks for taking care of this. I will be sending out the draft agenda
> tomorrow.
>
> > This enables me to announce that James has just delivered a preliminary
> > draft for the Conformance chapter of P5, which should be on our agenda
> > for next week. You can read the draft at
> >
> > http://www.tei-c.org/Council/conformance-draft.pdf
>
> Thanks to James as well.
>
> Christian
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 15 2007 - 15:18:51 EST
From Syd_Bauman at Brown.edu Thu Mar 15 18:16:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Mar 2007 19:16:20 -0400 Subject: [tei-council] Berlin airports Message-ID: <17913.54212.273809.344367@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 15 Mar 2007 19:16:20 -0400
Sorry if this has gone by and I've missed it --
* Which airport should we use, or does it matter?
* When & where are we expected to be on Wed 25 Apr?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 15 2007 - 18:16:24 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Mar 16 03:16:53 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Mar 2007 16:16:53 +0800 Subject: [tei-council] Test In-Reply-To: <1173983702.25173.15.camel@odonned-eng06> Message-ID: <45FA5275.9060705@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 16 Mar 2007 16:16:53 +0800
Dan O'Donnell wrote:
> I think this might be working now.
>
It does. Thanks for clearing the roadblock.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 16 2007 - 03:43:40 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Mar 16 03:18:59 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Mar 2007 16:18:59 +0800 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Message-ID: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 16 Mar 2007 16:18:59 +0800
Dear Council members,
Here is the draft agenda. The time is still 1200 UTC, but your local
time may have changed relative to it, so please pay attention.

DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at
1200 UTC

Expected to participate:
Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna
Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter,
Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian
Wittern

============================================================
How to connect:
We will use the highspeedconferencing.com service again (hopefully
the tennis player will take his day off).
Participants can use their skype account (www.skype.com) or regular
phones to call. When calling via skype, *please use a headset*. If
in doubt, it might be better to call via regular phone. Numbers as follow:
>From Skype call +99008278525675
In the US, call 1-712-432-4000
Calling from Europe, call
In Austria: 0820 400 01562
In Belgium: 0703 59 984
In France: 0826 100 266
In Germany 01805 00 7620
In UK: 0870 119 2350
other places: call to US:-(
Enter Conference Room Number : 5326922
(this is Sebastians Conference room)
============================================================
Please read through the following. Wherever a report is requested, a
brief note to the list before the call is much appreciated and will
help us use the time during the call more effectively.
============================================================
1) Minutes, work items, progress since last meeting:
http://www.tei-c.org.uk/Council/tcm28.xml?style=printable
Please look at the action items and report progress here before the
meeting!
============================================================
2) Reports & Documents
PERS
Matthew, please give us an update on the outcoming of the meeting etc.
CONFORMANCE
James has the draft up here.
http://www.tei-c.org/Council/conformance-draft.pdf
(I think we can only do a brief review here and will have it on the
table for further scrutiny in Berlin)
============================================================
3) Road to P5:
The roadmap on trac is here:
http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap
We need to discuss how we want to share work on the items on the table

============================================================
4) Meetings
Council 2007: Berlin, preparations? What do we need to discuss there?

============================================================
5) Other business TBA

============================================================

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 16 2007 - 03:43:40 EST

From tone.bruvik at aksis.uib.no Fri Mar 16 04:06:04 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Fri, 16 Mar 2007 10:06:04 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Message-ID:
From: Tone Merete Bruvik
Date: Fri, 16 Mar 2007 10:06:04 +0100
The link to the minutes from last meeting does not work (error at the
server in Oxford?), but it looks like the server in Charlottesville
is up running:
http://www.tei-c.org/Council/tcm28.xml?style=printable
Tone Merete
Den 16. mar. 2007 kl. 09.18 skrev Christian Wittern:
> Dear Council members,
>
> Here is the draft agenda. The time is still 1200 UTC, but your local
> time may have changed relative to it, so please pay attention.
>
>
> DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at
> 1200 UTC
>
>
> Expected to participate:
>
> Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna
> Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter,
> Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian
> Wittern
>
>
> ============================================================
> How to connect:
>
> We will use the highspeedconferencing.com service again (hopefully
> the tennis player will take his day off).
>
> Participants can use their skype account (www.skype.com) or regular
> phones to call. When calling via skype, *please use a headset*. If
> in doubt, it might be better to call via regular phone. Numbers as
> follow:
>
>> From Skype call +99008278525675
> In the US, call 1-712-432-4000
> Calling from Europe, call
> In Austria: 0820 400 01562
> In Belgium: 0703 59 984
> In France: 0826 100 266
> In Germany 01805 00 7620
> In UK: 0870 119 2350
> other places: call to US:-(
> Enter Conference Room Number : 5326922
> (this is Sebastians Conference room)
> ============================================================
>
> Please read through the following. Wherever a report is requested, a
> brief note to the list before the call is much appreciated and will
> help us use the time during the call more effectively.
>
> ============================================================
>
> 1) Minutes, work items, progress since last meeting:
> http://www.tei-c.org.uk/Council/tcm28.xml?style=printable
> Please look at the action items and report progress here before the
> meeting!
>
> ============================================================
> 2) Reports & Documents
>
> PERS
>
> Matthew, please give us an update on the outcoming of the meeting etc.
>
> CONFORMANCE
> James has the draft up here.
> http://www.tei-c.org/Council/conformance-draft.pdf
> (I think we can only do a brief review here and will have it on the
> table for further scrutiny in Berlin)
>
> ============================================================
> 3) Road to P5:
>
> The roadmap on trac is here:
> http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap
>
> We need to discuss how we want to share work on the items on the table
>
>
> ============================================================
>
> 4) Meetings
>
> Council 2007: Berlin, preparations? What do we need to discuss there?
>
>
> ============================================================
> 5) Other business TBA
>
>
> ============================================================
>
>
> --
>
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 16 2007 - 04:06:13 EST
From laurent.romary at loria.fr Fri Mar 16 04:46:59 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 16 Mar 2007 10:46:59 +0100 Subject: [tei-council] Berlin airports In-Reply-To: <17913.54212.273809.344367@emt.wwp.brown.edu> Message-ID:
From: Laurent Romary
Date: Fri, 16 Mar 2007 10:46:59 +0100
Le 16 mars 07 ? 00:16, Syd Bauman a ?crit :
> Sorry if this has gone by and I've missed it --
>
> * Which airport should we use, or does it matter?
Not really. I guess most of you would arrive at Tegel.

> * When & where are we expected to be on Wed 25 Apr?
I am planning to have the workshop start at 10.30
Best wishes,
Laurent_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 16 2007 - 04:48:19 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 16 05:22:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Mar 2007 10:22:08 +0000 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: Message-ID: <45FA6FD0.3090208@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 16 Mar 2007 10:22:08 +0000
Tone Merete Bruvik wrote:
> The link to the minutes from last meeting does not work (error at the
> server in Oxford?)
restarted. hitting out of memory problems for some reason
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 16 2007 - 05:22:12 EST
From dporter at uky.edu Fri Mar 16 08:52:33 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 16 Mar 2007 09:52:33 -0400 Subject: [tei-council] facsimile odd In-Reply-To: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <96f3df640703160652j45a8e138wbbd5e4577785a914@mail.gmail.com>
From: Dot Porter
Date: Fri, 16 Mar 2007 09:52:33 -0400
Hi Christian and all,
On 3/12/07, Christian Wittern zinbun.kyoto-u.ac.jp> wrote:
> Dot Porter wrote:
> > I expect the hold up is on my end - I am supposed to be supplying
> > sample texts to Conal so he can test the ODD (which is probably
> > finished). I will get the testing materials to him this afternoon.
> > Sorry for the hold up...
> >
>
> Dot, any news about this?
>
Conal is currently working on an instance document for testing the
ODD, based on the sample projects I sent him last month. The ODD is
currently on the TEI wiki:
http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD
It lacks documentation and is unchanged from the last conference call.
Conal and I expect that once the test instance is complete there will
be a certain amount of back-and-forthing, modifying the ODD and then
the instance to make sure it all does what we want it to do. Earlier
this week, Conal thought that the instance would be finished by the
end of this week, but I don't know how much we will have done before
the call on Monday.
Dot
> > Sebastian Rahtz wrote:
> >> Any sign?
> >>
> >> I added a ticket to trac about it.
> >>
>
> I can't find the ticket in trac, neither by looking at active tickets by
> owner, nor by searching globally.
>
> Christian
>
> --
>
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 16 2007 - 08:52:38 EST

From mjd at hum.ku.dk Sun Mar 18 05:58:36 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Sun, 18 Mar 2007 11:58:36 +0100 Subject: [tei-council] Report on Vilnius meeting Message-ID: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Sun, 18 Mar 2007 11:58:36 +0100
TEI Place-name meeting, Vilnius, 23-24 February
In attendance were: Lou Burnard, Matthew Driscoll, ?yvind Eide, Richard
Light, Tadeusz Piotrowski, Tatjana Timchenko and Sebastian Rahtz.
The first day we were at the Institute of Lithuanian language
(http://www.lki.lt/indexeng.php), part of the Lithuanian Academy of
Sciences, and on the second day the Faculty of Philology
(http://www.flf.vu.lt/) at Vilnius University; we are grateful to both
institutions for acting as hosts.
1. Names and nyms
We began by tackling one bit of business outstanding from the Personography
meeting last year in Oxford, viz. the development of a mechanism for
pointing from actual name instances to the canonical form of that name, thus
addressing the needs of onomasticians (who are interested in names per se),
in addition to those of prosopographers (who are interested in people). If,
for example, the names Tony Blair and Tony Benn occur in a text it should be
possible to tag them in such a way that they both point to information about
these respective gentlemen and are flagged as instances of the name "Tony".
It should further be possible to indicate that "Tony" is a (pet-)form of
"Anthony", which is itself a member of a family of names containing forms
such as "Antonio", "Anton", "Antoine" and so on. We propose doing this by
means of a new element, called , which contains the definition for a
canonical name or name-part of any kind. In addition to global attributes
and those inherited from att.typed it can take a @parts attribute, which
points to constituent nyms. The attribute @nymKey is available on any
element which is a member of the att.naming class in order to point to the
nym with which it corresponds. Thus, to take our example, the name "Tony
Blair" in running prose could be tagged as follows:

Tony
Blair

The @key attribute on would point to a element giving
information about Tony Blair, while @nymKey on points to the
relevant . A element may also combine a number of other
elements together, where it is intended to show that one is a pet form or
diminutive of another, or that different nyms are to be regarded as variants
of the same base nym, using the
element (from the model.entryParts
class); orthographic variants are dealt with using , while can
be used for information on the origin of the name:


Antonius
From the Roman family name Antonius,
which is of unknown, presumably Etruscan, origin. It has been
commonly, but incorrectly, associated with Greek xml:lang="gr">ανθος
flower, which resulted in spellings with th in some
languages.


Anthony
Antony


Tony


Antonio


Tonio





This mechanism could also be used for place-names and place-name elements
(e.g. thorp, caster).
2. Place-names
Our principal task at this meeting was to develop mechanisms for encoding
place-names, analogous to those which were developed for personal names at
the meeting in Oxford last year, which would allow for the recording of
abstracted information about a place, such as map coordinate, GIS
information etc., as well as variant forms of the name, in different
languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g.
Lundunum, London). On the analogy with , we propose a
element, which will usually contain at least one, and possibly several,
elements, followed by one or more elements to provide
geographical and/or geo-political information about the location of the
place. The existing element is available to provide a brief
informal description of the nature of a place. In addition, three new
elements have been proposed: , and ,
which all have similar content models to their counterparts within .
To take a fairly simple example:

Iceland
?sland
65 00 N, 18 00 W
103,000 sq km
Constitutional
republic
Previously part of the kingdom of
Denmark, Iceland became independent
on 17 June 1944.

3. Events
There was also some discussion on the feasibility (and desirability) of
developing a generic tagset for encoding assertions about events, although
no real conclusion was reached.
M. J. Driscoll
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Mar 18 2007 - 05:58:55 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Mar 18 07:20:50 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sun, 18 Mar 2007 20:20:50 +0800 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> Message-ID: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sun, 18 Mar 2007 20:20:50 +0800
Thanks Matthew. I have one quick question below
Matthew James Driscoll wrote:
>
>
does that mean you also proposa a listNym for TEI?

> Our principal task at this meeting was to develop mechanisms for encoding
> place-names, analogous to those which were developed for personal names at
> the meeting in Oxford last year, which would allow for the recording of
> abstracted information about a place, such as map coordinate, GIS
> information etc., as well as variant forms of the name, in different
> languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g.
> Lundunum, London). On the analogy with , we propose a
> element, which will usually contain at least one, and possibly several,
> elements, followed by one or more elements to provide
> geographical and/or geo-political information about the location of the
> place.
Why would you need more than one ? I had the impression that
the place is what stays constant? Is it because it also stands in for
the geopolitical information? However, if we talk about administrative
geography here, you will also have to account for changes in the size
and super/sub components of a place and a way to link this to
coordinates defining the polygon. Would the tagset be up to this task?
And I guess you would need to say something about how the coordinates
are expressed, otherwise your fancy GPS equipment (or Google Maps for
that matter) wouldn't be able to do anything with it.
>
> Iceland
> ?sland
> 65 00 N, 18 00 W
> 103,000 sq km
Here you seem to point to a point with the extension of 103 000 sq km?!
> Constitutional
> republic
> Previously part of the kingdom of
> Denmark, Iceland became independent
> on 17 June 1944.
>
best, chw

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 18 2007 - 07:52:00 EST

From lou.burnard at computing-services.oxford.ac.uk Sun Mar 18 11:13:44 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Mar 2007 16:13:44 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD6538.1060002@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 18 Mar 2007 16:13:44 +0000
Christian Wittern wrote:
> Matthew James Driscoll wrote:
>>
>>
>
> does that mean you also proposa a listNym for TEI?
>
>
Yes. Matthew's report doesn't mention that there is a draft ODD,
probably because I have not yet got round to putting it anywhere where
Council members can see it easily. But if you look in the P5/Test
directory on sourceforge, you will see a file called testndextra.odd,
which contains the current state of the draft.
I've just put a copy of the HTML generated from this by Roma on the
website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep
this up to date as the draft progresses

>> Our principal task at this meeting was to develop mechanisms for
>> encoding
>> place-names, analogous to those which were developed for personal
>> names at
>> the meeting in Oxford last year, which would allow for the recording of
>> abstracted information about a place, such as map coordinate, GIS
>> information etc., as well as variant forms of the name, in different
>> languages (e.g. Praha, Prague, Praga) and/or different forms over
>> time (e.g.
>> Lundunum, London). On the analogy with , we propose a
>> element, which will usually contain at least one, and possibly several,
>> elements, followed by one or more elements to
>> provide
>> geographical and/or geo-political information about the location of the
>> place.
>
> Why would you need more than one ? I had the impression
> that the place is what stays constant? Is it because it also stands in
> for the geopolitical information?
Because a place might be located in more than one way (e.g. by its
geopolitical status, or by its co-ordinates), and may also move its
location over time.
> However, if we talk about administrative geography here, you will also
> have to account for changes in the size and super/sub components of a
> place and a way to link this to coordinates defining the polygon.
> Would the tagset be up to this task?
probably... because we embed GML!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Mar 18 2007 - 11:13:50 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 18 11:21:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Mar 2007 16:21:19 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD66FF.7060805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Mar 2007 16:21:19 +0000
Christian Wittern wrote:
> However, if we talk about administrative geography here, you will
> also have to account for changes in the size and super/sub components
> of a place and a way to link this to coordinates defining the
> polygon. Would the tagset be up to this task?
> And I guess you would need to say something about how the coordinates
> are expressed, otherwise your fancy GPS equipment (or Google Maps for
> that matter) wouldn't be able to do anything with it.
the testndextra.xml file, which is the test file for testndextra.odd
(Matthew, Lou - don't forget that important file) has an example
of GML:

srsName="urn:ogc:def:crs:EPSG:6.6:4326">
41.876143755230956 12.479267120361328


This describes a point, but obviously a polygon would be just
as easy (!) to encode.
Translating that to KML for eg Google Maps / Earth would be
trivial.
It was clear at the meeting that we could not (must not) think out a TEI
scheme
for serious GIS work, and GML seemed the likeliest contender as the drop in.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 18 2007 - 11:21:30 EST

From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 18 11:44:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Mar 2007 16:44:44 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD6C7C.1040109@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 18 Mar 2007 16:44:44 +0000
to follow up,
http://www.ogleearth.com/2005/11/convert_gml_to.html
has pointers to a "real" GML file, and notes on converting
that to KML.
perhaps important to say that I at least imagine
this is is like using RELAXNG in ODD - it is what we use,
but it is not mandated. You could equally
embed KML in the element. The assumption
is that you will switch to a special namespace if you
want to play scientific data with the big boys.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 18 2007 - 11:44:59 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Mar 18 19:05:19 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 08:05:19 +0800 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD66FF.7060805@oucs.ox.ac.uk> Message-ID: <45FDD3BF.4020209@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 19 Mar 2007 08:05:19 +0800
Sebastian Rahtz wrote:
>
>
>
> srsName="urn:ogc:def:crs:EPSG:6.6:4326">
> 41.876143755230956 12.479267120361328
>
>
>
> This describes a point, but obviously a polygon would be just
> as easy (!) to encode.
Thanks. That looks good enough for a start.
> It was clear at the meeting that we could not (must not) think out a TEI
> scheme
> for serious GIS work, and GML seemed the likeliest contender as the drop
> in.
Thats what I expected :-)
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 18 2007 - 19:54:05 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 19 04:33:31 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 17:33:31 +0800 Subject: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 19 Mar 2007 17:33:31 +0800
Christian Wittern wrote:
> Dear Council members,
>
> Here is the draft agenda. The time is still 1200 UTC, but your local
> time may have changed relative to it, so please pay attention.
>
>
> DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at
> 1200 UTC
I got the date wrong, sorry: The telecon is *today* Monday March 19!
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 05:25:40 EST

From mjd at hum.ku.dk Mon Mar 19 05:50:59 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 19 Mar 2007 11:50:59 +0100 Subject: [tei-council] Physical bibliography Message-ID: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Mon, 19 Mar 2007 11:50:59 +0100
I was asked (or volunteered, I can't remember) many moons ago to look at the
draft proposal for marking up the physical structure of books and
manuscripts (PB), and propose alternative solutions in cases where I found
the markup unnecessarily verbose. Having now finally done so, I see that my
alternative solutions are essentially the same as those proposed by Dot in a
posting to the council on 2 August 2006, viz. replacing the bulk of the
elements with attributes. So, according to Dot and me, instead of:

A
C
4

one could have

I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be
acoommodated through the magic of Unicode.
The insertion and cancellation of leaves should also be easily dealt with,
e.g.
missing="C2"/>
The same applies to . Format, signature alphabet and other things
where there is a finite number of possibilities could also be dealt with
using attributes.
Matthew
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 05:51:13 EST
From laurent.romary at loria.fr Mon Mar 19 06:16:13 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 19 Mar 2007 12:16:13 +0100 Subject: !SPAM? Re: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <06315B31-C224-49A1-8BD0-31DF97DE588C@loria.fr>
From: Laurent Romary
Date: Mon, 19 Mar 2007 12:16:13 +0100
Then I cannit make it... I would have been free on 23rd, but I give a
talk exactly at that time (entitled: "do we need librarians?" for
those of you who want to send tomatoes at me.
Laurent
Le 19 mars 07 ? 10:33, Christian Wittern a ?crit :
> Christian Wittern wrote:
>> Dear Council members,
>>
>> Here is the draft agenda. The time is still 1200 UTC, but your local
>> time may have changed relative to it, so please pay attention.
>>
>>
>> DRAFT Agenda for the TEI Council teleconference on January 23,
>> 2007 at
>> 1200 UTC
>
> I got the date wrong, sorry: The telecon is *today* Monday March 19!
>
> Christian
>
>
> --
>
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 06:19:20 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 19 06:25:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 19:25:11 +0800 Subject: [tei-council] Re: !SPAM? Re: telecon today (March 19)! In-Reply-To: <06315B31-C224-49A1-8BD0-31DF97DE588C@loria.fr> Message-ID: <45FE7317.4020508@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 19 Mar 2007 19:25:11 +0800
Laurent Romary wrote:
> Then I cannit make it... I would have been free on 23rd, but I give a
> talk exactly at that time (entitled: "do we need librarians?" for those
> of you who want to send tomatoes at me.
> Laurent
That was the 23rd of January, when we decided on the date for today --
you had no conflicts at that time.
It would be helpful if you could post directions etc. for the Berlin
meeting asap.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 06:25:49 EST

From dporter at uky.edu Mon Mar 19 06:36:06 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 07:36:06 -0400 Subject: [tei-council] Physical bibliography In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk> Message-ID: <96f3df640703190436w49e7447cnd2daf5e70305bb3d@mail.gmail.com>
From: Dot Porter
Date: Mon, 19 Mar 2007 07:36:06 -0400
Matthew and Council,
After posting my PB suggestions to the council list, Lou and I raised
a discussion on the PB workgroup listserv about modifying their
recommendations to incorporate some of our suggestions. The workgroup
chair, Murray McGillivray, expressed his disapproval of replacing the
elements with attributes and I don't think anyone else in the
workgroup had anything to contribute. We didn't get much farther than
this. At the last council call we decided to table PB for now, should
we consider putting it back on the table for the Berlin meeting?
Dot
On 3/19/07, Matthew James Driscoll ku.dk> wrote:
> I was asked (or volunteered, I can't remember) many moons ago to look at the
> draft proposal for marking up the physical structure of books and
> manuscripts (PB), and propose alternative solutions in cases where I found
> the markup unnecessarily verbose. Having now finally done so, I see that my
> alternative solutions are essentially the same as those proposed by Dot in a
> posting to the council on 2 August 2006, viz. replacing the bulk of the
> elements with attributes. So, according to Dot and me, instead of:
>
>
> A
> C
> 4
>
>
> one could have
>
>
>
> I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be
> acoommodated through the magic of Unicode.
>
> The insertion and cancellation of leaves should also be easily dealt with,
> e.g.
>
>
> missing="C2"/>
>
> The same applies to . Format, signature alphabet and other things
> where there is a finite number of possibilities could also be dealt with
> using attributes.
>
> Matthew
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 06:36:09 EST

From lou.burnard at computing-services.oxford.ac.uk Mon Mar 19 06:43:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Mar 2007 11:43:17 +0000 Subject: [tei-council] Physical bibliography In-Reply-To: <96f3df640703190436w49e7447cnd2daf5e70305bb3d@mail.gmail.com> Message-ID: <45FE7755.6080801@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 19 Mar 2007 11:43:17 +0000
This is my recollection too. The problem, as noted before, is that this
is effectively a workgroup of one member. Someone should nevertheless
revisit Murray's counter arguments to see whether they have any
substance. I assume they're still accessible from the Brown listserv
archive Syd?
Dot Porter wrote:
> Matthew and Council,
>
> After posting my PB suggestions to the council list, Lou and I raised
> a discussion on the PB workgroup listserv about modifying their
> recommendations to incorporate some of our suggestions. The workgroup
> chair, Murray McGillivray, expressed his disapproval of replacing the
> elements with attributes and I don't think anyone else in the
> workgroup had anything to contribute. We didn't get much farther than
> this. At the last council call we decided to table PB for now, should
> we consider putting it back on the table for the Berlin meeting?
>
> Dot
>
> On 3/19/07, Matthew James Driscoll ku.dk> wrote:
>> I was asked (or volunteered, I can't remember) many moons ago to look
>> at the
>> draft proposal for marking up the physical structure of books and
>> manuscripts (PB), and propose alternative solutions in cases where I
>> found
>> the markup unnecessarily verbose. Having now finally done so, I see
>> that my
>> alternative solutions are essentially the same as those proposed by
>> Dot in a
>> posting to the council on 2 August 2006, viz. replacing the bulk of the
>> elements with attributes. So, according to Dot and me, instead of:
>>
>>
>> A
>> C
>> 4
>>
>>
>> one could have
>>
>>
>>
>> I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be
>> acoommodated through the magic of Unicode.
>>
>> The insertion and cancellation of leaves should also be easily dealt
>> with,
>> e.g.
>>
>>
>> missing="C2"/>
>>
>> The same applies to . Format, signature alphabet and other
>> things
>> where there is a finite number of possibilities could also be dealt with
>> using attributes.
>>
>> Matthew
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 06:47:40 EST
From dporter at uky.edu Mon Mar 19 07:06:23 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 08:06:23 -0400 Subject: [tei-council] Council phone # for US Message-ID: <96f3df640703190506g40887785k114883ffa7cadf97@mail.gmail.com>
From: Dot Porter
Date: Mon, 19 Mar 2007 08:06:23 -0400
Council members in the US,
The call in number for the highspeedconferencing.com has changed.
Instead of the phone number in the draft agenda message, please call
605-475-8500
If you call the number in the email, they'll give you this phone #...
Dot
-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 07:06:26 EST
From Conal.Tuohy at vuw.ac.nz Mon Mar 19 07:10:12 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 20 Mar 2007 00:10:12 +1200 Subject: [tei-council] conformance draft Message-ID:
From: Conal Tuohy
Date: Tue, 20 Mar 2007 00:10:12 +1200
I have read JC's "conformance" draft and I like it very much. Thanks James!
I have one comment there about the use of namespaces in "renaming" schemas. There is a kind of "loophole" there which I think should be tightened.
Renaming subset schema is defined on page 4
http://www.tei-c.org/Council/conformance-draft.pdf#page=4
The section on namespaces is on page 6
http://www.tei-c.org/Council/conformance-draft.pdf#page=6
If I read it correctly it seems to imply that Renaming Subset Schemas should have a special exemption to allow them to define new names in the TEI namespace, if it does so using to relate them to existing elements.
TEI-Conformant documents must not extend the TEI Namespace with additional elements and attributes except by means of a TEI Renaming Subset Schema produced from a TEI ODD file which properly documents the renamed elements or attributes through the use of the element.
It seems to me that a schema which renames an existing TEI element should do so in a new namespace. The semantics of the renamed element are the same as before, of course, but I'm not sure that automatically implies that the new element should belong to the TEI namespace. The issue to me is whether we should allow anyone to add names to the TEI namespace, and the question of whether those names are just new names for old elements or new names for new elements is not really relevant. The relevant question, to my mind, is whether those names are defined by someone independently of the official TEI schema development process. My rule of thumb is: if multiple people are defining names in the same namespace, then they should be coordinated; if they are not coordinated, then they should use distinct namespaces, otherwise there is a risk of collision.
e.g. if I rename tei:div1 to tei:book, and someone else renames tei:text to tei:book, then we have a name collision. Whereas if I rename tei:div1 to my:book, and someone else renames tei:text to their:book then there's no conflation (assuming that my: and their: are prefixes bound to distinct namespace URIs, of course).
It is true that by using the ODD, it should be possible to convert an instance of a Renaming Subset Schema to regular TEI, and this is a way around the issue. NB this does require that the instance documents are linked to their ODD in some way, and we'd also need to actually have such an equiv-based translator (I assume this would be quite an easy task? has it been done?). NB if different namespaces were used, it would be possible to perform such translations on an instance document, even if they had no link to their ODD file, since it would be possible to recognise my:book and their:book by their namespace URIs, without having to refer to "my.odd" amd "their.odd".
On a similar subject: shouldn't the official TEI translations of element names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for the Spanish translation?
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 07:10:32 EST
From dporter at uky.edu Mon Mar 19 07:13:04 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 08:13:04 -0400 Subject: [tei-council] facsimile ODD Message-ID: <96f3df640703190513s7468e833s6f7675345fc14ca6@mail.gmail.com>
From: Dot Porter
Date: Mon, 19 Mar 2007 08:13:04 -0400
Facsimile ODD is on the wiki:
http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD
-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 07:13:07 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 07:20:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 12:20:19 +0000 Subject: [tei-council] Council phone # for US In-Reply-To: <96f3df640703190506g40887785k114883ffa7cadf97@mail.gmail.com> Message-ID: <45FE8003.1020801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Mar 2007 12:20:19 +0000
Is anyone trying to get in and failing?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 07:20:23 EST
From Conal.Tuohy at vuw.ac.nz Mon Mar 19 08:00:33 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 20 Mar 2007 01:00:33 +1200 Subject: [tei-council] text and image encoding Message-ID:
From: Conal Tuohy
Date: Tue, 20 Mar 2007 01:00:33 +1200
I'm sorry to report that Dot and I have not made as much progress as we should have on this work item: http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/291
After the last teleconference I posted the ODD to the Wiki:
http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD
Since then we've been working on it sporadically, but we haven't yet updated the Wiki with anything new.
I have mostly integrated the discursive text into the ODD (locally), and I expect to have finished that tomorrow-ish, and upload it.
I've also been working on making test instance documents by generating them from PDF using the open source pdftohtml tool.
We have been looking at the Image Markup Tool and looking at the Edition Production Technology system, to see how they relate to the draft. The current draft has two mechanisms each of which correspond pretty well to these two different schemes.
The IMT schema essentially defines regions of images (using svg) and uses div elements as annotations of those regions, linking from the div/@n to the svg:rect/@id. This is a bit implicit and informal, but structurally it maps closely to our draft: we have a region element which is the equivalent of a rect. In our schema, an annotation could be done as a note linking to the region.
The EPT system is more about linking text to graphical images of the text, and that also maps pretty well, using the @left, @right, etc attributes.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 08:00:48 EST

From lou.burnard at computing-services.oxford.ac.uk Mon Mar 19 10:35:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Mar 2007 15:35:42 +0000 Subject: [tei-council] Notes from this morning's call Message-ID: <45FEADCE.8000003@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 19 Mar 2007 15:35:42 +0000
Brief notes from this morning's call are now up at
http://www.tei-c.org/Council/tcm29.xml?style=printable
L
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 10:36:37 EST
From James.Cummings at oucs.ox.ac.uk Mon Mar 19 10:56:07 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 19 Mar 2007 15:56:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: Message-ID: <45FEB297.1000906@oucs.ox.ac.uk>
From: James Cummings
Date: Mon, 19 Mar 2007 15:56:07 +0000
Conal Tuohy wrote:
> I have read JC's "conformance" draft and I like it very much. Thanks James!
You're welcome, but I'm sure not everyone will be so positive. :-) I know for a
fact that a number of people don't like this moral high ground of namespaces.
> I have one comment there about the use of namespaces in "renaming" schemas.
> There is a kind of "loophole" there which I think should be tightened.
I think I understand the loophole to which you refer, but might wish to tighten
it in a different way.
> If I read it correctly it seems to imply that Renaming Subset Schemas should
> have a special exemption to allow them to define new names in the TEI
> namespace, if it does so using to relate them to existing elements.
I'd say that these aren't 'new' elements, they are simply 'renamed' elements,
syntactic sugar if you like.
> TEI-Conformant documents must not extend the TEI Namespace with
> additional elements and attributes except by means of a TEI Renaming Subset
> Schema produced from a TEI ODD file which properly documents the renamed
> elements or attributes through the use of the element. It
> seems to me that a schema which renames an existing TEI element should do so
> in a new namespace. The semantics of the renamed element are the same as
> before, of course, but I'm not sure that automatically implies that the new
> element should belong to the TEI namespace. The issue to me is whether we
> should allow anyone to add names to the TEI namespace, and the question of
> whether those names are just new names for old elements or new names for new
> elements is not really relevant. The relevant question, to my mind, is
> whether those names are defined by someone independently of the official TEI
> schema development process. My rule of thumb is: if multiple people are
> defining names in the same namespace, then they should be coordinated; if
> they are not coordinated, then they should use distinct namespaces, otherwise
> there is a risk of collision.
Ok, I understand that. Perhaps we should be distinguishing here between local
processing documents and those for 'interchange'. We could say that a document
which validates against a TEI Renaming Subset schema should only be interchanged
with others when the changes have been reversed?
>
> e.g. if I rename tei:div1 to tei:book, and someone else renames tei:text to
> tei:book, then we have a name collision. Whereas if I rename tei:div1 to
> my:book, and someone else renames tei:text to their:book then there's no
> conflation (assuming that my: and their: are prefixes bound to distinct
> namespace URIs, of course).
I don't think there is an assumption that documents validating against different
TEI Renaming Subsets are in any way compatible or interoperable. Perhaps we
should tighten up the language to make sure. Documents validating against any
individual TEI Renaming Subset schema don't have this problem, do they? This
only occurs when I try to combine your documents with my documents? Conformance
shouldn't imply interoperability... but two people with documents that validate
against a TEI Renaming Subset *can* interchange documents as long as they
convert them back to TEI Pure Subset first.
> On a similar subject: shouldn't the official TEI translations of element
> names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for
> the Spanish translation?
I'll leave that one to Sebastian, he wot knows internationalisation.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 10:56:12 EST
From Syd_Bauman at Brown.edu Mon Mar 19 11:57:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 19 Mar 2007 12:57:57 -0400 Subject: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17918.49429.959292.434527@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 19 Mar 2007 12:57:57 -0400
Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got
duped by the incorrect date, and didn't read Christian's correction
until after the call was over. (I found out by desperately trying to
dial in 1st one Skype number, then the other, then the direct US
number, inadvertantly dialing Dan directly someplace in there ... ah,
well. :-)
Again, my apologies, and thanks to those who did make it for carrying
on, and to Lou for a nice and rapid job on the minutes.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 11:58:01 EST

From djbpitt+tei at pitt.edu Mon Mar 19 12:08:35 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 19 Mar 2007 13:08:35 -0400 Subject: [tei-council] Re: telecon today (March 19)! In-Reply-To: <17918.49429.959292.434527@emt.wwp.brown.edu> Message-ID: <45FEC393.4090102@pitt.edu>
From: David J Birnbaum
Date: Mon, 19 Mar 2007 13:08:35 -0400
Dear Council,
Sorry here, too. Still stranded this morning in the Philadelphia airport
by the ice storm that had shut everything down on Saturday (home now,
but hour too late).
Best,
David
Syd Bauman wrote:
> Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got
> duped by the incorrect date, and didn't read Christian's correction
> until after the call was over. (I found out by desperately trying to
> dial in 1st one Skype number, then the other, then the direct US
> number, inadvertantly dialing Dan directly someplace in there ... ah,
> well. :-)
>
> Again, my apologies, and thanks to those who did make it for carrying
> on, and to Lou for a nice and rapid job on the minutes.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 12:08:39 EST

From daniel.odonnell at uleth.ca Mon Mar 19 12:10:28 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 19 Mar 2007 11:10:28 -0600 Subject: [tei-council] Re: telecon today (March 19)! In-Reply-To: <45FEC393.4090102@pitt.edu> Message-ID: <1174324228.19319.0.camel@odonned-eng06>
From: Dan O'Donnell
Date: Mon, 19 Mar 2007 11:10:28 -0600
Wait till you guys see the action items we assigned you ;)
-dan
On Mon, 2007-19-03 at 13:08 -0400, David J Birnbaum wrote:
> Dear Council,
>
> Sorry here, too. Still stranded this morning in the Philadelphia airport
> by the ice storm that had shut everything down on Saturday (home now,
> but hour too late).
>
> Best,
>
> David
>
> Syd Bauman wrote:
> > Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got
> > duped by the incorrect date, and didn't read Christian's correction
> > until after the call was over. (I found out by desperately trying to
> > dial in 1st one Skype number, then the other, then the direct US
> > number, inadvertantly dialing Dan directly someplace in there ... ah,
> > well. :-)
> >
> > Again, my apologies, and thanks to those who did make it for carrying
> > on, and to Lou for a nice and rapid job on the minutes.
> >
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 12:09:38 EST
From dporter at uky.edu Mon Mar 19 13:36:16 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 14:36:16 -0400 Subject: [tei-council] Notes from this morning's call In-Reply-To: <45FEADCE.8000003@oucs.ox.ac.uk> Message-ID: <96f3df640703191136y74004ceay9bf25f7d5adf5822@mail.gmail.com>
From: Dot Porter
Date: Mon, 19 Mar 2007 14:36:16 -0400
Hi Lou,
Thanks for posting the minutes so quickly. Just a small note - I
wasn't responsible in any way for the Conformance draft, that's all
James' work.
Dot
On 3/19/07, Lou Burnard oxford.ac.uk> wrote:
> Brief notes from this morning's call are now up at
> http://www.tei-c.org/Council/tcm29.xml?style=printable
>
> L
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 13:36:19 EST

From djbpitt+tei at pitt.edu Mon Mar 19 15:47:59 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 19 Mar 2007 16:47:59 -0400 Subject: [tei-council] conformance draft In-Reply-To: <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FEF6FF.9040800@pitt.edu>
From: David J Birnbaum
Date: Mon, 19 Mar 2007 16:47:59 -0400
Dear Council,
>
>> This enables me to announce that James has just delivered a
>> preliminary draft for the Conformance chapter of P5, which should be
>> on our agenda for next week. You can read the draft at
>>
>> http://www.tei-c.org/Council/conformance-draft.pdf
Thanks, James; this looks very good! Just a few minor details (some of
which may reflect my ignorance of British English):
Section 1.2.5: extra "a" in "the TEI provides a web-based tools and scripts"
Section 1.3.1 (under tei_allPlus): spurious "the" in "but also the
demonstrates"
Section 1.3.1 (under tei_bare): "the very basic ... possible" in
"provides the very basic minimum TEI possible" is bad in American
English. If it's okay in British English, so be it, but if it's bad
there too, you might want to change it to "the most basic ... possible."
Section 1.3.1 (under teilite): "It can be a useful starting point for
those who want to add or remove only a few aspects to TEI Lite." There's
nothing wrong with this, but because we spent many years telling people
"don't customize TEI Lite" and feeling exasperated when they didn't
listen that we might want to add a footnote explaining why it's a new
world now.
Section 1.3.1 (under tei_odds): "This includes not only the TEI module
for documentation elements, but the external Relax NG schema." American
English requires an "also" after the "but." If British English doesn't,
so be it.
Section 1.3.1 (under tei_svg): "the minimum basic four TEI modules" is
the first time we mention that there are four basic modules. Should we
list them here, on first reference, in a footnote?
Section 1.3.1 (under tei_xinclude): "set up" in "This example has been
setup ..." should be two words. This whole sentence is a bit awkward;
"has been set up ... and allows" is nonparallel and there's a comma
splice at the end.
Section 1.3.2 (under TEI Extension Schema): Comma splice in "The
relationship of any extensions to the TEI should be documented in a TEI
ODD file, additionally all renamings of existing TEI elements and
attributes should be documented with an element to an existing
TEI Pure Subset schema equivalent for them."
Section 1.3.3.3: missing space in "customization is"
Section 1.4: "It is a requirement of TEI Conformance that, in a
TEI-Conformant document, all existing TEI elements and attributes are in
the TEI Namespace" should read "be" instead of "are"
Section 1.4: Hyphenate the attributive adjective "user-defined" in "a
user-defined one". It is hyphenated correctly later in the same
paragraph: "In choosing user-defined namespaces ..."
Throughout: Failure to distinguish restrictive and nonrestrictive
clauses (use of commas and use of which/that). I'm a pedant about such
matters; if you don't care, just ignore me and I'll try not to rant.
Cheers,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 19 2007 - 15:48:16 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 17:15:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 22:15:59 +0000 Subject: [tei-council] cleaning up trac Message-ID: <45FF0B9F.5090100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Mar 2007 22:15:59 +0000
As per council meeting action today, I have checked the
tracker, moved some tickets, closed some tickets, and
clarified some tickets.
In summary:
* 6 tickets now outstanding in the "left over from SF" category. these
are all assigned to Lou or Syd,
and really need knocking on the head ASAP.
* 3 items in "make last minute technical proposals", for Conal on
facsimile markup and for Lou
on personography.
We can expect more items to get into the "make last minute technical
proposals" section;
this forms an important part of the Berlin agenda; so anything which
involves non-trivial
changes or additions needs to have a ticket in there, and an owner, who
will propose
and defend it in Berlin. As a result of that, there can be 3 outcomes:
a) transfer to //"Solve remaining technical issues" for resolution; b)
assign to new ticket//

under P5.1; or c) abandon it.
This affects the editors most. The rest of the Council should be looking
forward with excitement to their assigned review chapters ("first pass
technical review").
I have entirely dropped a milestone which said "review datatype and
class decisions". This
will be merged into "first pass technical review", for simplicity.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 17:16:08 EST
From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 18:04:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 23:04:16 +0000 Subject: [tei-council] easter presents for everyone Message-ID: <45FF16F0.7080301@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Mar 2007 23:04:16 +0000
As per council action today,
I have made a first pass through the chapters,
and assigned all the chapters to people. I have _not_
included Lou and Syd in this, as they have
other tasks to complete before Berlin.
I have vaguely balanced the workload depending
on what else people are committed to, but not
necessarily fairly; so feel free to horse trade,
and complain, and wriggle. If you genuinely
can't do the job at all, say so now! You can even
volunteer to take on more.
The assignments are made in trac.
A more detailed spec of the task will
follow shortly, but the essence of it
is that you will read the chapter, and make
a first pass review looking for stuff which
is unclear, undated, or broken.
So, opening the envelope, this is what you get:
ariana SG: Gentle intro
ariana DS: Default Text Structure
ariana ND: Names and Dates
christian TE: Terminological Databases
christian CE: Certainty and Responsibility
christian FD: Feature System Declaration
conal AI: Simple Analytic Mechanisms
conal FT: Tables, Formulae, and Graphics
daniel DEDICATION
daniel AB: About the guidelines
daniel MS: The Manuscript Description Element
daniel PH: Transcription of Primary Sources
daniel TC: Critical Apparatus
david ST: Structure of the TEI Document Type Definition
david CO: Elements Available in All TEI Documents
david TD: Documentation Elements
dot TS: Transcriptions of Speech
dot SA: Linking, Segmentation, and Alignment
dot CC: Language Corpora
james FM1: Preface
james DR: Base Tag Set for Drama
james CF: Conformance
john HD: The TEI Header
john VE: Base Tag Set for Verse
john FS: Feature Structures
laurent SH: The Independent Header
laurent WD: Writing System Declaration
matthew HD: The TEI Header
matthew PR: Base Tag Set for Prose
matthew DI: Print Dictionaries
rahtz GD: Graphs, Networks, and Trees
rahtz MD: Modifying and Customizing the TEI DTD
rahtz IN: Rules for Interchange
rahtz DT: Obtaining the TEI DTD
tone CH: Languages and Character Sets
tone NH: Multiple Hierarchies
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 18:04:20 EST
From James.Cummings at computing-services.oxford.ac.uk Mon Mar 19 18:19:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 19 Mar 2007 23:19:53 +0000 Subject: [tei-council] conformance draft In-Reply-To: <45FEF6FF.9040800@pitt.edu> Message-ID: <45FF1A99.7010003@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 19 Mar 2007 23:19:53 +0000
Thanks David, I'm sure you are right about almost all those.

> Section 1.3.1 (under teilite): "It can be a useful starting point for
> those who want to add or remove only a few aspects to TEI Lite." There's
> nothing wrong with this, but because we spent many years telling people
> "don't customize TEI Lite" and feeling exasperated when they didn't
> listen that we might want to add a footnote explaining why it's a new
> world now.
Good point.
> Section 1.3.1 (under tei_svg): "the minimum basic four TEI modules" is
> the first time we mention that there are four basic modules. Should we
> list them here, on first reference, in a footnote?
Or should this have been explained elsewhere, prior to this chapter? (For
example in Modification which precedes it?
> Throughout: Failure to distinguish restrictive and nonrestrictive
> clauses (use of commas and use of which/that). I'm a pedant about such
> matters; if you don't care, just ignore me and I'll try not to rant.
Yes, Canadians tend to use 'that' for restrictive relative clauses and I've
always been fairly bad about distinguishing them overall. Thanks for all the
grammatical corrections; I'd assumed that I'd tidy up grammar once people had
agreed to the concepts, but that still should not be an excuse.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 18:19:50 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 18:41:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 23:41:19 +0000 Subject: [tei-council] conformance draft In-Reply-To: <45FEB297.1000906@oucs.ox.ac.uk> Message-ID: <45FF1F9F.3030101@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 19 Mar 2007 23:41:19 +0000
James Cummings wrote:
>
>> On a similar subject: shouldn't the official TEI translations of element
>> names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for
>> the Spanish translation?
>>
>
> I'll leave that one to Sebastian, he wot knows internationalisation.
>
the translations are simply a convenience
canned example of a "TEI Renaming Subset",
so I don't think they need special treatment.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 19 2007 - 18:41:29 EST
From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Mar 20 02:27:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 20 Mar 2007 15:27:11 +0800 Subject: [tei-council] Notes from this morning's call In-Reply-To: <45FEADCE.8000003@oucs.ox.ac.uk> Message-ID: <45FF8CCF.2050506@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 20 Mar 2007 15:27:11 +0800
Lou Burnard wrote:
> Brief notes from this morning's call are now up at
> http://www.tei-c.org/Council/tcm29.xml?style=printable
Great. They look complete to me.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 20 2007 - 02:59:12 EST

From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 06:13:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 11:13:52 +0000 Subject: [tei-council] New draft editorial guidelines Message-ID: <46011370.4070608@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 21 Mar 2007 11:13:52 +0000
As a preliminary to unwrapping the easter egg Sebastian has just offered
you all, Council members might like to have a quick read through the
document on Editorial Guidelines which I posted on the web yesterday.
It's at http://www.tei-c.org/Drafts/editorial.xml
The document is an updating of sage advice prepared by the TEI Editors
in days of yore (i.e. about 9 years ago) and still accessible in the
Vault as edw55.tei if you don't believe me. I have added a little about
how I think we ought to do things now, and removed anything which is
definitely superannuated, but the important parts of the "house rules"
for writing P5 are unchanged. Please bear them in mind as you review
your chapters!
I'd be grateful for suggestions as to (a) rules missing from the
document which should be added (b) rules which we no longer believe in.
Note that a biggish chunk of the document is taken from one of the
chapters of the Guidelines (AB), so the two need to be kept in step.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 06:14:53 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Mar 21 07:15:47 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 21 Mar 2007 20:15:47 +0800 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46011370.4070608@oucs.ox.ac.uk> Message-ID: <460121F3.4030103@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 21 Mar 2007 20:15:47 +0800
Lou Burnard wrote:
> As a preliminary to unwrapping the easter egg Sebastian has just offered
> you all, Council members might like to have a quick read through the
> document on Editorial Guidelines which I posted on the web yesterday.
> It's at http://www.tei-c.org/Drafts/editorial.xml
Ahem, trying to look at this gives me:
The content of elements must consist of well-formed character data or
markup.
org.apache.cocoon.ProcessingException: Error executing pipeline.:
file:/home12/tei/web/Drafts/editorial.xml:463:35:org.xml.sax.SAXParseException:
The content of elements must consist of well-formed character data or
markup.

Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 08:03:59 EST

From daniel.odonnell at uleth.ca Wed Mar 21 09:17:42 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 08:17:42 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46011370.4070608@oucs.ox.ac.uk> Message-ID: <1174486662.32123.7.camel@caedmon>
From: Daniel O'Donnell
Date: Wed, 21 Mar 2007 08:17:42 -0600
Gettinng a different cocoon error than the one Christian reported, but a
cocoon error none the less.
On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote:
> As a preliminary to unwrapping the easter egg Sebastian has just offered
> you all, Council members might like to have a quick read through the
> document on Editorial Guidelines which I posted on the web yesterday.
> It's at http://www.tei-c.org/Drafts/editorial.xml
>
> The document is an updating of sage advice prepared by the TEI Editors
> in days of yore (i.e. about 9 years ago) and still accessible in the
> Vault as edw55.tei if you don't believe me. I have added a little about
> how I think we ought to do things now, and removed anything which is
> definitely superannuated, but the important parts of the "house rules"
> for writing P5 are unchanged. Please bear them in mind as you review
> your chapters!
>
> I'd be grateful for suggestions as to (a) rules missing from the
> document which should be added (b) rules which we no longer believe in.
>
> Note that a biggish chunk of the document is taken from one of the
> chapters of the Guidelines (AB), so the two need to be kept in step.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 09:17:46 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 09:23:46 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 14:23:46 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> Message-ID: <46013FF2.9030806@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 21 Mar 2007 14:23:46 +0000
Sorry -- my error. I introduced a typo making some other fixes spotted
by Sebastian this morning.
Shd be ok now.
Daniel O'Donnell wrote:
> Gettinng a different cocoon error than the one Christian reported, but a
> cocoon error none the less.
>
> On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote:
>> As a preliminary to unwrapping the easter egg Sebastian has just offered
>> you all, Council members might like to have a quick read through the
>> document on Editorial Guidelines which I posted on the web yesterday.
>> It's at http://www.tei-c.org/Drafts/editorial.xml
>>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 09:24:47 EST
From laurent.romary at loria.fr Wed Mar 21 09:23:21 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 21 Mar 2007 15:23:21 +0100 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> Message-ID: <6DA197E5-A179-4BA8-996E-DB471A15E940@loria.fr>
From: Laurent Romary
Date: Wed, 21 Mar 2007 15:23:21 +0100
No error on my side... I have printed and read the document all right.
Cheers,
Laurent
Le 21 mars 07 ? 15:17, Daniel O'Donnell a ?crit :
> Gettinng a different cocoon error than the one Christian reported,
> but a
> cocoon error none the less.
>
> On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote:
>> As a preliminary to unwrapping the easter egg Sebastian has just
>> offered
>> you all, Council members might like to have a quick read through
>> the
>> document on Editorial Guidelines which I posted on the web yesterday.
>> It's at http://www.tei-c.org/Drafts/editorial.xml
>>
>> The document is an updating of sage advice prepared by the TEI
>> Editors
>> in days of yore (i.e. about 9 years ago) and still accessible in the
>> Vault as edw55.tei if you don't believe me. I have added a little
>> about
>> how I think we ought to do things now, and removed anything which is
>> definitely superannuated, but the important parts of the "house
>> rules"
>> for writing P5 are unchanged. Please bear them in mind as you review
>> your chapters!
>>
>> I'd be grateful for suggestions as to (a) rules missing from the
>> document which should be added (b) rules which we no longer
>> believe in.
>>
>> Note that a biggish chunk of the document is taken from one of the
>> chapters of the Guidelines (AB), so the two need to be kept in step.
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> --
> Daniel Paul O'Donnell, PhD
> Department Chair and Associate Professor of English
> Director, Digital Medievalist Project http://
> www.digitalmedievalist.org/
> Chair, Text Encoding Initiative http://www.tei-c.org/
>
> Department of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox +1 403 329-2377
> Fax +1 403 382-7191
> Email: daniel.odonnell_at_uleth.ca
> WWW: http://people.uleth.ca/~daniel.odonnell/
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 09:24:55 EST
From daniel.odonnell at uleth.ca Wed Mar 21 10:18:26 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 09:18:26 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> Message-ID: <1174490306.32123.72.camel@caedmon>
From: Daniel O'Donnell
Date: Wed, 21 Mar 2007 09:18:26 -0600
http://www.tei-c.org/Drafts/editorial.xml:
503: Service Temporarily Unavailable
The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.
On Wed, 2007-03-21 at 08:17 -0600, Daniel O'Donnell wrote:
> Gettinng a different cocoon error than the one Christian reported, but a
> cocoon error none the less.
>
> On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote:
> > As a preliminary to unwrapping the easter egg Sebastian has just offered
> > you all, Council members might like to have a quick read through the
> > document on Editorial Guidelines which I posted on the web yesterday.
> > It's at http://www.tei-c.org/Drafts/editorial.xml
> >
> > The document is an updating of sage advice prepared by the TEI Editors
> > in days of yore (i.e. about 9 years ago) and still accessible in the
> > Vault as edw55.tei if you don't believe me. I have added a little about
> > how I think we ought to do things now, and removed anything which is
> > definitely superannuated, but the important parts of the "house rules"
> > for writing P5 are unchanged. Please bear them in mind as you review
> > your chapters!
> >
> > I'd be grateful for suggestions as to (a) rules missing from the
> > document which should be added (b) rules which we no longer believe in.
> >
> > Note that a biggish chunk of the document is taken from one of the
> > chapters of the Guidelines (AB), so the two need to be kept in step.
> >
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 10:18:29 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 10:27:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 15:27:35 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174490306.32123.72.camel@caedmon> Message-ID: <46014EE7.8060601@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 21 Mar 2007 15:27:35 +0000
Nothing to do with me guvnor. That's a virginian problem affecting the
whole website (which was OK about 15 minutes ago...)
Still, it's better than the (lack of) messages we were getting last time
someone fell over the power cable or spilled coffee into the disk array
or whatever their problem is.
Daniel O'Donnell wrote:
> http://www.tei-c.org/Drafts/editorial.xml:
>
> 503: Service Temporarily Unavailable
> The server is temporarily unable to service your request due to
> maintenance downtime or capacity problems. Please try again later.
>
-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 10:28:35 EST
From arianna.ciula at kcl.ac.uk Wed Mar 21 10:57:54 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 21 Mar 2007 15:57:54 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46014EE7.8060601@oucs.ox.ac.uk> Message-ID: <46015602.4070600@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 21 Mar 2007 15:57:54 +0000
If we continue to get the error could you please make the document
available in some other ways?
Thanks,
Arianna
Lou Burnard wrote:
> Nothing to do with me guvnor. That's a virginian problem affecting the
> whole website (which was OK about 15 minutes ago...)
>
> Still, it's better than the (lack of) messages we were getting last time
> someone fell over the power cable or spilled coffee into the disk array
> or whatever their problem is.
>
> Daniel O'Donnell wrote:
>> http://www.tei-c.org/Drafts/editorial.xml:
>>
>> 503: Service Temporarily Unavailable
>> The server is temporarily unable to service your request due to
>> maintenance downtime or capacity problems. Please try again later.
>>
> -council_at_lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 11:00:40 EST
From daniel.odonnell at uleth.ca Wed Mar 21 12:10:44 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 11:10:44 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46015602.4070600@kcl.ac.uk> Message-ID: <1174497044.5280.4.camel@caedmon>
From: Daniel O'Donnell
Date: Wed, 21 Mar 2007 11:10:44 -0600
I've contacted the powers that be to get it fixed.
On Wed, 2007-03-21 at 15:57 +0000, Arianna Ciula wrote:
> If we continue to get the error could you please make the document
> available in some other ways?
>
> Thanks,
> Arianna
>
> Lou Burnard wrote:
> > Nothing to do with me guvnor. That's a virginian problem affecting the
> > whole website (which was OK about 15 minutes ago...)
> >
> > Still, it's better than the (lack of) messages we were getting last time
> > someone fell over the power cable or spilled coffee into the disk array
> > or whatever their problem is.
> >
> > Daniel O'Donnell wrote:
> >> http://www.tei-c.org/Drafts/editorial.xml:
> >>
> >> 503: Service Temporarily Unavailable
> >> The server is temporarily unable to service your request due to
> >> maintenance downtime or capacity problems. Please try again later.
> >>
> > -council_at_lists.village.Virginia.EDU
> >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 12:10:50 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 12:25:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 17:25:19 +0000 Subject: [tei-council] Re: 503 error on tei-c In-Reply-To: <1174496976.5280.2.camel@caedmon> Message-ID: <46016A7F.7000501@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 21 Mar 2007 17:25:19 +0000
As there appear to be problems with the Virginia site again this
afternoon, council members may wish to access the UK mirror instead
http://www.tei-c.org.uk/Drafts/editorial.xml
(there was a brief hiatus here this afternoon while we did some local
updating but it's back now)
Lou
Daniel O'Donnell wrote:
> Hi Shayne,
>
> There's a 503 error on the tei site:
> http://www.tei-c.org/Drafts/editorial.xml
>
> The council is using this as a guideline for review in preparation for
> our upcoming meeting, so we will need to get it back up.
>
> -dan
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 12:26:20 EST
From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 18:22:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 23:22:05 +0000 Subject: [tei-council] Witness proposal Message-ID: <4601BE1D.3010403@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 21 Mar 2007 23:22:05 +0000
In early november last year, Gautier Poupeau whom several of you will
recall from his presentation at the Members meeting, sent me a document
outlining a proposal to address the inconsistency currently subsisting
in the Guidelines about how manuscript (or print) witnesses should be
documented. I owe him, and the Council, a major apology for having not
done anything with it -- it simply got mislaid and then forgotten.
Fortunately, he's a persevering kind of chap, and I have now recovered
the draft and placed it somewhere you can see it, viz:
http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
It's in French, so I will summarize briefly the proposal here (I will
also translate the document fully if so requested)
* create a new class called model.witnessPart. which is a subclass of
model.phrasel; use this class in the content model of
* add to this class a number of elements currently specific to
msDescription, specifically:
origDate, material, physDesc, seal, dimensions,
filiation,msIdentifier, msContents, rubric;
* re-introduce the "sigil" attribute as a new element
* add a "class" attribute to
The suggestion is based on Gautier's extensive experience in adapting
TEI to the description of cartularies and similar documents, with due
regard to practice in German, Italian, and French collections.
I think the work is sufficiently straightforward to do quite quickly
(i.e. it can be done for P5); I also suspect that it would be a very
smart political move to be seen to be doing something in this area.
Initial comments?
(It occurs to me also that this might be something the newly revived mss
SIG would like to kick around -- but that could happen independently of
plumbing his suggestion into P5)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Mar 21 2007 - 18:22:08 EST
From dporter at uky.edu Wed Mar 21 18:47:09 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 21 Mar 2007 15:47:09 -0800 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <96f3df640703211647q3f44a6e7k7dafe343624cb704@mail.gmail.com>
From: Dot Porter
Date: Wed, 21 Mar 2007 15:47:09 -0800
This sounds like an interesting proposal, but I would like to know a
bit more. Lou, if you could provide a translation I would appreciate
it.
Thanks,
Dot
On 3/21/07, Lou Burnard oxford.ac.uk> wrote:
> In early november last year, Gautier Poupeau whom several of you will
> recall from his presentation at the Members meeting, sent me a document
> outlining a proposal to address the inconsistency currently subsisting
> in the Guidelines about how manuscript (or print) witnesses should be
> documented. I owe him, and the Council, a major apology for having not
> done anything with it -- it simply got mislaid and then forgotten.
> Fortunately, he's a persevering kind of chap, and I have now recovered
> the draft and placed it somewhere you can see it, viz:
>
> http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
>
> It's in French, so I will summarize briefly the proposal here (I will
> also translate the document fully if so requested)
>
> * create a new class called model.witnessPart. which is a subclass of
> model.phrasel; use this class in the content model of
> * add to this class a number of elements currently specific to
> msDescription, specifically:
> origDate, material, physDesc, seal, dimensions,
> filiation,msIdentifier, msContents, rubric;
> * re-introduce the "sigil" attribute as a new element
> * add a "class" attribute to
>
> The suggestion is based on Gautier's extensive experience in adapting
> TEI to the description of cartularies and similar documents, with due
> regard to practice in German, Italian, and French collections.
>
> I think the work is sufficiently straightforward to do quite quickly
> (i.e. it can be done for P5); I also suspect that it would be a very
> smart political move to be seen to be doing something in this area.
>
> Initial comments?
>
> (It occurs to me also that this might be something the newly revived mss
> SIG would like to kick around -- but that could happen independently of
> plumbing his suggestion into P5)
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 21 2007 - 18:47:13 EST

From mjd at hum.ku.dk Thu Mar 22 05:16:06 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Thu, 22 Mar 2007 11:16:06 +0100 Subject: [tei-council] SV: Witness proposal Message-ID: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Thu, 22 Mar 2007 11:16:06 +0100
In terms of revamping , which was never a terribly sophisticated
element, this proposal makes perfect sense. It is not clear to me, however,
whether the newly redefined element is intended as an alternative
to or whether there are situations in which one would use
both. Neither appeals much to me, I must say, especially as I can't see that
what is being proposed can't be done with as it is. The
original idea behind , in any case, was very much that it
should be able to be used for more than just cataloguing (our insistence on
this was what led to the bulk of the disagreements with "TEI-MMSS"), and it
was indeed my understanding that and were now to be
deprecated as redundant. If there are things which Gautier, representing
German, Italian and French practice, genuinely can't do using the current
mechanism it would be far more useful, it seems to me, for
us to try and adapt the existing mechanism, rather than coming up with a
parallel one.
Looking at his proposal, the chief lack seems to be a means of indicating
the sigla, for which he proposes a new element; these can easily
appear within as , which takes a type
attribute. Otherwise the elements are largely from the
module, suggesting that perhaps we aren't so far off the mark after all.
Matthew


-----Oprindelig meddelelse-----
Fra: Lou Burnard [mailto:lou.burnard_at_computing-services.oxford.ac.uk]
Sendt: 22 March 2007 00:22
Til: Matthew James Driscoll; TEI Council; gotpoupeau_at_infonie.fr
Emne: Witness proposal
In early november last year, Gautier Poupeau whom several of you will
recall from his presentation at the Members meeting, sent me a document
outlining a proposal to address the inconsistency currently subsisting
in the Guidelines about how manuscript (or print) witnesses should be
documented. I owe him, and the Council, a major apology for having not
done anything with it -- it simply got mislaid and then forgotten.
Fortunately, he's a persevering kind of chap, and I have now recovered
the draft and placed it somewhere you can see it, viz:
http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
It's in French, so I will summarize briefly the proposal here (I will
also translate the document fully if so requested)
* create a new class called model.witnessPart. which is a subclass of
model.phrasel; use this class in the content model of
* add to this class a number of elements currently specific to
msDescription, specifically:
origDate, material, physDesc, seal, dimensions,
filiation,msIdentifier, msContents, rubric;
* re-introduce the "sigil" attribute as a new element
* add a "class" attribute to
The suggestion is based on Gautier's extensive experience in adapting
TEI to the description of cartularies and similar documents, with due
regard to practice in German, Italian, and French collections.
I think the work is sufficiently straightforward to do quite quickly
(i.e. it can be done for P5); I also suspect that it would be a very
smart political move to be seen to be doing something in this area.
Initial comments?
(It occurs to me also that this might be something the newly revived mss
SIG would like to kick around -- but that could happen independently of
plumbing his suggestion into P5)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 05:16:20 EST
From dporter at uky.edu Thu Mar 22 05:40:57 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 22 Mar 2007 02:40:57 -0800 Subject: [tei-council] SV: Witness proposal In-Reply-To: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk> Message-ID: <96f3df640703220340v2b42b2e8s4517b8b6ca52feac@mail.gmail.com>
From: Dot Porter
Date: Thu, 22 Mar 2007 02:40:57 -0800
Hi Matthew and council,
On 3/22/07, Matthew James Driscoll ku.dk> wrote:
> In terms of revamping , which was never a terribly sophisticated
> element, this proposal makes perfect sense. It is not clear to me, however,
> whether the newly redefined element is intended as an alternative
> to or whether there are situations in which one would use
> both. Neither appeals much to me, I must say, especially as I can't see that
> what is being proposed can't be done with as it is.
This is my concern as well. Since I can't read French, I was hoping
that the proposal includes some reasoning for basically placing
in , rather just using
(multiple instances, if need be) and linking them to the es.
Thanks,
Dot
The
> original idea behind , in any case, was very much that it
> should be able to be used for more than just cataloguing (our insistence on
> this was what led to the bulk of the disagreements with "TEI-MMSS"), and it
> was indeed my understanding that and were now to be
> deprecated as redundant. If there are things which Gautier, representing
> German, Italian and French practice, genuinely can't do using the current
> mechanism it would be far more useful, it seems to me, for
> us to try and adapt the existing mechanism, rather than coming up with a
> parallel one.
>
> Looking at his proposal, the chief lack seems to be a means of indicating
> the sigla, for which he proposes a new element; these can easily
> appear within as , which takes a type
> attribute. Otherwise the elements are largely from the
> module, suggesting that perhaps we aren't so far off the mark after all.
>
> Matthew
>
>
>
>
> -----Oprindelig meddelelse-----
> Fra: Lou Burnard [mailto:lou.burnard_at_computing-services.oxford.ac.uk]
> Sendt: 22 March 2007 00:22
> Til: Matthew James Driscoll; TEI Council; gotpoupeau_at_infonie.fr
> Emne: Witness proposal
>
> In early november last year, Gautier Poupeau whom several of you will
> recall from his presentation at the Members meeting, sent me a document
> outlining a proposal to address the inconsistency currently subsisting
> in the Guidelines about how manuscript (or print) witnesses should be
> documented. I owe him, and the Council, a major apology for having not
> done anything with it -- it simply got mislaid and then forgotten.
> Fortunately, he's a persevering kind of chap, and I have now recovered
> the draft and placed it somewhere you can see it, viz:
>
> http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
>
> It's in French, so I will summarize briefly the proposal here (I will
> also translate the document fully if so requested)
>
> * create a new class called model.witnessPart. which is a subclass of
> model.phrasel; use this class in the content model of
> * add to this class a number of elements currently specific to
> msDescription, specifically:
> origDate, material, physDesc, seal, dimensions,
> filiation,msIdentifier, msContents, rubric;
> * re-introduce the "sigil" attribute as a new element
> * add a "class" attribute to
>
> The suggestion is based on Gautier's extensive experience in adapting
> TEI to the description of cartularies and similar documents, with due
> regard to practice in German, Italian, and French collections.
>
> I think the work is sufficiently straightforward to do quite quickly
> (i.e. it can be done for P5); I also suspect that it would be a very
> smart political move to be seen to be doing something in this area.
>
> Initial comments?
>
> (It occurs to me also that this might be something the newly revived mss
> SIG would like to kick around -- but that could happen independently of
> plumbing his suggestion into P5)
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 05:41:01 EST

From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 05:57:45 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 22 Mar 2007 10:57:45 +0000 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <46026129.6030503@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 22 Mar 2007 10:57:45 +0000
Lou Burnard wrote:
> Fortunately, he's a persevering kind of chap, and I have now recovered
> the draft and placed it somewhere you can see it, viz:
>
> http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
>
> It's in French, so I will summarize briefly the proposal here (I will
> also translate the document fully if so requested)
While I'm able to get the general sense from the document, I'm sure a
translation would help me as well, so I'd second Dot's request.
> * create a new class called model.witnessPart. which is a subclass of
> model.phrasel; use this class in the content model of
> * add to this class a number of elements currently specific to
> msDescription, specifically:
> origDate, material, physDesc, seal, dimensions,
> filiation,msIdentifier, msContents, rubric;
Why can't the witness instead link to an msDescription?
> * re-introduce the "sigil" attribute as a new element
If I'm understanding the French, the complaint is that the suggested use of
xml:id is to constricting since people may wish to use existing sigla well-known
in the community, but that simultaneously is too vague and generic but
also won't allow some useful elements. Am I understanding that correctly? I
still think I'd favour a linking mechanism from witness to msIdentifier if
someone needs a more detailed identification. Maybe I'm misunderstanding the
proposal though.

> * add a "class" attribute to
I was unable to get up the "Appendix A Liste des ?l?ments de la classe
witnessPart", but if I'm understanding the prose description correctly, this
attribute would be used to indicate a taxonomy used to classify that witness.
Which again seems like something which should be off in msDescription
I'm probably just mistranslating things though, so I look forward to Lou's
translation which I know is in hand.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 05:57:49 EST

From lou.burnard at computing-services.oxford.ac.uk Thu Mar 22 05:58:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 22 Mar 2007 10:58:12 +0000 Subject: [tei-council] SV: Witness proposal In-Reply-To: <96f3df640703220340v2b42b2e8s4517b8b6ca52feac@mail.gmail.com> Message-ID: <46026144.6070004@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 22 Mar 2007 10:58:12 +0000
A hasty English translation, not yet checked by Goto, is at
http://www.tei-c.org/Drafts/witnessPart/index.xml?style=printable
My own comments will follow...

Dot Porter wrote:
> Hi Matthew and council,
>
> On 3/22/07, Matthew James Driscoll ku.dk> wrote:
>> In terms of revamping , which was never a terribly sophisticated
>> element, this proposal makes perfect sense. It is not clear to me,
>> however,
>> whether the newly redefined element is intended as an
>> alternative
>> to or whether there are situations in which one would use
>> both. Neither appeals much to me, I must say, especially as I can't
>> see that
>> what is being proposed can't be done with as it is.
>
> This is my concern as well. Since I can't read French, I was hoping
> that the proposal includes some reasoning for basically placing
> in , rather just using
> (multiple instances, if need be) and linking them to the es.
>
> Thanks,
> Dot
>
> The
>> original idea behind , in any case, was very much that it
>> should be able to be used for more than just cataloguing (our
>> insistence on
>> this was what led to the bulk of the disagreements with "TEI-MMSS"),
>> and it
>> was indeed my understanding that and were now to be
>> deprecated as redundant. If there are things which Gautier, representing
>> German, Italian and French practice, genuinely can't do using the current
>> mechanism it would be far more useful, it seems to me,
>> for
>> us to try and adapt the existing mechanism, rather than coming up with a
>> parallel one.
>>
>> Looking at his proposal, the chief lack seems to be a means of indicating
>> the sigla, for which he proposes a new element; these can easily
>> appear within as , which takes a type
>> attribute. Otherwise the elements are largely from the
>> module, suggesting that perhaps we aren't so far off the mark after all.
>>
>> Matthew
>>
>>
>>
>>
>> -----Oprindelig meddelelse-----
>> Fra: Lou Burnard [mailto:lou.burnard_at_computing-services.oxford.ac.uk]
>> Sendt: 22 March 2007 00:22
>> Til: Matthew James Driscoll; TEI Council; gotpoupeau_at_infonie.fr
>> Emne: Witness proposal
>>
>> In early november last year, Gautier Poupeau whom several of you will
>> recall from his presentation at the Members meeting, sent me a document
>> outlining a proposal to address the inconsistency currently subsisting
>> in the Guidelines about how manuscript (or print) witnesses should be
>> documented. I owe him, and the Council, a major apology for having not
>> done anything with it -- it simply got mislaid and then forgotten.
>> Fortunately, he's a persevering kind of chap, and I have now recovered
>> the draft and placed it somewhere you can see it, viz:
>>
>> http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
>>
>> It's in French, so I will summarize briefly the proposal here (I will
>> also translate the document fully if so requested)
>>
>> * create a new class called model.witnessPart. which is a subclass of
>> model.phrasel; use this class in the content model of
>> * add to this class a number of elements currently specific to
>> msDescription, specifically:
>> origDate, material, physDesc, seal, dimensions,
>> filiation,msIdentifier, msContents, rubric;
>> * re-introduce the "sigil" attribute as a new element
>> * add a "class" attribute to
>>
>> The suggestion is based on Gautier's extensive experience in adapting
>> TEI to the description of cartularies and similar documents, with due
>> regard to practice in German, Italian, and French collections.
>>
>> I think the work is sufficiently straightforward to do quite quickly
>> (i.e. it can be done for P5); I also suspect that it would be a very
>> smart political move to be seen to be doing something in this area.
>>
>> Initial comments?
>>
>> (It occurs to me also that this might be something the newly revived mss
>> SIG would like to kick around -- but that could happen independently of
>> plumbing his suggestion into P5)
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 05:59:18 EST

From dporter at uky.edu Thu Mar 22 06:08:26 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 22 Mar 2007 03:08:26 -0800 Subject: [tei-council] Witness proposal In-Reply-To: <46026129.6030503@computing-services.oxford.ac.uk> Message-ID: <96f3df640703220408x2021978j694e59ec60206518@mail.gmail.com>
From: Dot Porter
Date: Thu, 22 Mar 2007 03:08:26 -0800
I agree with James here - why not link multiple msDescriptions to witnesses?
Gautier (in Lou's translation) says:
"The second solution would be to place a list containing a description
of each witness used by the critical edition in the header of the
file. This solution is quite feasible, and even advisable in the case
of an edition of one text, such as a literary edition, for example.
But where the critical edition is a collection of texts, for example a
collection of charters, exempla or even "farces", it would be
preferable to use a precise description of each witness in each text."
This could be multiple msDescriptions in the header.
"Moreover, the witness list will include not only manuscripts
(archives, or books) but also printed material: the description of
witnesses therefore involves more than msdescriptions."
List both multiple s (for printed material) and multiple
s (for manuscript/archives) in the sourceDesc?
Dot
On 3/22/07, James Cummings
oxford.ac.uk> wrote:
> Lou Burnard wrote:
> > Fortunately, he's a persevering kind of chap, and I have now recovered
> > the draft and placed it somewhere you can see it, viz:
> >
> > http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml
> >
> > It's in French, so I will summarize briefly the proposal here (I will
> > also translate the document fully if so requested)
>
> While I'm able to get the general sense from the document, I'm sure a
> translation would help me as well, so I'd second Dot's request.
>
> > * create a new class called model.witnessPart. which is a subclass of
> > model.phrasel; use this class in the content model of
> > * add to this class a number of elements currently specific to
> > msDescription, specifically:
> > origDate, material, physDesc, seal, dimensions,
> > filiation,msIdentifier, msContents, rubric;
>
> Why can't the witness instead link to an msDescription?
>
> > * re-introduce the "sigil" attribute as a new element
>
> If I'm understanding the French, the complaint is that the suggested use of
> xml:id is to constricting since people may wish to use existing sigla well-known
> in the community, but that simultaneously is too vague and generic but
> also won't allow some useful elements. Am I understanding that correctly? I
> still think I'd favour a linking mechanism from witness to msIdentifier if
> someone needs a more detailed identification. Maybe I'm misunderstanding the
> proposal though.
>
>
> > * add a "class" attribute to
>
> I was unable to get up the "Appendix A Liste des ?l?ments de la classe
> witnessPart", but if I'm understanding the prose description correctly, this
> attribute would be used to indicate a taxonomy used to classify that witness.
> Which again seems like something which should be off in msDescription
>
> I'm probably just mistranslating things though, so I look forward to Lou's
> translation which I know is in hand.
>
> -James
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 06:08:31 EST

From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 06:29:56 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 22 Mar 2007 11:29:56 +0000 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <460268B4.4040705@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 22 Mar 2007 11:29:56 +0000
Lou Burnard wrote:
> * re-introduce the "sigil" attribute as a new element
I'm still not sure I understand this...I must be missing something.
What is wrong with xml:id values of 'A1', 'a1', 'A2', 'b5' etc? If you then
want to indicate that the numerical portion is superscript, that seems like
additional information to be included in the (or ?) or
to which that witness relates (and I assume points). I've
always thought that msDescription could have a more general role than just
manuscripts. But I'm happy to receive correction from Gautier on the intention
behind this.

> * add a "class" attribute to
Ok, based on the translation, it seems to me that this class attribute sort of
does the same thing as @type on altIdentifier? I.e. this identifier refers to a
copy, this one to an original, this one to a fragment? (Or is my understanding
abusing altIdentifier/@type ?)
I think I would have an msDescription for each non-printed witness and have the
witList point in turn to each of these. Most additional material, I feel
shouldn't be in the at all, but the msDescription.
I guess I'm just still to be convinced, but I'm receptive to more explanation.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 06:29:59 EST

From arianna.ciula at kcl.ac.uk Thu Mar 22 12:44:38 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 22 Mar 2007 17:44:38 +0000 Subject: [tei-council] TEI meeting 2008 Message-ID: <4602C086.6000102@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 22 Mar 2007 17:44:38 +0000
Dear all,
is anybody aware of which is deadline to submit proposals to host the
next TEI meeting (2008)?
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 12:45:04 EST
From Syd_Bauman at Brown.edu Thu Mar 22 13:49:31 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 14:49:31 -0400 Subject: [tei-council] conformance draft Message-ID: <17922.53179.482722.150943@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 22 Mar 2007 14:49:31 -0400
I have finally gotten to reading James' draft
(http://www.tei-c.org/Council/conformance-draft.pdf). Thanks to James
for doing this work. Overall I think it looks quite good. However, I
have lots of nit-picks (some of which others may have noted already),
two procedural issues, and a few major points to raise. I am going to
skip the nit-picks for now, mostly because all of Council need not be
bothered.
I will post the procedural issues separately, as they are less
important, and may be uninteresting to many Council members.

So, on with my main issues with the draft conformance chapter.

One: ODD validate against which schema?
---- --- -------- ------- ----- -------
At several points the chapter refers to the need for a "valid TEI
ODD" file. This is well and good, but valid against what? I don't
think it will be particularly difficult to come up with a statement
against which schema such an ODD should be valid, but such a
statement is, I think, necessary. And it isn't trivial. E.g.,
Roma-the-web-app often produces ODD files that are invalid with
respect to the schema that I would expect them to be valid against.
(Currently the 0.6 version of P5/p5odds.rnc, available at
http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/p5odds.rnc.)

Two: Exemplars
---- ---------
I feel that too much weight is placed on the TEI Customization
Exemplars, although I don't have specific suggestions for improvement
at the moment. These exemplars are primarily intended to be examples
of how to perform specific kinds of customizations (e.g., including
SVG) or to be good starting points for customization, but are not
intended to generate schemas that are useful for encoding, and
indeed, they don't. Most obviously, they do not provide controlled
vocabularies for data.enumerated attributes.

Three: Schemas
------ -------
I think it is important to make it clearer that validation against a
schema is a necessary, but insufficient, condition of conformance --
that there are constraints required by the Guidelines that are not
schema-enforced. (E.g., that a hand= attribute point to a
element, not an inside a .)
Furthermore, I think it is important to explain that DTD validation
will not inform a user about as many constraints as will Relax NG
validation. (E.g., many attribute values have datatypes that provide
useful constraints in RelaxNG-land, but are just CDATA in DTD-land.)

Four: namespace of new elements
----- --------- -- --- --------
I am not at all sure it is a good idea that TEI require that new
elements be in a separate namespace. I think that doing so
* creates a higher barrier to actual use of the customization
mechanism
* makes instances harder to read by humans
* sends the wrong message politically -- that if you create a new
element, somehow you're not a member of the same TEI club
for an extremely limited technical gain. Rather than make this a
condition of conformance, I would like to see the definitions of the
various categories of TEI-Conformant schemas (& documents)
differentiate based on use of namespaces.
So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
create a new category "Extension Schema", which permits the addition
of new elements in the TEI namespace.

Again, thanks to James for doing the footwork, here.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 13:49:36 EST

From Syd_Bauman at Brown.edu Thu Mar 22 14:09:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 15:09:52 -0400 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <17922.54400.512473.511195@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 22 Mar 2007 15:09:52 -0400
> ... I have ... two procedural issues, [which] I will post ...
> separately,
Alright, only 1 is procedural, the other is really technical.

The formatting of the PDF is lovely, and it is very nice to read
something pretty for a change. But why only the PDF? While I agree
that it is too early to check this draft into the development trunk
on Sourceforge, it certainly could at least have been made available
as on ODD with the associated fscicule output (e.g. HTML & PDF), if
not checked into a separate branch.

But I'm also having a technical problem with Perforce. I don't know
exactly when, but some point between the files' check-in (03-15) and
today I synched my laptop and it dutifully downloaded the file. When
I issue `p4 sync` on my laptop I am told 'File(s) up-to-date.'. On my
desktop at work I issued `p4 sync` both yesterday and today. When I
issue `p4 sync` right now I am told 'File(s) up-to-date.'. But the
file //TEI/web/Council/conformance-draft.pdf does not exist on my
desktop! I am quite confident I did not erase it, and even if I had,
wouldn't Perforce replace it on a `sync`? Anyone have any idea as to
what might be going on?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 14:09:56 EST

From Syd_Bauman at Brown.edu Thu Mar 22 15:24:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 16:24:02 -0400 Subject: [tei-council] TEI meeting 2008 In-Reply-To: <4602C086.6000102@kcl.ac.uk> Message-ID: <17922.58850.549094.932187@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 22 Mar 2007 16:24:02 -0400
> is anybody aware of which is deadline to submit proposals to host
> the next TEI meeting (2008)?
I don't believe that the call for bids has gone out yet.
Proposals for time and place of each members meeting should be
solicited in the spring of the previous year (e.g. April 2005 for
the members' meeting of 2006) so that the venue can be announced
at the members' meeting a year in advance.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 15:24:05 EST
From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 22 15:32:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 22 Mar 2007 20:32:41 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <4602E7E9.8040701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 22 Mar 2007 20:32:41 +0000
Syd Bauman wrote:
> statement is, I think, necessary. And it isn't trivial. E.g.,
> Roma-the-web-app often produces ODD files that are invalid with
> respect to the schema that I would expect them to be valid against.
> (Currently the 0.6 version of P5/p5odds.rnc, available at
> http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/p5odds.rnc.)
>
if you get an ODD which is not valid, I need to know!
that would be a bug.
the Exemplar "tei_odds" is the expected target for
validation/
>
> Two: Exemplars
> ---- ---------
> I feel that too much weight is placed on the TEI Customization
> Exemplars,
i kind of agree that they come over too prominent.
> SVG) or to be good starting points for customization, but are not
> intended to generate schemas that are useful for encoding, and
> indeed, they don't. Most obviously, they do not provide controlled
> vocabularies for data.enumerated attributes.
>
bit like TEI P1, P2, P3, and P4, then....?
>
> Furthermore, I think it is important to explain that DTD validation
> will not inform a user about as many constraints as will Relax NG
> validation. (E.g., many attribute values have datatypes that provide
> useful constraints in RelaxNG-land, but are just CDATA in DTD-land.)
>
thats very true; wording this will not be easy, I think.
>
> Four: namespace of new elements
> ----- --------- -- --- --------
> I am not at all sure it is a good idea that TEI require that new
> elements be in a separate namespace.
I tend to agree, though I quite see the argument of James.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 15:32:46 EST
From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 22 15:36:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 22 Mar 2007 20:36:29 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.54400.512473.511195@emt.wwp.brown.edu> Message-ID: <4602E8CD.8040103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 22 Mar 2007 20:36:29 +0000
Syd Bauman wrote:
>
>
> The formatting of the PDF is lovely, and it is very nice to read
> something pretty for a change. But why only the PDF? While I agree
> that it is too early to check this draft into the development trunk
> on Sourceforge, it certainly could at least have been made available
> as on ODD with the associated fscicule output (e.g. HTML & PDF), if
> not checked into a separate branch.
>
my bad, partly. "make fascicule" was broken when James
did it, then he got sick, so I lashed up the PDF while
he lay a-weepin'.
might as well check it straight into the trunk, no? after all,
Subversion will remember the previous versions OK.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 15:36:42 EST

From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 19:31:07 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 00:31:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <46031FCB.90304@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 00:31:07 +0000
Syd Bauman wrote:
> I am going to
> skip the nit-picks for now, mostly because all of Council need not be
> bothered.
Do feel free to pass on the nit-picks privately. That which doesn't kill us...
> One: ODD validate against which schema?
> ---- --- -------- ------- ----- -------
> At several points the chapter refers to the need for a "valid TEI
> ODD" file. This is well and good, but valid against what?
Make sense, agreed that this should be more specific.
> Two: Exemplars
> ---- ---------
> I feel that too much weight is placed on the TEI Customization
> Exemplars, although I don't have specific suggestions for improvement
> at the moment.
My suggestion is that the discussion here should lessened, but that they be
discussed in more depth in the chapter on customisation/modification.
>
> Three: Schemas
> ------ -------
> I think it is important to make it clearer that validation against a
> schema is a necessary, but insufficient, condition of conformance --
> that there are constraints required by the Guidelines that are not
> schema-enforced. (E.g., that a hand= attribute point to a
> element, not an inside a .)
Yes, that should be stated more clearly.

> Furthermore, I think it is important to explain that DTD validation
> will not inform a user about as many constraints as will Relax NG
> validation.
While DTD validation may not provide as many constraints, if the document
instance validates against a DTD generated from a TEI ODD is the document
instance somehow less conformant than if it is validated against a Relax NG
schema generated from the same ODD? Either DTDs are acceptable to validate TEI
Conformant documents against or they are not. I admit that I have a little
niggle worrying in the back of my head about someone creating an ODD for a
schema which would be considered in one of those categories of TEI Conformance,
but that the lack of constraints in DTD means that document instances which
validate against the DTD are non-conformant because they don't include certain
constraints in the Relax NG version generated from the same ODD. (Can someone
invent an occasion where this might happen that simultaneously breaks
conformance?) Maybe we should think about that more.
>
> Four: namespace of new elements
> ----- --------- -- --- --------
> I am not at all sure it is a good idea that TEI require that new
> elements be in a separate namespace. I think that doing so
> * creates a higher barrier to actual use of the customization
> mechanism
> * makes instances harder to read by humans
> * sends the wrong message politically -- that if you create a new
> element, somehow you're not a member of the same TEI club
> for an extremely limited technical gain.
I think I'm still going to try and take the moral high ground...I recognise that
it creates a barrier to use of the customisation mechanism. I'm not entirely
convinced that it truly impairs human readability. Having a few namespace
prefixes might actually clarify things more. I'm entirely used to xml:id now as
an attribute. I don't think it sends the wrong message politically either...or
at least you can view that in two ways. When you create a new element you get
the privilege of putting it in your own project's namespace, and the comforting
knowledge that the TEI namespace is kept pure. When you use other TEI documents
you know the elements and their semantics because they are in the TEI namespace.
I will admit that I am torn...I understand how much of a pain it is to do
things in multiple namespaces even just in writing XSLT stylesheets, never mind
full-blown applications. As an elected member of the council I feel I'm here to
support the interests of the members. However, I'm torn between doing what I
feel is right and doing what is easier. Would the membership want me to make
life easy on them, or really make use of namespaces in the way I feel we should?
The only real objection anyone has made so far concerning the
use-your-own-namespace-for-new-elements idea is that it is difficult. Does
anyone have any other arguments against this idea?
While I unquestioningly accept that the use of namespaces in this way means that
it will be more difficult to use the customisation mechanism, it might not pose
an insurmountable difficulty or dissuade people from customisation as much as we
might expect. Partly that depends on front-end applications like webRoma. If
when I add a new element it is also prompting me for the namespace (perhaps with
a previously-used suggestion) or something, then the barrier to use is lessened.
Couple that with some XSLT examples handling multiple namespaces and a lot of
the fear is reduced.
> Rather than make this a
> condition of conformance, I would like to see the definitions of the
> various categories of TEI-Conformant schemas (& documents)
> differentiate based on use of namespaces.
>
> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
> create a new category "Extension Schema", which permits the addition
> of new elements in the TEI namespace.
This is certainly a possibility. Would the lack of namespace only occur in this
category of schema? And even if the current conformance draft was the final
chapter, this is something I think many people would probably do. If we persist
with this use of namespaces I think there will be an increase in local encoding
formats with transformations to multi-namespaced TEI Conformant documents only
for interchange/deposit-with-archives/pleasing-the-funders, and such. But if
using multiple namespaces is still the 'right' thing to do...then should this
dissuade us?
No one has said anything about the section 1.7 'TEI Conformance and Funding
Bodies', since the claim of TEI Conformance is something that is often added to
funding applications (since I read scores of them for the AHRC) in hopes of
people saying "look how good we are, please, please fund us", I thought that we
should say something about Conformance in no way indicating quality. However, I
wasn't quite sure how far we should go along that road or other appropriate
messages, etc.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 22 2007 - 19:31:11 EST

From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:09:17 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:09:17 +1200 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID:
From: Conal Tuohy
Date: Fri, 23 Mar 2007 14:09:17 +1200
Syd Bauman wrote:
> Four: namespace of new elements
> ----- --------- -- --- --------
> I am not at all sure it is a good idea that TEI require that new
> elements be in a separate namespace. I think that doing so
> * creates a higher barrier to actual use of the customization
> mechanism
> * makes instances harder to read by humans
> * sends the wrong message politically -- that if you create a new
> element, somehow you're not a member of the same TEI club
> for an extremely limited technical gain.
I tend to disagree with all these points, actually, but for the moment I
will just make the strongest claim I can:
It is bad practice for the TEI Council to licence others to define new
names within the TEI namespace, under ANY circumstances.
Why do I think it's a bad idea to licence others to pollute the TEI
namespace?
Well, why do TEI elements use a namespace at all? The point of
namespaces is to "avoid clashes between names from different markup
vocabularies" ... "by assigning 'expanded names' to elements and
attributes".[1]
These "clashes" or "collisions" could otherwise occur in documents which
contain markup from multiple XML vocabularies, since the same name might
be defined in multiple vocabularies (e.g. "p" in TEI and HTML, "seg" in
TEI and DocBook).
Let me first describe how namespaces work to avoid such collisions:
To distinguish similar names from distinct vocabularies, names are each
associated with a URI which identifies the vocabulary from which it is
drawn. e.g. TEI elements are associated with the TEI namespace URI
http://www.tei-c.org/ns/1.0 which is the name of the TEI vocabulary -
the "namespace URI" or "namespace name".
Because URIs can be quite long, the XML namespaces specification
provided a way to use short prefixes in place of those URIs, and also
provided a way to specify a "default" namespace URI which can apply to
an entire document or a section of a document. Using a namespace prefix
or a "default" namespace is just shorthand syntax, though; the real
("expanded") name of a tei:p element is actually a pair of values: the
TEI namespace URI, and the "local" name "p":
{"http://www.tei-c.org/ns/1.0", "p"}
Whereas an html:p has an "expanded name" with a different namespace URI
and the same "local" name:
{"http://www.w3.org/1999/xhtml/", "p"}.
Now, the reason that URIs were used to identify vocabularies was that
URIs are a globally distributed naming scheme in which anyone can easily
define a URI which is unique, and use that URI as the name of their
vocabulary. If vocabulary names were not unique, then we would still
have the problem of name collision, since e.g. we might call our
vocabulary "TEI", and the Tax Executives Institute might also define a
vocabulary with the same name.
There can be no dispute as to who is responsible for the TEI namespace
URI "http://www.tei-c.org/ns/1.0" - it's owned by the TEI Consortium,
and it is up to us, the Council, to declare that it is the name of the
TEI vocabulary, and not the name of some OTHER vocabulary. If we say to
TEI encoders that they may use the "http://www.tei-c.org/ns/1.0" name to
identify OTHER vocabularies, then we have effectively negated the
purpose of using a namespace, because some "extension" vocabularies will
contain names which collide with names in other "extension"
vocabularies.
Now, do we want to avoid name collisions or don't we? If we don't care
about name collisions, what is the TEI namespace for? Why have we added
it?
I don't see that using multiple namespaces in text encoding is really a
serious barrier, but if other people think it is, then we need to find
ways to help people use multiple namespaces, rather than pollute the TEI
namespace. In the meantime, if using multiple namespaces is too great a
barrier for some people, then they can use P4. P5 is namespaced, and
customisers should get used to it.
Cheers
Con

1. "Namespaces in XML 1.0 (Second Edition)"
http://www.w3.org/TR/REC-xml-names/#sec-intro
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 21:09:39 EST

From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:39:58 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:39:58 +1200 Subject: [tei-council] conformance draft In-Reply-To: <46031FCB.90304@computing-services.oxford.ac.uk> Message-ID:
From: Conal Tuohy
Date: Fri, 23 Mar 2007 14:39:58 +1200
James Cummings wrote:
> I recognise that
> it creates a barrier to use of the customisation mechanism.
That's perhaps true, in the first instance.
However, it can also make customisation much easier.
If a customisation has been made using a namespace then it will be
easier to combine with other customisations.
I envisage a situation where encoders may pick a set of 2 or 3 existing
customisations want to combine them together. Perhaps an
"image-annotation" customisation might be mixed with a "CIDOC-ontology"
customisation, an "AppInfo" customisation, or whatever. If these
customisations used namespaces, then they could be combined more or less
just by sticking them together.
Whereas if they did not use namespaces, they might produce name
collisions, and it would be necessary to resolve the conflicts, and
define a new customisation independently.
In summary, the non-use of namespaces tends to make customisations
non-reusable, and makes document interchange harder.
> I'm not entirely
> convinced that it truly impairs human readability. Having a
> few namespace
> prefixes might actually clarify things more. I'm entirely
> used to xml:id now as
> an attribute.
I agree. It may be seen as added clutter, but it may also be seen as a
useful visual hint: if an encoding project has defined a new attribute,
it's because they have some special requirement. Having a namespace
prefix may help to draw their attention to the attribute, making it
easier to find when reading the TEI. This is certainly my own
experience.
In any case, if namespace prefixes are seen as a barrier, then a
customisation can rename ALL the TEI elements into a new namespace, and
then add new elements to that namespace. Instance documents could then
use a default namespace to qualify names, so there'd be no need for
namespace prefixes. e.g.



...





...

i.e. a "renaming extension" schema.
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 21:40:19 EST
From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:55:14 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:55:14 +1200 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID:
From: Conal Tuohy
Date: Fri, 23 Mar 2007 14:55:14 +1200
Syd Bauman wrote:
> I am not at all sure it is a good idea that TEI require that new
> elements be in a separate namespace. I think that doing so
> * sends the wrong message politically -- that if you create a new
> element, somehow you're not a member of the same TEI club
I am not sure I understand the "politics" there.
Will people be discouraged from using TEI if we ask them not to add new
names in the TEI namespace? Is that what you're implying? Will they
think we are arrogant to delimit the official TEI vocabulary?
Perhaps requiring a separate namespace for additions will actually
encourage customisers to harmonise and unify their customisations with
other similar customisations, so that the customisation may eventually
be accepted into the TEI and moved into the TEI namespace. To my mind
that would be a very good political message to send.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 22 2007 - 21:55:31 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 04:25:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 09:25:40 +0000 Subject: [tei-council] conformance issues Message-ID: <46039D14.3050805@oucs.ox.ac.uk>
From: Lou Burnard
Date: Fri, 23 Mar 2007 09:25:40 +0000
"If we say to
TEI encoders that they may use the "http://www.tei-c.org/ns/1.0" name to
identify OTHER vocabularies, then we have effectively negated the
purpose of using a namespace, because some "extension" vocabularies will
contain names which collide with names in other "extension"
vocabularies."
This is a knock-down argument as far as I am concerned. I agree with
Conal 100%.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 23 2007 - 04:26:46 EST
From dporter at uky.edu Fri Mar 23 04:57:48 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 01:57:48 -0800 Subject: [tei-council] conformance draft In-Reply-To: Message-ID: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com>
From: Dot Porter
Date: Fri, 23 Mar 2007 01:57:48 -0800
Conal, you've made a great deal of sense in all your comments. Thanks
for taking the time to argue your points so clearly.
On 3/22/07, Conal Tuohy ac.nz> wrote:
> James Cummings wrote:
>
> > I recognise that
> > it creates a barrier to use of the customisation mechanism.
>
> That's perhaps true, in the first instance.
>
Everyone, after the call earlier this week I volunteered privately to
James to take an existing customization that I've been working on and
have it "namespaced" by the council meeting, just to see how much of a
barrier this actually is to people (like me) with middle-of-the-road
tech skills. This particular customization is designed to be plugged
into a METS file, so there is another layer to contend with there as
well.
Dot

> However, it can also make customisation much easier.
>
> If a customisation has been made using a namespace then it will be
> easier to combine with other customisations.
>
> I envisage a situation where encoders may pick a set of 2 or 3 existing
> customisations want to combine them together. Perhaps an
> "image-annotation" customisation might be mixed with a "CIDOC-ontology"
> customisation, an "AppInfo" customisation, or whatever. If these
> customisations used namespaces, then they could be combined more or less
> just by sticking them together.
>
> Whereas if they did not use namespaces, they might produce name
> collisions, and it would be necessary to resolve the conflicts, and
> define a new customisation independently.
>
> In summary, the non-use of namespaces tends to make customisations
> non-reusable, and makes document interchange harder.
>
> > I'm not entirely
> > convinced that it truly impairs human readability. Having a
> > few namespace
> > prefixes might actually clarify things more. I'm entirely
> > used to xml:id now as
> > an attribute.
>
> I agree. It may be seen as added clutter, but it may also be seen as a
> useful visual hint: if an encoding project has defined a new attribute,
> it's because they have some special requirement. Having a namespace
> prefix may help to draw their attention to the attribute, making it
> easier to find when reading the TEI. This is certainly my own
> experience.
>
> In any case, if namespace prefixes are seen as a barrier, then a
> customisation can rename ALL the TEI elements into a new namespace, and
> then add new elements to that namespace. Instance documents could then
> use a default namespace to qualify names, so there'd be no need for
> namespace prefixes. e.g.
>
>
>
>
> ...
>
>
>
>
>
> ...
>
>
> i.e. a "renaming extension" schema.
>
> Cheers
>
> Con
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 04:57:52 EST

From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:09:17 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:09:17 +0000 Subject: [tei-council] conformance draft In-Reply-To: Message-ID: <4603A74D.9000602@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 10:09:17 +0000
Conal Tuohy wrote:
> It is bad practice for the TEI Council to licence others to define new
> names within the TEI namespace, under ANY circumstances.
Agreed. In principle this is bad practice.
> Now, do we want to avoid name collisions or don't we? If we don't care
> about name collisions, what is the TEI namespace for? Why have we added
> it?
See, that is what I *should* have said! Thanks Conal!
> I don't see that using multiple namespaces in text encoding is really a
> serious barrier, but if other people think it is, then we need to find
> ways to help people use multiple namespaces, rather than pollute the TEI
> namespace. In the meantime, if using multiple namespaces is too great a
> barrier for some people, then they can use P4. P5 is namespaced, and
> customisers should get used to it.
I do feel it is a bit of a barrier, but that this is a barrier which should be
negated through application interface (Roma), numerous examples, and education.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 05:09:23 EST
From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:13:07 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:13:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: Message-ID: <4603A833.2000401@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 10:13:07 +0000
Conal Tuohy wrote:
> James Cummings wrote:
>> I recognise that
>> it creates a barrier to use of the customisation mechanism.
> That's perhaps true, in the first instance.
> However, it can also make customisation much easier.
I take that point, it will make merging micro-extensions easier. Though, that
said, I still imagine having to deal with 20 namespaces all in one document
would be a 'barrier'. (A not insurmountable one... but still a barrier.)
> In summary, the non-use of namespaces tends to make customisations
> non-reusable, and makes document interchange harder.
Good point.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 05:13:10 EST
From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:15:38 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:15:38 +0000 Subject: [tei-council] conformance draft In-Reply-To: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> Message-ID: <4603A8CA.9050100@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 10:15:38 +0000
Dot Porter wrote:
> Everyone, after the call earlier this week I volunteered privately to
> James to take an existing customization that I've been working on and
> have it "namespaced" by the council meeting, just to see how much of a
> barrier this actually is to people (like me) with middle-of-the-road
> tech skills. This particular customization is designed to be plugged
> into a METS file, so there is another layer to contend with there as
> well.
And while this will be useful, and just plain good for Dot (like any medicine),
we should remember that what we hopefully will add is interfaces in Roma, lots
of examples, documentation, and training. So that while Dot has little support
in this now, those who come after her will not be so bad off in comparison.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 05:15:41 EST
From dporter at uky.edu Fri Mar 23 05:51:37 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 02:51:37 -0800 Subject: [tei-council] conformance draft In-Reply-To: <4603A8CA.9050100@computing-services.oxford.ac.uk> Message-ID: <96f3df640703230351g2df7d7b0k7027be751989670@mail.gmail.com>
From: Dot Porter
Date: Fri, 23 Mar 2007 02:51:37 -0800
> And while this will be useful, and just plain good for Dot (like any medicine),
Okay, I admit, this is just an excuse for me to try something new!
On 3/23/07, James Cummings
oxford.ac.uk> wrote:
> Dot Porter wrote:
>
> > Everyone, after the call earlier this week I volunteered privately to
> > James to take an existing customization that I've been working on and
> > have it "namespaced" by the council meeting, just to see how much of a
> > barrier this actually is to people (like me) with middle-of-the-road
> > tech skills. This particular customization is designed to be plugged
> > into a METS file, so there is another layer to contend with there as
> > well.
>
> we should remember that what we hopefully will add is interfaces in Roma, lots
> of examples, documentation, and training. So that while Dot has little support
> in this now, those who come after her will not be so bad off in comparison.
>
> -James
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 05:51:41 EST

From arianna.ciula at kcl.ac.uk Fri Mar 23 06:18:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 11:18:58 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD6538.1060002@computing-services.oxford.ac.uk> Message-ID: <4603B7A2.4050604@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 23 Mar 2007 11:18:58 +0000
The resource at http://www.tei-c.org/Drafts/ndextra.html is not
available any more and the proposal made accessible for the TEI list at
http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new
examples for Places but just the Nym section.
Any idea where I can find the former examples that have disappeared?
Arianna
Lou Burnard wrote:
> Christian Wittern wrote:
>> Matthew James Driscoll wrote:
>>>
>>>
>>
>> does that mean you also proposa a listNym for TEI?
>>
>>
>
> Yes. Matthew's report doesn't mention that there is a draft ODD,
> probably because I have not yet got round to putting it anywhere where
> Council members can see it easily. But if you look in the P5/Test
> directory on sourceforge, you will see a file called testndextra.odd,
> which contains the current state of the draft.
>
> I've just put a copy of the HTML generated from this by Roma on the
> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep
> this up to date as the draft progresses
>
>
>>> Our principal task at this meeting was to develop mechanisms for
>>> encoding
>>> place-names, analogous to those which were developed for personal
>>> names at
>>> the meeting in Oxford last year, which would allow for the recording of
>>> abstracted information about a place, such as map coordinate, GIS
>>> information etc., as well as variant forms of the name, in different
>>> languages (e.g. Praha, Prague, Praga) and/or different forms over
>>> time (e.g.
>>> Lundunum, London). On the analogy with , we propose a
>>> element, which will usually contain at least one, and possibly several,
>>> elements, followed by one or more elements to
>>> provide
>>> geographical and/or geo-political information about the location of the
>>> place.
>>
>> Why would you need more than one ? I had the impression
>> that the place is what stays constant? Is it because it also stands in
>> for the geopolitical information?
>
> Because a place might be located in more than one way (e.g. by its
> geopolitical status, or by its co-ordinates), and may also move its
> location over time.
>> However, if we talk about administrative geography here, you will also
>> have to account for changes in the size and super/sub components of a
>> place and a way to link this to coordinates defining the polygon.
>> Would the tagset be up to this task?
>
> probably... because we embed GML!
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 06:19:34 EST
From arianna.ciula at kcl.ac.uk Fri Mar 23 06:25:19 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 11:25:19 +0000 Subject: [tei-council] conformance draft In-Reply-To: <46031FCB.90304@computing-services.oxford.ac.uk> Message-ID: <4603B91F.5070903@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 23 Mar 2007 11:25:19 +0000
> While I unquestioningly accept that the use of namespaces in this way
> means that it will be more difficult to use the customisation mechanism,
> it might not pose an insurmountable difficulty or dissuade people from
> customisation as much as we might expect. Partly that depends on
> front-end applications like webRoma. If when I add a new element it is
> also prompting me for the namespace (perhaps with a previously-used
> suggestion) or something, then the barrier to use is lessened. Couple
> that with some XSLT examples handling multiple namespaces and a lot of
> the fear is reduced.
Totally agree with James on this and with Conan on the rest.
Arianna
James Cummings wrote:
> Syd Bauman wrote:
>> I am going to
>> skip the nit-picks for now, mostly because all of Council need not be
>> bothered.
>
> Do feel free to pass on the nit-picks privately. That which doesn't
> kill us...
>
>> One: ODD validate against which schema?
>> ---- --- -------- ------- ----- -------
>> At several points the chapter refers to the need for a "valid TEI
>> ODD" file. This is well and good, but valid against what?
>
> Make sense, agreed that this should be more specific.
>
>> Two: Exemplars
>> ---- ---------
>> I feel that too much weight is placed on the TEI Customization
>> Exemplars, although I don't have specific suggestions for improvement
>> at the moment.
>
> My suggestion is that the discussion here should lessened, but that they
> be discussed in more depth in the chapter on customisation/modification.
>
>>
>> Three: Schemas
>> ------ -------
>> I think it is important to make it clearer that validation against a
>> schema is a necessary, but insufficient, condition of conformance --
>> that there are constraints required by the Guidelines that are not
>> schema-enforced. (E.g., that a hand= attribute point to a
>> element, not an inside a .)
>
> Yes, that should be stated more clearly.
>
>
>> Furthermore, I think it is important to explain that DTD validation
>> will not inform a user about as many constraints as will Relax NG
>> validation.
>
> While DTD validation may not provide as many constraints, if the
> document instance validates against a DTD generated from a TEI ODD is
> the document instance somehow less conformant than if it is validated
> against a Relax NG schema generated from the same ODD? Either DTDs are
> acceptable to validate TEI Conformant documents against or they are
> not. I admit that I have a little niggle worrying in the back of my
> head about someone creating an ODD for a schema which would be
> considered in one of those categories of TEI Conformance, but that the
> lack of constraints in DTD means that document instances which validate
> against the DTD are non-conformant because they don't include certain
> constraints in the Relax NG version generated from the same ODD. (Can
> someone invent an occasion where this might happen that simultaneously
> breaks conformance?) Maybe we should think about that more.
>
>>
>> Four: namespace of new elements
>> ----- --------- -- --- --------
>> I am not at all sure it is a good idea that TEI require that new
>> elements be in a separate namespace. I think that doing so
>> * creates a higher barrier to actual use of the customization
>> mechanism
>> * makes instances harder to read by humans
>> * sends the wrong message politically -- that if you create a new
>> element, somehow you're not a member of the same TEI club
>> for an extremely limited technical gain.
>
> I think I'm still going to try and take the moral high ground...I
> recognise that it creates a barrier to use of the customisation
> mechanism. I'm not entirely convinced that it truly impairs human
> readability. Having a few namespace prefixes might actually clarify
> things more. I'm entirely used to xml:id now as an attribute. I don't
> think it sends the wrong message politically either...or at least you
> can view that in two ways. When you create a new element you get the
> privilege of putting it in your own project's namespace, and the
> comforting knowledge that the TEI namespace is kept pure. When you use
> other TEI documents you know the elements and their semantics because
> they are in the TEI namespace. I will admit that I am torn...I
> understand how much of a pain it is to do things in multiple namespaces
> even just in writing XSLT stylesheets, never mind full-blown
> applications. As an elected member of the council I feel I'm here to
> support the interests of the members. However, I'm torn between doing
> what I feel is right and doing what is easier. Would the membership
> want me to make life easy on them, or really make use of namespaces in
> the way I feel we should?
>
> The only real objection anyone has made so far concerning the
> use-your-own-namespace-for-new-elements idea is that it is difficult.
> Does anyone have any other arguments against this idea?
>
> While I unquestioningly accept that the use of namespaces in this way
> means that it will be more difficult to use the customisation mechanism,
> it might not pose an insurmountable difficulty or dissuade people from
> customisation as much as we might expect. Partly that depends on
> front-end applications like webRoma. If when I add a new element it is
> also prompting me for the namespace (perhaps with a previously-used
> suggestion) or something, then the barrier to use is lessened. Couple
> that with some XSLT examples handling multiple namespaces and a lot of
> the fear is reduced.
>
>> Rather than make this a
>> condition of conformance, I would like to see the definitions of the
>> various categories of TEI-Conformant schemas (& documents)
>> differentiate based on use of namespaces.
>>
>> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
>> create a new category "Extension Schema", which permits the addition
>> of new elements in the TEI namespace.
>
> This is certainly a possibility. Would the lack of namespace only occur
> in this category of schema? And even if the current conformance draft
> was the final chapter, this is something I think many people would
> probably do. If we persist with this use of namespaces I think there
> will be an increase in local encoding formats with transformations to
> multi-namespaced TEI Conformant documents only for
> interchange/deposit-with-archives/pleasing-the-funders, and such. But
> if using multiple namespaces is still the 'right' thing to do...then
> should this dissuade us?
>
> No one has said anything about the section 1.7 'TEI Conformance and
> Funding Bodies', since the claim of TEI Conformance is something that is
> often added to funding applications (since I read scores of them for the
> AHRC) in hopes of people saying "look how good we are, please, please
> fund us", I thought that we should say something about Conformance in no
> way indicating quality. However, I wasn't quite sure how far we should
> go along that road or other appropriate messages, etc.
>
> -James
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 06:26:00 EST
From dporter at uky.edu Fri Mar 23 06:29:52 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 03:29:52 -0800 Subject: [tei-council] conformance draft In-Reply-To: <4603B91F.5070903@kcl.ac.uk> Message-ID: <96f3df640703230429j3ba5e377rf3befa7bef3580f4@mail.gmail.com>
From: Dot Porter
Date: Fri, 23 Mar 2007 03:29:52 -0800
On 3/23/07, Arianna Ciula ac.uk> wrote:
> Totally agree with James on this and with Conan on the rest.
>
TEI barbarians!
> Arianna
>
> James Cummings wrote:
> > Syd Bauman wrote:
> >> I am going to
> >> skip the nit-picks for now, mostly because all of Council need not be
> >> bothered.
> >
> > Do feel free to pass on the nit-picks privately. That which doesn't
> > kill us...
> >
> >> One: ODD validate against which schema?
> >> ---- --- -------- ------- ----- -------
> >> At several points the chapter refers to the need for a "valid TEI
> >> ODD" file. This is well and good, but valid against what?
> >
> > Make sense, agreed that this should be more specific.
> >
> >> Two: Exemplars
> >> ---- ---------
> >> I feel that too much weight is placed on the TEI Customization
> >> Exemplars, although I don't have specific suggestions for improvement
> >> at the moment.
> >
> > My suggestion is that the discussion here should lessened, but that they
> > be discussed in more depth in the chapter on customisation/modification.
> >
> >>
> >> Three: Schemas
> >> ------ -------
> >> I think it is important to make it clearer that validation against a
> >> schema is a necessary, but insufficient, condition of conformance --
> >> that there are constraints required by the Guidelines that are not
> >> schema-enforced. (E.g., that a hand= attribute point to a
> >> element, not an inside a .)
> >
> > Yes, that should be stated more clearly.
> >
> >
> >> Furthermore, I think it is important to explain that DTD validation
> >> will not inform a user about as many constraints as will Relax NG
> >> validation.
> >
> > While DTD validation may not provide as many constraints, if the
> > document instance validates against a DTD generated from a TEI ODD is
> > the document instance somehow less conformant than if it is validated
> > against a Relax NG schema generated from the same ODD? Either DTDs are
> > acceptable to validate TEI Conformant documents against or they are
> > not. I admit that I have a little niggle worrying in the back of my
> > head about someone creating an ODD for a schema which would be
> > considered in one of those categories of TEI Conformance, but that the
> > lack of constraints in DTD means that document instances which validate
> > against the DTD are non-conformant because they don't include certain
> > constraints in the Relax NG version generated from the same ODD. (Can
> > someone invent an occasion where this might happen that simultaneously
> > breaks conformance?) Maybe we should think about that more.
> >
> >>
> >> Four: namespace of new elements
> >> ----- --------- -- --- --------
> >> I am not at all sure it is a good idea that TEI require that new
> >> elements be in a separate namespace. I think that doing so
> >> * creates a higher barrier to actual use of the customization
> >> mechanism
> >> * makes instances harder to read by humans
> >> * sends the wrong message politically -- that if you create a new
> >> element, somehow you're not a member of the same TEI club
> >> for an extremely limited technical gain.
> >
> > I think I'm still going to try and take the moral high ground...I
> > recognise that it creates a barrier to use of the customisation
> > mechanism. I'm not entirely convinced that it truly impairs human
> > readability. Having a few namespace prefixes might actually clarify
> > things more. I'm entirely used to xml:id now as an attribute. I don't
> > think it sends the wrong message politically either...or at least you
> > can view that in two ways. When you create a new element you get the
> > privilege of putting it in your own project's namespace, and the
> > comforting knowledge that the TEI namespace is kept pure. When you use
> > other TEI documents you know the elements and their semantics because
> > they are in the TEI namespace. I will admit that I am torn...I
> > understand how much of a pain it is to do things in multiple namespaces
> > even just in writing XSLT stylesheets, never mind full-blown
> > applications. As an elected member of the council I feel I'm here to
> > support the interests of the members. However, I'm torn between doing
> > what I feel is right and doing what is easier. Would the membership
> > want me to make life easy on them, or really make use of namespaces in
> > the way I feel we should?
> >
> > The only real objection anyone has made so far concerning the
> > use-your-own-namespace-for-new-elements idea is that it is difficult.
> > Does anyone have any other arguments against this idea?
> >
> > While I unquestioningly accept that the use of namespaces in this way
> > means that it will be more difficult to use the customisation mechanism,
> > it might not pose an insurmountable difficulty or dissuade people from
> > customisation as much as we might expect. Partly that depends on
> > front-end applications like webRoma. If when I add a new element it is
> > also prompting me for the namespace (perhaps with a previously-used
> > suggestion) or something, then the barrier to use is lessened. Couple
> > that with some XSLT examples handling multiple namespaces and a lot of
> > the fear is reduced.
> >
> >> Rather than make this a
> >> condition of conformance, I would like to see the definitions of the
> >> various categories of TEI-Conformant schemas (& documents)
> >> differentiate based on use of namespaces.
> >>
> >> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
> >> create a new category "Extension Schema", which permits the addition
> >> of new elements in the TEI namespace.
> >
> > This is certainly a possibility. Would the lack of namespace only occur
> > in this category of schema? And even if the current conformance draft
> > was the final chapter, this is something I think many people would
> > probably do. If we persist with this use of namespaces I think there
> > will be an increase in local encoding formats with transformations to
> > multi-namespaced TEI Conformant documents only for
> > interchange/deposit-with-archives/pleasing-the-funders, and such. But
> > if using multiple namespaces is still the 'right' thing to do...then
> > should this dissuade us?
> >
> > No one has said anything about the section 1.7 'TEI Conformance and
> > Funding Bodies', since the claim of TEI Conformance is something that is
> > often added to funding applications (since I read scores of them for the
> > AHRC) in hopes of people saying "look how good we are, please, please
> > fund us", I thought that we should say something about Conformance in no
> > way indicating quality. However, I wasn't quite sure how far we should
> > go along that road or other appropriate messages, etc.
> >
> > -James
> >
>
> --
> Dr Arianna Ciula
> Research Associate
> Centre for Computing in the Humanities
> King's College London
> Strand
> London WC2R 2LS (UK)
> Tel: +44 (0)20 78481945
> http://www.kcl.ac.uk/cch
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 06:29:55 EST

From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 07:41:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 12:41:49 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <4603B7A2.4050604@kcl.ac.uk> Message-ID: <4603CB0D.8070900@oucs.ox.ac.uk>
From: Lou Burnard
Date: Fri, 23 Mar 2007 12:41:49 +0000
Apologies -- I am still hoping to get the material on places back online
by the weekend -- it got pushed off by other committments. The ndextra
document is still accessible at www.tei-c.org/oldDrafts/ndextra.html
(along with all the other old junk that used to be in Drafts) if you're
desperate...

Arianna Ciula wrote:
> The resource at http://www.tei-c.org/Drafts/ndextra.html is not
> available any more and the proposal made accessible for the TEI list at
> http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new
> examples for Places but just the Nym section.
>
> Any idea where I can find the former examples that have disappeared?
>
> Arianna
>
> Lou Burnard wrote:
>> Christian Wittern wrote:
>>> Matthew James Driscoll wrote:
>>>>
>>>>
>>>
>>> does that mean you also proposa a listNym for TEI?
>>>
>>>
>>
>> Yes. Matthew's report doesn't mention that there is a draft ODD,
>> probably because I have not yet got round to putting it anywhere where
>> Council members can see it easily. But if you look in the P5/Test
>> directory on sourceforge, you will see a file called testndextra.odd,
>> which contains the current state of the draft.
>>
>> I've just put a copy of the HTML generated from this by Roma on the
>> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to
>> keep this up to date as the draft progresses
>>
>>
>>>> Our principal task at this meeting was to develop mechanisms for
>>>> encoding
>>>> place-names, analogous to those which were developed for personal
>>>> names at
>>>> the meeting in Oxford last year, which would allow for the recording of
>>>> abstracted information about a place, such as map coordinate, GIS
>>>> information etc., as well as variant forms of the name, in different
>>>> languages (e.g. Praha, Prague, Praga) and/or different forms over
>>>> time (e.g.
>>>> Lundunum, London). On the analogy with , we propose a
>>>> element, which will usually contain at least one, and possibly several,
>>>> elements, followed by one or more elements to
>>>> provide
>>>> geographical and/or geo-political information about the location of the
>>>> place.
>>>
>>> Why would you need more than one ? I had the impression
>>> that the place is what stays constant? Is it because it also stands
>>> in for the geopolitical information?
>>
>> Because a place might be located in more than one way (e.g. by its
>> geopolitical status, or by its co-ordinates), and may also move its
>> location over time.
>>> However, if we talk about administrative geography here, you will
>>> also have to account for changes in the size and super/sub components
>>> of a place and a way to link this to coordinates defining the
>>> polygon. Would the tagset be up to this task?
>>
>> probably... because we embed GML!
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 23 2007 - 07:42:56 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 09:42:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 14:42:26 +0000 Subject: [tei-council] conformance draft In-Reply-To: Message-ID: <4603E752.5010806@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 23 Mar 2007 14:42:26 +0000
I have to confess, the cogent arguments from
the far side of the world are convincing me.
Namespaced extensions it is.
I would propose that Roma suggests a namespace
for each element you add - based on the name
of the customization? if not, i need somewhere
else to store it in the odd.
Given that this is the most contentious
part of James' draft (in my mind) is this section,

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 09:42:35 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 09:59:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 14:59:50 +0000 Subject: [tei-council] conformance draft In-Reply-To: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> Message-ID: <4603EB66.5010706@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 23 Mar 2007 14:59:50 +0000
Dot Porter wrote:
>
> James to take an existing customization that I've been working on and
> have it "namespaced" by the council meeting, just to see how much of a
> barrier this actually is to people (like me) with middle-of-the-road
> tech skills. This particular customization is designed to be plugged
> into a METS file, so there is another layer to contend with there as
> well.
it should be said that the true integration with METS
is a far far bigger challenge than
a few added elements in or out of namespaces.
And it is not something lots of separate people
should or will undertake. IMHO.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 10:00:03 EST
From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 10:06:31 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 15:06:31 +0000 Subject: [tei-council] conformance draft In-Reply-To: <4603E752.5010806@oucs.ox.ac.uk> Message-ID: <4603ECF7.5060608@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 15:06:31 +0000
Sebastian Rahtz wrote:
> I have to confess, the cogent arguments from
> the far side of the world are convincing me.
> Namespaced extensions it is.
>
> I would propose that Roma suggests a namespace
> for each element you add - based on the name
> of the customization? if not, i need somewhere
> else to store it in the odd.
>
> Given that this is the most contentious
> part of James' draft (in my mind) is this section,
Am I alone in thinking that Sebastian's train of thought was interrupted at this
point and he meant to say something more?

There seem to be more people accepting namespaces-for-new-elements so far (with
some wanting an extra schema category of 'extension-without-the-namespace').
Any other arguments against this? One of the reasons I want us to be sure that
this is the change we want to make is because I think it is one we will have to
actively and committedly sell to the community (even if it is the right decision
and in their own interest), so I want to flush out the arguments against it.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 10:06:36 EST

From Syd_Bauman at Brown.edu Fri Mar 23 10:15:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 23 Mar 2007 11:15:24 -0400 Subject: [tei-council] conformance draft In-Reply-To: <4603A74D.9000602@computing-services.oxford.ac.uk> Message-ID: <17923.61196.153165.470900@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 23 Mar 2007 11:15:24 -0400
Wow, excellent discussion thread. I am sorry I don't have a chance to
really dive into deeply right now: Conal's "political" questions are
worth pondering, and I am very interested in Dot's experiments. I
will take the time to address two arguments, though.

jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly
jc:impairs jc:human jc:readability. jc:Having jc:a jc:few
jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things
jc:more.
b:I sb:find sb:this sb:pretty sb:hard sb:to sb:swallow, sb:at
sb:least sb:keeping sb:in sb:mind sb:that sb:the sb:target
sb:audience sb:we're sb:talking sb:about sb:here sb:are sb:relative
sb:beginners.

CT> Now, do we want to avoid name collisions or don't we?
Yes, of course, name collision is annoying, and we'd prefer to avoid
it. But on the scale of problems someone has merging TEI vocabularies
or getting one project's files to be interoperable with another
project's software, name collision is extremely low on the list of
difficulties. (And it's quite rare, to boot.)
Let's say you and I both have rich TEI vocabularies for encoding
early modern printed books, and we each have added elements
with different semantics. If you want to suck some of my files into
your system, you are going to have deal with a *lot* worse than the
fact that is a name collision.
* The fact that I record the idealized page number on n= of ,
whereas you store it as the content of
fw[@type='pageNum']/choice/corr.
* The fact that your software expects quotations in , but I've
encoded both quotations and direct speech in .
* The fact that our value lists for type= of

and are
different.
* The fact that I record rhyme scheme on rhyme= of , whereas you
indicate rhyme using inside .
* The fact that I handle overlapping speeches and metrical lines
using part= of , and you use next= & prev=.
* The fact that you encode the author in .../titleStmt/author
regardless, whereas I put it in .../titleStmt/author/persName,
.../ittleStmt/author/orgName, or .../titleStmt/author, depending on
whether (I think) the author was a person, an organization, or is
neither (e.g., "unknown").
* The fact that you've used 2-letter ISO 639 language codes, but I've
used 3-letter codes.
* The fact that your software expects an whenever there is a
line-break, but my encoding presumes that certain elements (,

, ) imply a line-break, so I haven't encoded an .
* The fact that I've recorded my sources in
.../sourceDesc/biblStruct, but you've used .../sourceDesc/bibl.
* The fact that I make use of default renditions, but you don't, so
your software doesn't know about them.
* Oh, and while we're on rendition, I use CSS2 in my rend=
attributes, but you use a home-grown solution.
* We've used different classification schemes for our s.
You get the idea. The list goes on and on and on even when two
different projects are applying "vanilla" TEI to similar kinds of
documents. Thus the gain of having one fewer problem (our s
needing to be put in a row) when trying to do something that is a
rare activity at the expense of making day-to-day activities a little
harder and (more importantly) raising the bar for entry into the land
of TEI seems like a bod idea to me.
Remember the words of the song (sung to the tune of "Jesus Christ
Superstar"):
T-E-I, Wendell notes,
Must remain easy for newer folks.
[http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0007&L=TEI-L&P=R969,
although you have to have read the entire thread to get some of
the jokes, and I can't spend the time to track it down now ...
besides, IIRC one or two of the exchanges were off-list.]

CT> If we don't care about name collisions, what is the TEI namespace
CT> for? Why have we added it?
For several reasons, but mostly so that one *can* import other
vocabularies into TEI, TEI into other vocabularies, or avoid
namespace collisions with your extensions. Remember, I am not for a
moment saying we should force people to stick their added elements
into the TEI namespace.
(One of the main reasons namespaces exist and are useful, not spelled
out in the Spec, IIRC, is that even without name collisions, it makes
processing much easier when everything is clearly labeled such that a
software package can divide all the elements into "those I am
supposed to process" and "others" with almost no effort.)

So I see these as reasons to permit a user to separate her additions
via namespace, perhaps even to encourage her to do so. But to insist
that the lone scholar studying Hispanic rhyming patterns in
17th-century manuscripts create his own namespace and deal with
multiple namespace issues for the one element he wants to add to
enhance his research (or lose the funding-helpful claim to "TEI
Conformance"); or worse yet, to risk having an administrator worry
that, like copyright infringement, it's illegal to add elements in
the TEI namespace ... all for a limited technical gain that may never
occur, seems like a bad idea.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 23 2007 - 10:15:27 EST

From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 11:18:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 16:18:48 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17923.61196.153165.470900@emt.wwp.brown.edu> Message-ID: <4603FDE8.8050505@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 23 Mar 2007 16:18:48 +0000
Syd Bauman wrote:
> jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly
> jc:impairs jc:human jc:readability. jc:Having jc:a jc:few
> jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things
> jc:more.
Surely that would be more accurate as:
I'm not entirely convinced that it truly impairs human TEI
beginners readability . :-)
I actually found the example quite readable, maybe I'm weird.
> Yes, of course, name collision is annoying, and we'd prefer to avoid
> it. But on the scale of problems someone has merging TEI vocabularies
> or getting one project's files to be interoperable with another
> project's software, name collision is extremely low on the list of
> difficulties. (And it's quite rare, to boot.)
I agree. Worries over namespace collisions isn't the only reason to be doing
this. Yes, they might be a problem, but I'm more convinced of the fact that we
are choosing to put TEI in a namespace. If we are choosing to do that, then we
should use them properly, and I don't think allowing anyone to add new elements
to that namespace is really using them properly.
> So I see these as reasons to permit a user to separate her additions
> via namespace, perhaps even to encourage her to do so. But to insist
> that the lone scholar studying Hispanic rhyming patterns in
> 17th-century manuscripts create his own namespace and deal with
> multiple namespace issues for the one element he wants to add to
> enhance his research (or lose the funding-helpful claim to "TEI
> Conformance"); or worse yet, to risk having an administrator worry
> that, like copyright infringement, it's illegal to add elements in
> the TEI namespace ... all for a limited technical gain that may never
> occur, seems like a bad idea.
Firstly, let's not make 'create his own namespace' into more than it is... if
Roma were edited as Sebastian suggests to provide a namespace, etc., then the
barrier isn't that high. Ok, there is still a barrier on 'deal with multiple
namespace issues' for his one element.
On the phone it has been suggested to me that a compromise might be something
like this:
a) Remove mentions of namespaces from the definition of TEI Conformance.
b) Include that the document must validate against one of the schema categories
listed in order to be conformant.
c) Add a new category which is
'extension-but-doesn't-use-TEI-namespace-for-new-elements'.
d) Add new-elements-in-new-namespace-requirement to a definition of 'TEI
Interchange Format'
An alternative possibility is to leave namespace-for-new-elements as a concept,
but not a requirement for conformance, and instead make it a requirement for
'TEI Interchange Format', but provide users an easy route to gain this to show
their funding bodies. I.e. Roma or a Roma-like tool reads an ODD and will
generate non-colliding schemas that use no-namespace for local processing, and
one which uses namespaces and an XSLT which will transform document instances
that validate against the no-namespace version into documents with namespaces.
While I think we should be providing as much help in this area as possible, I am
not sure this promotes best practice.
Part of the problem is that funding bodies want to see funded projects using
'the best' method possible. While often this sense of 'best' is based entirely
on misunderstandings, if we have TEI Conformance, and then TEI Conformance+TEI
Interchange Format, they'll probably just view that as better and require it.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 11:18:52 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 11:27:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 16:27:29 +0000 Subject: [tei-council] What to do with an easter egg Message-ID: <4603FFF1.90002@oucs.ox.ac.uk>
From: Lou Burnard
Date: Fri, 23 Mar 2007 16:27:29 +0000
I haven't seen any comment here on the document about editorial practice
which I posted here a couple of days ago, so I'm assuming that everyone
is reasonably happy with it. Which means that I can now circulate the
following slightly more detailed description of how I at least would
like council members to proceed when reviewing the chapters assigned to
them by Sebastian's note at the start of the week.
First however something we do NOT want: at this stage, we are not asking
you to undertake detailed proof-reading; we'll have another pass at that
later.
What we DO want is for you to read the material carefully and ask yourself:
* is this expressed clearly
* is this actually not a sensible recommendation (for whatever reason)
* is this inadequate -- e.g. because it is out of date or incomplete
If you find something which doesn't pass all three of these tests, you
should do one of the following
(a) get the XML source out of the subversion repository (see James's
notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
improve the text and either put the results back in the Council's branch
of the Subversion repository, or just email it to an editor.
(b) add a comment to the TRAC ticket for this chapter in this task,
leaving the ticket open for someone else to complete the required action
(c) create a completely new TRAC ticket identifying the issue for
other people to pick up and work on.
Choose option (a) if what needs doing is obvious and easily
accomplished. Choose option (b) if it looks straightforward but you're
not sure how (or don't have time) to fix the problem. Choose option
(c) if it doesn't look straightforward, you're not sure how to fix it,
and you think it needs a closer look.
The editorial guidelines mentions a number of stylistic things to look
out for (e.g. rhetorical style in new sections, references to DTDs,
additional or base tag sets in old sections, etc). You should also be
looking for unanticipated consequences of pervasive changes in P5 (e.g.
class work, datatyping of attributes, introduction of xml:id etc). And
please remember that after Berlin there will be *no* opportunity to
introduce further technical changes in 1.0 !
Excelsior!
Lou
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 23 2007 - 11:28:36 EST
From arianna.ciula at kcl.ac.uk Fri Mar 23 12:51:07 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 17:51:07 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> Message-ID: <4604138B.4040000@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 23 Mar 2007 17:51:07 +0000
I think we were supposed to comments on Matthew's draft about additions
to Places and Names and Nyms by giving some encoding examples today.
I would have like to have had the time to do this more extensively, but
here are my examples/comments for places for now and, even more briefly,
for nym.
*Places: examples*
An example of hierarchy among places expressed by using only nesting and
not relation and variants of place names (I suppose that this
could be expressed better using now):

Wales
Wallie
Wallia
Wall
Le Waleis

Carmarthenshire

Carmarthen
notAfter="1300">Kaermerdin
Caerfyrddin

castle of Carmarthen




An example of a place that is unidentified, but that may be in Wales:

Hendy
...?
cert="high"/>
...?

If I wanted to encode that the person Ranulf de Blundeville has been
earl of Chester, how would I encode this within the place tag for
Chester? as a placeEvent?
e.g.

...

Ranulf de
Blundeville was earl of Chester to="1132">from 1118 to 1132.

...

Indeed, I wouldn't mind to use placeEvent for this type of
information, but its description would then need to be expanded and say
that it could be used for facts involving a place actively as well as
passively (well...relatively passively, since the place is actually
"witnessing" a fact here).
*Places: comments*
Prose errors:
There are some errors related to missing words, punctuation etc., but
given the state of the draft I don't think it's necessary to report on
this at this stage and, in any case, no to the entire list.
Reification of placeName:
I find a bit confusing the use of the type attribute for the
placeName vs. place in the given examples.
e.g.
Brasserie George
Shouldn't this be type of the place element instead?
Same for the use of bloc within placeName in another
example.
Place Description:
placeDesc is not described.
*Nym general*
I think this addition has lots of potential uses.
The segmentation of a person surname into components which are, for
instance, toponymics and therefore place names in its own right could be
one of these. I could also see a possible combination between the use of
nym and relations between person names for patronymics or similar.
So, for now, thanks to the people who have worked on this in Vilnius.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch Matthew James Driscoll wrote: > TEI Place-name meeting, Vilnius, 23-24 February > > In attendance were: Lou Burnard, Matthew Driscoll, ??yvind Eide, Richard > Light, Tadeusz Piotrowski, Tatjana Timchenko and Sebastian Rahtz. > > The first day we were at the Institute of Lithuanian language > (http://www.lki.lt/indexeng.php), part of the Lithuanian Academy of > Sciences, and on the second day the Faculty of Philology > (http://www.flf.vu.lt/) at Vilnius University; we are grateful to both > institutions for acting as hosts. > > 1. Names and nyms > > We began by tackling one bit of business outstanding from the Personography > meeting last year in Oxford, viz. the development of a mechanism for > pointing from actual name instances to the canonical form of that name, thus > addressing the needs of onomasticians (who are interested in names per se), > in addition to those of prosopographers (who are interested in people). If, > for example, the names Tony Blair and Tony Benn occur in a text it should be > possible to tag them in such a way that they both point to information about > these respective gentlemen and are flagged as instances of the name "Tony". > It should further be possible to indicate that "Tony" is a (pet-)form of > "Anthony", which is itself a member of a family of names containing forms > such as "Antonio", "Anton", "Antoine" and so on. We propose doing this by > means of a new element, called , which contains the definition for a > canonical name or name-part of any kind. In addition to global attributes > and those inherited from att.typed it can take a @parts attribute, which > points to constituent nyms. The attribute @nymKey is available on any > element which is a member of the att.naming class in order to point to the > nym with which it corresponds. Thus, to take our example, the name "Tony > Blair" in running prose could be tagged as follows: > > > Tony > Blair > > > The @key attribute on would point to a element giving > information about Tony Blair, while @nymKey on points to the > relevant . A element may also combine a number of other > elements together, where it is intended to show that one is a pet form or > diminutive of another, or that different nyms are to be regarded as variants > of the same base nym, using the
element (from the model.entryParts > class); orthographic variants are dealt with using , while can > be used for information on the origin of the name: > > > > Antonius > From the Roman family name Antonius, > which is of unknown, presumably Etruscan, origin. It has been > commonly, but incorrectly, associated with Greek xml:lang="gr">ανθος > flower, which resulted in spellings with th in some > languages. > >
> Anthony > Antony >
> >
Tony
> > > >
Antonio
> >
Tonio
> > > > > > > > > This mechanism could also be used for place-names and place-name elements > (e.g. thorp, caster). > > 2. Place-names > > Our principal task at this meeting was to develop mechanisms for encoding > place-names, analogous to those which were developed for personal names at > the meeting in Oxford last year, which would allow for the recording of > abstracted information about a place, such as map coordinate, GIS > information etc., as well as variant forms of the name, in different > languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g. > Lundunum, London). On the analogy with , we propose a > element, which will usually contain at least one, and possibly several, > elements, followed by one or more elements to provide > geographical and/or geo-political information about the location of the > place. The existing element is available to provide a brief > informal description of the nature of a place. In addition, three new > elements have been proposed: , and , > which all have similar content models to their counterparts within . > > To take a fairly simple example: > > > Iceland > ??sland > 65 00 N, 18 00 W > 103,000 sq km > Constitutional > republic > Previously part of the kingdom of > Denmark, Iceland became independent > on 17 June 1944. > > > > 3. Events > > There was also some discussion on the feasibility (and desirability) of > developing a generic tagset for encoding assertions about events, although > no real conclusion was reached. > > M. J. Driscoll > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 12:51:38 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 14:21:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 19:21:23 +0000 Subject: [tei-council] conformance draft In-Reply-To: <4603ECF7.5060608@computing-services.oxford.ac.uk> Message-ID: <460428B3.6050304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 23 Mar 2007 19:21:23 +0000
James Cummings wrote:
>
>> Given that this is the most contentious
>> part of James' draft (in my mind) is this section,
>>
>
> Am I alone in thinking that Sebastian's train of thought was interrupted at this
> point and he meant to say something more?
>
er, um. yes. I meant to say I am relieved we are
discussing just this in some detail, as it implies
the rest is generally accepted.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 14:21:27 EST

From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 15:16:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 20:16:22 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17923.61196.153165.470900@emt.wwp.brown.edu> Message-ID: <46043596.9010603@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 23 Mar 2007 20:16:22 +0000
Syd Bauman wrote:
> sb:I sb:find sb:this sb:pretty sb:hard sb:to sb:swallow, sb:at
> sb:least sb:keeping sb:in sb:mind sb:that sb:the sb:target
> sb:audience sb:we're sb:talking sb:about sb:here sb:are sb:relative
> sb:beginners.
>
I question this. A "relative beginner", if we have done
our job right, does NOT need to add new elements.
Yes, many projects will need to; yes, it is not evil;
but I still claim that it is not something to undertake
casually. The TEI out of the box should be able
to encode mainstream texts.
I would also claim that anyone doing text encoding
using XML is not a beginner. You can't go from
no experience at all in markup and XML to TEI
customization involving new elements in one stage.
> If you want to suck some of my files into
> your system, you are going to have deal with a *lot* worse than the
> fact that is a name collision.
>
your list is amusing and instructive :-}
Maybe we should get you to deliver
a "why the TEI is rubbish" talk at the MM!
.....

> But to insist
> that the lone scholar studying Hispanic rhyming patterns in
> 17th-century manuscripts create his own namespace and deal with
> multiple namespace issues for the one element he wants to add to
> enhance his research (or lose the funding-helpful claim to "TEI
> Conformance")
I am coming around to believing that having to write
match="mytei:duck" instead of match="tei:duck" is
positively useful for maintenance purposes (I can quickly
spot where my code is for my elements only) and really
not that hard after all. your scholar has to learn to deal
with the xml namespace already, after all, and quite
possibly XInclude and xlink as well; better get the pain
over sooner.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 15:16:28 EST

From daniel.odonnell at uleth.ca Fri Mar 23 16:38:29 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 23 Mar 2007 15:38:29 -0600 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <4603CB0D.8070900@oucs.ox.ac.uk> Message-ID: <1174685910.6064.1.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 23 Mar 2007 15:38:29 -0600
Can we have an extension on this then? I'd started encoding Lethbridge
guessing a procedure on analogy with person and Matthew's email, but I
see now there is a lot to digest--especially since my other idea was to
encode the Old Man River.
Would 03-25 be good for us all?
On Fri, 2007-03-23 at 12:41 +0000, Lou Burnard wrote:
> Apologies -- I am still hoping to get the material on places back online
> by the weekend -- it got pushed off by other committments. The ndextra
> document is still accessible at www.tei-c.org/oldDrafts/ndextra.html
> (along with all the other old junk that used to be in Drafts) if you're
> desperate...
>
>
> Arianna Ciula wrote:
> > The resource at http://www.tei-c.org/Drafts/ndextra.html is not
> > available any more and the proposal made accessible for the TEI list at
> > http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new
> > examples for Places but just the Nym section.
> >
> > Any idea where I can find the former examples that have disappeared?
> >
> > Arianna
> >
> > Lou Burnard wrote:
> >> Christian Wittern wrote:
> >>> Matthew James Driscoll wrote:
> >>>>
> >>>>
> >>>
> >>> does that mean you also proposa a listNym for TEI?
> >>>
> >>>
> >>
> >> Yes. Matthew's report doesn't mention that there is a draft ODD,
> >> probably because I have not yet got round to putting it anywhere where
> >> Council members can see it easily. But if you look in the P5/Test
> >> directory on sourceforge, you will see a file called testndextra.odd,
> >> which contains the current state of the draft.
> >>
> >> I've just put a copy of the HTML generated from this by Roma on the
> >> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to
> >> keep this up to date as the draft progresses
> >>
> >>
> >>>> Our principal task at this meeting was to develop mechanisms for
> >>>> encoding
> >>>> place-names, analogous to those which were developed for personal
> >>>> names at
> >>>> the meeting in Oxford last year, which would allow for the recording of
> >>>> abstracted information about a place, such as map coordinate, GIS
> >>>> information etc., as well as variant forms of the name, in different
> >>>> languages (e.g. Praha, Prague, Praga) and/or different forms over
> >>>> time (e.g.
> >>>> Lundunum, London). On the analogy with , we propose a
> >>>> element, which will usually contain at least one, and possibly several,
> >>>> elements, followed by one or more elements to
> >>>> provide
> >>>> geographical and/or geo-political information about the location of the
> >>>> place.
> >>>
> >>> Why would you need more than one ? I had the impression
> >>> that the place is what stays constant? Is it because it also stands
> >>> in for the geopolitical information?
> >>
> >> Because a place might be located in more than one way (e.g. by its
> >> geopolitical status, or by its co-ordinates), and may also move its
> >> location over time.
> >>> However, if we talk about administrative geography here, you will
> >>> also have to account for changes in the size and super/sub components
> >>> of a place and a way to link this to coordinates defining the
> >>> polygon. Would the tagset be up to this task?
> >>
> >> probably... because we embed GML!
> >>
> >>
> >> _______________________________________________
> >> tei-council mailing list
> >> tei-council_at_lists.village.Virginia.EDU
> >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 23 2007 - 16:38:41 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 19:11:47 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 24 Mar 2007 00:11:47 +0000 Subject: [tei-council] Place draft In-Reply-To: <45E7F824.8070600@oucs.ox.ac.uk> Message-ID: <46046CC3.5070309@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sat, 24 Mar 2007 00:11:47 +0000
Still some way to go on this one, I fear -- keep those examples flooding
in chaps --
but I have now checked in a revised odd at P5/Test/testplace.odd and
you can see the HTML it generates at
http://www.tei-c.org/Drafts/testplace.html
goodnite
Lou
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 23 2007 - 19:11:51 EST
From James.Cummings at oucs.ox.ac.uk Sat Mar 24 20:14:16 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 25 Mar 2007 02:14:16 +0100 Subject: [tei-council] testplace.odd Message-ID: <4605CCE8.3010601@oucs.ox.ac.uk>
From: James Cummings
Date: Sun, 25 Mar 2007 02:14:16 +0100
Hiya,
I generated an .rnc from the testplace.odd found in sourceforge
P5/Test/testplace.odd and this seems to work fine except that I don't seem to be
offered inside even though the examples do.
Am I meant to be using a different odd? Or did I do something wrong?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Mar 24 2007 - 20:14:26 EST
From lou.burnard at computing-services.oxford.ac.uk Sun Mar 25 03:43:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 25 Mar 2007 09:43:39 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <4605CCE8.3010601@oucs.ox.ac.uk> Message-ID: <4606363B.2030607@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 25 Mar 2007 09:43:39 +0100
James Cummings wrote:
>
> Hiya,
>
> I generated an .rnc from the testplace.odd found in sourceforge
> P5/Test/testplace.odd and this seems to work fine except that I don't
> seem to be offered inside even though the examples do.
>
> Am I meant to be using a different odd? Or did I do something wrong?
>
> -James
Nope to both -- I just forgot to add the corpus module into the mix.
Will fix after breakfast!
Intermodule dependency rides again.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Mar 25 2007 - 03:43:42 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 04:08:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2007 10:08:17 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <4606363B.2030607@computing-services.oxford.ac.uk> Message-ID: <46063C01.5060809@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 25 Mar 2007 10:08:17 +0100
Lou Burnard wrote:
> Nope to both -- I just forgot to add the corpus module into the mix.
> Will fix after breakfast!
>
> Intermodule dependency rides again.
no, it means that is in the wrong module....
but it also shows that modules work - you dont see some elements unless
you load a module, but it works without.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 25 2007 - 04:08:23 EST
From daniel.odonnell at uleth.ca Sun Mar 25 15:06:05 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 14:06:05 -0600 Subject: [tei-council] testplace.odd In-Reply-To: <4606363B.2030607@computing-services.oxford.ac.uk> Message-ID: <1174853165.9661.3.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 25 Mar 2007 14:06:05 -0600
If I've build my rng correction, locale is still not working. Also many
of our examples have text inside location, where I suspect this should
either be inside rs (e.g. Junction of Park Street and Charlotte Street)
or measure (e.g. 41.687142 -74.870109).
On Sun, 2007-03-25 at 09:43 +0100, Lou Burnard wrote:
> James Cummings wrote:
> >
> > Hiya,
> >
> > I generated an .rnc from the testplace.odd found in sourceforge
> > P5/Test/testplace.odd and this seems to work fine except that I don't
> > seem to be offered inside even though the examples do.
> >
> > Am I meant to be using a different odd? Or did I do something wrong?
> >
> > -James
> Nope to both -- I just forgot to add the corpus module into the mix.
> Will fix after breakfast!
> Intermodule dependency rides again.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 25 2007 - 15:06:08 EST
From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 15:45:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2007 21:45:52 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <1174853165.9661.3.camel@localhost> Message-ID: <4606DF80.6040504@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 25 Mar 2007 21:45:52 +0100
Daniel O'Donnell wrote:
> If I've build my rng correction, locale is still not working.
On inspection, I think Lou is talking porkies
with his in testplace.odd. We never
mentioned in Vilnius, and there is
no reason why it should ever work inside
(since its just a member of model.settingPart).
> Also many
> of our examples have text inside location, where I suspect this should
> either be inside rs (e.g. Junction of Park Street and Charlotte Street)
> or measure (e.g. 41.687142 -74.870109).
>
"should", or "could"?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 25 2007 - 15:45:57 EST

From daniel.odonnell at uleth.ca Sun Mar 25 17:48:24 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 16:48:24 -0600 Subject: [tei-council] testplace.odd In-Reply-To: <4606DF80.6040504@oucs.ox.ac.uk> Message-ID: <1174862904.9661.4.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 25 Mar 2007 16:48:24 -0600
On Sun, 2007-03-25 at 21:45 +0100, Sebastian Rahtz wrote:
> Daniel O'Donnell wrote:
> > If I've build my rng correction, locale is still not working.
> On inspection, I think Lou is talking porkies
> with his in testplace.odd. We never
> mentioned in Vilnius, and there is
> no reason why it should ever work inside
> (since its just a member of model.settingPart).
> > Also many
> > of our examples have text inside location, where I suspect this should
> > either be inside rs (e.g. Junction of Park Street and Charlotte Street)
> > or measure (e.g. 41.687142 -74.870109).
> >
> "should", or "could"?
"Should" according to the ODD. We're not allow text inside location.
-dan, who just lost a very detailed example, O'Donnell
>
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Mar 25 2007 - 17:48:30 EST
From daniel.odonnell at uleth.ca Mon Mar 26 00:06:10 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 23:06:10 -0600 Subject: [tei-council] Some place tests Message-ID: <1174885570.9661.16.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 25 Mar 2007 23:06:10 -0600
My tests are below. I tried a place that was destroyed and rebuilt as a
museum somewhere else (Fort Hamilton/Fort Whoop Up); a place that has a
huge number of names and is in a district that changed names
(Coalbanks/Lethbridge/Sikohktoks), and a river (Belly/Old Man).
I've added some comments on issues that arose interlinealy in the code.
I also ran all the examples against an rng schema produced from this
afternoon's ODD: the problems are indicated by comments. All the ones
that did not have any problems have been cut back out. (I'm reproducing
it here in case attachments aren't allowed).
-dan
P.S. a problem independent of place came up: if I want to encode the
orgName
North West Mounted Police (NWMP)/Royal Canadian Mounted Police (RCMP),
the "Mounties"
How does one do that? I original wanted to do


North West Mounted Police
NWMP
Mounties

But soCalled wasn't allowed in the choice. I'm wondering if there is a
way of getting all three or five names, nicknames, and abbreviations
into a single ancestor element while indicating the connection between
them in a fashion similar to my typography above.
-----------------

type="xml"?>




Place Test


Sample test

Born electronic






type="official">Fort Hamilton
Fort Whoop
Up

Trading fort and later museum/interpretative
centre.



Canada
Alberta


Confluence of the St.
Mary's and Old
Man
(Belly) rivers


type="Lat-Long">49.626502,-112.886925


49.714491,-112.861862


Canada
Alberta
City of Lethbridge
Indan Battle Park


Established as a trading fort by
J.J. Healy and
A.B. Hamilton

Policed by the

North West Mounted
Police
NWMP



notAfter="1892">

Abandoned sometime between 1890 and 1892.

Washed away in flood of the
Oldman river

Recreated as a Centenial project in a new
location.

Fort Hamilton/Fort Whoop Up was established
as a trading fort at the
confluence of the St. Mary's and Belly (now
Oldman) rivers in 1869 by
J.J. Healy and
A.B.
Hamilton, American traders from
Montana. The fort was
established in large part
in response to the enactment of laws
forbidding the sale of alcohol on
the nearby Montana Reserves that same year.
Although the fort carried
out legitimate trade, the fort also rapidly
became one of the more
notorious Whiskey trading posts in the
Canadian North West. Prompted in
part by the threat these forts posed to good
order (Whiskey traders
massacred a number of Assiniboine in the
nearby Cyprus Hills in 1873)
and in part by the threat to sovereinty
posed by the largely
American-run Whiskey trade (Fort Whoop Up
used a flag that closely
resembled the U.S. Stars and Stripes), in
1874 the government of the new
Dominion of Canada established the

North West Mounted
Police
NWMP

(later the

Royal Canadian Mounted
Police
RCMP

) to police the new territories.
By the fall of 1874, the NWMP
had established a presence in the area (they
even rented barack space
from Healy and Hamilton at the fort), and
brought the whiskey trade
under control. The fort continued as a
legitimate trading post until it
was abandoned in the early 1890s. The last
remnants of the original
structures were washed away in a flood of
the Oldman (formerly Belly)
river in 1915.


The fort was recreated as a museum and
interpretative centre
approximately 7 km downstream (NW) of the
original site in Indian Battle
Park, an urban park of the City of
Lethbridge, as a Centennial project
in 1967.


from="1885-10-15">Lethbridge
to="1885-10-15">Coalbanks

xml:id="sikohkotoks0001">Sikohkotoks
Black
Rocks



xml:id="sikokotoks0001">Sikokotoks
Black
Rocks


xml:id="sikoohkotoks0001">Sikoohkotoks
Black
Rocks


xml:id="aksaysim0001">Aksaysim
Steep
Banks


xml:id="aksiiksahko0001">Aksiiksahko
Steep
Banks


xml:id="mek-kio-towaghs0001">Mek-kio-towaghs
Painted
Rock, Red Painted Rock,
Medicine Stone


xml:id="miiksskoowa0001">Miiksskoowa
Painted Rock,
Red Painted Rock, Medicine
Stone


xml:id="assini-etomochi0001">Assini-etomochi
Where We
Slaughtered the Crees


xml:id="asinaawaiitomottsaawa0001"
>Asinaawaiitomottsaawa
Where
We Slaughtered the
Crees


xml:id="chadish-kashi0001">Chadish-kashi
Black
Rocks


xml:id="kuskusukisay-guni0001">Kuskusukisay-guni
Black
Rocks


xml:id="ipubin-saba-akabin0001">Ipubin-saba-akabin
Digging
coal



LA
Lethbridge, Alberta




Canada
Alberta


49.7000,
-112.8330




67,374


63,053



121.83






unit="population/km2">121.83






553.0



notBefore="2001">

3,050
notBefore="2001">

3,270
notBefore="2001">

3,670
notBefore="2001">

1,820
notBefore="2001">

1,850
notBefore="2001">


unit="CAD">27,090



notBefore="1869">

The first European activity occurred in the
early 1870s when a coal mine
was established by Nicolas Sheran to supply
Fort Hamilton NWMP posts in
the area.
from="1882-10">

The first significant European settlement was
established in 1882 when
Sir Alexander Galt and the
North West Coal and Navigation
Company
NWC&NC
opened a more significant mine
across the river. This
settlement was initially known as
Coalbanks (a
calque of the Blackfoot name for the
area).
from="1885-10-15">

The town was renamed
Lethbridge after the then
president of the NWC&NC,
William
Lethbridge.

Lethbridge is incorporated as a town with
proclaimation of Ordinance No.
24.

Lethbridge is incorporated as a city by an
act of the Alberta
Legislature.


Oldman River
Belly River

Mount Gass


type="lat-long">50.120578,-114.674263


type="lat-long">49.600698,-114.048729


Oldman Reservoir


Fort Macleod


type="lat-long">49.756651,-113.362427


type="lat-long">49.626502,-112.886925


Lethbridge


type="lat-long">49.886451,-112.474937


type="lat-long">49.931887,-111.692505



unit="km">209
unit="km">241





unit="km2">25,100






The mountainous region of the
watershed serves as the headwaters
for the Oldman River and its
tributaries. Headwaters for the Belly,
Waterton, and St. Marys rivers begin in
Montana. The coldwater
streams of the mountain and foothill
regions support a large sport
fishery. This region is largely forested
with stands of aspen and
lodgepole pine. The stands become more
continuous with elevation,
and include white spruce, douglas fir,
engelmann spruce, alpine fir,
and alpine larch.
target="http://www.uoguelph.ca/gwmg/wcp_home/Pages/O_ne.htm"/>





The foothills region is characterised
by rolling hills, and a
fragile foothills fescue vegetation
ecosystem that is threatened by
introduction of non-native vegetation
and extensive cattle grazing.
The foothills are a result of uplifting
of the Rocky Mountains in
the Cenozoic era (65 million years to
present), when shale and
sandstone deposits were broken and
pushed eastward in ripples
target="http://www.uoguelph.ca/gwmg/wcp_home/Pages/O_ne.htm"/>





The plains region comprises
approximately 80 percent of the
watershed. The area is characterised by
dark brown chernozemic soils
that are well suited to agriculture. The
conversion of natural
prairie vegetation to agricultural crop
production and cattle
grazing has resulted in the natural
prairie ecosystem being the most
threatened ecosystem in Alberta. The
most urbanised section of the
watershed is the eastern portion, around
the City of Lethbridge, and
the towns of Coaldale and Taber. Here
the landscape is fragmented by
multiple land uses. The Oldman River
above Lethbridge supports some
coldwater and warmwater fisheries, while
the area downstream of
Lethbridge is a warmwater
fishery.
target="http://www.uoguelph.ca/gwmg/wcp_home/Pages/O_ne.htm"/>





The climate of Southern Alberta is
semi-arid with extremes of
weather, and great day-to-day potential
variation in local climate.
Climate conditions in the Oldman River
watershed vary across two
climatic regions. The Rocky Mountains in
the western portion of the
watershed are part of the Cordillera
climatic region. This region is
characterized by short, cool summers and
highly variable weather.
The Prairie region is characterized by
warm-to-hot summers, extreme
seasonal temperature variations, dry
artic winter air, rain shadow
effects, and moisture deficits.
Precipitation in the region also
follows a gradient whereby the mountains
receive up to 110 cm per
year, compared to 35 cm near Taber, in
the eastern portion of the
watershed.
target="http://www.uoguelph.ca/gwmg/wcp_home/Pages/O_ne.htm"/>





Approximately 60 percent of the
annual discharge of the Oldman
River and its tributaries flows between
April and June, due to snow
melt in the mountains. In addition to
high streamflows from spring
melting, flooding is often caused by
high intensity rainfall events
occurring in early- to mid-summer. This
was the case on June 5,
1995, when flooding caused $88,000,000
in damages in the watershed.
Streamflows are typically the lowest
during the months of August and
September, making low water levels a
particular concern in the late
summer and fall. Drought conditions in
2000 and 2001 highlighted the
susceptibility of the region to drought.
It is expected that given
future climate change and variability
there will be more intense and
numerous periods of drought.
target="http://www.uoguelph.ca/gwmg/wcp_home/Pages/O_ne.htm"/>





The Oldman river has its headwaters near Mt.
Gass, Alberta. It is also
fed by the Mt. Lyall glacier.


The Oldman river ends when it combines with
the Bow to form the South
Saskatchewan river

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Lyon
Lugdunum


xmlns="http://www.opengis.net/gml">
xmlns="http://www.opengis.net/gml"> 45.256 -110.45 46.46 -109.48 43.84
-109.86 45.8 -109.2 45.256 -110.45




city

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Lyon
Lugdunum

EU
France


city

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Brasserie Georges


Lyon
type="arrondissement">Perrache
Rue de la
Charit??


Restaurant

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Lyon
Lugdunum



xmlns="http://www.opengis.net/gml">
xmlns="http://www.opengis.net/gml"> 45.1 -110.23 46.48 -99.08 31.74
-108.86 45.3 -78.2 42.25 -103.45






xmlns="http://www.opengis.net/gml">
xmlns="http://www.opengis.net/gml"> 45.256 -110.45 46.46 -109.48 43.84
-109.86 45.8 -109.2 45.256 -110.45




xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">

Junction of Park Street and Charlotte
Street
fire hydrant

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">

Atlantis

Unknown

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Yasgur's Farm
Woodstock Festival
Site


one mile

north west of
Bethel
New York


41.687142
-74.870109

xmlns:rng="http://relaxng.org/ns/structure/1.0"
xmlns:gml="http://www.opengis.net/gml">
Lithuania
Lietuva

Vilnius


Kaunas






-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 26 2007 - 00:06:15 EST
From Syd_Bauman at Brown.edu Mon Mar 26 08:46:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 26 Mar 2007 09:46:40 -0400 (EDT) Subject: [tei-council] webRoma (was "Re: conformance draft") In-Reply-To: <4602E7E9.8040701@oucs.ox.ac.uk> Message-ID: <200703261346.l2QDkeKC022450@draco.services.brown.edu>
From: Syd Bauman
Date: Mon, 26 Mar 2007 09:46:40 -0400 (EDT)
SR> if you get an ODD which is not valid, I need to know!
SR> that would be a bug.
* webRoma spits out elements where it means
* webRoma will stick an after the and
of an (sometimes this has happened even when there is no
reason for an at all -- the content of
matches the value of ident= of parent )
I'm also quite sure I had some problem with an attribute last week,
but for the life of me I can't remember what it was. It may not have
been a webRoma-produced invalidity. E.g., it may have been a webRoma
passed-on invalidity. (I.e., what happens when user enters invalid
value, like "hi Mom!" as the value for the 'prefix' field.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Mar 26 2007 - 08:46:43 EST
From daniel.odonnell at uleth.ca Mon Mar 26 09:37:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 26 Mar 2007 08:37:33 -0600 Subject: [tei-council] Place followup Message-ID: <1174919853.11966.29.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 26 Mar 2007 08:37:33 -0600
I'd been too tired to add some additional comments on the place name
test when I submitted my example last night. But here they are now.
I found a couple of minor inconsistencies in the ODD: notBefore and
notAfter failing to be available in places where the examples say they
should be, examples that should text data in elements that the ODD
requires child elements for. I also wonder if we shouldn't have someway
of indicating point-in-time for all elements that have
from/to/notBefore/notAfter elements: like birthdays (where we use
@date), acts of incorporation or census data are valid only for specific
points in time and it felt silly using either from or from/to with the
same date to indicate that Lethbridge changed its name on 1885-10-15 or
had 1850 women in common law relationships in the 2001 census.
The main issues I had, however, were the inability to create structures
within groups of the main elements (i.e. placeName or placeTrait) and,
in the case of the river, to express parts of the place (this last is
not too hard, I suspect though).
So, to give an example, in the case of Lethbridge, various online
sources supply quite a number of Native American names for the city in
various spellings. I went and checked with an elder from the local
Peigan community, and not all of these are equally valid or acceptable,
even though all are out there in sources somewhere. There were at least
three spellings for the most common semi-official name of Lethbridge
among the Blackfoot--sikohkitoks, sik-oki-toks, and sik-ooh-kitoks--of
which the first is the correct current spelling and the others probably
formulated by non-speakers. The other terms all refer to the specific
area in which Lethbridge is, but not all are used to refer to the city.
The one that means "place where we slaughtered the crees" refers to a
major battle that took place here in the very early 1870s just as the
first European settlers started establishing themselves on the townsite.
I don't believe it is current and if it was, I doubt it is polite.
It would be nice to be able first of all to qualify names (something I
guess you can do with type), and secondly somehow group and distinguish
among alternatives, commenting on mistakes if applicable. Also, almost
every source I saw glossed the Native names the first time they came up.
I did this by using foreign within placeName, but I can see that causing
problems if you only gloss "unusual" foreign names: so I could see in
the case of something like Rome using placeName xml:lang="en" for Rome,
and placeName xml:lang="it" for Roma but wanting to gloss whatever the
Blackfoot word for the city is.
Secondly, in the case of Lethbridge I went to Census Canada, where there
were a number of newly released placeTraits. But there is no way of
keeping the internal (tabular) structure Census Canada or even group
them as a subsection of the placeTrait. Leaving aside the ability to
introduce tables--though these are commonly used by geographers--it
would be nice to be able to do something like this at least:

20
19

Finally, in the case of the Oldman river, I wanted to be able both to
group locations (some places on the river are both lat-long,
confluences, and towns and it would nice to indicate their relationship
to each other--a similar problem to the above) and discuss the river in
terms of the different geographical areas it went through--mountainous,
foothills, and plains. Here I was getting my information from a study of
the river and they tended to discuss the river in this way.
One option for this would have been to divide the river into multiple
places, one each for each region:

Oldman river

Mountainous region



Foothills region



Plains region



The trouble with this, though, is that the same source discussed the
climate in two regions--mountains and plains (which affected foothills
and plains). I thought I'd then try to tie placeTraits to location
ranges, but there is no corresp or targets att available.

-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 26 2007 - 09:37:38 EST

From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 26 16:03:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 26 Mar 2007 22:03:06 +0100 Subject: [tei-council] webRoma (was "Re: conformance draft") In-Reply-To: <200703261346.l2QDkeKC022450@draco.services.brown.edu> Message-ID: <4608350A.3000204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 26 Mar 2007 22:03:06 +0100
Syd Bauman wrote:
> * webRoma spits out elements where it means
>
I can see this one, and I think its fixed
> * webRoma will stick an after the and
> of an (sometimes this has happened even when there is no
> reason for an at all -- the content of
> matches the value of ident= of parent )
>
>
I can see this, but I am having trouble
understanding how to fix it.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Mar 26 2007 - 16:03:21 EST

From Syd_Bauman at Brown.edu Tue Mar 27 11:09:50 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 27 Mar 2007 12:09:50 -0400 Subject: [tei-council] Re: webRoma In-Reply-To: <89553718@toto.iv> Message-ID: <17929.16846.916660.924189@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 27 Mar 2007 12:09:50 -0400
> I'm also quite sure I had some problem with an attribute last week,
> but for the life of me I can't remember what it was.
Ah! That's what it was. webRoma will generate elements
that do not have (the required) type= attribute.

While we're talking about webRoma, one of the things I really feel
needs to be improved is the interface to & data.enumerated.
At the very least when an ODD is read in, the "List of values" field
on the "Add a new attribute" page (which is often used for changing
attributes) should be pre-populated with the values found in the
existing . Also the "Closed list" question should probably
include all three possibilities, no? ("closed", "open", and "semi").
Lastly, although to my knowledge we have still not entirely
straightened the data.enumerated vs. valItem/@ident issue, I think
(perhaps incorrectly) that we are still of the opinion that
should only be used in combination with certain datatypes[1]. If
there are datatypes with which we feel a value list should not be
specified (data.count jumps to mind), I think the webRoma front-end
should reflect this.
Note
---- [1] The GLs currently use in conjunction with: 13 data.truthValue 1 data.xTruthValue 1 data.certainty (not including precision= of , which is about to be removed) 70 data.enumerated 1 data.name, w/ maxOccurs=5, which is for generate= of , and which I claim is in error: should be data.enumerated. Are there any other datatypes with which makes a lot of sense? (To be honest, I'm not very convinced of truthValue, xTruthValue, and certainty -- seems to leave open the possibility for discrepancy.) _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 11:09:56 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 11:18:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 17:18:20 +0100 Subject: [tei-council] Re: webRoma In-Reply-To: <17929.16846.916660.924189@emt.wwp.brown.edu> Message-ID: <460943CC.2000800@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 27 Mar 2007 17:18:20 +0100
Syd Bauman wrote:
> Ah! That's what it was. webRoma will generate elements
> that do not have (the required) type= attribute.
>
ok, have made a trac ticket to remind me
>
> While we're talking about webRoma, one of the things I really feel
> needs to be improved is the interface to & data.enumerated.
> At the very least when an ODD is read in, the "List of values" field
> on the "Add a new attribute" page (which is often used for changing
> attributes) should be pre-populated with the values found in the
> existing . Also the "Closed list" question should probably
> include all three possibilities, no? ("closed", "open", and "semi").
>
ok, agreed, ditto.
> Lastly, although to my knowledge we have still not entirely
> straightened the data.enumerated vs. valItem/@ident issue, I think
> (perhaps incorrectly) that we are still of the opinion that
> should only be used in combination with certain datatypes[1]. If
> there are datatypes with which we feel a value list should not be
> specified (data.count jumps to mind), I think the webRoma front-end
> should reflect this.
>
how is it to know, though? where will these rules be
expressed.
I agree its not quite nice as it is.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 11:18:23 EST
From Syd_Bauman at Brown.edu Tue Mar 27 11:25:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 27 Mar 2007 12:25:47 -0400 Subject: [tei-council] Re: webRoma In-Reply-To: <460943CC.2000800@oucs.ox.ac.uk> Message-ID: <17929.17803.358253.328215@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 27 Mar 2007 12:25:47 -0400
> ok, have made a trac ticket to remind me
> ok, agreed, ditto.
Check, thanks.

> how is it to know, though? where will these rules be expressed.
Really good question. When Lou dreamed this concept up I was
initially under the (perhaps false) impression that attributes of
datatype data.enumerated had to have s, and those of other
datatypes had to *not* have s. This is why I thought
should be a child of .
But if we're not to follow some simple algorithm like this, then we
would have to either:
* build rules not described in the Guidelines into the logic of
webRoma, realizing they could be over-ridden by an ODD author if
she wanted, OR
* make it explicit which datatypes may have s and which may
not. Perhaps by putting an attribute on the which
defines the datatype? (Or a different value for type=?)

I think we should open a Trac ticket to tackle this and solve it.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Mar 27 2007 - 11:25:50 EST

From arianna.ciula at kcl.ac.uk Tue Mar 27 11:26:21 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Mar 2007 17:26:21 +0100 Subject: [tei-council] HTML output of guidelines Message-ID: <460945AD.9080407@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 27 Mar 2007 17:26:21 +0100
While starting the proofreading on the chapters I have been assigned, I
have noticed that some content of elements is either not rendered or,
more importantly, not output in the html of the guidelines.
I wander whether this is because James and Dot are working on the new
output model right now and therefore changing things as I write.
I can of course collect this details in a ticket while I do the
checking, but the fact the any content within is lost in
translation alerted me a bit.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 11:27:07 EST
From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 11:29:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 17:29:04 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <460945AD.9080407@kcl.ac.uk> Message-ID: <46094650.4080204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 27 Mar 2007 17:29:04 +0100
Arianna Ciula wrote:
> While starting the proofreading on the chapters I have been assigned,
> I have noticed that some content of elements is either not rendered
> or, more importantly, not output in the html of the guidelines.
thats a bit serious. give me chapter and verse and
I'll deal with it immediately.
> I wander whether this is because James and Dot are working on the new
> output model right now and therefore changing things as I write.
no, James and Dot have not started committting code yet
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 11:29:08 EST
From arianna.ciula at kcl.ac.uk Tue Mar 27 11:34:17 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Mar 2007 17:34:17 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094650.4080204@oucs.ox.ac.uk> Message-ID: <46094789.4040502@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 27 Mar 2007 17:34:17 +0100
SG: Gentle intro: Proof-read text looking for references to DTDs and P4
architecture
....red is #PCDATA, as in
this example.
This is an abbreviation for parsed character data

That the text within gloss doesn't show up.
Arianna
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> While starting the proofreading on the chapters I have been assigned,
>> I have noticed that some content of elements is either not rendered
>> or, more importantly, not output in the html of the guidelines.
> thats a bit serious. give me chapter and verse and
> I'll deal with it immediately.
>> I wander whether this is because James and Dot are working on the new
>> output model right now and therefore changing things as I write.
> no, James and Dot have not started committting code yet
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 11:34:57 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 12:57:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 18:57:16 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094789.4040502@kcl.ac.uk> Message-ID: <46095AFC.2080402@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 27 Mar 2007 18:57:16 +0100
Arianna Ciula wrote:
> SG: Gentle intro: Proof-read text looking for references to DTDs and
> P4 architecture
>
>
....red is #PCDATA, as in
> this example.
> This is an abbreviation for parsed character data
amazing that has not come up before, its a glaring great bug!
I have found the hole, plugged it, will now test and then
put new HTML in place on web site by hand.
please report any other funnies like this as soon as you see them.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 12:57:21 EST
From daniel.odonnell at uleth.ca Tue Mar 27 14:09:27 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 27 Mar 2007 13:09:27 -0600 Subject: [tei-council] conformance draft In-Reply-To: <4603FDE8.8050505@computing-services.oxford.ac.uk> Message-ID: <1175022567.27266.85.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 27 Mar 2007 13:09:27 -0600
Picking this up by reading backwards--I'm still with the draft on this:
-This seems to me to be how we are supposed to do it, in keeping with
the proper use of namespaces
-If we can modify roma, we have a relatively painless way of dealing
with it
-Anybody who is in a position to be adding new elements is not a novice
and is going to be in a state to think up ways of making the task of
adding them to the relevant elements easier.
On Fri, 2007-23-03 at 16:18 +0000, James Cummings wrote:
> Syd Bauman wrote:
>
> > jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly
> > jc:impairs jc:human jc:readability. jc:Having jc:a jc:few
> > jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things
> > jc:more.
>
> Surely that would be more accurate as:
>
> I'm not entirely convinced that it truly impairs human TEI
> beginners readability . :-)
>
> I actually found the example quite readable, maybe I'm weird.
>
> > Yes, of course, name collision is annoying, and we'd prefer to avoid
> > it. But on the scale of problems someone has merging TEI vocabularies
> > or getting one project's files to be interoperable with another
> > project's software, name collision is extremely low on the list of
> > difficulties. (And it's quite rare, to boot.)
>
> I agree. Worries over namespace collisions isn't the only reason to be doing
> this. Yes, they might be a problem, but I'm more convinced of the fact that we
> are choosing to put TEI in a namespace. If we are choosing to do that, then we
> should use them properly, and I don't think allowing anyone to add new elements
> to that namespace is really using them properly.
>
> > So I see these as reasons to permit a user to separate her additions
> > via namespace, perhaps even to encourage her to do so. But to insist
> > that the lone scholar studying Hispanic rhyming patterns in
> > 17th-century manuscripts create his own namespace and deal with
> > multiple namespace issues for the one element he wants to add to
> > enhance his research (or lose the funding-helpful claim to "TEI
> > Conformance"); or worse yet, to risk having an administrator worry
> > that, like copyright infringement, it's illegal to add elements in
> > the TEI namespace ... all for a limited technical gain that may never
> > occur, seems like a bad idea.
>
> Firstly, let's not make 'create his own namespace' into more than it is... if
> Roma were edited as Sebastian suggests to provide a namespace, etc., then the
> barrier isn't that high. Ok, there is still a barrier on 'deal with multiple
> namespace issues' for his one element.
>
> On the phone it has been suggested to me that a compromise might be something
> like this:
>
> a) Remove mentions of namespaces from the definition of TEI Conformance.
> b) Include that the document must validate against one of the schema categories
> listed in order to be conformant.
> c) Add a new category which is
> 'extension-but-doesn't-use-TEI-namespace-for-new-elements'.
> d) Add new-elements-in-new-namespace-requirement to a definition of 'TEI
> Interchange Format'
>
> An alternative possibility is to leave namespace-for-new-elements as a concept,
> but not a requirement for conformance, and instead make it a requirement for
> 'TEI Interchange Format', but provide users an easy route to gain this to show
> their funding bodies. I.e. Roma or a Roma-like tool reads an ODD and will
> generate non-colliding schemas that use no-namespace for local processing, and
> one which uses namespaces and an XSLT which will transform document instances
> that validate against the no-namespace version into documents with namespaces.
> While I think we should be providing as much help in this area as possible, I am
> not sure this promotes best practice.
>
> Part of the problem is that funding bodies want to see funded projects using
> 'the best' method possible. While often this sense of 'best' is based entirely
> on misunderstandings, if we have TEI Conformance, and then TEI Conformance+TEI
> Interchange Format, they'll probably just view that as better and require it.
>
> -James
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 14:07:45 EST
From James.Cummings at computing-services.oxford.ac.uk Tue Mar 27 15:07:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 27 Mar 2007 21:07:34 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094650.4080204@oucs.ox.ac.uk> Message-ID: <46097986.7080105@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 27 Mar 2007 21:07:34 +0100
Sebastian Rahtz wrote:
>> I wander whether this is because James and Dot are working on the new
>> output model right now and therefore changing things as I write.
> no, James and Dot have not started committting code yet
Nope, Dot and I still haven't started this yet.

-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 15:07:39 EST

From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 17:11:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 23:11:13 +0100 Subject: [tei-council] Re: webRoma In-Reply-To: <17929.16846.916660.924189@emt.wwp.brown.edu> Message-ID: <46099681.2060109@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 27 Mar 2007 23:11:13 +0100
Syd Bauman wrote:
>
> Ah! That's what it was. webRoma will generate elements
> that do not have (the required) type= attribute.
>
>
fixed on Sourceforge, albeit untested :-{
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Mar 27 2007 - 17:11:23 EST
From arianna.ciula at kcl.ac.uk Wed Mar 28 03:40:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 28 Mar 2007 09:40:15 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46095AFC.2080402@oucs.ox.ac.uk> Message-ID: <460A29EF.3070105@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 28 Mar 2007 09:40:15 +0100
will do
Thanks,
Arianna
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> SG: Gentle intro: Proof-read text looking for references to DTDs and
>> P4 architecture
>>
>>
....red is #PCDATA, as in
>> this example.
>> This is an abbreviation for parsed character data
> amazing that has not come up before, its a glaring great bug!
>
> I have found the hole, plugged it, will now test and then
> put new HTML in place on web site by hand.
>
> please report any other funnies like this as soon as you see them.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Mar 28 2007 - 03:41:17 EST
From lou.burnard at computing-services.oxford.ac.uk Thu Mar 29 02:04:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 29 Mar 2007 08:04:40 +0100 Subject: [tei-council] Re: Fwd: TEI Workshop - 25 Apr. 2007 In-Reply-To: <311C7571-9285-407E-B419-7925710FAB27@loria.fr> Message-ID: <20070329070440.F3DA930001@webmail217.herald.ox.ac.uk>
From: Lou Burnard
Date: Thu, 29 Mar 2007 08:04:40 +0100
It has now!

In message <311C7571-9285-407E-B419-7925710FAB27_at_loria.fr> Laurent Romary
fr> writes:
> Hi Lou,
> Has this message gone through the list or is the HTML content
> considered as an attached document to the message?
> Cheers,
> Laurent
>
> D?but du message r?exp?di? :
>
> > De : Laurent Romary fr>
> > Date : 28 mars 2007 08:11:59 HAEC
> > ? : TEI Council village.virginia.edu>
> > Objet : TEI Workshop - 25 Apr. 2007
> >
> > Dear all,
> > You will find below a program outline for the workshop that will
> > take place at Harnak Haus on 25 April. The next step is for some of
> > you to volunteer to chair and/or contribute to the discussion
> > sessions corresponding to the various topics adressed along the
> > day. The idea is to react to usages, needs or request in the light
> > of the ongoing and future workplan of the TEI-C.
> >
> > As you can see, we have somehov managed to get all the important
> > German projects on board that actually work with the TEI. It may be
> > a very fruitful day.
> >
> > Best,
> > Laurent
> >
> > WORKING DOCUMENT
> >
> > For internal use only
> >
> > Program TEI workshop ?Putting the TEI to the test?
> >
> > (Status: 27.03.07, not all presentations and title of presentations
> > are yet confirmed)
> >
> > DRAFT:
> >
> > 10:30 ? 11:00
> >
> > Introductory Talk
> >
> > 10:30 ? 10:45 Christian Wittern: P5: current state and
> > prospects
> >
> > 10:45 ? 11:00 Lou Burnard: P5: technical
> > overview
> >
> > 11:00 ? 13:10
> >
> > 1. Session: Text-based projects
> >
> > Chair: N.N.
> >
> > 11:00 ? 11:15 Fotis Jannidis: Searching TEI texts in
> > TextGrid using basic encodings
> >
> > 11:15 ? 11:30 Torsten Scha?an: Aspects of the integration
> > of TEI in the workflows of the Wolfenbuettel digital library (WDB)
> >
> > 11:30 ? 12:00 joint
> > discussion
> >
> > 12:00 ? 12:15 Christian Mahnke: Fulltext processing at
> > the GDZ
> >
> > 12:15 ? 12:25 Bernhard Assmann: Der Einsatz der TEI im
> > Digitalisierungsprojekt der Werke Friedrichs des Gro?en (status
> > report)
> >
> > 12:25 ? 12:35 Thomas Burch: to be announced (status report)
> >
> > 12:35 ? 13:10 joint
> > discussion
> >
> > 13:10 - 14:00 lunch
> > break
> >
> > 14:00 ? 15:00
> >
> > 3. Session: Charter
> >
> > Chair: N.N.
> >
> > 14:00 ? 14:15 Georg Vogeler (?): Erweiterung der TEI f?r
> > die Verarbeitung von Archivmaterial (Urkunden)
> >
> > 14:15 ? 14:30 Patrick Sahle: Charter Encoding Initiative,
> > Codierungs-vorschl?ge f?r mittelalterliche Urkunden (?)
> >
> > 14:30 ? 15:00 joint discussion
> >
> > 15:00 ? 16:00
> >
> > 4. Session: Dictionaries
> >
> > Chair: N.N.
> >
> > 15:00 ? 15:15 Alexander Geyken: Representation of the
> > German ?Woerterbuch der Gegenwartssprache? in TEI: encoding
> > strategies and limitations
> >
> > 15:15 ? 15:30 Werner Wegstein: to be announced
> >
> > 15:30 ? 16:00 joint discussion
> >
> > 16:00 ? 16:20 coffee
> > break
> >
> > 16:20 ? 17:20
> >
> > 5. Session: Linguistic Annotations
> >
> > Chair: N.N.
> >
> > 16:20 ? 16:35 Susanne Alt: TEI-Kodierung von Parallelen
> > Dt.-Frz. Literatur-Korpora
> >
> > 16:35 ? 16:50 Andreas Witt: The Role of TEI-Annotations
> > for the Sustainable Representation of Linguistic Resources
> >
> > 16:50 ? 17:20 joint discussion
> >
> > 17:20 end of workshop
> >
> >
> >
> >
> >
> >
> >
> >
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 29 2007 - 02:04:44 EST

From James.Cummings at computing-services.oxford.ac.uk Thu Mar 29 03:59:22 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 29 Mar 2007 09:59:22 +0100 Subject: [tei-council] Place draft In-Reply-To: <46046CC3.5070309@computing-services.oxford.ac.uk> Message-ID: <460B7FEA.90306@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 29 Mar 2007 09:59:22 +0100
Lou's Laptop wrote:
> Still some way to go on this one, I fear -- keep those examples flooding
> in chaps --
Ok, find below my sample, which validated against an rnc generated from the
testplace.odd. I'm not entirely sure I've done things correctly, and happy
to hear where I've gone wrong.
I chose the "Regional Municipality of Waterloo" in Ontario, Canada. Dat is
where I done growed up! This regional municipality used to be called
'Waterloo County', and comprises a number of cities including
Kitchener-Waterloo. K-W, as everyone calls it, is officially two separate
cities which have grown together in a conurbation, but their governments
are entirely separate. Kitchener, up until 1916, used to be called
'Berlin' when a (much derided) vote was held to change its name. I've not
included the other cities and townships which make up the regional
municipality for brevity. Find my below.

=========



Waterloo County
Regional Municipality of Waterloo

Canada
Ontario



1,382
km²


Area is created as Waterloo County




Regional Municipality

Reorganisation from County to Regional Municipality



Kitchener-Waterloo
K-W
KW


Twin Cities

Berlin
Kitchener

136.89
km²


Recognised as a Hamlet

Incorporation as a City


In 1916 as a result of the first world war, and given the
large percentage of people of German background living in
Canada's German capital, it was
decided by ballot to change the name from
Berlin to
Kitchener after Lord
Kitchener. Although
Berlin's population ridiculed the
proposed name change and refused to vote. Although it had
a populate of well over 15,000 only 892 people voted. The
name Kitchener with 346 votes won
by 81 votes. Many Berliners supported maintaining
the name of the city, as it reflected a proud tradition
of growth and prosperity for German, and non-German,
Canadians alike. Those citizens who supported the status
quo were immediately perceived, by those who wanted
change, as being unpatriotic and sympathizers with the
enemy. Violence, riots and intimidation, often
instigated by imperialistic members of the 118th
Battalion, were not uncommon in the months leading up to
the May 1916 referendum on the issue. See target="http://www.collectionscanada.ca/education/firstworldwar/05180204/0518020404_e.html"
>What?s In a Name? Berlin to
Kitchener


See also
http://en.wikipedia.org/wiki/Berlin_to_Kitchener_name_change



Waterloo

64.1
km²


Recognised as a village

Officially a town

Incorporated as a city

Kitchener-Waterloo (K-W) is an unofficial but ubiquitous
name for the area in Ontario, Canada consisting of the twin
cities of Kitchener and Waterloo, approximately 100 kilometres
west of Toronto. The two cities grew into each other decades
ago and their shared boundary cuts through streets, backyards
and houses. While the term is used by local residents,
Kitchener and Waterloo are separate cities and not a single
municipal entity.





=========

-James

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 03:59:28 EST

From arianna.ciula at kcl.ac.uk Thu Mar 29 09:56:11 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 15:56:11 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <4603FFF1.90002@oucs.ox.ac.uk> Message-ID: <460BD38B.2010200@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 29 Mar 2007 15:56:11 +0100
A quick question:
if identifiers are missing for divisions of @type div3
e.g.
xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes
hould we add them (possibly following the existing model if consistent
in that chapter, otherwise following the editorial guidelines) or we
can/should leave it?
Thanks,
Arianna

Lou Burnard wrote:
> I haven't seen any comment here on the document about editorial practice
> which I posted here a couple of days ago, so I'm assuming that everyone
> is reasonably happy with it. Which means that I can now circulate the
> following slightly more detailed description of how I at least would
> like council members to proceed when reviewing the chapters assigned to
> them by Sebastian's note at the start of the week.
>
> First however something we do NOT want: at this stage, we are not asking
> you to undertake detailed proof-reading; we'll have another pass at that
> later.
>
> What we DO want is for you to read the material carefully and ask yourself:
> * is this expressed clearly
> * is this actually not a sensible recommendation (for whatever reason)
> * is this inadequate -- e.g. because it is out of date or incomplete
>
> If you find something which doesn't pass all three of these tests, you
> should do one of the following
>
> (a) get the XML source out of the subversion repository (see James's
> notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
> improve the text and either put the results back in the Council's branch
> of the Subversion repository, or just email it to an editor.
>
> (b) add a comment to the TRAC ticket for this chapter in this task,
> leaving the ticket open for someone else to complete the required action
>
> (c) create a completely new TRAC ticket identifying the issue for other
> people to pick up and work on.
>
> Choose option (a) if what needs doing is obvious and easily
> accomplished. Choose option (b) if it looks straightforward but you're
> not sure how (or don't have time) to fix the problem. Choose option
> (c) if it doesn't look straightforward, you're not sure how to fix it,
> and you think it needs a closer look.
>
> The editorial guidelines mentions a number of stylistic things to look
> out for (e.g. rhetorical style in new sections, references to DTDs,
> additional or base tag sets in old sections, etc). You should also be
> looking for unanticipated consequences of pervasive changes in P5 (e.g.
> class work, datatyping of attributes, introduction of xml:id etc). And
> please remember that after Berlin there will be *no* opportunity to
> introduce further technical changes in 1.0 !
>
> Excelsior!
>
> Lou
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 09:57:15 EST

From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 29 10:00:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 29 Mar 2007 16:00:11 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD38B.2010200@kcl.ac.uk> Message-ID: <460BD47B.4010007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 29 Mar 2007 16:00:11 +0100
Arianna Ciula wrote:
> A quick question:
> if identifiers are missing for divisions of @type div3
>
> e.g.

> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes
>
> should we add them (possibly following the existing model if
> consistent in that chapter, otherwise following the editorial
> guidelines) or we can/should leave it?
the type attribute on
has (currently) no effect at all. it was put in
there to test the conversion from numbered divs to unnumbered.
ignore it....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 10:00:14 EST
From arianna.ciula at kcl.ac.uk Thu Mar 29 10:11:35 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 16:11:35 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD47B.4010007@oucs.ox.ac.uk> Message-ID: <460BD727.3030902@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 29 Mar 2007 16:11:35 +0100
May I didn't explain myself properly;what I meant is that some divisions
have identifiers (so we can link to them) while others don't. Should we
add identifiers where they don't exists?
e.g.
xmlns="http://www.tei-c.org/ns/1.0">An example DTD
This div has an identifier probably because whoever edited the XML
wanted to have the possibility to create a link to it, but other divs don't.
Arianna
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> A quick question:
>> if identifiers are missing for divisions of @type div3
>>
>> e.g.

>> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes
>>
>> should we add them (possibly following the existing model if
>> consistent in that chapter, otherwise following the editorial
>> guidelines) or we can/should leave it?
> the type attribute on
has (currently) no effect at all. it was put in
> there to test the conversion from numbered divs to unnumbered.
>
> ignore it....
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 10:12:01 EST
From lou.burnard at computing-services.oxford.ac.uk Thu Mar 29 10:13:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 29 Mar 2007 16:13:54 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD38B.2010200@kcl.ac.uk> Message-ID: <20070329151354.982F530001@webmail217.herald.ox.ac.uk>
From: Lou Burnard
Date: Thu, 29 Mar 2007 16:13:54 +0100
Sections at that level only get an identifier if they have something pointing at
them. So you shouldn't need add them, in my opinion. Unless of course you're
adding a reference to one of them!

In message <460BD38B.2010200_at_kcl.ac.uk> Arianna Ciula ac.uk>
writes:
> A quick question:
> if identifiers are missing for divisions of @type div3
>
> e.g.


> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes
>
> should we add them (possibly following the existing model if consistent
> in that chapter, otherwise following the editorial guidelines) or we
> can/should leave it?
>
> Thanks,
> Arianna
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Mar 29 2007 - 10:13:57 EST
From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 29 10:16:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 29 Mar 2007 16:16:35 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD727.3030902@kcl.ac.uk> Message-ID: <460BD853.4090100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 29 Mar 2007 16:16:35 +0100
Arianna Ciula wrote:
> May I didn't explain myself properly

no, I was being an idiot. sorry. Lou is correct.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 10:16:39 EST

From arianna.ciula at kcl.ac.uk Thu Mar 29 10:31:01 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 16:31:01 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <20070329151354.982F530001@webmail217.herald.ox.ac.uk> Message-ID: <460BDBB5.3030006@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 29 Mar 2007 16:31:01 +0100
Lou Burnard wrote:
> Sections at that level only get an identifier if they have something pointing at
> them. So you shouldn't need add them, in my opinion. Unless of course you're
> adding a reference to one of them!
Thought so, but checking just in case, thank-you.
Arianna
>
>
> In message <460BD38B.2010200_at_kcl.ac.uk> Arianna Ciula ac.uk>
> writes:
>> A quick question:
>> if identifiers are missing for divisions of @type div3
>>
>> e.g.

>> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes
>>
>> should we add them (possibly following the existing model if consistent
>> in that chapter, otherwise following the editorial guidelines) or we
>> can/should leave it?
>>
>> Thanks,
>> Arianna
>>
>>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Mar 29 2007 - 10:31:41 EST
From arianna.ciula at kcl.ac.uk Fri Mar 30 11:08:09 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 30 Mar 2007 17:08:09 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <4603FFF1.90002@oucs.ox.ac.uk> Message-ID: <460D35E9.7030501@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 30 Mar 2007 17:08:09 +0100
> (a) get the XML source out of the subversion repository (see James's
> notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
> improve the text and either put the results back in the Council's branch
> of the Subversion repository, or just email it to an editor.
I don't have access to commit stuff to subversion. Should I just send
the revised SG chapter to you Lou?
Arianna
Lou Burnard wrote:
> I haven't seen any comment here on the document about editorial practice
> which I posted here a couple of days ago, so I'm assuming that everyone
> is reasonably happy with it. Which means that I can now circulate the
> following slightly more detailed description of how I at least would
> like council members to proceed when reviewing the chapters assigned to
> them by Sebastian's note at the start of the week.
>
> First however something we do NOT want: at this stage, we are not asking
> you to undertake detailed proof-reading; we'll have another pass at that
> later.
>
> What we DO want is for you to read the material carefully and ask yourself:
> * is this expressed clearly
> * is this actually not a sensible recommendation (for whatever reason)
> * is this inadequate -- e.g. because it is out of date or incomplete
>
> If you find something which doesn't pass all three of these tests, you
> should do one of the following
>
> (a) get the XML source out of the subversion repository (see James's
> notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
> improve the text and either put the results back in the Council's branch
> of the Subversion repository, or just email it to an editor.
>
> (b) add a comment to the TRAC ticket for this chapter in this task,
> leaving the ticket open for someone else to complete the required action
>
> (c) create a completely new TRAC ticket identifying the issue for other
> people to pick up and work on.
>
> Choose option (a) if what needs doing is obvious and easily
> accomplished. Choose option (b) if it looks straightforward but you're
> not sure how (or don't have time) to fix the problem. Choose option
> (c) if it doesn't look straightforward, you're not sure how to fix it,
> and you think it needs a closer look.
>
> The editorial guidelines mentions a number of stylistic things to look
> out for (e.g. rhetorical style in new sections, references to DTDs,
> additional or base tag sets in old sections, etc). You should also be
> looking for unanticipated consequences of pervasive changes in P5 (e.g.
> class work, datatyping of attributes, introduction of xml:id etc). And
> please remember that after Berlin there will be *no* opportunity to
> introduce further technical changes in 1.0 !
>
> Excelsior!
>
> Lou
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 30 2007 - 11:08:37 EST
From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 30 11:47:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 30 Mar 2007 17:47:20 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D35E9.7030501@kcl.ac.uk> Message-ID: <460D3F18.8050705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 30 Mar 2007 17:47:20 +0100
Arianna Ciula wrote:
> > (a) get the XML source out of the subversion repository (see James's
> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
> > improve the text and either put the results back in the Council's
> branch
> > of the Subversion repository, or just email it to an editor.
>
> I don't have access to commit stuff to subversion. Should I just send
> the revised SG chapter to you Lou?
>
If you have a sourceforge account, send me the name and I
will give you commit rights. otherwise send XML to me
or Lou or Syd to check in.
if your changes are controversial, they could go
in Council branch. are they?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 30 2007 - 11:47:30 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Mar 30 15:52:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 30 Mar 2007 21:52:56 +0100 Subject: [tei-council] floating texts Message-ID: <460D78A8.6070107@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 30 Mar 2007 21:52:56 +0100
Following up on SFFR 1308688, I have now checked in a preliminary
attempt at defining a new floatingText element, and made a number of
minor changes in the wording of some other chapters (mostly DS and DR)
to explain what it is and how it's different from the existing
I *really really* need some real examples though. Anyone care to
volunteer some?
Julia, are you there?
Lou
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 30 2007 - 15:53:00 EST
From lou.burnard at computing-services.oxford.ac.uk Fri Mar 30 16:27:22 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 30 Mar 2007 22:27:22 +0100 Subject: [tei-council] witness lists again Message-ID: <460D80BA.3080600@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 30 Mar 2007 22:27:22 +0100
I had the opportunity to discuss Gautier's ideas about witness lists
(see mail of 21st and 22nd) with the man himself, over several beers in
Paris earlier this week. I won't try to repeat all the discussion now
(and not just because of the beers), but I would like to ask those who
confidently assert that it can all be done with existing elements to
take a look at a real live example, such as the following. Put yourself
in the place of the downtrodden archivist trying to produce a reliable
edition of gazillions of charters each of which has a complicated
witness list associated with it, like this:
/A. Original sur parchemin, larg. 280 mm x haut. 720/755 mm, partie
droite d?un chirographe avec, ? gauche, la partie droite des lettres
composant le mot CYROGRAPHUM, jadis scell? d?un sceau comtal, sur
courroie. Arc//h. d?p. Somme, 9 H 337, n? ^ 1 /
/B/. Copie dans le vidimus de Baudouin IX, comte de Flandre, en date du
13 octobre 1201 aujourd?hui perdu, d?apr?s ^
/C/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de
Fr., lat. 17759, fol. 70v, sous la rubrique : ? Carta Roberti comitis
Flandrie super nemore de Walnosia. LXXXV ?, d?apr?s /A/.
/D/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Moreau 38,
fol. 100, avec r?f?rences ? /A/.
/E/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
237, fol. 115, avec r?f?rences ? /A/.
/F/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de
Fr., lat. 17759, fol. 67v, sous la rubrique : ? Carta Balduini comitis
Flandrie de Walnoisie nemore. LXXXI ?, sans doute d?apr?s /B/.
/G/. Copie de 1295, Cartulaire noir, Bibl. nat. de Fr., lat. 17758, fol.
207 (livre XXIV, n? XVI), sans doute d?apr?s /B/.
/H./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
79, fol. 138, avec r?f?rences ? /C/.
/I./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
79, fol. 163, avec r?f?rences ? /C/.

/a/. Chan. [F.-J] R[ay]m[ae]r[kers], /Donation faite en faveur de
l?abbaye de Corbie (France) par Robert, comte de Flandre, en 1096/, dans
/Analectes pour servir ? l?histoire eccl?siastique de la Belgique/, t.
II, 1865, p. 268, d?apr?s /A/.
/b/. E. Van den Bussche, /Recherches sur la for?t d?Houthulst/, dans /La
Flandre/, t. V, 1873-1874, p. 331, d?apr?s /a/ et une copie de /B/.
/c/. Godefroy Menilglaise (Marquis de), /Accord entre le comte de
Flandre et l?abbaye de Corbie pour le partage de la for?t de Wouthulst
et de terres vagues adjacentes?/, dans /Bulletin de la Soci?t? des
antiquaires de Picardie/, t. II, 1874, p. 76, d?apr?s une copie de /B/.
/d/. A. Wauters, dans /Bulletin de la Commission royale d?histoire/, t.
II, 1874, p. 178, d?apr?s /D/.
/e/. Th. de Limburg Stirum, /Cartulaire de Louis de Male, comte de
Flandre/, t. I, Bruges, 1898, n? 559, p. 506, d?apr?s une copie issue de
la tradition de /B/.
/f/. Huyghebaert et Six, /La for?t/, p. 245, d?apr?s /A/.
/g/. Prevenier, /De oorkonden/, n?^ 165, p. 357 (?dition du vidimus de
1201 suivie de celle de l?acte de 1096), d?apr?s /ACD/ et une copie
prise sur /B/.

Indiqu? : /R?pertoire du chartrier/ (1421), Bibl. nat. de Fr., fr.
24143, fol. 29 : ? Item une lettre du comte Robert de Flandres qui
recongnoist que toute le forest de le Warnoise fu a l?eglise, et
l?eglise lui en donna le moiti? par indivis reserv? le cacher et le
voler que le comte y a et l?eglise a le miel. Sign? g 111 ?. ? Wauters,
/Table chronologique/, t. VII/1, p. 179. ? Bormans et Halkin, /Table
chronologique/, t. XI, p. 92 et 343. ? Vercauteren, /Actes/, p.
CXIII-CXIV. ? Huyghebaert, /Ad villam/. ? Huyghebaert, /Houlthulst/, p.
186. ? Zoller-Devroey, /Le domaine/, p. 444. ? Morelle, /L?histoire/, p.
650.

Do you really want to produce a full blown msDescription for all of
these things and stash it away in the header?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Mar 30 2007 - 16:27:26 EST

From dporter at uky.edu Fri Mar 30 17:03:50 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 30 Mar 2007 18:03:50 -0400 Subject: [tei-council] witness lists again In-Reply-To: <460D80BA.3080600@computing-services.oxford.ac.uk> Message-ID: <96f3df640703301503o459f7357w22f7c34420eece58@mail.gmail.com>
From: Dot Porter
Date: Fri, 30 Mar 2007 18:03:50 -0400
Hi All,
I'm willing to revisit this. I opened up my oXygen and attempted to
build an msDescription based on Gautier's requests (as translated
here: http://www.tei-c.org/Drafts/witnessPart/index.xml?style=printable)
and indeed I had some trouble. But it's not a problem of in the header
vs. in the witness list - I think that is a red herring. The problem
is that this does not validate:

manuscript

filiation


seal description

More physical description


wxh


parchment
1145

So, yes, in order to get some of these in you need to include their
parent elements as well (to have we need , to have
we need to have and ) but that's not such
a big deal. The big deal, as I see it, is that we can't mix

s up
with the specialized elements from the model.physDescPart class. So if
our intrepid archivist wants to include a general physical description
in his

s, plus a more detailed description of the seal (taking
advantage of the element), he can't do it. He'd need to use the
other specialized elements as well, and that indeed could be a burden.
I don't suppose we'd want to allow as a member of
model.pPart.msdesc, so it could occur within

? I really think this
is the big issue. Other than that, the example above is valid and, I'd
argue, not very burdensome. And whether it appears in the header or in
the witness list, it'll look about the same.
Dot
On 3/30/07, Lou Burnard oxford.ac.uk> wrote:
> I had the opportunity to discuss Gautier's ideas about witness lists
> (see mail of 21st and 22nd) with the man himself, over several beers in
> Paris earlier this week. I won't try to repeat all the discussion now
> (and not just because of the beers), but I would like to ask those who
> confidently assert that it can all be done with existing elements to
> take a look at a real live example, such as the following. Put yourself
> in the place of the downtrodden archivist trying to produce a reliable
> edition of gazillions of charters each of which has a complicated
> witness list associated with it, like this:
>
> /A. Original sur parchemin, larg. 280 mm x haut. 720/755 mm, partie
> droite d'un chirographe avec, ? gauche, la partie droite des lettres
> composant le mot CYROGRAPHUM, jadis scell? d'un sceau comtal, sur
> courroie. Arc//h. d?p. Somme, 9 H 337, n? ^ 1 /
>
> /B/. Copie dans le vidimus de Baudouin IX, comte de Flandre, en date du
> 13 octobre 1201 aujourd'hui perdu, d'apr?s ^
> /C/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de
> Fr., lat. 17759, fol. 70v, sous la rubrique : ? Carta Roberti comitis
> Flandrie super nemore de Walnosia. LXXXV ?, d'apr?s /A/.
>
> /D/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Moreau 38,
> fol. 100, avec r?f?rences ? /A/.
>
> /E/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
> 237, fol. 115, avec r?f?rences ? /A/.
>
> /F/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de
> Fr., lat. 17759, fol. 67v, sous la rubrique : ? Carta Balduini comitis
> Flandrie de Walnoisie nemore. LXXXI ?, sans doute d'apr?s /B/.
>
> /G/. Copie de 1295, Cartulaire noir, Bibl. nat. de Fr., lat. 17758, fol.
> 207 (livre XXIV, n? XVI), sans doute d'apr?s /B/.
>
> /H./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
> 79, fol. 138, avec r?f?rences ? /C/.
>
> /I./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie
> 79, fol. 163, avec r?f?rences ? /C/.
>
>
> /a/. Chan. [F.-J] R[ay]m[ae]r[kers], /Donation faite en faveur de
> l'abbaye de Corbie (France) par Robert, comte de Flandre, en 1096/, dans
> /Analectes pour servir ? l'histoire eccl?siastique de la Belgique/, t.
> II, 1865, p. 268, d'apr?s /A/.
>
> /b/. E. Van den Bussche, /Recherches sur la for?t d'Houthulst/, dans /La
> Flandre/, t. V, 1873-1874, p. 331, d'apr?s /a/ et une copie de /B/.
>
> /c/. Godefroy Menilglaise (Marquis de), /Accord entre le comte de
> Flandre et l'abbaye de Corbie pour le partage de la for?t de Wouthulst
> et de terres vagues adjacentes?/, dans /Bulletin de la Soci?t? des
> antiquaires de Picardie/, t. II, 1874, p. 76, d'apr?s une copie de /B/.
>
> /d/. A. Wauters, dans /Bulletin de la Commission royale d'histoire/, t.
> II, 1874, p. 178, d'apr?s /D/.
>
> /e/. Th. de Limburg Stirum, /Cartulaire de Louis de Male, comte de
> Flandre/, t. I, Bruges, 1898, n? 559, p. 506, d'apr?s une copie issue de
> la tradition de /B/.
>
> /f/. Huyghebaert et Six, /La for?t/, p. 245, d'apr?s /A/.
>
> /g/. Prevenier, /De oorkonden/, n?^ 165, p. 357 (?dition du vidimus de
> 1201 suivie de celle de l'acte de 1096), d'apr?s /ACD/ et une copie
> prise sur /B/.
>
>
> Indiqu? : /R?pertoire du chartrier/ (1421), Bibl. nat. de Fr., fr.
> 24143, fol. 29 : ? Item une lettre du comte Robert de Flandres qui
> recongnoist que toute le forest de le Warnoise fu a l'eglise, et
> l'eglise lui en donna le moiti? par indivis reserv? le cacher et le
> voler que le comte y a et l'eglise a le miel. Sign? g 111 ?. ? Wauters,
> /Table chronologique/, t. VII/1, p. 179. ? Bormans et Halkin, /Table
> chronologique/, t. XI, p. 92 et 343. ? Vercauteren, /Actes/, p.
> CXIII-CXIV. ? Huyghebaert, /Ad villam/. ? Huyghebaert, /Houlthulst/, p.
> 186. ? Zoller-Devroey, /Le domaine/, p. 444. ? Morelle, /L'histoire/, p.
> 650.
>
>
> Do you really want to produce a full blown msDescription for all of
> these things and stash it away in the header?
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Mar 30 2007 - 17:03:57 EST

From arianna.ciula at kcl.ac.uk Sat Mar 31 05:00:53 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Sat, 31 Mar 2007 11:00:53 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D3F18.8050705@oucs.ox.ac.uk> Message-ID: <460E3155.704@kcl.ac.uk>
From: Arianna Ciula
Date: Sat, 31 Mar 2007 11:00:53 +0100
I sent the XML to Lou.
There shouldn't be anything controversial in my changes: some evident
mistakes/omissions in the prose or examples, some other minor things
related to what's called "Positioning" in the editorial guidelines and
so on.
I have some suggestions for things to add to those guidelines, but it's
probably better to wait until I have done all the three chapters.
> If you have a sourceforge account, send me the name and I
> will give you commit rights.
I don't think I do. I have downloaded all the repository to edit the
relevant XML file, but that doesn't require an account as far as I know.
Sorry my comments on Trac are not styled...copied them quickly and
didn't realise I could edit them as Wiki style.
Arianna
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> > (a) get the XML source out of the subversion repository (see James's
>> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
>> > improve the text and either put the results back in the Council's
>> branch
>> > of the Subversion repository, or just email it to an editor.
>>
>> I don't have access to commit stuff to subversion. Should I just send
>> the revised SG chapter to you Lou?
>>
> If you have a sourceforge account, send me the name and I
> will give you commit rights. otherwise send XML to me
> or Lou or Syd to check in.
>
> if your changes are controversial, they could go
> in Council branch. are they?
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Mar 31 2007 - 05:01:00 EST
From lou.burnard at computing-services.oxford.ac.uk Sat Mar 31 11:42:00 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 31 Mar 2007 17:42:00 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460E3155.704@kcl.ac.uk> Message-ID: <460E8F58.6090605@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 31 Mar 2007 17:42:00 +0100
I did a bit of quick reformatting of Arianna's version to make it easier
to edit in emacs, and then checked it in.
Her comments on the WIKI are very helpful too, but I haven't done
anything about most of them yet.
The main thing that worries me about this chapter is that it really
doesn't give RelaxNG and DTD language equal time. If it just used DTD
language as a vehicle to explain basic XML concepts that would be OK,
but it goes into a lot more detail than necessary for that job. So I
can't decide whether the best course is to add a comparable amount of
detail about RELAXNG, or cut the chapter down drastically. Either way
would require quite a lot of editorial time.
The goal of the original was to explain enough of SGML for the user of
the TEI to understand how the DTDs worked, and I think that's probably
still a good goal. I'm just not sure that we have time to do the job
equally well now that the the technical
basis for the Guidelines has changed so much.

Arianna Ciula wrote:
> I sent the XML to Lou.
> There shouldn't be anything controversial in my changes: some evident
> mistakes/omissions in the prose or examples, some other minor things
> related to what's called "Positioning" in the editorial guidelines and
> so on.
>
> I have some suggestions for things to add to those guidelines, but
> it's probably better to wait until I have done all the three chapters.
>
> > If you have a sourceforge account, send me the name and I
> > will give you commit rights.
> I don't think I do. I have downloaded all the repository to edit the
> relevant XML file, but that doesn't require an account as far as I know.
>
> Sorry my comments on Trac are not styled...copied them quickly and
> didn't realise I could edit them as Wiki style.
>
> Arianna
>
> Sebastian Rahtz wrote:
>> Arianna Ciula wrote:
>>> > (a) get the XML source out of the subversion repository (see James's
>>> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
>>> > improve the text and either put the results back in the Council's
>>> branch
>>> > of the Subversion repository, or just email it to an editor.
>>>
>>> I don't have access to commit stuff to subversion. Should I just
>>> send the revised SG chapter to you Lou?
>>>
>> If you have a sourceforge account, send me the name and I
>> will give you commit rights. otherwise send XML to me
>> or Lou or Syd to check in.
>>
>> if your changes are controversial, they could go
>> in Council branch. are they?
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Mar 31 2007 - 11:42:05 EST

From Syd_Bauman at Brown.edu Sun Apr 1 21:08:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 1 Apr 2007 21:08:55 -0400 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D35E9.7030501@kcl.ac.uk> Message-ID: <17936.22439.193898.662593@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 1 Apr 2007 21:08:55 -0400
I think, as a general rule, revised chapters should be checked into
the Council branch or sent to editors_at_tei-c.org.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Apr 01 2007 - 21:08:59 EDT
From arianna.ciula at kcl.ac.uk Mon Apr 2 04:56:07 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 02 Apr 2007 09:56:07 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460E8F58.6090605@computing-services.oxford.ac.uk> Message-ID: <4610C527.6050005@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 02 Apr 2007 09:56:07 +0100
> I did a bit of quick reformatting of Arianna's version to make it easier
> to edit in emacs, and then checked it in.
I am sorry for a likely dull question: but what does "checked in" mean
here? I can't see my changed added to the Source and not even online.
> The main thing that worries me about this chapter is that it really
> doesn't give RelaxNG and DTD language equal time.
Indeed, even if I didn't give weight to my comments, I think this is
probably the only serious editorial issue of this chapter.
> If it just used DTD
> language as a vehicle to explain basic XML concepts that would be OK,
> but it goes into a lot more detail than necessary for that job. So I
> can't decide whether the best course is to add a comparable amount of
> detail about RELAXNG, or cut the chapter down drastically. Either way
> would require quite a lot of editorial time.
If cutting would be quicker, for the sake of a realistic roadmap, I
would say that taking out the additional details on DTDs would be good
enough for now. But if you say that adding information on RelaxNG may be
as time consuming may be it is worth going this way instead, unless the
editors think there is a better place than the Gentle introduction where
details on how to write a schema could be included.
Arianna
Lou Burnard wrote:
> I did a bit of quick reformatting of Arianna's version to make it easier
> to edit in emacs, and then checked it in.
>
> Her comments on the WIKI are very helpful too, but I haven't done
> anything about most of them yet.
>
> The main thing that worries me about this chapter is that it really
> doesn't give RelaxNG and DTD language equal time. If it just used DTD
> language as a vehicle to explain basic XML concepts that would be OK,
> but it goes into a lot more detail than necessary for that job. So I
> can't decide whether the best course is to add a comparable amount of
> detail about RELAXNG, or cut the chapter down drastically. Either way
> would require quite a lot of editorial time.
>
> The goal of the original was to explain enough of SGML for the user of
> the TEI to understand how the DTDs worked, and I think that's probably
> still a good goal. I'm just not sure that we have time to do the job
> equally well now that the the technical
> basis for the Guidelines has changed so much.
>
>
> Arianna Ciula wrote:
>> I sent the XML to Lou.
>> There shouldn't be anything controversial in my changes: some evident
>> mistakes/omissions in the prose or examples, some other minor things
>> related to what's called "Positioning" in the editorial guidelines and
>> so on.
>>
>> I have some suggestions for things to add to those guidelines, but
>> it's probably better to wait until I have done all the three chapters.
>>
>> > If you have a sourceforge account, send me the name and I
>> > will give you commit rights.
>> I don't think I do. I have downloaded all the repository to edit the
>> relevant XML file, but that doesn't require an account as far as I know.
>>
>> Sorry my comments on Trac are not styled...copied them quickly and
>> didn't realise I could edit them as Wiki style.
>>
>> Arianna
>>
>> Sebastian Rahtz wrote:
>>> Arianna Ciula wrote:
>>>> > (a) get the XML source out of the subversion repository (see James's
>>>> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml);
>>>> > improve the text and either put the results back in the Council's
>>>> branch
>>>> > of the Subversion repository, or just email it to an editor.
>>>>
>>>> I don't have access to commit stuff to subversion. Should I just
>>>> send the revised SG chapter to you Lou?
>>>>
>>> If you have a sourceforge account, send me the name and I
>>> will give you commit rights. otherwise send XML to me
>>> or Lou or Syd to check in.
>>>
>>> if your changes are controversial, they could go
>>> in Council branch. are they?
>>>
>>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 04:56:39 EDT
From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Apr 2 04:24:49 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 02 Apr 2007 17:24:49 +0900 Subject: [tei-council] Can't find my easter egg! Message-ID: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Mon, 02 Apr 2007 17:24:49 +0900
I was assigned three easter eggs, one of which I can't find!
#103: TE: Terminological Databases:
The file is at SF, but it says only:


This chapter has been temporarily removed, pending a complete
revision. The work described here in earlier versions of the
Guidelines has since been superceded by a number of related and
emerging ISO standards, in particular ISO 12200: 1999 Computer <br /> applications in Terminology -- Machine-readable terminology interchange <br /> format (MARTIF) -- negotiated interchange and more recently ISO
16642: 2003 Computer applications in terminology - <br /> Terminological Markup Framework, which defines a familly of
formats to be used in combination with descriptors provided by ISO CD
12620:1999 Computer applications in terminology - Data <br /> categories (under revision). The revised chapter will specify
a core terminological model, conformant with ISO 16642


So, what is the plan for this in P5 1.0?
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 05:20:56 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 05:23:09 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 10:23:09 +0100 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4610CB7D.1060604@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 10:23:09 +0100
Christian Wittern wrote:
> I was assigned three easter eggs, one of which I can't find!
> #103: TE: Terminological Databases:
>
> The file is at SF, but it says only:
>
>


> This chapter has been temporarily removed, pending a complete
> revision. The work described here in earlier versions of the
> Guidelines has since been superceded by a number of related and
> emerging ISO standards, in particular ISO 12200: 1999 Computer </em><br /> <em class="quotelev1">> applications in Terminology -- Machine-readable terminology interchange </em><br /> <em class="quotelev1">> format (MARTIF) -- negotiated interchange and more recently ISO
> 16642: 2003 Computer applications in terminology - </em><br /> <em class="quotelev1">> Terminological Markup Framework, which defines a familly of
> formats to be used in combination with descriptors provided by ISO CD
> 12620:1999 Computer applications in terminology - Data </em><br /> <em class="quotelev1">> categories (under revision). The revised chapter will specify
> a core terminological model, conformant with ISO 16642
>


> So, what is the plan for this in P5 1.0?
>
> Christian
>
>
Well, we were rather hoping that you, as reviewer, might come up with an
answer to that question!
I dont know why it was assigned to you rather than Laurent though.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 05:23:13 EDT
From laurent.romary at loria.fr Mon Apr 2 05:27:03 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 2 Apr 2007 11:27:03 +0200 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610CB7D.1060604@computing-services.oxford.ac.uk> Message-ID: <4EC3B16F-2948-4561-9790-417EEEBA9DED@loria.fr>
From: Laurent Romary
Date: Mon, 2 Apr 2007 11:27:03 +0200
The answer is obviously no, but as we are currently establishing a
working plan with our colleagues from Lisa to synchronise with TBX,
we can plan it for a 1.x release.
Best,
Laurent
Le 2 avr. 07 ? 11:23, Lou Burnard a ?crit :
> Christian Wittern wrote:
>> I was assigned three easter eggs, one of which I can't find!
>> #103: TE: Terminological Databases:
>>
>> The file is at SF, but it says only:
>>
>>


>> This chapter has been temporarily removed, pending a complete
>> revision. The work described here in earlier versions of the
>> Guidelines has since been superceded by a number of related and
>> emerging ISO standards, in particular ISO 12200: 1999 Computer </em><br /> <em class="quotelev2">>> applications in Terminology ? Machine-readable terminology </em><br /> <em class="quotelev2">>> interchange </em><br /> <em class="quotelev2">>> format (MARTIF) ? negotiated interchange and more recently
>> ISO
>> 16642: 2003 Computer applications in terminology - </em><br /> <em class="quotelev2">>> Terminological Markup Framework, which defines a familly of
>> formats to be used in combination with descriptors provided by ISO CD
>> 12620:1999 Computer applications in terminology - Data </em><br /> <em class="quotelev2">>> categories (under revision). The revised chapter will specify
>> a core terminological model, conformant with ISO 16642
>>


>> So, what is the plan for this in P5 1.0?
>>
>> Christian
>>
>>
> Well, we were rather hoping that you, as reviewer, might come up
> with an
> answer to that question!
>
> I dont know why it was assigned to you rather than Laurent though.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 05:28:33 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 05:49:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 10:49:27 +0100 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4610D1A7.5020702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 10:49:27 +0100
Christian Wittern wrote:
> I was assigned three easter eggs, one of which I can't find!
> #103: TE: Terminological Databases:
>
> The file is at SF, but it says only:
>
>


> This chapter has been temporarily removed,
you got lucky. one of your eggs needs no eating
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 05:49:32 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 14:25:50 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 19:25:50 +0100 Subject: [tei-council] Conformance draft: namespace purity Message-ID: <46114AAE.1030100@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 19:25:50 +0100
Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have all
expressed support for James's proposal that (inter alia) conformance in
a TEI document implies that the TEI namespace remains unpolluted by
user-defined elements.
Does any of those who have remained silent on the topic wish to speak up
before we move on to the next drafting phase of this document, or can I
assume that the argument in favour of TEI purity is carried? Re-reading
the thread again, there does seem to be a strong consensus, but I am
also aware that not everyone is sure about how far this extends.
Personally, I would like to see a bit more text at the start of this
chapter explaining what conformance is for and what it means. This ought
to explain the distinction between formal validation (against a specific
schema) and usage of a namespace, and what each buys you in terms of
interoperability. It should make clear the reasoning behind insisting
that elements which are not defined by the TEI (i.e. not in the
Guidelines) cannot be in the TEI namespace. And of course it should make
clear what this means in practice for TEI-schema-developers.
I have a couple of other points about the draft, which I will make in
separate notes.


_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 14:25:54 EDT

From Syd_Bauman at Brown.edu Mon Apr 2 15:35:54 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 15:35:54 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46114AAE.1030100@computing-services.oxford.ac.uk> Message-ID: <17937.23322.362024.862804@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 2 Apr 2007 15:35:54 -0400
> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have
> all expressed support for James's proposal that (inter alia)
> conformance in a TEI document implies that the TEI namespace
> remains unpolluted by user-defined elements.
I had thought that perhaps James (and someone else?) now believed
that namespace-purity be in the realm of the definition of "TEI
Interchange Format", rather than of "TEI Conformance". I certainly
do.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 15:35:58 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 15:57:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 20:57:56 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.23322.362024.862804@emt.wwp.brown.edu> Message-ID: <46116044.2040709@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 20:57:56 +0100
That was certainly a minority view which has been expressed. And
certainly the material on the interchange format (formerly IN, now 24.2)
is in need of substantial revision. Maybe a good way forward would be to
see how far we can get with that first? Certainly the two are closely
related!

Syd Bauman wrote:
>> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have
>> all expressed support for James's proposal that (inter alia)
>> conformance in a TEI document implies that the TEI namespace
>> remains unpolluted by user-defined elements.
>>
>
> I had thought that perhaps James (and someone else?) now believed
> that namespace-purity be in the realm of the definition of "TEI
> Interchange Format", rather than of "TEI Conformance". I certainly
> do.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 15:58:01 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:14:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:14:36 +0100 Subject: [tei-council] outstanding SF requests Message-ID: <4611642C.3010508@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 21:14:36 +0100
Looking at SF, I see 3 tickets still open under feature requests
1. pointer to schema in header. I have closed this, and relegated it
to 1.1. My sense of the discussion on here and on the RELAXNG list is
that there is insufficient consensus to reasonably proceed at this stage.
2. a header element to hold application data. My sense is that there
is enough genuine interest in this that
we must discuss a proposal in Berlin. I have closed the SF ticket and
created a new one in trac for it.
3. 1019594 Manuscript encoding
.
Lou, can you polish that one off in some way?
There are, delightfully, no open bug requests in Sourceforge.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:14:47 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:22:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:22:45 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116044.2040709@computing-services.oxford.ac.uk> Message-ID: <46116615.3080101@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 21:22:45 +0100
Regardless of the letter of the law, we can influence a good many TEI
customizers by what Roma does. Is it the Feeling Of The Meeting
that I should change web-Roma to make new elements
be by default in a non-TEI namespace?
My suggestion would be
to put them in http://www.tei-c.org/ns/$NAME, where $NAME
is the name given to the ODD, which dictates the name of the
output schema file. I know that's not ideal, so if you have a
better suggestion, let me know.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:22:50 EDT
From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:27:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:27:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116044.2040709@computing-services.oxford.ac.uk> Message-ID: <46116735.3090806@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 02 Apr 2007 21:27:33 +0100
While I think that Namespace Purity should be a requirement for any form of
Interchange Format, I'm am not yet unconvinced that it should not be a
requirement for Conformance as well. I.e. if we are going to do namespaces, we
owe it to our users and place as a standard to do so properly. I do agree that
including more discussion on the benefits of namespaces, their relationship to
conformance and schemas, will benefit the Conformance chapter section (since it
is no longer a chapter by itself). I had not included such because I was not
sure that the council would agree to the principle of TEI Namespace purity. I
think there should be more discussion, in the Non-Conformant section, on those
schemas which otherwise would be Conformant, but simply lack the namespace
differentiation required by Conformance. I don't think we should view such
documents as *bad* in any way, simply not Conformant nor in Interchange Format.
i.e., I see Syd's point, but am not convinced that we should back down from
Namespace Purity.
I have not yet done any of the changes or corrections suggested to me (I had
timetabled it for starting at the end of this week), and am happy for Lou to add
any of his changes in the meantime.
-James
Lou Burnard wrote:
> That was certainly a minority view which has been expressed. And
> certainly the material on the interchange format (formerly IN, now 24.2)
> is in need of substantial revision. Maybe a good way forward would be to
> see how far we can get with that first? Certainly the two are closely
> related!
>
>
> Syd Bauman wrote:
>>> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have
>>> all expressed support for James's proposal that (inter alia)
>>> conformance in a TEI document implies that the TEI namespace
>>> remains unpolluted by user-defined elements.
>>>
>>
>> I had thought that perhaps James (and someone else?) now believed
>> that namespace-purity be in the realm of the definition of "TEI
>> Interchange Format", rather than of "TEI Conformance". I certainly
>> do.
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:27:41 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:31:26 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:31:26 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116615.3080101@oucs.ox.ac.uk> Message-ID: <4611681E.3040604@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 02 Apr 2007 21:31:26 +0100
Sebastian Rahtz wrote:
> Regardless of the letter of the law, we can influence a good many TEI
> customizers by what Roma does. Is it the Feeling Of The Meeting
> that I should change web-Roma to make new elements
> be by default in a non-TEI namespace?
>
> My suggestion would be
> to put them in http://www.tei-c.org/ns/$NAME, where $NAME
> is the name given to the ODD, which dictates the name of the
> output schema file. I know that's not ideal, so if you have a
> better suggestion, let me know.
I believe when I suggested this earlier a number of people argued against it
because having it have the appearance of being part of the TEI NS URI might
imply approval or condoning of these changes. I can see how some would abuse
this, or how it might be confusing.
Maybe something like http://www.ProjectName.info/ns/$VersionNumber ?
Not sure.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:31:30 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:37:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:37:58 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4611681E.3040604@computing-services.oxford.ac.uk> Message-ID: <461169A6.9080707@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 21:37:58 +0100
James Cummings wrote:
>
> I believe when I suggested this earlier a number of people argued
> against it because having it have the appearance of being part of the
> TEI NS URI might imply approval or condoning of these changes.
I can't say I buy that. By using the TEI NS URI, we are saying that these
are intended to be used with the TEI, but are not the TEI. But I don't mind
if there is an alternative algorithm.
> I can see how some would abuse this, or how it might be confusing.
>
> Maybe something like http://www.ProjectName.info/ns/$VersionNumber ?
where does $VersionNumber come from?
the problem with http://www.ProjectName.info/ns is that people have
a minimal expectation of namespaces being human readable
(for good or bad). If I had a "ProjectName" to hand, I could use it,
I agree.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:38:03 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 16:43:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 21:43:08 +0100 Subject: [tei-council] conformance draft In-Reply-To: <460428B3.6050304@oucs.ox.ac.uk> Message-ID: <46116ADC.2020106@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 21:43:08 +0100
Sebastian said
> er, um. yes. I meant to say I am relieved we are
> discussing just this in some detail, as it implies
> the rest is generally accepted.
>
Not so fast Red Baron...
1. The definition of "recommended practice" used to have a third point:
"all textual features which the guidelines recommend be captured are in
fact encoded. "
which James removed presumably because he could think of no case where
the Guidelines actually makes recommendations about the level of
encoding to be applied (i.e. where it suggests that you really ought to
mark up paragraphs, say, or lines in verse)
2. The original draft distinguishes two formats for a conformant document:
"A document is /TEI-conformant/ if it is either in /TEI local processing
format/ or in /TEI interchange format/. A full description of the
document should specify which format it is in."
The new draft does not make this distinction up front, although it is
discussed later on at 1.3.3.2. Was this a deliberate decision or an
oversight? Should we not make the distinction earlier? I can see that
the case for a third possible format originally discussed ("TEI packed
interchange format") is hard to maintain with the availability of XML,
but maybe we ought to preserve the other two?
3. The discussion of a "TEI derived schema" (1.2.2 in the current draft)
talks about ODD-derived schemas and about exemplars, but does not
mention the feasibility of constructing a TEI schema by combining either
DTD fragments or RelaxNG fragments. Are we specifically outlawing that
approach, or are we just passing over it in silence? I don't think
either approach will win us any friends.
4. The suggestion that a sourceDesc element is no longer required seems
unwise to me. If a document is "born digital" the fact should be
stated, and the sourceDesc is the place to do it.
5. 1.2.5 introduces a new term "TEI compliant" but does not seem to
define it anywhere: is it meant to be synonymous with "TEI conformant"?
6. As others have suggested, the list of exemplars should probably move
somewhere else. Except that the definition of tei_all is important,
since it's used in the following section to define varieties of
conformant schemas.
7. I am a bit unclear about the purpose of a "TEI Supported Extension
Schema". Can anyone suggest one? what does "is supported (to some
degree) by the TEI" mean?
8. The last bullet point in the list at the start of 1.3.3 (requiring
the existence of an ODD to document the schema used by a non conformant
customization) while I agree with it in principle is (a) not a property
of a document (b) somewhat at variance with my point 3 above.
9. I don't like section 1.7 much: it makes me feel uneasy. We are not in
a position to tell funding bodies what they should or shouldn't think,
and even if we were it shouldn't be a topic for this chapter. We ought
to be clear first about what *we* mean by TEI conformance, and although
I think this discussion is clarifying that quite a lot, we ain't there
yet. Issues of "superior quality" and "greater academic scrutiny" surely
relate to matters which are out of scope here (see for example my point
1 above)
Let me repeat that I think this draft is definitely going in the right
direction, despite these somewhat picky comments! I think it's really
important to get a good version of this chapter into draft 1.0 so I hope
we can focus on that for a while..


_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 16:43:17 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:44:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:44:27 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461169A6.9080707@oucs.ox.ac.uk> Message-ID: <46116B2B.6030609@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 02 Apr 2007 21:44:27 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
>>
>> I believe when I suggested this earlier a number of people argued
>> against it because having it have the appearance of being part of the
>> TEI NS URI might imply approval or condoning of these changes.
> I can't say I buy that. By using the TEI NS URI, we are saying that these
> are intended to be used with the TEI, but are not the TEI. But I don't
> mind if there is an alternative algorithm.
I could be convinced by that argument. It also means that
http://www.tei-c.org/ns/$NAME is under our control and we can put a page at
http://www.tei-c.org/ns/* (that isn't 1.0) saying that it is a user-defined
namespace and the TEI is not responsible for it.
>> Maybe something like http://www.ProjectName.info/ns/$VersionNumber ?
> where does $VersionNumber come from?
Was assuming they'd add it just as they add ProjectName (as the name of the file)
-James
>
> the problem with http://www.ProjectName.info/ns is that people have
> a minimal expectation of namespaces being human readable
> (for good or bad). If I had a "ProjectName" to hand, I could use it,
> I agree.
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:44:32 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:49:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:49:47 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116B2B.6030609@computing-services.oxford.ac.uk> Message-ID: <46116C6B.7060000@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 21:49:47 +0100
James Cummings wrote:
>
> Was assuming they'd add it just as they add ProjectName (as the name
> of the file)
>
nowhere to store it, tho. I need a place in an ODD file to record
anything which should be restored next time.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 16:49:56 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 16:50:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 21:50:42 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116B2B.6030609@computing-services.oxford.ac.uk> Message-ID: <46116CA2.6090004@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 21:50:42 +0100
James Cummings wrote:
> Sebastian Rahtz wrote:
>> James Cummings wrote:
>>>
>>> I believe when I suggested this earlier a number of people argued
>>> against it because having it have the appearance of being part of
>>> the TEI NS URI might imply approval or condoning of these changes.
>> I can't say I buy that. By using the TEI NS URI, we are saying that
>> these
>> are intended to be used with the TEI, but are not the TEI. But I
>> don't mind if there is an alternative algorithm.
>
> I could be convinced by that argument. It also means that
> http://www.tei-c.org/ns/$NAME is under our control and we can put a
> page at
> http://www.tei-c.org/ns/* (that isn't 1.0) saying that it is a
> user-defined namespace and the TEI is not responsible for it.
>
I can probably be persuaded to like this eventually, but it does rather
raise the spectre of "TEI approved extensions" vs "TEI not approved
extensions". And how on earth can we guarantee that $NAME is going to be
unique? In which case all the arguments about namespace pollution
reappear, though at a higher level.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 16:50:45 EDT
From Syd_Bauman at Brown.edu Mon Apr 2 16:53:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 16:53:14 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461169A6.9080707@oucs.ox.ac.uk> Message-ID: <17937.27962.620536.39642@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 2 Apr 2007 16:53:14 -0400
If we're going to do this (and I'm still agin it), my instinct is
that webRoma should have a text field for the user to fill in. If you
want to put in a default, why not put in a URI that points to the IP
address of the user? Thus a default value might be something like
http://128.148.123.321/TEIP5Customization/$ns
where $ns is the value of the Filename or the Prefix pattern field.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 16:53:19 EDT
From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 17:00:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 22:00:52 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116ADC.2020106@computing-services.oxford.ac.uk> Message-ID: <46116F04.8030100@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 02 Apr 2007 22:00:52 +0100
Lou Burnard wrote:
> 1. The definition of "recommended practice" used to have a third point:
>
> "all textual features which the guidelines recommend be captured are in
> fact encoded. "
> which James removed presumably because he could think of no case where
> the Guidelines actually makes recommendations about the level of
> encoding to be applied (i.e. where it suggests that you really ought to
> mark up paragraphs, say, or lines in verse)
To be honest, I think Sebastian commented that one out, not me, but I agreed
with him that I couldn't think of a place where the TEI Guidelines (strongly at
least) recommend to what level encoding should be applied. I.e. if I'm doing a
poem it is fine if I do rather than , never mind that I'm not marking
up .
> 2. The original draft distinguishes two formats for a conformant document:
> "A document is /TEI-conformant/ if it is either in /TEI local processing
> format/ or in /TEI interchange format/. A full description of the
> document should specify which format it is in."
>
> The new draft does not make this distinction up front, although it is
> discussed later on at 1.3.3.2. Was this a deliberate decision or an
> oversight? Should we not make the distinction earlier? I can see that
> the case for a third possible format originally discussed ("TEI packed
> interchange format") is hard to maintain with the availability of XML,
> but maybe we ought to preserve the other two?
It was deliberate. My TEI is in TEI Interchange Format and is TEI Local
Processing Format. I thought we should keep the distinction to make those who
are not-fully-Conformant because of local processing needs, realise that this is
an acceptable thing to do even if not strictly Conformant.
> 3. The discussion of a "TEI derived schema" (1.2.2 in the current draft)
> talks about ODD-derived schemas and about exemplars, but does not
> mention the feasibility of constructing a TEI schema by combining either
> DTD fragments or RelaxNG fragments. Are we specifically outlawing that
> approach, or are we just passing over it in silence? I don't think
> either approach will win us any friends.
I was wondering who would raise that first -- that is before Wendell sees it --
I was intentionally being hard-line dictatorial and stating that TEI Conformance
requires there to have been an ODD at some point to generate the schema. I think
we should outlaw that approach for TEI Conformance. I'm happy for people to do
it, but think we should have a No-ODD, No-Conformance, approach. I don't feel
that people who will be doing that will be as concerned about Conformance in any
case.
> 4. The suggestion that a sourceDesc element is no longer required seems
> unwise to me. If a document is "born digital" the fact should be
> stated, and the sourceDesc is the place to do it.
Yes, and that is the suggestion made. I just wondered about making it a
requirement for *any* TEI document (which is what the old description did).
> 5. 1.2.5 introduces a new term "TEI compliant" but does not seem to
> define it anywhere: is it meant to be synonymous with "TEI conformant"?
Typo.
> 6. As others have suggested, the list of exemplars should probably move
> somewhere else. Except that the definition of tei_all is important,
> since it's used in the following section to define varieties of
> conformant schemas.
Since Modification is now a section of the Using TEI chapter, as long as that
goes before the Conformance section, then that would seem an appropriate place
to discuss these in depth.
> 7. I am a bit unclear about the purpose of a "TEI Supported Extension
> Schema". Can anyone suggest one? what does "is supported (to some
> degree) by the TEI" mean?
I.e. TEI with XInclude, TEI with SVG in graphic, etc. Customisations that are
not pure TEI which the TEI produces.
> 8. The last bullet point in the list at the start of 1.3.3 (requiring
> the existence of an ODD to document the schema used by a non conformant
> customization) while I agree with it in principle is (a) not a property
> of a document (b) somewhat at variance with my point 3 above.
This list is meant to be identical as the one at 1.2.

> 9. I don't like section 1.7 much: it makes me feel uneasy. We are not in
> a position to tell funding bodies what they should or shouldn't think,
> and even if we were it shouldn't be a topic for this chapter. We ought
> to be clear first about what *we* mean by TEI conformance, and although
> I think this discussion is clarifying that quite a lot, we ain't there
> yet. Issues of "superior quality" and "greater academic scrutiny" surely
> relate to matters which are out of scope here (see for example my point
> 1 above)
Agreed. But I still feel it is important to stress (to them and others) that
Conformance != Quality.
>
> Let me repeat that I think this draft is definitely going in the right
> direction, despite these somewhat picky comments! I think it's really
> important to get a good version of this chapter into draft 1.0 so I hope
> we can focus on that for a while..
I think all these comments are the kind I was hoping to get.

-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 17:00:57 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 17:04:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 22:04:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.27962.620536.39642@emt.wwp.brown.edu> Message-ID: <46116FE1.5010201@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 02 Apr 2007 22:04:33 +0100
Syd Bauman wrote:
> If we're going to do this (and I'm still agin it), my instinct is
> that webRoma should have a text field for the user to fill in. If you
> want to put in a default, why not put in a URI that points to the IP
> address of the user? Thus a default value might be something like
>
> http://128.148.123.321/TEIP5Customization/$ns
>
> where $ns is the value of the Filename or the Prefix pattern field.
That would certainly make namespace pollution much less likely to happen.
-James

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 17:04:37 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:48:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:48:18 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.27962.620536.39642@emt.wwp.brown.edu> Message-ID: <46117A22.3050701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 22:48:18 +0100
Syd Bauman wrote:
> If we're going to do this (and I'm still agin it), my instinct is
> that webRoma should have a text field for the user to fill in. If you
> want to put in a default, why not put in a URI that points to the IP
> address of the user? Thus a default value might be something like
>
> http://128.148.123.321/TEIP5Customization/$ns
>
> where $ns is the value of the Filename or the Prefix pattern field.
>
>
Gracious. My IP address from home changes every day (assigned by
by ISP).
More importantly, I need to store it somewhere....
I don't want to overload the meaning of Prefix, as that
is used for something else
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 17:48:23 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 17:49:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 22:49:56 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116F04.8030100@computing-services.oxford.ac.uk> Message-ID: <46117A84.8010704@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 22:49:56 +0100
James Cummings wrote:
>
>> 3. The discussion of a "TEI derived schema" (1.2.2 in the current
>> draft) talks about ODD-derived schemas and about exemplars, but does
>> not mention the feasibility of constructing a TEI schema by combining
>> either DTD fragments or RelaxNG fragments. Are we specifically
>> outlawing that approach, or are we just passing over it in silence? I
>> don't think either approach will win us any friends.
>
> I was wondering who would raise that first -- that is before Wendell
> sees it -- I was intentionally being hard-line dictatorial and stating
> that TEI Conformance requires there to have been an ODD at some point
> to generate the schema. I think we should outlaw that approach for TEI
> Conformance. I'm happy for people to do it, but think we should have
> a No-ODD, No-Conformance, approach. I don't feel that people who will
> be doing that will be as concerned about Conformance in any case.
OK, well just supposing for the moment that we don't mind upsetting
Wendell too much, how do we feel about the current text of MD which I am
currently hacking at?
I am now thinking that the sensible thing would be to simply axe all the
discussion of parameter entities etc. and simply say how to do the job
with an ODD. Do we agree?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 17:49:59 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:50:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:50:20 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116CA2.6090004@computing-services.oxford.ac.uk> Message-ID: <46117A9C.9030100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 22:50:20 +0100
Lou Burnard wrote:
>
> I can probably be persuaded to like this eventually, but it does
> rather raise the spectre of "TEI approved extensions" vs "TEI not
> approved extensions". And how on earth can we guarantee that $NAME is
> going to be unique? In which case all the arguments about namespace
> pollution reappear, though at a higher level.
>
Not our problem, though. We can't get bogged down in registration of
namespaces
or resolving conflicts. Whatever scheme we choose, we can't guarentee
uniqueness.
I am only talking about a _suggestion_ for the namespace, anyone with
more than
two brains will know to change it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 17:50:24 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 17:51:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 22:51:30 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117A22.3050701@oucs.ox.ac.uk> Message-ID: <46117AE2.1060804@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 22:51:30 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> If we're going to do this (and I'm still agin it), my instinct is
>> that webRoma should have a text field for the user to fill in. If you
>> want to put in a default, why not put in a URI that points to the IP
>> address of the user? Thus a default value might be something like
>>
>> http://128.148.123.321/TEIP5Customization/$ns
>>
>> where $ns is the value of the Filename or the Prefix pattern field.
>>
>>
> Gracious. My IP address from home changes every day (assigned by
> by ISP).
>
> More importantly, I need to store it somewhere....
>
> I don't want to overload the meaning of Prefix, as that
> is used for something else
>
Then it looks as if you must insist on the poor benighted customizer
supplying their own URI for the customization.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 17:51:34 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:58:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:58:21 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117AE2.1060804@computing-services.oxford.ac.uk> Message-ID: <46117C7D.9030704@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 22:58:21 +0100
Lou Burnard wrote:
>
> Then it looks as if you must insist on the poor benighted customizer
> supplying their own URI for the customization.
>
which may still be the same as the one you choose.
I need to see how to do this in Roma, forcing you
to fill in a field.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 17:58:25 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:03:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:03:12 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46117A84.8010704@computing-services.oxford.ac.uk> Message-ID: <46117DA0.3070207@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 23:03:12 +0100
Lou Burnard wrote:
>
> I am now thinking that the sensible thing would be to simply axe all
> the discussion of parameter entities etc. and simply say how to do the
> job with an ODD. Do we agree?
if we don't document the parameter entities, we might as well stop producing
them, no? and we might as well stop distributing the DTD modules?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:03:16 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:08:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:08:03 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116ADC.2020106@computing-services.oxford.ac.uk> Message-ID: <46117EC3.10307@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 23:08:03 +0100
Lou Burnard wrote:
>
> 1. The definition of "recommended practice" used to have a third point:
>
> "all textual features which the guidelines recommend be captured are
> in fact encoded. "
> which James removed presumably because he could think of no case where
> the Guidelines actually makes recommendations about the level of
> encoding to be applied (i.e. where it suggests that you really ought
> to mark up paragraphs, say, or lines in verse)
I confess it all. It was me what removed that sentence. for the reason
you suggest. It just
begs the question "yeah, so what are they, then?".
>
> 4. The suggestion that a sourceDesc element is no longer required
> seems unwise to me. If a document is "born digital" the fact should
> be stated, and the sourceDesc is the place to do it.
if a document has no , then its born digital. QED. Its just
silly in practice to
force me to _say_ so on every document I write, especially since I
always leave it blank....
(apropos of which, I can't remember if James avoided this trap? does he
say that
the mandatory elenents cannot be empty?
>
> 9. I don't like section 1.7 much: it makes me feel uneasy. We are not
> in a position to tell funding bodies what they should or shouldn't
> think, and even if we were it shouldn't be a topic for this chapter.
> We ought to be clear first about what *we* mean by TEI conformance,
> and although I think this discussion is clarifying that quite a lot,
> we ain't there yet. Issues of "superior quality" and "greater academic
> scrutiny" surely relate to matters which are out of scope here (see
> for example my point 1 above)
it could be said that this section is a bit patronizing. I didn't mind
it when I read it,
but if you object, it doesnt damage the chapter to remove it.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:08:13 EDT

From daniel.odonnell at uleth.ca Mon Apr 2 18:25:10 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 16:25:10 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117AE2.1060804@computing-services.oxford.ac.uk> Message-ID: <1175552710.6077.5.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 02 Apr 2007 16:25:10 -0600
I'm not convinced by the counter arguments to Sebastian's original
namespace suggestion. What if instead of ns/ we used user_defined/ or
something to indicate that it was not TEI approved?
Not knowing the capabilities of Roma's internals, I don't know if this
following is possible, but I'd prefer two options:
1) tei.org//user_defined/$name/
2) $project.$tld/$somethingelse
I.e. it seems to me to be useful to supply a default ns for people but
also to allow ones that already have something in mind the option of
including that.
On Mon, 2007-04-02 at 22:51 +0100, Lou Burnard wrote:
> Sebastian Rahtz wrote:
> > Syd Bauman wrote:
> >> If we're going to do this (and I'm still agin it), my instinct is
> >> that webRoma should have a text field for the user to fill in. If you
> >> want to put in a default, why not put in a URI that points to the IP
> >> address of the user? Thus a default value might be something like
> >>
> >> http://128.148.123.321/TEIP5Customization/$ns
> >>
> >> where $ns is the value of the Filename or the Prefix pattern field.
> >>
> >>
> > Gracious. My IP address from home changes every day (assigned by
> > by ISP).
> >
> > More importantly, I need to store it somewhere....
> >
> > I don't want to overload the meaning of Prefix, as that
> > is used for something else
> >
>
> Then it looks as if you must insist on the poor benighted customizer
> supplying their own URI for the customization.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:25:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:30:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:30:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175552710.6077.5.camel@localhost> Message-ID: <461183F0.1070609@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 23:30:08 +0100
Daniel O'Donnell wrote:
> 1) tei.org//user_defined/$name/
> 2) $project.$tld/$somethingelse
>
not sure what "$tld" is?
> I.e. it seems to me to be useful to supply a default ns for people but
> also to allow ones that already have something in mind the option of
> including that.
>
it would always be a suggestion, indeed. just a matter
of whether a field is filled in with a default or not when you come to
"add a new element" page.
I would strongly suggest that people use something
based on their project URL if they have one.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:30:13 EDT
From daniel.odonnell at uleth.ca Mon Apr 2 18:31:06 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 16:31:06 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461183F0.1070609@oucs.ox.ac.uk> Message-ID: <1175553066.6077.16.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 02 Apr 2007 16:31:06 -0600
$tld = $tld = .com|.org|.co.uk, etc.
On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote:
> Daniel O'Donnell wrote:
> > 1) tei.org//user_defined/$name/
> > 2) $project.$tld/$somethingelse
> >
> not sure what "$tld" is?
> > I.e. it seems to me to be useful to supply a default ns for people but
> > also to allow ones that already have something in mind the option of
> > including that.
> >
>
> it would always be a suggestion, indeed. just a matter
> of whether a field is filled in with a default or not when you come to
> "add a new element" page.
>
> I would strongly suggest that people use something
> based on their project URL if they have one.
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:31:10 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 18:36:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 23:36:43 +0100 Subject: [tei-council] rules about renaming Message-ID: <4611857B.3060506@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 02 Apr 2007 23:36:43 +0100
If I want to rename a TEI element, I am obviously required not to use as
the new name an existing name in the schema. Slightly less obviously, I
cannot use as the new name any name from any module I might want to
include in some other schema for the same document.
I cannot, for example, rename

as if I am already using or plan
to use .
But what about names which happen to look the same in different languages?
For example, suppose the French for "p" were "q"... would the presence
of the xml:lang attribute here be enough to make the following valid:

q

and if not, does this mean that all identifiers share the same name space?
I rayther suspect they have to....

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 18:36:47 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:42:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:42:52 +0100 Subject: [tei-council] rules about renaming In-Reply-To: <4611857B.3060506@computing-services.oxford.ac.uk> Message-ID: <461186EC.5050004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 02 Apr 2007 23:42:52 +0100
Lou Burnard wrote:
> But what about names which happen to look the same in different
> languages?
>
> For example, suppose the French for "p" were "q"... would the presence
> of the xml:lang attribute here be enough to make the following valid:
>
>
> q
>
>
> and if not, does this mean that all identifiers share the same name
> space?
>
the xml:lang makes no difference there, its just documentation.
am trying to think what the effect would be. have you tried it?
my brain is hurting following through the implications. I suspect
that in RELAXNG it might just work, in the sense of getting a valid
schema.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 18:42:57 EDT

From Syd_Bauman at Brown.edu Mon Apr 2 19:24:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 19:24:22 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117A22.3050701@oucs.ox.ac.uk> Message-ID: <17937.37030.473212.244366@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 2 Apr 2007 19:24:22 -0400
> Gracious. My IP address from home changes every day (assigned by by
> ISP).
Mine too. What difference does that make? Only reinforces the idea
that this is a silly default you might use for quick tests, but not a
good idea for you True Customization.

> More importantly, I need to store it somewhere....
I don't understand. Don't you need to store it no matter what it is?

> I don't want to overload the meaning of Prefix, as that is used for
> something else
As is the filename. Which may be different than the ident= of
. Seems to me to be a good idea to use one of 'em for the
default. As you've pointed out, this is only a default, not a
suggestion.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 19:24:26 EDT

From conal.tuohy at vuw.ac.nz Mon Apr 2 19:26:48 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 03 Apr 2007 11:26:48 +1200 Subject: [tei-council] rules about renaming In-Reply-To: <4611857B.3060506@computing-services.oxford.ac.uk> Message-ID: <1175556408.3766.104.camel@localhost>
From: Conal Tuohy
Date: Tue, 03 Apr 2007 11:26:48 +1200
On Mon, 2007-04-02 at 23:36 +0100, Lou Burnard wrote:
> If I want to rename a TEI element, I am obviously required not to use as
> the new name an existing name in the schema. Slightly less obviously, I
> cannot use as the new name any name from any module I might want to
> include in some other schema for the same document.
>
> I cannot, for example, rename

as if I am already using or plan
> to use .
>
> But what about names which happen to look the same in different languages?
>
> For example, suppose the French for "p" were "q"... would the presence
> of the xml:lang attribute here be enough to make the following valid:
>
>
> q
>
>
> and if not, does this mean that all identifiers share the same name space?
>
> I rayther suspect they have to....
I think you're right.
In my earlier response to the conformance draft I suggested that the
localised TEI schemas should have their own namespace URIs, too,
because, as you point out, sharing a common namespace across all natural
languages is, on the face of it, running a risk that names will collide.
My suggestion to mitigate this risk was that we publish distinct
namespace URIs for each language into which the TEI vocabulary is
translated, in addition to the existing one for the standard
English TEI:
http://www.tei-c.org/ns/1.0
I suggest that the namespace URI for every localised version should have
the same base URI as above, but also include a fragment identifier to
point to part of the page. So, for instance, the hypothetical French
TEI, in which means

, might have this namespace URI:
http://www.tei-c.org/ns/1.0#fr
If we did this we also ought to modify the HTML page at
http://www.tei-c.org/ns/1.0 to include an element with an id of "fr",
perhaps like so:


This document describes the namespaces of the Text Encoding
Initiative (TEI).


The namespace whose URI is "http://www.tei-c.org/P5/" identifies the
primary TEI vocabulary described in the href="http://www.tei-c.org/release/doc/tei-p5-doc/html/">TEI
Guidelines.


Localised versions


The primary TEI vocabulary is largely based on English, but it has
also been localised into other languages. Encoders who are more fluent
in one of these languages may wish to use one of these alternative
vocabularies.



  • fran??aise





These list items should, where possible, contain pointers to information
about the localised versions (e.g. to the relevant guidelines document,
ODDs, or whatever was the most appropriate.)
Con

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 19:27:45 EDT

From daniel.odonnell at uleth.ca Mon Apr 2 19:46:51 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 17:46:51 -0600 Subject: [tei-council] rules about renaming In-Reply-To: <1175556408.3766.104.camel@localhost> Message-ID: <1175557611.9157.0.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 02 Apr 2007 17:46:51 -0600
Ooh I like this. Fits in with the i18n.
On Tue, 2007-04-03 at 11:26 +1200, Conal Tuohy wrote:
> On Mon, 2007-04-02 at 23:36 +0100, Lou Burnard wrote:
> > If I want to rename a TEI element, I am obviously required not to use as
> > the new name an existing name in the schema. Slightly less obviously, I
> > cannot use as the new name any name from any module I might want to
> > include in some other schema for the same document.
> >
> > I cannot, for example, rename

as if I am already using or plan
> > to use .
> >
> > But what about names which happen to look the same in different languages?
> >
> > For example, suppose the French for "p" were "q"... would the presence
> > of the xml:lang attribute here be enough to make the following valid:
> >
> >
> > q
> >
> >
> > and if not, does this mean that all identifiers share the same name space?
> >
> > I rayther suspect they have to....
>
> I think you're right.
>
> In my earlier response to the conformance draft I suggested that the
> localised TEI schemas should have their own namespace URIs, too,
> because, as you point out, sharing a common namespace across all natural
> languages is, on the face of it, running a risk that names will collide.
>
> My suggestion to mitigate this risk was that we publish distinct
> namespace URIs for each language into which the TEI vocabulary is
> translated, in addition to the existing one for the standard
> English TEI:
>
> http://www.tei-c.org/ns/1.0
>
> I suggest that the namespace URI for every localised version should have
> the same base URI as above, but also include a fragment identifier to
> point to part of the page. So, for instance, the hypothetical French
> TEI, in which means

, might have this namespace URI:
>
> http://www.tei-c.org/ns/1.0#fr
>
> If we did this we also ought to modify the HTML page at
> http://www.tei-c.org/ns/1.0 to include an element with an id of "fr",
> perhaps like so:
>
>
>
>

This document describes the namespaces of the Text Encoding
> Initiative (TEI).


>

The namespace whose URI is "http://www.tei-c.org/P5/" identifies the
> primary TEI vocabulary described in the
> href="http://www.tei-c.org/release/doc/tei-p5-doc/html/">TEI
> Guidelines.


>
>

Localised versions


>

The primary TEI vocabulary is largely based on English, but it has
> also been localised into other languages. Encoders who are more fluent
> in one of these languages may wish to use one of these alternative
> vocabularies.


>

    >
  • fran??aise

    • >
    >

>
>
>
> These list items should, where possible, contain pointers to information
> about the localised versions (e.g. to the relevant guidelines document,
> ODDs, or whatever was the most appropriate.)
>
> Con
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Apr 02 2007 - 19:46:55 EDT
From conal.tuohy at vuw.ac.nz Mon Apr 2 19:49:34 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 03 Apr 2007 11:49:34 +1200 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461183F0.1070609@oucs.ox.ac.uk> Message-ID: <1175557774.3766.127.camel@localhost>
From: Conal Tuohy
Date: Tue, 03 Apr 2007 11:49:34 +1200
On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote:
> I would strongly suggest that people use something
> based on their project URL if they have one.
I agree.
The W3's architecture document "Architecture of the World Wide Web"
includes some relevant guidelines, including this one about "namespace
documents":
http://www.w3.org/TR/webarch/#namespace-document
> Good practice: Namespace documents
>
> The owner of an XML namespace name SHOULD make available material
> intended for people to read and material optimized for software agents
> in order to meet the needs of those who will use the namespace
> vocabulary.
Here "an XML namespace name" means the namespace URI itself, and
"namespace document" means a document you can retrieve from that URI.
The TEI namespace URI, for instance, identifies a document on the TEI
website which says that it's the TEI namespace, published by the
Council, that there's no plans for it to change, etc, and links to the
TEI guidelines themselves.
So I think if people are using ODD to make a custom schema in which they
add new elements, it is good practice for them to publish information
about those changes in a "namespace document". A good way is for their
namespace URI to be an http URL pointing to a location where they will
publish that information. e.g. If a project were to publish their ODD
file on their website, that ODD file could itself be a good namespace
document.
But I think this W3 guideline implies we should not suggest an http URI
which starts with "http://www.tei-c.org/ns/user-defined/" (or similar)
because that might imply that we would be maintaining a register of
customisations. The namespace URI should clearly belong to the person
making the customisation, not to the TEI Consortium.
However, if the project doesn't have a website, then it might prove a
barrier to provide a "namespace document". During the development phase
of a project, it might not be clear what namespace URI would be best, so
a temporary URI might be needed. In such cases, rather than use an HTTP
URI, they could use some other kind of URI, such as a "tag" URI, e.g.
"tag:conal.tuohy_at_gmail.com,2007:xmlns/my-customisation"
The syntax of a tag URI allows for people to mint one based on their own
email address, so the barrier to use is low.
Tag URI syntax:
http://www.taguri.org/07/draft-kindberg-tag-uri-07.html#SYNTAX
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 19:50:13 EDT
From Syd_Bauman at Brown.edu Mon Apr 2 23:08:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 23:08:57 -0400 Subject: [tei-council] conformance draft In-Reply-To: <46117DA0.3070207@oucs.ox.ac.uk> Message-ID: <17937.50505.542961.283268@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 2 Apr 2007 23:08:57 -0400
Apologies, I'm not entirely up-to-date on this thread, but ...
> I was intentionally being hard-line dictatorial and stating that
> TEI Conformance requires there to have been an ODD at some point to
> generate the schema.
I recall that Council expressed a pretty strong opinion on this at
the 2005 meeting in Paris, although I don't know if it was an
official vote or not. The overwhelming majority thought that ODD
should be the only way to go.

> I am now thinking that the sensible thing would be to simply axe
> all the discussion of parameter entities etc. and simply say how to
> do the job with an ODD. Do we agree?
I don't think any discussion of parameter entities is warranted.
*Maybe* instructions for stitching together a Relax NG schema. Maybe.

> if we don't document the parameter entities, we might as well stop
> producing them, no? and we might as well stop distributing the DTD
> modules?
Right. If you wanna use a DTD, the only one you get to use is either
a) the one generated from your ODD via roma, or
b) one you create from the Relax NG schema you stitched together, if
we go that route.
Furthermore, if you wanna use a DTD we should make it very clear and
abundantly explicit that you are not getting a lot of the validation
that you would get if you were using Relax NG.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Apr 02 2007 - 23:09:02 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Apr 2 21:53:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 03 Apr 2007 10:53:28 +0900 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.23322.362024.862804@emt.wwp.brown.edu> Message-ID: <4611B398.3000107@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 03 Apr 2007 10:53:28 +0900
Syd Bauman wrote:
>> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have
>> all expressed support for James's proposal that (inter alia)
>> conformance in a TEI document implies that the TEI namespace
>> remains unpolluted by user-defined elements.
I would like to register my strong support for the pure namespace in its
strict version, with different namespaces for translated vocabularies.
>
> I had thought that perhaps James (and someone else?) now believed
> that namespace-purity be in the realm of the definition of "TEI
> Interchange Format", rather than of "TEI Conformance". I certainly
> do.
To me, this would belong to TEI Conformance, not just interchange, but I
am willing to sit on the fence until the interchange is a bit more
panned out.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 00:54:08 EDT
From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 03:05:25 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 03 Apr 2007 16:05:25 +0900 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Tue, 03 Apr 2007 16:05:25 +0900
Syd Bauman wrote:
> Apologies, I'm not entirely up-to-date on this thread, but ...
>
>> I was intentionally being hard-line dictatorial and stating that
>> TEI Conformance requires there to have been an ODD at some point to
>> generate the schema.
>
> I recall that Council expressed a pretty strong opinion on this at
> the 2005 meeting in Paris, although I don't know if it was an
> official vote or not. The overwhelming majority thought that ODD
> should be the only way to go.
>
At least for conformant documents, that was my impression as well. And I
still think this is the way it should be.
>> I am now thinking that the sensible thing would be to simply axe
>> all the discussion of parameter entities etc. and simply say how to
>> do the job with an ODD. Do we agree?
>
> I don't think any discussion of parameter entities is warranted.
> *Maybe* instructions for stitching together a Relax NG schema. Maybe.
>
We should let go of both, IMHO. P5 is a radical break, part of the 21st
century and the future, and DTD are soo 90s.
>
>> if we don't document the parameter entities, we might as well stop
>> producing them, no? and we might as well stop distributing the DTD
>> modules?
>
> Right. If you wanna use a DTD, the only one you get to use is either
> a) the one generated from your ODD via roma, or
> b) one you create from the Relax NG schema you stitched together, if
> we go that route.
I don't think (b) needs to be mentioned somewhere. If we do it right,
most people (except Wendell) will not feel the need to hack the Schemas.
> Furthermore, if you wanna use a DTD we should make it very clear and
> abundantly explicit that you are not getting a lot of the validation
> that you would get if you were using Relax NG.
+1
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 03:54:35 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:01:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:01:25 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.37030.473212.244366@emt.wwp.brown.edu> Message-ID: <461209D5.7010100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 09:01:25 +0100
Syd Bauman wrote:
>> Gracious. My IP address from home changes every day (assigned by by
>> ISP).
>>
>
> Mine too. What difference does that make? Only reinforces the idea
> that this is a silly default you might use for quick tests, but not a
> good idea for you True Customization.
>
a default you would never use doesnt seem sensible.
I might as well leave blank, and make that an error
>
>> More importantly, I need to store it somewhere....
>>
>
> I don't understand. Don't you need to store it no matter what it is?
>
yes, but i do already store the Name (the @ident of the )
>
>
>> I don't want to overload the meaning of Prefix, as that is used for
>> something else
>>
>
> As is the filename. Which may be different than the ident= of
> . Seems to me to be a good idea to use one of 'em for the
> default. As you've pointed out, this is only a default, not a
> suggestion.
>
but the prefix is empty by default......
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 04:01:39 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:20:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:20:58 +0100 Subject: [tei-council] rules about renaming In-Reply-To: <1175556408.3766.104.camel@localhost> Message-ID: <46120E6A.5040106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 09:20:58 +0100
I see why a complete Frenchified TEI might have its own namespace.
But I would point out that the mechanism used to Frenchify the TEI
(ie ) is no different from that used to change

to
for readability. By this argument, any use of would mean you
should also change the namespace.
what if you find most of the TEI OK, but change a few common tags to French
names, to help your encoders?
I am willing to be convinced, but I don't really see how this would
all work in practice.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 04:21:02 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:27:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:27:39 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175557774.3766.127.camel@localhost> Message-ID: <46120FFB.8040909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 09:27:39 +0100
I am reluctant to force people to show an email address
of any kind, though its a nice idea.
I incline to making the box empty by default[1],
but compulsory, with some guidelines on good choices.
[1] and allowing for a way for them to create
elements in the empty namespace...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 04:27:46 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:32:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:32:43 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <4612112B.1060807@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 09:32:43 +0100
Syd Bauman wrote:
> Right. If you wanna use a DTD, the only one you get to use is either
> a) the one generated from your ODD via roma, or
> b) one you create from the Relax NG schema you stitched together, if
> we go that route.
>
pretty radical. no DTD modules to be created at all any more?
I had the impression on TEI-L that the "DTD bad, schema good"
war is not proceeding very well.
I'd wager that at least 1/3 of the Council members
use DTDs for their day to day work with the TEI....
> Furthermore, if you wanna use a DTD we should make it very clear and
> abundantly explicit that you are not getting a lot of the validation
> that you would get if you were using Relax NG.
>
that's a separate matter (though I agree)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 04:32:48 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:32:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:32:56 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <46121138.9010801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 09:32:56 +0100
Syd Bauman wrote:
> Right. If you wanna use a DTD, the only one you get to use is either
> a) the one generated from your ODD via roma, or
> b) one you create from the Relax NG schema you stitched together, if
> we go that route.
>
pretty radical. no DTD modules to be created at all any more?
I had the impression on TEI-L that the "DTD bad, schema good"
war is not proceeding very well.
I'd wager that at least 1/3 of the Council members
use DTDs for their day to day work with the TEI...
(including you, Syd?)
> Furthermore, if you wanna use a DTD we should make it very clear and
> abundantly explicit that you are not getting a lot of the validation
> that you would get if you were using Relax NG.
>
that's a separate matter (though I agree)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 04:33:00 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:00:14 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:00:14 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121138.9010801@oucs.ox.ac.uk> Message-ID: <4612179E.50609@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:00:14 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> Right. If you wanna use a DTD, the only one you get to use is either
>> a) the one generated from your ODD via roma, or
>> b) one you create from the Relax NG schema you stitched together, if
>> we go that route.
>>
> pretty radical. no DTD modules to be created at all any more?
>
> I had the impression on TEI-L that the "DTD bad, schema good"
> war is not proceeding very well.
>
> I'd wager that at least 1/3 of the Council members
> use DTDs for their day to day work with the TEI...
> (including you, Syd?)
I don't see that this matters? Surely these days those DTDs are generated
from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't
generated from Roma. Since Syd above in point a) says that DTDs generated
from roma are OK, then I don't see this as part of the "DTD bad, Schema
good" debate. People are still free to use DTDs, they just have to be
generated from Roma.
>> Furthermore, if you wanna use a DTD we should make it very clear and
>> abundantly explicit that you are not getting a lot of the validation
>> that you would get if you were using Relax NG.
> that's a separate matter (though I agree)
Agreed (though not in Conformance, but Modification section).
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:00:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:05:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:05:08 +0100 Subject: [tei-council] conformance draft In-Reply-To: <4612179E.50609@computing-services.oxford.ac.uk> Message-ID: <461218C4.5010509@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 10:05:08 +0100
James Cummings wrote:
> I don't see that this matters? Surely these days those DTDs are generated
> from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't
> generated from Roma.
sorry, I mean "old-fashioned DTDs" there.
well, turn this around. Someone pose the question
on TEI-L "has anyone ever, at all, used the parameterized
DTDs of TEI P5? can anyone imagine doing so?",
and see if anyone squeaks.
I'd post it myself, but am in pre-holiday purdah
(off from tomorrow)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:05:13 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:07:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:07:48 +0100 Subject: [tei-council] conformance draft In-Reply-To: <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <46121964.5000004@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:07:48 +0100
Christian Wittern wrote:
> Syd Bauman wrote:
>> Apologies, I'm not entirely up-to-date on this thread, but ...
>>
>>> I was intentionally being hard-line dictatorial and stating that
>>> TEI Conformance requires there to have been an ODD at some point to
>>> generate the schema.
>> I recall that Council expressed a pretty strong opinion on this at
>> the 2005 meeting in Paris, although I don't know if it was an
>> official vote or not. The overwhelming majority thought that ODD
>> should be the only way to go.
> At least for conformant documents, that was my impression as well. And I
> still think this is the way it should be.
Good. Is anyone disagreeing that for Conformance there must have been, at
some point, a TEI ODD? (i.e. even if the user is using a tei_lite schema,
that was originally an ODD).
>>> I am now thinking that the sensible thing would be to simply axe
>>> all the discussion of parameter entities etc. and simply say how to
>>> do the job with an ODD. Do we agree?
>> I don't think any discussion of parameter entities is warranted.
>> *Maybe* instructions for stitching together a Relax NG schema. Maybe.
> We should let go of both, IMHO. P5 is a radical break, part of the 21st
> century and the future, and DTD are soo 90s.
I don't think we need instructions for stitching together a Relax NG
schema, although there should be discussion of Relax in the Modification
section.
> I don't think (b) needs to be mentioned somewhere. If we do it right,
> most people (except Wendell) will not feel the need to hack the Schemas.
Yes, there are some people who will always do such things, but they know
enough to recognise that they are 'going off the reservation'. With other
guidelines/standards, if you took one part of it and ignored how it was
meant to be done and did it an entirely different way, you'd recognise that
you might not have support, interoperability, or 'certification' or
whatnot. ODD is the way this is meant to be done, so I don't think we
should be shy about stating it.
>> Furthermore, if you wanna use a DTD we should make it very clear and
>> abundantly explicit that you are not getting a lot of the validation
>> that you would get if you were using Relax NG.
> +1
Me Too
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:07:51 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:11:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:11:35 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121964.5000004@computing-services.oxford.ac.uk> Message-ID: <46121A47.2000502@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 10:11:35 +0100
James Cummings wrote:
> Good. Is anyone disagreeing that for Conformance there must have been, at
> some point, a TEI ODD? (i.e. even if the user is using a tei_lite schema,
> that was originally an ODD).
>
Well, yes, I am not that happy about it. Just call me Wendell.
Seems like painting ourselves into a corner, to throw
away the chance of customing it with RELAXNG fragments.
>
> With other
> guidelines/standards, if you took one part of it and ignored how it was
> meant to be done and did it an entirely different way, you'd recognise that
> you might not have support, interoperability, or 'certification' or
> whatnot.
note that you don't use the word "conformance" there.
I won't go to the stake on this, though.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:11:40 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:16:04 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:16:04 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175557774.3766.127.camel@localhost> Message-ID: <46121B54.7030500@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:16:04 +0100
Conal Tuohy wrote:
> On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote:
>> I would strongly suggest that people use something
>> based on their project URL if they have one.
> I agree.
I don't think anyone is disagreeing that this is desirable, if they have a
project URL.

> But I think this W3 guideline implies we should not suggest an http URI
> which starts with "http://www.tei-c.org/ns/user-defined/" (or similar)
> because that might imply that we would be maintaining a register of
> customisations. The namespace URI should clearly belong to the person
> making the customisation, not to the TEI Consortium.
I think this is enough to convince me that having user-defined NS at
tei-c.org is not a good idea. I think that:
1) the Roma web-form input for the namespace should defaultly be blank
(unless the ODD has already got a namespace),
2) that ODD needs somewhere agreed upon to store this namespace,
3) that there should be help text next to the box stating something like:
"Required: Add your project namespace here for any new elements you create.
We suggest that this is based on the URL for your project. Perhaps
something like http://www.ProjectName.org/ns/1.0"
> However, if the project doesn't have a website, then it might prove a
> barrier to provide a "namespace document". During the development phase
> of a project, it might not be clear what namespace URI would be best, so
> a temporary URI might be needed. In such cases, rather than use an HTTP
> URI, they could use some other kind of URI, such as a "tag" URI, e.g.
>
> "tag:conal.tuohy_at_gmail.com,2007:xmlns/my-customisation"
I don't like this idea. Even if they don't have a website, they can create
a temporary URI, it doesn't even have to point to a real site. (While not
best practice, this is within the W3C recommendation I believe?) I feel
the tag uri will just confuse them more.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:16:07 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:19:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:19:58 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121B54.7030500@computing-services.oxford.ac.uk> Message-ID: <46121C3E.7060100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 10:19:58 +0100
James Cummings wrote:
>
> 1) the Roma web-form input for the namespace should defaultly be blank
> (unless the ODD has already got a namespace),
>
agreed
> 2) that ODD needs somewhere agreed upon to store this namespace,
>
no, because you may use several namespaces in one ODD.
dont ask me why, but it would not be illegal.
I think you're making this over-complicated. Just
say "You must supply a namespace for each element
you add. Here is a pointer to guidelines on making namespaces.
You cannot use the TEI namespace."
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:20:03 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:21:29 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:21:29 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121A47.2000502@oucs.ox.ac.uk> Message-ID: <46121C99.9050805@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:21:29 +0100
Sebastian Rahtz wrote:
> Well, yes, I am not that happy about it. Just call me Wendell.
> Seems like painting ourselves into a corner, to throw
> away the chance of customing it with RELAXNG fragments.
Other than painting ourselves into a corner, can you explain to me why this
is such a bad thing? Surely this customising can still be done with
RELAXNG inside an ODD?
>> With other
>> guidelines/standards, if you took one part of it and ignored how it was
>> meant to be done and did it an entirely different way, you'd recognise
>> that
>> you might not have support, interoperability, or 'certification' or
>> whatnot.
> note that you don't use the word "conformance" there.
That's because most of the other standards I've looked at don't have a
definition of conformance in the way we do. This is because, I believe,
most other standards set out one way, and one way only, for you to do
things. The idea of you adding to, expanding, renaming, and otherwise
customising the standard are entirely foreign to most of them. TEI's
liberality in allowing customisation is simultaneously its greatest
strength and greatest barrier to mass-adoption. In most standards there
seems to be a one-to-one relationship, "it validates against the schema and
you've put the suggested information in the right place, then you are
Conformant". i.e. they conflate conformance and validity.
> I won't go to the stake on this, though.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:21:32 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:24:08 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:24:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121C3E.7060100@oucs.ox.ac.uk> Message-ID: <46121D38.3000306@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:24:08 +0100
Sebastian Rahtz wrote:
>> 2) that ODD needs somewhere agreed upon to store this namespace,
> no, because you may use several namespaces in one ODD.
> dont ask me why, but it would not be illegal.
Ok, when I feed my ODD back into Roma, how does it know the namespace(s) of
the elements I added last time?
> I think you're making this over-complicated. Just
> say "You must supply a namespace for each element
> you add. Here is a pointer to guidelines on making namespaces.
> You cannot use the TEI namespace."
I'd have no problem with that. But it would be good if Roma remembered
this for the session at least and used as a default the namespace I used
for the last 3 elements I added. That would satisfy me.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:24:11 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:30:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:30:39 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121C99.9050805@computing-services.oxford.ac.uk> Message-ID: <46121EBF.6090004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 10:30:39 +0100
James Cummings wrote:
> Other than painting ourselves into a corner, can you explain to me why this
> is such a bad thing? Surely this customising can still be done with
> RELAXNG inside an ODD?
>
Yes, but it is a pain. If all you want to do is have a RELAXNG
wrapper schema which imports 4 or 5 TEI modules, you
are forced to go through a klunky web service, or install
amateurish software locally. It makes an unncessary bottleneck.
>
> TEI's
> liberality in allowing customisation is simultaneously its greatest
> strength and greatest barrier to mass-adoption.
amen, bro...

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:30:49 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 05:32:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 10:32:18 +0100 Subject: [tei-council]DTDs (was conformance draft) In-Reply-To: <4612179E.50609@computing-services.oxford.ac.uk> Message-ID: <46121F22.9080705@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 03 Apr 2007 10:32:18 +0100
We are not talking about dropping support for DTDs any time soon. We are
talking about how much of the inner workings of the TEI DTDs should be
exposed in P5.
In P3 and preceding, DTD technology was moderately new as far as many of
its users were concerned, and so the Guidelines go to great lengths to
explain everything about how it works, exactly. There was no pizza chef,
let alone Roma, so the only way of customizing the thing was to really
grok those parameter entities.
We have now introduced ODD which is widely regarded as a great step
forward precisely because it conceals that machinery from the user and
allows us to specify in the Guidelines how schemas should be constructed
without going into details about how they should be instantiated as
RelaxNG or DTD or whatever... sort of like we don't talk about the
stylesheets needed to format TEI elements.
However, I think there is justice in the Mulberry view that says we
really ought not to require that everyone use our own ODD engine, and
that no-one will ever be able to build another ODD engine if we don't
document how such an engine is supposed to work somewhere. Note that I
am not saying "we need a user manual for Roma" (we have one more or
less); I am saying "we need a specification for how the various bits of
ODD are actually used to generate Relaxng and DTD schemas"
I am now coming round to the view that this should be a new section of
chapter 28. I think the DTD part of it would be fairly easy to compile
(l;argely from all the bits I've been hacking out of other parts of that
chapter) but I will need help drafting the RelaxNG bits. Something for
Sebastian to be thinking about on his boat?
Lou

James Cummings wrote:
> Sebastian Rahtz wrote:
>
>> Syd Bauman wrote:
>>
>>> Right. If you wanna use a DTD, the only one you get to use is either
>>> a) the one generated from your ODD via roma, or
>>> b) one you create from the Relax NG schema you stitched together, if
>>> we go that route.
>>>
>>>
>> pretty radical. no DTD modules to be created at all any more?
>>
>> I had the impression on TEI-L that the "DTD bad, schema good"
>> war is not proceeding very well.
>>
>> I'd wager that at least 1/3 of the Council members
>> use DTDs for their day to day work with the TEI...
>> (including you, Syd?)
>>
>
> I don't see that this matters? Surely these days those DTDs are generated
> from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't
> generated from Roma. Since Syd above in point a) says that DTDs generated
> from roma are OK, then I don't see this as part of the "DTD bad, Schema
> good" debate. People are still free to use DTDs, they just have to be
> generated from Roma.
>
>
>>> Furthermore, if you wanna use a DTD we should make it very clear and
>>> abundantly explicit that you are not getting a lot of the validation
>>> that you would get if you were using Relax NG.
>>>
>> that's a separate matter (though I agree)
>>
>
> Agreed (though not in Conformance, but Modification section).
>
> -James
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 05:32:22 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:32:28 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:32:28 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121D38.3000306@computing-services.oxford.ac.uk> Message-ID: <46121F2C.1040009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 10:32:28 +0100
James Cummings wrote:
>
> Ok, when I feed my ODD back into Roma, how does it know the namespace(s) of
> the elements I added last time?
>
the @ns attribute on each , natch.
> But it would be good if Roma remembered
> this for the session at least and used as a default the namespace I used
> for the last 3 elements I added. That would satisfy me.
>
thats a simple matter of programming, I think.
no big problem.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:32:37 EDT

From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:42:42 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:42:42 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121EBF.6090004@oucs.ox.ac.uk> Message-ID: <46122192.2090901@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:42:42 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
>> Other than painting ourselves into a corner, can you explain to me why
>> this
>> is such a bad thing? Surely this customising can still be done with
>> RELAXNG inside an ODD?
>>
> Yes, but it is a pain. If all you want to do is have a RELAXNG
> wrapper schema which imports 4 or 5 TEI modules, you
> are forced to go through a klunky web service, or install
> amateurish software locally. It makes an unncessary bottleneck.
Ok, but let's remember we're talking about Conformance here... there is no
requirement for them to be Conformant, and if all they want to do is have a
RELAXNG wrapper schema to do this, perhaps Conformance isn't something they
are interested in?
>> TEI's
>> liberality in allowing customisation is simultaneously its greatest
>> strength and greatest barrier to mass-adoption.
> amen, bro...
And hence why ODD will hopefully be useful in creating focussed
micro-formats which will aid this.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:42:47 EDT
From Conal.Tuohy at vuw.ac.nz Tue Apr 3 05:43:13 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 3 Apr 2007 21:43:13 +1200 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46120FFB.8040909@oucs.ox.ac.uk> Message-ID:
From: Conal Tuohy
Date: Tue, 3 Apr 2007 21:43:13 +1200
yeah I don't think we should force people to use any particular namespace URI.
If they want to leave it blank that's OK with me ... though what's the conformance status of a schema that includes names which are not in any namespace?
Con
-----Original Message-----
From: Sebastian Rahtz [mailto:sebastian.rahtz_at_oucs.ox.ac.uk]
Sent: Tue 03/04/07 20:27
To: Conal Tuohy
Cc: TEI Council
Subject: Re: [tei-council] Conformance draft: namespace purity

I am reluctant to force people to show an email address
of any kind, though its a nice idea.
I incline to making the box empty by default[1],
but compulsory, with some guidelines on good choices.
[1] and allowing for a way for them to create
elements in the empty namespace...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:43:30 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:46:08 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:46:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121F2C.1040009@oucs.ox.ac.uk> Message-ID: <46122260.3050302@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 10:46:08 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
>>
>> Ok, when I feed my ODD back into Roma, how does it know the
>> namespace(s) of
>> the elements I added last time?
>>
> the @ns attribute on each , natch.
Thus ODD has a place to store the namespace used. That is all I was
requiring, and you tell me it can already do it. :-) Ok, on a per element
basis could be confusing since if I have multiple namespaces and am adding
a new one, Roma has no way to know which one I might want as the default.
Wait until I add one then use the last added one I say.

>> But it would be good if Roma remembered
>> this for the session at least and used as a default the namespace I used
>> for the last 3 elements I added. That would satisfy me.
>>
> thats a simple matter of programming, I think.
> no big problem.
Good, I'm happy then.

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 05:52:43 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 06:02:33 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 11:02:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: Message-ID: <46122639.6050601@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 03 Apr 2007 11:02:33 +0100
Conal Tuohy wrote:
> yeah I don't think we should force people to use any particular namespace URI.
>
> If they want to leave it blank that's OK with me ... though what's the conformance status of a schema that includes names which are not in any namespace?
>
>
Interesting question. Suppose my extension consists of adding some
non-namespaced elements which just happen to have the same names as some
existing TEI-namespaced elements. A namespace aware processor wont be
confused but it sure as hell confuses me.
Actually thinking about this further, is there any difference between
this case and the case where I do have a namespace for my TEI-homonyms?
And, if is not the same as is not the same as

, maybe
we can say that by default extensions are not in any namespace? This
seems such an obvious escape hatch I must have missed something.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 06:04:12 EDT

From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 06:13:12 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 11:13:12 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: Message-ID: <461228B8.5030503@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 11:13:12 +0100
Conal Tuohy wrote:
> If they want to leave it blank that's OK with me ... though what's the
> conformance status of a schema that includes names which are not in any
> namespace?
According to 1.3.2, 'TEI Extension Schema':
"All new elements and attributes, which are not renamings of current
elements and attributes, must be added in a separate namespace." This
implies to me that they should not be in a null namespace.
Perhaps this should be stated more explicitly?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 06:13:16 EDT
From arianna.ciula at kcl.ac.uk Tue Apr 3 08:19:41 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 13:19:41 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46120FFB.8040909@oucs.ox.ac.uk> Message-ID: <4612465D.5030905@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 03 Apr 2007 13:19:41 +0100
Sebastian Rahtz wrote:
> I am reluctant to force people to show an email address
> of any kind, though its a nice idea.
>
> I incline to making the box empty by default[1],
> but compulsory, with some guidelines on good choices.
>
> [1] and allowing for a way for them to create
> elements in the empty namespace...
>
I think this is the best solution. However, I am not sure whether you
would need two fields instead: indeed, how would you retrieve the
namespace prefix from the URI?
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 08:19:50 EDT
From arianna.ciula at kcl.ac.uk Tue Apr 3 08:28:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 13:28:06 +0100 Subject: [tei-council]DTDs (was conformance draft) In-Reply-To: <46121F22.9080705@computing-services.oxford.ac.uk> Message-ID: <46124856.3090002@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 03 Apr 2007 13:28:06 +0100
Lou Burnard wrote:
> Note that I
> am not saying "we need a user manual for Roma" (we have one more or
> less); I am saying "we need a specification for how the various bits of
> ODD are actually used to generate Relaxng and DTD schemas"
I agree with this.
Arianna
>
> I am now coming round to the view that this should be a new section of
> chapter 28. I think the DTD part of it would be fairly easy to compile
> (l;argely from all the bits I've been hacking out of other parts of that
> chapter) but I will need help drafting the RelaxNG bits. Something for
> Sebastian to be thinking about on his boat?
>
> Lou
>
>
> James Cummings wrote:
>> Sebastian Rahtz wrote:
>>
>>> Syd Bauman wrote:
>>>
>>>> Right. If you wanna use a DTD, the only one you get to use is either
>>>> a) the one generated from your ODD via roma, or
>>>> b) one you create from the Relax NG schema you stitched together, if
>>>> we go that route.
>>>>
>>> pretty radical. no DTD modules to be created at all any more?
>>>
>>> I had the impression on TEI-L that the "DTD bad, schema good"
>>> war is not proceeding very well.
>>>
>>> I'd wager that at least 1/3 of the Council members
>>> use DTDs for their day to day work with the TEI...
>>> (including you, Syd?)
>>>
>>
>> I don't see that this matters? Surely these days those DTDs are
>> generated
>> from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't
>> generated from Roma. Since Syd above in point a) says that DTDs
>> generated
>> from roma are OK, then I don't see this as part of the "DTD bad, Schema
>> good" debate. People are still free to use DTDs, they just have to be
>> generated from Roma.
>>
>>
>>>> Furthermore, if you wanna use a DTD we should make it very clear and
>>>> abundantly explicit that you are not getting a lot of the validation
>>>> that you would get if you were using Relax NG.
>>>>
>>> that's a separate matter (though I agree)
>>>
>>
>> Agreed (though not in Conformance, but Modification section).
>>
>> -James
>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 08:28:36 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 08:31:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 13:31:38 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612465D.5030905@kcl.ac.uk> Message-ID: <4612492A.7090004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 13:31:38 +0100
Arianna Ciula wrote:
>
> I think this is the best solution. However, I am not sure whether you
> would need two fields instead: indeed, how would you retrieve the
> namespace prefix from the URI?
namespace prefixes dont come into it. they are an artefact of the XML
instance,
not the schema
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 08:31:45 EDT
From Syd_Bauman at Brown.edu Tue Apr 3 09:53:06 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 09:53:06 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612492A.7090004@oucs.ox.ac.uk> Message-ID: <17938.23618.968848.542046@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 09:53:06 -0400
First, let me reiterate that I think we should permit conformant
documents to add elements in the TEI namespace. But given that we are
not going to permit that:
I think that James' stipulation in the draft that new elements
*must* be in a a non-TEI namespace might be a bit overstated --
perhaps we should *permit* null-namespace additions.
BUT, it certainly shouldn't be the default. Remember that our target
audience includes (lots of) folks who are decidedly not XML experts.
Can you imagine the confusion of having to change


Blue

My encoded text with the thing I am
interested in encoding
into


Blue
My encoded text with the thing I am
interested in encoding


Just to add the one element a user needs for some process or
other? How annoying. So annoying, BTW, that I think many, if not
most, people wouldn't do it even if we did require it.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 09:53:10 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 10:01:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 15:01:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <46125E3D.1040200@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 15:01:33 +0100
Syd Bauman wrote:
> that I think many, if not
> most, people wouldn't do it even if we did require it.
>
of course, this applies to the whole discussion. people
(including funders) may well turn around
say "oh well, so we're not conformant. ".....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 10:01:38 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 10:02:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 15:02:06 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <46125E5E.7030800@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 15:02:06 +0100
PS
> I think that James' stipulation in the draft that new elements
> *must* be in a a non-TEI namespace might be a bit overstated --
> perhaps we should *permit* null-namespace additions.
>
I agree ..
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 10:02:09 EDT
From arianna.ciula at kcl.ac.uk Tue Apr 3 10:04:51 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 15:04:51 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines Message-ID: <46125F03.8070702@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 03 Apr 2007 15:04:51 +0100
I am not sure whom I should address for this:
the link from each element description page e.g.
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to the
TEI Guidelines (bottom of the page) doesn't seem to work:
"No pipeline matched request: release/doc/tei-p5-doc/html/$"
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 10:05:09 EDT
From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 10:11:49 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 15:11:49 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E5E.7030800@oucs.ox.ac.uk> Message-ID: <461260A5.8010806@computing-services.oxford.ac.uk>
From: James Cummings
Date: Tue, 03 Apr 2007 15:11:49 +0100
Sebastian Rahtz wrote:
> PS
>> I think that James' stipulation in the draft that new elements
>> *must* be in a a non-TEI namespace might be a bit overstated --
>> perhaps we should *permit* null-namespace additions.
> I agree ..
Discussing this with Lou this afternoon he too seemed to be of the opinion
that we should *permit* null-namespace additions as a Conformant TEI
Extension schema. I believe the draft he will be working on this weekend
will incorporate that.
I agree that new elements cannot be in the TEI namespace, but am flexible
on whether they need to be in any namespace. Certainly my draft was
assuming that they would be, and I think this should be 'Recommended
Practice', even if we don't make it a requirement for conformance.
This only affects the TEI Extension and similar schemas. For example, a
Renaming Customisation is still using the TEI namespace for its
TEI-but-renamed elements.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 10:11:54 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 10:23:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 15:23:54 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] Message-ID: <4612637A.4040501@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 03 Apr 2007 15:23:54 +0100
Syd sayd:
|BUT, it certainly shouldn't be the default. Remember that our target
|audience includes (lots of) folks who are decidedly not XML experts.
|Can you imagine the confusion of having to change
|
|
|
| Blue
|

My encoded text with the thing I am
| interested in encoding


|
|

Err, actually I think there is quite a lot less confusion in explaining
that they need to turn that into something like this:
xmlns:mine="http://mynamespace.org">


Blue

My encoded text with the
thing I am
interested in encoding




_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 10:25:33 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 10:25:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 15:25:57 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines In-Reply-To: <46125F03.8070702@kcl.ac.uk> Message-ID: <461263F5.3000503@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 03 Apr 2007 15:25:57 +0100
It's a bug in the stylesheets which should be addressed to the TEI's
team of professional software developers, only he's going on holiday
this afternoon...

Arianna Ciula wrote:
> I am not sure whom I should address for this:
> the link from each element description page e.g.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to the
> TEI Guidelines (bottom of the page) doesn't seem to work:
> "No pipeline matched request: release/doc/tei-p5-doc/html/$"
>
> Arianna
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 10:27:38 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 11:00:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 16:00:37 +0100 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] Message-ID: <46126C15.1080504@oucs.ox.ac.uk>
From: Lou Burnard
Date: Tue, 03 Apr 2007 16:00:37 +0100
I think this is worthy of note:
http://www.w3.org/News/2007#item64
The specification is here:
http://www.w3.org/TR/2007/REC-its-20070403/
Why is it worthy of note? well, partly because it's been keeping
Sebastian busy for the last 18 months or so, but also because it shows
that the TEI ODD language can actually be used to document other non-TEI
standards.
Congratulations!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 11:02:18 EDT

From daniel.odonnell at uleth.ca Tue Apr 3 11:59:47 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 09:59:47 -0600 Subject: [tei-council] rules about renaming In-Reply-To: <46120E6A.5040106@oucs.ox.ac.uk> Message-ID: <1175615987.3483.11.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 03 Apr 2007 09:59:47 -0600
On Tue, 2007-03-04 at 09:20 +0100, Sebastian Rahtz wrote:
> I see why a complete Frenchified TEI might have its own namespace.
> But I would point out that the mechanism used to Frenchify the TEI
> (ie ) is no different from that used to change

to
> for readability. By this argument, any use of would mean you
> should also change the namespace.
>
> what if you find most of the TEI OK, but change a few common tags to French
> names, to help your encoders?
>
> I am willing to be convinced, but I don't really see how this would
> all work in practice.
But what about our hypothetical english

= language x ? If you
change the tagnames to accommodate that, you might have something less
than a complete internationalisation but something more than an
innocuous change.
But maybe it is a silly example: since q already exists in the TEI,
somebody contemplating a partial change would almost certainly want a
longer tagname: maybe or something so as not to conflict with p.
I wonder what if we isolated the case of changes that conflict directly
with english tei names (or extend an official i18n version) and proposed
that in those cases you need a separate namespace to stay conformant.
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 11:57:21 EDT

From daniel.odonnell at uleth.ca Tue Apr 3 12:02:15 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 10:02:15 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E3D.1040200@oucs.ox.ac.uk> Message-ID: <1175616135.3483.13.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 03 Apr 2007 10:02:15 -0600
On Tue, 2007-03-04 at 15:01 +0100, Sebastian Rahtz wrote:
> Syd Bauman wrote:
> > that I think many, if not
> > most, people wouldn't do it even if we did require it.
> >
> of course, this applies to the whole discussion. people
> (including funders) may well turn around
> say "oh well, so we're not conformant. ".....
This is the kind of thing the board should be addressing: it is not a
technical issue but a good practice and archiving issue.
>
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 11:59:44 EDT
From Syd_Bauman at Brown.edu Tue Apr 3 12:53:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 12:53:11 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E3D.1040200@oucs.ox.ac.uk> Message-ID: <17938.34423.359122.826819@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 12:53:11 -0400
> of course, this applies to the whole discussion. people (including
> funders) may well turn around say "oh well, so we're not
> conformant. ".....
Yes, they might; and I think it is incumbent upon us to try to make
sure that the conformance bar is set low enough that most users
*don't*. While I don't think the usefulness of the Guidelines is lost
if no one is conformant, certainly the rules for conformance become
useless in that case. :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 12:53:14 EDT
From Syd_Bauman at Brown.edu Tue Apr 3 13:00:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 13:00:29 -0400 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <4612637A.4040501@oucs.ox.ac.uk> Message-ID: <17938.34861.379138.981406@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 13:00:29 -0400
> Err, actually I think there is quite a lot less confusion in
> explaining that they need to turn that into something like this:
>
>
> xmlns:mine="http://mynamespace.org">
>
>
> Blue
>

My encoded text with the
> thing I am
> interested in encoding


>
>
If I understand you correctly, you are absolutely right, and have
reiterated the point I was making. If by default Roma gives them a
schema for

Blue
My encoded text with the thing I am
interested in encoding

(i.e., only new added elements in null namespace) when what they
would have really wanted is that which you posted (new added elements
in new non-null namespace), they're going to be confused or unhappy
(or both). Therefore, I do not think Roma should use the null
namespace as a default for newly added elements.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 13:00:32 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 13:00:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 18:00:57 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.34423.359122.826819@emt.wwp.brown.edu> Message-ID: <46128849.3070001@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 18:00:57 +0100
Syd Bauman wrote:
> Yes, they might; and I think it is incumbent upon us to try to make
> sure that the conformance bar is set low enough that most users
> *don't*.
>
but not so low that baby Maggie can waddle over it.
it's hard to tell until we have watched the first
100 competitors try
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 13:01:01 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 13:04:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 18:04:41 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <17938.34861.379138.981406@emt.wwp.brown.edu> Message-ID: <46128929.6060606@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 18:04:41 +0100
Syd Bauman wrote:
> Therefore, I do not think Roma should use the null
> namespace as a default for newly added elements.
>
I think we all agree on this.
I will make the field have a default of "-" (say),
and make this illegal. They have to put in some
text other than - or something which does not
start with "http://www.tei-c.org/", or they can
consciously empty it.
people who really want to force it to add elemnets
in the TEI namespace have to edit the ODD by hand.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 13:04:45 EDT

From Syd_Bauman at Brown.edu Tue Apr 3 13:13:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 13:13:14 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175616135.3483.13.camel@odonned-eng06> Message-ID: <17938.35626.998383.176354@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 13:13:14 -0400
> This is the kind of thing the board should be addressing: it is not
> a technical issue but a good practice and archiving issue.
I'm not sure exactly what you're addressing, Daniel, but I think the
issue at hand (how customizations, namespaces, conformance, and
interchange format interact) is a technical issue, albeit one with
some non-technical ramifications. While the Board may want to review
Council's ideas and decisions about these issues and give some
high-level guidance in setting the balance point between ease-of-use
and best practices (like "it should be easier", or "the definitions
should be more specific", or "it would be good if it could handle
internationalization more smoothly"), seems to me the details are
entirely up to the Council and the editors.
That said, if the Board thinks a certain technical path is likely to
have a negative impact on the TEI Consortium (which I am quite
worried about), they should say so. Since we haven't left ourselves
enough time, I don't think, to get a good feeling of how the general
TEI community feels about these issues, perhaps getting the Board's
thoughts is a good idea.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 13:13:19 EDT
From Syd_Bauman at Brown.edu Tue Apr 3 14:00:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 14:00:21 -0400 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <46128929.6060606@oucs.ox.ac.uk> Message-ID: <17938.38453.187269.987187@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 14:00:21 -0400
> I will make the field have a default of "-" (say), and make this
> illegal. They have to put in some text other than - or something
> which does not start with "http://www.tei-c.org/", or they can
> consciously empty it.
>
> people who really want to force it to add elemnets in the TEI
> namespace have to edit the ODD by hand.
I think that (given the non-TEI namespace for new element
requirement, which I think is a bad idea) this all makes sense,
except that I still lean towards making the default be a valid (if
useless) namespace URI. Makes it a lot easier to use Roma for quick
testing, a use to which webRoma is often put, I think.
I agree that a namespace URI in www.tei-c.org, even if it has
"user-extension/" carries too much of an implication; I agree that
putting an e-mail address inside the URI by default is a bad idea.
But note that the "tag" scheme that Conal pointed us to does not
require an e-mail address. It only requires a DNSname, and if I read
the BNF right, a dotted-quad IP address qualifies as a DNSname. Thus
tag:128.148.123.321,2007-04-03:P5customization/$name
(where $name is whichever one of prefix, filename, schemaSpec/@ident
that Sebastian finds easier to use) seems reasonable to me.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 14:00:25 EDT
From daniel.odonnell at uleth.ca Tue Apr 3 14:16:03 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 12:16:03 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.35626.998383.176354@emt.wwp.brown.edu> Message-ID: <1175624163.16472.0.camel@odonned-eng06>
From: Dan O'Donnell
Date: Tue, 03 Apr 2007 12:16:03 -0600
On Tue, 2007-03-04 at 13:13 -0400, Syd Bauman wrote:
> > This is the kind of thing the board should be addressing: it is not
> > a technical issue but a good practice and archiving issue.
>
> I'm not sure exactly what you're addressing, Daniel, but I think the
> issue at hand (how customizations, namespaces, conformance, and
> interchange format interact) is a technical issue, albeit one with
> some non-technical ramifications. While the Board may want to review
> Council's ideas and decisions about these issues and give some
> high-level guidance in setting the balance point between ease-of-use
> and best practices (like "it should be easier", or "the definitions
> should be more specific", or "it would be good if it could handle
> internationalization more smoothly"), seems to me the details are
> entirely up to the Council and the editors.
>
> That said, if the Board thinks a certain technical path is likely to
> have a negative impact on the TEI Consortium (which I am quite
> worried about), they should say so. Since we haven't left ourselves
> enough time, I don't think, to get a good feeling of how the general
> TEI community feels about these issues, perhaps getting the Board's
> thoughts is a good idea.
No I meant the "shrug" is a board issue: convincing funding agencies
that it is nothing to shrug about is not directly technical, provided
that the technical is good.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 14:13:30 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 14:20:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 19:20:23 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <17938.38453.187269.987187@emt.wwp.brown.edu> Message-ID: <46129AE7.7040008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 19:20:23 +0100
Syd Bauman wrote:
> I think that (given the non-TEI namespace for new element
> requirement, which I think is a bad idea) this all makes sense,
> except that I still lean towards making the default be a valid (if
> useless) namespace URI. Makes it a lot easier to use Roma for quick
> testing, a use to which webRoma is often put, I think.
>
you may be right. anyway, I'll work on the stuff
after Easter so that we can experiment.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 14:20:27 EDT

From Syd_Bauman at Brown.edu Tue Apr 3 15:07:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 15:07:18 -0400 Subject: [tei-council] conformance draft In-Reply-To: <46122192.2090901@computing-services.oxford.ac.uk> Message-ID: <17938.42470.585777.717173@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 15:07:18 -0400
First of all, especially for those of you who were not at the 2004
meeting in Paris, it is mildly amusing to note that once again
Sebastian & I have traded places ... in Paris I was the lone voice
for permitting users to stitch together a Relax NG schema as they
might not have an ODD processor handy. But now, I think James may
have convinced me that even if the schema lends itself to such
stitching, the definition of Conformance should be through ODD.

> >> is such a bad thing? Surely this customising can still be done
> >> with RELAXNG inside an ODD?
This is not at all clear to me. We haven't developed any rules,
guidelines, suggestions, hooks, or any such things for how this would
be done, have we? Could someone hack a TEI Relax NG schema so that it
made use of Relax NG features that ODD does not support?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 15:07:22 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 15:22:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 20:22:04 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17938.42470.585777.717173@emt.wwp.brown.edu> Message-ID: <4612A95C.5070501@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 20:22:04 +0100
Syd Bauman wrote:
> First of all, especially for those of you who were not at the 2004
> meeting in Paris, it is mildly amusing to note that once again
> Sebastian & I have traded places ... in Paris I was the lone voice
> for permitting users to stitch together a Relax NG schema as they
> might not have an ODD processor handy.
do you mean 2005? if so, I was not there. but no matter.
> This is not at all clear to me. We haven't developed any rules,
> guidelines, suggestions, hooks, or any such things for how this would
> be done, have we? Could someone hack a TEI Relax NG schema so that it
> made use of Relax NG features that ODD does not support?
>
>
certainly, in a content model, you could
make a local element declaration, for instance.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 15:22:08 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 15:53:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 20:53:58 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines In-Reply-To: <46125F03.8070702@kcl.ac.uk> Message-ID: <4612B0D6.2000707@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 20:53:58 +0100
Arianna Ciula wrote:
> I am not sure whom I should address for this:
> the link from each element description page e.g.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to
> the TEI Guidelines (bottom of the page) doesn't seem to work:
> "No pipeline matched request: release/doc/tei-p5-doc/html/$"
fixed, updates going onto web site now.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 15:54:03 EDT
From Syd_Bauman at Brown.edu Tue Apr 3 16:18:34 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 16:18:34 -0400 Subject: [tei-council] conformance draft In-Reply-To: <4612A95C.5070501@oucs.ox.ac.uk> Message-ID: <17938.46746.545430.36475@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 16:18:34 -0400
> do you mean 2005? if so, I was not there. but no matter.
Yes, that was a boo-boo, sorry. 2004 was in Ghent, 2005 in Paris.

> > This is not at all clear to me. We haven't developed any rules,
> > guidelines, suggestions, hooks, or any such things for how this
> > would be done, have we? Could someone hack a TEI Relax NG schema
> > so that it made use of Relax NG features that ODD does not
> > support?
> certainly, in a content model, you could make a local element
> declaration, for instance.
Hmmm ... you mean in an ODD, or directly? Either way, that gives me
the capability to declare the element differently when it is
inside a , right?
One of Relax NG's greatest powers is co-occurrence constraints. For
example, declaring that must have character content or a key=
attribute, but not both[1]; or declaring the content of


differently iff the type= is "USA"[2]. I do not think we can do these
things via ODD, nor do I have confidence that we can (or even should
bother) coming up with a good mechanism for doing so by manipulating
the Relax NG schemas somehow. I'm inclined to just say "yup, there
are things Relax NG can do that TEI cannot; you can certainly use
non-TEI conformant Relax NG schemas in addition to your normal
Roma-generated Relax NG schema -- but why not use Schematron embedded
in your ODD? Here is a sample of how to do that ...".

Notes
-----
[1]
element name {
attribute key { data.key }
| xsd:token { pattern = ".+" }
}
[2]
address = addressOther | addressUSA
addressUSA =
element address {
attribute type { xsd:token "USA" },
name,
street,
city,
state,
postCode
}
addressOther =
element address {
attribute type { xsd:token - "USA" },
addrLine+
}
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 16:18:38 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 16:30:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 21:30:11 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17938.46746.545430.36475@emt.wwp.brown.edu> Message-ID: <4612B953.1090607@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 03 Apr 2007 21:30:11 +0100
Syd Bauman wrote:
> Hmmm ... you mean in an ODD, or directly? Either way, that gives me
> the capability to declare the element differently when it is
> inside a , right?
>
yes, I think so. I havent tried it yet
> ings via ODD, nor do I have confidence that we can (or even should
> bother) coming up with a good mechanism for doing so by manipulating
> the Relax NG schemas somehow. I'm inclined to just say "yup, there
> are things Relax NG can do that TEI cannot; yo
and I would say "one of the reasons is that we still
want to be able to produce DTDs, so we use a subset
of what RELAXNG can offer"

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 16:30:16 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 21:18:38 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 04 Apr 2007 10:18:38 +0900 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] In-Reply-To: <46126C15.1080504@oucs.ox.ac.uk> Message-ID: <4612FCEE.5040903@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 04 Apr 2007 10:18:38 +0900
Lou Burnard wrote:
> The specification is here:
> http://www.w3.org/TR/2007/REC-its-20070403/
>
This is great news indeed. The ODD is even mentioned in the spec with
some favourable words. Good PR for TEI-C I'd say.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 21:27:28 EDT
From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 20:58:37 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 04 Apr 2007 09:58:37 +0900 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <4612F83D.70209@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Wed, 04 Apr 2007 09:58:37 +0900
Syd Bauman wrote:
>
> I think that James' stipulation in the draft that new elements
> *must* be in a a non-TEI namespace might be a bit overstated --
> perhaps we should *permit* null-namespace additions.
This seems like splitting hairs, but since the null-namespace is
certainly not a TEI namespace, I would think this is licensed by the
current draft.
> BUT, it certainly shouldn't be the default. Remember that our target
> audience includes (lots of) folks who are decidedly not XML experts.
> Can you imagine the confusion of having to change
>
>
>
> Blue
>

My encoded text with the thing I am
> interested in encoding


>
>
>
> into
>
>
>
> Blue
> My encoded text with the thing I am
> interested in encoding
>
>
This is not what you will do. You will add a
xmlns="http://www.tei-c.org/ns/1.0" to the TEI element above and then
get the following:


Blue

My encoded text with the thing I am
interested in encoding

This is if we allow a null namespace, which seems reasonable to me,
otherwise you will get the thing which seems nice
to me as well.
The downside of this of course is that it will need to jump some through
some hoops in DTD land where you have to emulate namespaces with
prefixes and or #FIXED attributes.
>
> Just to add the one element a user needs for some process or
> other? How annoying. So annoying, BTW, that I think many, if not
> most, people wouldn't do it even if we did require it.
The annoying part starts only if you want to process this, but even
there you could argue it is entirely reasonable to have to deal with
your own stuff yourself and this namespace business helps you separate
your stuff from their stuff.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Apr 03 2007 - 21:27:28 EDT

From Syd_Bauman at Brown.edu Tue Apr 3 22:05:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 22:05:41 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612F83D.70209@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17939.2037.11157.614358@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 3 Apr 2007 22:05:41 -0400
Good morning, Christian!

> > I think that James' stipulation in the draft that new elements
> > *must* be in a a non-TEI namespace might be a bit overstated --
> > perhaps we should *permit* null-namespace additions.
>
> This seems like splitting hairs, but since the null-namespace is
> certainly not a TEI namespace, I would think this is licensed by
> the current draft.
I had thought that an element w/o a namespace declaration in force is
not really in a namespace at all, rather than being in the null
namespace (which we were using as shorthand notation for this
condition).

> This is not what you will do. You will add a
> xmlns="http://www.tei-c.org/ns/1.0" to the TEI element above and
> then get the following:
>
>
> Blue
>

My encoded text with the thing I am
> interested in encoding


>
>
I had forgotten about the possibility of xmlns="" -- it is the same
as no namespace, right?

> The downside of this of course is that it will need to jump some
> through some hoops in DTD land where you have to emulate namespaces
> with prefixes and or #FIXED attributes.
I'm not sure if I want to use that as an argument against requiring
added elements be in a different namespace, or against supporting
DTDs! :-)

> The annoying part starts only if you want to process this,
I think it's pretty annoying to edit & proofread, too.

> ... but even there you could argue it is entirely reasonable to
> have to deal with your own stuff yourself and this namespace
> business helps you separate your stuff from their stuff.
Absolutely. But my major point is that you are going to have to deal
with not only your own stuff, but TEI stuff anyway. It's not like
it's really possible to have out-of-the-box TEI software to process
your TEI documents. Besides, if such a beast existed, it would likely
choke as soon as I use a customization that is not a restriction, but
since it isn't a new element, doesn't change the namespace. (E.g., if
I were to change a content model to permit an element that isn't
available in vanilla.)

G'night!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Apr 03 2007 - 22:05:45 EDT

From James.Cummings at computing-services.oxford.ac.uk Wed Apr 4 05:27:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 04 Apr 2007 10:27:34 +0100 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] In-Reply-To: <4612FCEE.5040903@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <46136F86.1070404@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 04 Apr 2007 10:27:34 +0100
Christian Wittern wrote:
> Lou Burnard wrote:
>> The specification is here:
>> http://www.w3.org/TR/2007/REC-its-20070403/
>>
>
> This is great news indeed. The ODD is even mentioned in the spec with
> some favourable words. Good PR for TEI-C I'd say.
Yes, great PR for TEI-C I'd say...so why hasn't someone from the board or
directly involved posted it to TEI-L to reassure our community how
wonderful we are? Or did they and I miss it?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Apr 04 2007 - 05:27:38 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Apr 4 06:53:58 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 04 Apr 2007 11:53:58 +0100 Subject: [tei-council] Conformance .... the continuing saga Message-ID: <461383C6.6000003@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 04 Apr 2007 11:53:58 +0100
Sebastian's now gone on holiday, but that hasn't stopped James and me
from continuing to argue about conformance!
How do other Council Members feel about this?

LB >>> You're making the same mistake I was: conflating "support for
DTDs" and
>>> "support for parameterized DTDs". We certainly have to go on supporting
>>> DTDs, but the record isn't clear as to whether we agreed to pull the rug
>>> out from under "parameterized DTDs". As in the SG chapter, we have to
>>> decide whether to remove that facility or complement it with some
>>> discussion of the RelaxNG alternative way.
JC >> If Parameterised DTDs are only being used for things which are now
>> done in
>> ODD, then, cognate with not allowing people to just stitch together
>> RelaxNG
>> schemas and be conformant, I don't think we necessarily should be
>> supporting/mentioning/recommending parameterised DTDs. I'm willing to be
>> convinced that we should, but I don't understand the argument for
>> continuing in support of them.
LB > We need a more open discussion about ways of customizing the TEI.
> Parameterised DTD fragments, knitting together RelaxNG fragments, and
> using ODD are three varyingly plausible ways of achieving the same goal.
> We are near to a consensus on which is regarded as "TEI conformant" (the
> last); but we haven't begun the debate as to whether or not we support
> the other two as well.
Should we actively support non-Conformant methods of doing things, or
simply have a short notice that there are other ways to do it with some
descriptions?
> The simplest argument in favour is
>
> (a) we are currently generating and distributing them
Not a good enough reason to keep doing so
> (b) we haven't told anyone we intend to stop doing so
Political, but again, P5 is such a big change
> (c) people e.g. wendell might want to use them
Those who don't care about Conformance? And nothing to stop them using
that locally, but producing versions that do the same thing in an ODD.
> (d) it's (probably) less work to add some stuff about relaxng than to
> completely remove all the stuff about DTDs
I can't really judge that.
> Maybe we should move this discussion to the council list?
Yes, certainly. :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Apr 04 2007 - 06:55:40 EDT

From Syd_Bauman at Brown.edu Wed Apr 4 08:56:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Apr 2007 08:56:56 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <461383C6.6000003@oucs.ox.ac.uk> Message-ID: <17939.41112.690281.365239@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 4 Apr 2007 08:56:56 -0400
> Should we actively support non-Conformant methods of doing things,
> or simply have a short notice that there are other ways to do it
> with some descriptions?
I think this is analogous to use of start= of . If you
specify , you end up with a schema that will
only mark as valid documents that are definitionally non-conformant
(because they have no header). The system supports doing so, because
it is often a *really* big help when making test files, etc. But it
isn't part of a TEI Conformant system. Similarly, you can stitch
together a schema from Relax NG fragments when it is more convenient
to do so (you're experimenting, you're on an airplane w/o access to
Roma, etc.). But the result is non-conformant, and we shouldn't spend
a lot of effort (if any) describing how to do this.

> > (a) we are currently generating and distributing them
> Not a good enough reason to keep doing so
Agreed. IMHO distributing parametrized DTD fragments is not only a
waste of Sebastian's time (although he points out not much), it is
potentially confusing to a DTD user who hasn't read the Guidelines
carefully, but remembers extending P4!

> > (b) we haven't told anyone we intend to stop doing so
> Political, but again, P5 is such a big change
No problem. We'll tell 'em now. (Or at release 0.7.)

> > (c) people e.g. wendell might want to use them
> Those who don't care about Conformance? And nothing to stop them
> using that locally, but producing versions that do the same thing
> in an ODD.
Wendell will want to stitch together Relax NG, sure, but who wants to
use parametrized DTDs? Remember, doing so is going to give you all
sorts of namespace headaches.

> > (d) it's (probably) less work to add some stuff about relaxng than to
> > completely remove all the stuff about DTDs
> I can't really judge that.
Whether we add Relax NG info or not, we should remove stuff about
using parametrized DTDs. It's a bad idea.
Perhaps a discussion of how to stitch together TEI Relax NG schema
fragments should be the subject of a white paper, and not in the
Guidelines?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Apr 04 2007 - 08:57:00 EDT

From James.Cummings at computing-services.oxford.ac.uk Wed Apr 4 09:07:23 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 04 Apr 2007 14:07:23 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17939.41112.690281.365239@emt.wwp.brown.edu> Message-ID: <4613A30B.9060607@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 04 Apr 2007 14:07:23 +0100
Syd Bauman wrote:
>> Should we actively support non-Conformant methods of doing things,
>> or simply have a short notice that there are other ways to do it
>> with some descriptions?
>
> I think this is analogous to use of start= of . If you
> specify , you end up with a schema that will
> only mark as valid documents that are definitionally non-conformant
> (because they have no header). The system supports doing so, because
> it is often a *really* big help when making test files, etc. But it
> isn't part of a TEI Conformant system. Similarly, you can stitch
> together a schema from Relax NG fragments when it is more convenient
> to do so (you're experimenting, you're on an airplane w/o access to
> Roma, etc.). But the result is non-conformant, and we shouldn't spend
> a lot of effort (if any) describing how to do this.
Exactly my thinking. We should maybe describe that it can be done and
might be useful in those circumstances, but I wouldn't suggest more than that.
>>> (a) we are currently generating and distributing them
>> Not a good enough reason to keep doing so
>
> Agreed. IMHO distributing parametrized DTD fragments is not only a
> waste of Sebastian's time (although he points out not much), it is
> potentially confusing to a DTD user who hasn't read the Guidelines
> carefully, but remembers extending P4!
Exactly.
>>> (b) we haven't told anyone we intend to stop doing so
>> Political, but again, P5 is such a big change
> No problem. We'll tell 'em now. (Or at release 0.7.)
Yup, along with the not-adding-elements to the TEI namespace thing. ;-)
>>> (c) people e.g. wendell might want to use them
>> Those who don't care about Conformance? And nothing to stop them
>> using that locally, but producing versions that do the same thing
>> in an ODD.
> Wendell will want to stitch together Relax NG, sure, but who wants to
> use parametrized DTDs? Remember, doing so is going to give you all
> sorts of namespace headaches.
I certainly won't -- what are some use cases for doing so assuming one can
use ODD to do the same thing?
> Whether we add Relax NG info or not, we should remove stuff about
> using parametrized DTDs. It's a bad idea.
If we aren't supporting it then I say remove it (except maybe a note about
the change and how it used to be done).
> Perhaps a discussion of how to stitch together TEI Relax NG schema
> fragments should be the subject of a white paper, and not in the
> Guidelines?
Isn't this what the now-conference-like bit of the TEIMM is for?
-James

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Apr 04 2007 - 09:07:27 EDT

From Syd_Bauman at Brown.edu Wed Apr 4 12:15:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Apr 2007 12:15:18 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613A30B.9060607@computing-services.oxford.ac.uk> Message-ID: <17939.53014.822219.184813@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 4 Apr 2007 12:15:18 -0400
> Yup, along with the not-adding-elements to the TEI namespace thing.
> ;-)
Which, I am worried, will not go over very well. I could be wrong,
but I don't think many TEI users will balk at the idea of not being
able to use DTD parametrization for customization, especially once
they've been introduced to ODD and realize that they couldn't just
port their P4 extensions over easily, anyway. But I worry that a lot
of people will be put off by the namespace purity.

> I certainly won't -- what are some use cases for doing so assuming
> one can use ODD to do the same thing?
I haven't come up with one, because you can't just port your P4
customization files, and because you smack into namespace headaches.
BTW, I was using Wendell as a generic example of a marvelously
maverick Relax NG expert -- I don't pretend to actually know what
Wendell will and won't do.

> If we aren't supporting it then I say remove it (except maybe a
> note about the change and how it used to be done).
Maybe. I'm not too fond of "how it used to be done" descriptions,
myself.

> > Perhaps a discussion of how to stitch together TEI Relax NG
> > schema fragments should be the subject of a white paper, and not
> > in the Guidelines?
> Isn't this what the now-conference-like bit of the TEIMM is for?
Hmmm.... while presenting this kind of information at the MM is a
good idea, I was thinking of a paper something like a HOWTO but with
more discussion of the issues, published by TEI-C, available from the
TEI-C website.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Apr 04 2007 - 12:15:24 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Apr 4 13:36:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 04 Apr 2007 18:36:39 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17939.53014.822219.184813@emt.wwp.brown.edu> Message-ID: <4613E227.2090909@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 04 Apr 2007 18:36:39 +0100
Does no-one else on the Council have a view on this issue? Or is
everyone already on holiday?
Personally, I am reluctant to remove parametrisable schemas without a
bit more consultation. I have no problem with saying that true TEI
conformance necessitates production of an ODD. But I still feel we have
an obligation to make it feasible for people to customize the system
without using tools that only we provide. Which means that we need to
continue to provide customizable fragments, and describe how they can be
used. We *want* people to use TEI P5 at whatever level they feel
comfortable, right? For people still in DTDworld, the old method of
stitching together DTD fragments is just fine, and they can go on doing
it without having to learn any of this newfangled namespace stuff.
People who, by contrast, are hip to the RelaxNG groove will want to know
how to plug TEI stuff into their production line without having to
completely revise the whole shooting match. So my preferred course of
action would be:
1. Revise MD to make explicit that there is more than one way of
building a schema from the TEI Guidelines. In fact there are three:
(a) write an ODD and process it with a conformant ODD processor
(b) write a DTD subset using parameter entities and ting and ting
(c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
2. Of these ways, only (a) is guaranteed to result in a schema which can
be used to validate TEI conformance for your documents, but the others
may be helpful for local use. So we provide suggested ways of doing
them, in two distinct subsections of the document.
3. We need, urgently, a definition of what exactly a "conformant ODD
processor" is supposed to do. This might include a description of what
the current ODD processor does, but that is less important.
If, on consultation, it is apparent that no-one cares about (2) above,
we can always throw away the lovingly-crafted prose I expect to be
generating this weekend, or put it somewhere else... but I think we must
have the consultation.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Apr 04 2007 - 13:38:22 EDT

From daniel.odonnell at uleth.ca Wed Apr 4 22:36:40 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 04 Apr 2007 20:36:40 -0600 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613E227.2090909@oucs.ox.ac.uk> Message-ID: <1175740600.5448.4.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 04 Apr 2007 20:36:40 -0600
I like your proposal and the reasons.
On Wed, 2007-04-04 at 18:36 +0100, Lou Burnard wrote:
> Does no-one else on the Council have a view on this issue? Or is
> everyone already on holiday?
>
> Personally, I am reluctant to remove parametrisable schemas without a
> bit more consultation. I have no problem with saying that true TEI
> conformance necessitates production of an ODD. But I still feel we have
> an obligation to make it feasible for people to customize the system
> without using tools that only we provide. Which means that we need to
> continue to provide customizable fragments, and describe how they can be
> used. We *want* people to use TEI P5 at whatever level they feel
> comfortable, right? For people still in DTDworld, the old method of
> stitching together DTD fragments is just fine, and they can go on doing
> it without having to learn any of this newfangled namespace stuff.
> People who, by contrast, are hip to the RelaxNG groove will want to know
> how to plug TEI stuff into their production line without having to
> completely revise the whole shooting match. So my preferred course of
> action would be:
>
> 1. Revise MD to make explicit that there is more than one way of
> building a schema from the TEI Guidelines. In fact there are three:
> (a) write an ODD and process it with a conformant ODD processor
> (b) write a DTD subset using parameter entities and ting and ting
> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
>
> 2. Of these ways, only (a) is guaranteed to result in a schema which can
> be used to validate TEI conformance for your documents, but the others
> may be helpful for local use. So we provide suggested ways of doing
> them, in two distinct subsections of the document.
>
> 3. We need, urgently, a definition of what exactly a "conformant ODD
> processor" is supposed to do. This might include a description of what
> the current ODD processor does, but that is less important.
>
> If, on consultation, it is apparent that no-one cares about (2) above,
> we can always throw away the lovingly-crafted prose I expect to be
> generating this weekend, or put it somewhere else... but I think we must
> have the consultation.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Apr 04 2007 - 22:36:43 EDT
From arianna.ciula at kcl.ac.uk Thu Apr 5 05:08:22 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 05 Apr 2007 10:08:22 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613E227.2090909@oucs.ox.ac.uk> Message-ID: <4614BC86.3000203@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 05 Apr 2007 10:08:22 +0100
> 1. Revise MD to make explicit that there is more than one way of
> building a schema from the TEI Guidelines. In fact there are three:
> (a) write an ODD and process it with a conformant ODD processor
> (b) write a DTD subset using parameter entities and ting and ting
> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
I support this proposal; it would make clear the evolution from P4 and
precedent versions to P5 without simply throwing away the old methods,
but giving them a context (even if marginal compared to schemas which
can be used to validate TEI conformance --> so I agree with 2 as well).
If we will go for it, we need to be sure other chapters (e.g. SG) are
consistent with it of course.
It would be useful to have 3 (LB:"a description of what the current ODD
processor does") somewhere in the guidelines (may be in one of the
appendixes?).
Arianna
Lou Burnard wrote:
> Does no-one else on the Council have a view on this issue? Or is
> everyone already on holiday?
>
> Personally, I am reluctant to remove parametrisable schemas without a
> bit more consultation. I have no problem with saying that true TEI
> conformance necessitates production of an ODD. But I still feel we have
> an obligation to make it feasible for people to customize the system
> without using tools that only we provide. Which means that we need to
> continue to provide customizable fragments, and describe how they can be
> used. We *want* people to use TEI P5 at whatever level they feel
> comfortable, right? For people still in DTDworld, the old method of
> stitching together DTD fragments is just fine, and they can go on doing
> it without having to learn any of this newfangled namespace stuff.
> People who, by contrast, are hip to the RelaxNG groove will want to know
> how to plug TEI stuff into their production line without having to
> completely revise the whole shooting match. So my preferred course of
> action would be:
>
> 1. Revise MD to make explicit that there is more than one way of
> building a schema from the TEI Guidelines. In fact there are three:
> (a) write an ODD and process it with a conformant ODD processor
> (b) write a DTD subset using parameter entities and ting and ting
> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
>
> 2. Of these ways, only (a) is guaranteed to result in a schema which can
> be used to validate TEI conformance for your documents, but the others
> may be helpful for local use. So we provide suggested ways of doing
> them, in two distinct subsections of the document.
>
> 3. We need, urgently, a definition of what exactly a "conformant ODD
> processor" is supposed to do. This might include a description of what
> the current ODD processor does, but that is less important.
>
> If, on consultation, it is apparent that no-one cares about (2) above,
> we can always throw away the lovingly-crafted prose I expect to be
> generating this weekend, or put it somewhere else... but I think we must
> have the consultation.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Apr 05 2007 - 05:08:31 EDT
From Syd_Bauman at Brown.edu Thu Apr 5 09:45:26 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Apr 2007 09:45:26 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4614BC86.3000203@kcl.ac.uk> Message-ID: <17940.64886.701634.932767@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Apr 2007 09:45:26 -0400
While on the face of it Lou's suggestion (mention all 3 methods of
generating a complete TEI schema: via ODD, parametrized DTD, or
stitching RNG) seems quite reasonable, Arianna's point that we would
then need to make sure SG explained both DTDs and RNG enough to do
this is a strong argument against, IMHO.
SG should not mention details of DTDs at all. (And yes, Lou,
stripping 'em out is still on my plate). Nor should the rest of the
Guidelines rely on DTD syntax at all.
There are lots of non-conformant methods of making a schema that will
validate TEI documents that could be conformant.[1] I do not think
the Guidelines themselves should discuss any of them. The Guidelines
are already daunting enough. Why add large sections of potentially
confusing information that will likely be used by an extraordinarily
small number of users (perhaps 0), to explain something that isn't
even conformant?
Again, a separate paper or HOWTO explaining this may be a good idea.

BTW, does anyone actually know how to go about stitching together the
RNG schema fragments in a manner that permits similar capabilities to
using parametrized DTDs? We would have to figure out how to do it
(although, because this is not conformant, I daresay we do not have
to figure out how to do it optimally), do extensive testing, and
write up a serious chunk of prose instructions.

Notes
-----
[1] E.g. (untested):
namespace tei = "http://www.tei-c.org/ns/1.0"
attrs = attribute xml:id { xsd:ID }
p = element tei:p { text }
start =
element tei:TEI {
attrs,
element tei:teiHeader {
attrs,
element tei:fileDesc {
attrs,
element tei:titleStmt {
attrs,
element tei:title { attrs, text }
},
element tei:publicationStmt { attrs, p+ },
element tei:sourceDesc { attrs, p+ }
}
},
element tei:text {
attrs,
element tei:body { attrs, p+ }
}
}
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Apr 05 2007 - 09:45:30 EDT

From arianna.ciula at kcl.ac.uk Thu Apr 5 10:04:41 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 05 Apr 2007 15:04:41 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17940.64886.701634.932767@emt.wwp.brown.edu> Message-ID: <461501F9.3020200@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 05 Apr 2007 15:04:41 +0100
Syd Bauman wrote:
> While on the face of it Lou's suggestion (mention all 3 methods of
> generating a complete TEI schema: via ODD, parametrized DTD, or
> stitching RNG) seems quite reasonable, Arianna's point that we would
> then need to make sure SG explained both DTDs and RNG enough to do
> this is a strong argument against, IMHO.
>
Probably I didn't explain myself properly. What I meant is that whatever
you editors decide to do (e.g. leave or take out the references to the
use of parameter entities to stitch DTD fragments in SG), this needs to
be consistent with what you say in MD or in your HOWTo do paper. So, for
instance, if there are references to the way you can stitch DTD
fragments and not references to the way you would do the same with
RelaxNG, this needs to be explained rather than left to the reader to
figure out that the old DTD method is there because it was once used and
supported by TEI.
> The Guidelines
> are already daunting enough. Why add large sections of potentially
> confusing information that will likely be used by an extraordinarily
> small number of users (perhaps 0), to explain something that isn't
> even conformant?
I agree that it may be overwhelming to add all this prose on
introductory chapters and, personally, I wouldn't mind if these
explanations were confined somewhere else even outside the guidelines if
that matters, but I do think they should be accessible and mentioned at
least. In any case, I don't want to sound pedantic. At the end of the
day, you have to write additional prose, so if adding this information
takes time from more urgent stuff, I am totally in favour of postponing
work on this.
Arianna

-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cc _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Apr 05 2007 - 10:05:07 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Apr 5 10:04:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Apr 2007 15:04:52 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17940.64886.701634.932767@emt.wwp.brown.edu> Message-ID: <46150204.2030103@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 05 Apr 2007 15:04:52 +0100
Syd Bauman wrote:
> While on the face of it Lou's suggestion (mention all 3 methods of
> generating a complete TEI schema: via ODD, parametrized DTD, or
> stitching RNG) seems quite reasonable, Arianna's point that we would
> then need to make sure SG explained both DTDs and RNG enough to do
> this is a strong argument against, IMHO.
Depends what "it" is. It only has to explain enough for the further
explanation in MD to be comprehensible.
>
> SG should not mention details of DTDs at all. (And yes, Lou,
> stripping 'em out is still on my plate). Nor should the rest of the
> Guidelines rely on DTD syntax at all.

When you get around to reviewing the mail on this list following
Arianna's work on that chapter, you may (possibly) notice that this
issue has already been raised there.

>
> There are lots of non-conformant methods of making a schema that will
> validate TEI documents that could be conformant.[1] I do not think
> the Guidelines themselves should discuss any of them. The Guidelines
> are already daunting enough. Why add large sections of potentially
> confusing information that will likely be used by an extraordinarily
> small number of users (perhaps 0), to explain something that isn't
> even conformant?
It is your assertion, and your assertion only, that no one will be
interested in making a schema capable of validating TEI conformant
documents without using ODD. You may be right, you may be wrong. But
simply repeating the assertion doesn't make it true. Nor does it address
the counter arguments raised in my earlier posting on this topic.
>
> Again, a separate paper or HOWTO explaining this may be a good idea.
>
>
> BTW, does anyone actually know how to go about stitching together the
> RNG schema fragments in a manner that permits similar capabilities to
> using parametrized DTDs?
Anyone capable of reading the output from Roma maybe?
We would have to figure out how to do it
> (although, because this is not conformant, I daresay we do not have
> to figure out how to do it optimally), do extensive testing, and
> write up a serious chunk of prose instructions.
Yes, that's what I said earlier.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Apr 05 2007 - 10:06:38 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Apr 5 21:21:30 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 06 Apr 2007 10:21:30 +0900 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <46144959.8050803@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4615A09A.7060907@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Fri, 06 Apr 2007 10:21:30 +0900
Sorry, folks -- this seems to have gone only to LB, not the Council list
where it was intended to.
Christian

Christian Wittern wrote:
> Lou Burnard wrote:
>> Does no-one else on the Council have a view on this issue? Or is
>> everyone already on holiday?
>
> We are a global organization, so you should at least let pass 24 hrs
> before any cry of desparation. But I agree that we need more input on
> this important matter.
>
>>
>> Personally, I am reluctant to remove parametrisable schemas without a
>> bit more consultation. I have no problem with saying that true TEI
>> conformance necessitates production of an ODD. But I still feel we
>> have an obligation to make it feasible for people to customize the
>> system without using tools that only we provide. Which means that we
>> need to continue to provide customizable fragments, and describe how
>> they can be used. We *want* people to use TEI P5 at whatever level
>> they feel comfortable, right?
>
> Maybe its survey-monkey time again?
> I remember us saying that we will continue to maintain P4 for those who
> need it for some reason, but will pipe new developments into P5 without
> too much consideration for how this will brake peoples *current*
> systems. Well, this was some years ago.
>
> With P5 now so deep into namespaces, data validation etc., we have moved
> pretty much away from things possible in DTDs. Because of editing
> support, we should continue to offer pre-a-porter DTDs for those who
> don't want to dress up, but I do not think we should continue to support
> the customization mechanism of P4. If we do not let go of this now, it
> will be a big headache down the road, since we stopped ourselve from
> removing it later in the P5 product cycle.
>
>> For people still in DTDworld, the old method of stitching together DTD
>> fragments is just fine, and they can go on doing it without having to
>> learn any of this newfangled namespace stuff.
>
> We will do them a mis-service. They will want to grow up and live on
> equal footing in XML-Land, so they need to wrap their heads around this
> stuff. We should mildly encourage them to do so.
>
>> People who, by contrast, are hip to the RelaxNG groove will want to
>> know how to plug TEI stuff into their production line without having
>> to completely revise the whole shooting match. So my preferred course
>> of action would be:
>>
>> 1. Revise MD to make explicit that there is more than one way of
>> building a schema from the TEI Guidelines. In fact there are three:
>> (a) write an ODD and process it with a conformant ODD processor
>> (b) write a DTD subset using parameter entities and ting and ting
>> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
>
> My course would be: do (a), forget about (b) and either mention (c) in a
> footnote or point to some white paper on the TEI website that explains
> how to do that, clearly marked as advanced material.
>
>> 2. Of these ways, only (a) is guaranteed to result in a schema which
>> can be used to validate TEI conformance for your documents, but the
>> others may be helpful for local use. So we provide suggested ways of
>> doing them, in two distinct subsections of the document.
>
> Hmm. I read the I in TEI as Interchange and think it is not really our
> business to think about what people should or should not do in the
> privacy of their own hard-drives.
>
>>
>> 3. We need, urgently, a definition of what exactly a "conformant ODD
>> processor" is supposed to do. This might include a description of what
>> the current ODD processor does, but that is less important.
>
> Hopefully Sebastian thinks about this while we speak.
>
>>
>> If, on consultation, it is apparent that no-one cares about (2) above,
>> we can always throw away the lovingly-crafted prose I expect to be
>> generating this weekend, or put it somewhere else... but I think we
>> must have the consultation.
>
> So maybe you could use your time to attend to other pressing matters and
> produce the prose once we reached agreement over this? I think that
> would be better use of our scarce ressources.
>
> All the best, "no holidays in sight" Christian
>
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Apr 06 2007 - 00:37:37 EDT

From daniel.odonnell at uleth.ca Fri Apr 6 12:21:58 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 06 Apr 2007 10:21:58 -0600 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4615A09A.7060907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1175876518.6146.5.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 06 Apr 2007 10:21:58 -0600
I think also that the issues are getting fine enough that it may be
difficult to have a strong opinion: personally I think I am an a and c
person in Christian's formulation: ODD as the recommended standard,
footnote or whitepaper on RNG, and drop the DTD for P5. I also suspect
from conversations I've had that we are likely to see a legacy of P4
projects for quite a while--especially institutional ones--so, I'm happy
dropping the dtd business for conformance for P5 anyway.
As to ODD processors--I've no informed opinion.
On Fri, 2007-04-06 at 10:21 +0900, Christian Wittern wrote:
> Sorry, folks -- this seems to have gone only to LB, not the Council list
> where it was intended to.
>
> Christian
>
>
> Christian Wittern wrote:
> > Lou Burnard wrote:
> >> Does no-one else on the Council have a view on this issue? Or is
> >> everyone already on holiday?
> >
> > We are a global organization, so you should at least let pass 24 hrs
> > before any cry of desparation. But I agree that we need more input on
> > this important matter.
> >
> >>
> >> Personally, I am reluctant to remove parametrisable schemas without a
> >> bit more consultation. I have no problem with saying that true TEI
> >> conformance necessitates production of an ODD. But I still feel we
> >> have an obligation to make it feasible for people to customize the
> >> system without using tools that only we provide. Which means that we
> >> need to continue to provide customizable fragments, and describe how
> >> they can be used. We *want* people to use TEI P5 at whatever level
> >> they feel comfortable, right?
> >
> > Maybe its survey-monkey time again?
> > I remember us saying that we will continue to maintain P4 for those who
> > need it for some reason, but will pipe new developments into P5 without
> > too much consideration for how this will brake peoples *current*
> > systems. Well, this was some years ago.
> >
> > With P5 now so deep into namespaces, data validation etc., we have moved
> > pretty much away from things possible in DTDs. Because of editing
> > support, we should continue to offer pre-a-porter DTDs for those who
> > don't want to dress up, but I do not think we should continue to support
> > the customization mechanism of P4. If we do not let go of this now, it
> > will be a big headache down the road, since we stopped ourselve from
> > removing it later in the P5 product cycle.
> >
> >> For people still in DTDworld, the old method of stitching together DTD
> >> fragments is just fine, and they can go on doing it without having to
> >> learn any of this newfangled namespace stuff.
> >
> > We will do them a mis-service. They will want to grow up and live on
> > equal footing in XML-Land, so they need to wrap their heads around this
> > stuff. We should mildly encourage them to do so.
> >
> >> People who, by contrast, are hip to the RelaxNG groove will want to
> >> know how to plug TEI stuff into their production line without having
> >> to completely revise the whole shooting match. So my preferred course
> >> of action would be:
> >>
> >> 1. Revise MD to make explicit that there is more than one way of
> >> building a schema from the TEI Guidelines. In fact there are three:
> >> (a) write an ODD and process it with a conformant ODD processor
> >> (b) write a DTD subset using parameter entities and ting and ting
> >> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
> >
> > My course would be: do (a), forget about (b) and either mention (c) in a
> > footnote or point to some white paper on the TEI website that explains
> > how to do that, clearly marked as advanced material.
> >
> >> 2. Of these ways, only (a) is guaranteed to result in a schema which
> >> can be used to validate TEI conformance for your documents, but the
> >> others may be helpful for local use. So we provide suggested ways of
> >> doing them, in two distinct subsections of the document.
> >
> > Hmm. I read the I in TEI as Interchange and think it is not really our
> > business to think about what people should or should not do in the
> > privacy of their own hard-drives.
> >
> >>
> >> 3. We need, urgently, a definition of what exactly a "conformant ODD
> >> processor" is supposed to do. This might include a description of what
> >> the current ODD processor does, but that is less important.
> >
> > Hopefully Sebastian thinks about this while we speak.
> >
> >>
> >> If, on consultation, it is apparent that no-one cares about (2) above,
> >> we can always throw away the lovingly-crafted prose I expect to be
> >> generating this weekend, or put it somewhere else... but I think we
> >> must have the consultation.
> >
> > So maybe you could use your time to attend to other pressing matters and
> > produce the prose once we reached agreement over this? I think that
> > would be better use of our scarce ressources.
> >
> > All the best, "no holidays in sight" Christian
> >
> >
>
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Apr 06 2007 - 12:22:02 EDT
From Syd_Bauman at Brown.edu Fri Apr 6 14:02:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 6 Apr 2007 14:02:52 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <46150204.2030103@oucs.ox.ac.uk> Message-ID: <17942.35660.718823.915509@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 6 Apr 2007 14:02:52 -0400
> Depends what "it" is. It only has to explain enough for the further
> explanation in MD to be comprehensible.
Absolutely true, but I'm claiming that's too much.

> It is your assertion, and your assertion only, that no one will be
> interested in making a schema capable of validating TEI conformant
> documents without using ODD. You may be right, you may be wrong.
Not quite. But I do think few enough people will want to do so
strongly enough that putting instructions on doing so in the
Guidelines is counter-productive. Discussions of parametrized DTDs
will add more confusion to more people than it will help those few
who might really want to do this.

> > BTW, does anyone actually know how to go about stitching together
> > the RNG schema fragments in a manner that permits similar
> > capabilities to using parametrized DTDs?
>
> Anyone capable of reading the output from Roma maybe?
Which output from Roma did you have in mind?
In any case, I'm guessing you think I mean "stitch together a schema
which loads some TEI modules", which I agree, is not particularly
difficult. But I had more complex customizations in mind. E.g.,
things like
* load core, tei, header, and textstructure (of course)
* also load gaiji & figures
* change things 'round so that is only permitted as a child of

* move

to model.global
* make a required child of

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Apr 06 2007 - 14:02:56 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Apr 6 18:12:14 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 06 Apr 2007 23:12:14 +0100 Subject: [tei-council] floating text launched Message-ID: <4616C5BE.3010803@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 06 Apr 2007 23:12:14 +0100
Following my plea for examples of floating texts earlier this week, I
am pleased to report that Julia duly delivered a splendid one, which I
have now duly incorporated into the text of DS. At the same time I was
doing this, I received notice from Arianna of a whole bunch of other
errors in the same chapter, which I was thus able to despatch at the
same time. Many thanks to both.
The corrected (and expanded) version is now checked into the main
branch. As this is new material which all Council members ought to
review, I have also put a copy of the revised draft chapter in HTML
format on the website at http://www.tei-c.org/Drafts/DS.html
Don't expect any of the links in it to work as I haven't put any of the
other chapters there! If you just want to cut straight to the chase to
find out what on earth a floating text is, go to
http://www.tei-c.org/Drafts/DS.html#DSFLT

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Apr 06 2007 - 18:12:18 EDT

From Syd_Bauman at Brown.edu Fri Apr 6 20:08:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 6 Apr 2007 20:08:21 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17942.57589.177531.95758@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 6 Apr 2007 20:08:21 -0400
LB> 1. Revise MD to make explicit that there is more than one way of
LB> building a schema from the TEI Guidelines. In fact there are three:
LB> (a) write an ODD and process it with a conformant ODD processor
LB> (b) write a DTD subset using parameter entities and ting and ting
LB> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
CW> My course would be: do (a), forget about (b) and either mention
CW> (c) in a footnote or point to some white paper on the TEI website
CW> that explains how to do that, clearly marked as advanced
CW> material.
So far I agree with you completely, Christian.

CW> This is what we invented ODD and Roma for. Whats the point in
CW> showing people how to do this on foot?
But now you've lost me. Are you thinking that "stitching together" a
Relax NG Schema for validating TEI instances should do nothing more
than module selection? I (apparently incorrectly) took Lou's
"combines TEI RelaxNG modules" to mean the same thing I have been
talking about, which includes the usual kinds of customizations users
need (without the documentation and perhaps some of the rigor ODD
provides, and thus a non-conformant methodology).
I think module selection alone would be insufficient. The point of a
schema is to provide constraint -- the user has to mold it so that it
provides the constraint she wants, else it is not a very useful
feature.

I think it may be a good idea to discuss/show/demonstrate how to do
this because, as has been pointed out
* user may not have easy access to roma or webRoma
* it's rude to insist people use a system for which the only supplier
of software is us
In P4 the user didn't need a tool at all. Just a text editor and a
copy of the Guidelines would do the trick. (Although I have to admit,
a copy of Goldfarb is a good idea, too :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Apr 06 2007 - 20:08:26 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Apr 6 19:27:56 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 07 Apr 2007 08:27:56 +0900 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17942.35660.718823.915509@emt.wwp.brown.edu> Message-ID: <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp>
From: Christian Wittern
Date: Sat, 07 Apr 2007 08:27:56 +0900
Syd Bauman wrote:
>> Anyone capable of reading the output from Roma maybe?
>
> Which output from Roma did you have in mind?
>
> In any case, I'm guessing you think I mean "stitch together a schema
> which loads some TEI modules", which I agree, is not particularly
> difficult. But I had more complex customizations in mind. E.g.,
> things like
> * load core, tei, header, and textstructure (of course)
> * also load gaiji & figures
> * change things 'round so that is only permitted as a child of
>
> * move
to model.global
> * make a required child of

This is what we invented ODD and Roma for. Whats the point in showing
people how to do this on foot?
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Apr 06 2007 - 20:09:07 EDT

From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 08:00:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 13:00:23 +0100 Subject: [tei-council] ODD processing and renaming Message-ID: <461787D7.4030500@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 07 Apr 2007 13:00:23 +0100
Given

yyy

we expect to generate a "foo" declaration for something called yyy
However, given

yyy
zzz

we will generate a "foo" declaration for something called zzz iff we
are producing a schema in language xx, and one for yyy otherwise.
Is overloading xml:lang in this way preferable to having an explicit
attribute on the which says "use ME" ? (Note that the current
scheme gives us no way of saying "here's another name for this element
in some language but don't use it")

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Apr 07 2007 - 08:00:25 EDT

From Syd_Bauman at Brown.edu Sat Apr 7 09:03:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 09:03:25 -0400 Subject: [tei-council] ODD processing and renaming In-Reply-To: <461787D7.4030500@computing-services.oxford.ac.uk> Message-ID: <17943.38557.51071.828895@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 7 Apr 2007 09:03:25 -0400
Perhaps because I'm used to the current system, or perhaps because
it's still morning here, I don't think I understand what the
advantage of a useMe="yes" on would be.
Current encoding lets an ODD processor:
* use *Spec/@ident, ignoring s
* use altIdent[xml:lang="xx"] if present, otherwise altIdent[xml:lang="en"]
if present, otherwise *Spec/@ident (what I would call the
"expected" behavior, but as I said, perhaps just because that's
what I think ours does)
* use altIdent[xml:lang="xx"] if present, *Spec/@ident
otherwise (ignoring altIdent[xml:lang="en"])
* Arrange possible languages in a desired languages in order (likely
to be user-specified, of course. i.e.:
use altIdent/[xml:lang="x1"] if present,
if not, use altIdent/[xml:lang="x2"] if present,
if not, use altIdent/[xml:lang="x3"] if present,
if not, use altIdent/[xml:lang="x4"] if present,
if not, use altIdent/[xml:lang="en"] if present,
if not, use *Spec/@ident.

> Is overloading xml:lang in this way preferable to having an
> explicit attribute on the which says "use ME" ? (Note
> that the current scheme gives us no way of saying "here's another
> name for this element in some language but don't use it")
I'm having some trouble wrapping my brain around that. Why would we
want to put a name for an element/attribute/class/macro in the ODD
and then tell the ODD processor not to use it?
Maybe what you're objecting to is that there can only be 1 identifier
per any given language, except for English, which (because it is the
canonical language) has 2 possibilities?
On quick thought, this doesn't bother me too much. Nothing stops a
user from using RFC 3066 tags in a more fine-grained manner:
hypertextDivision
hyperDiv
ldb
Notes
-----
* Remember, that these names are not *in* a natural language -- they
are arbitrary identifiers chosen to be easy for native speakers of
a particular natural language to remember. This, IMHO, is an
argument for not using xml:lang=.
* IIRC, the only special restriction RFC 3066 places on the second
subtag is that it may not be two letters long unless it is a
country code from ISO 3166 or whatever. (And in which case it is
recommended, but not required, that it be in upper case.) Also
1-letter codes may not be registered with IANA, but I don't think
that's an issue here :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Apr 07 2007 - 09:03:27 EDT

From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 10:01:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 15:01:51 +0100 Subject: [tei-council] Minimal TEI schema Message-ID: <4617A44F.50705@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 07 Apr 2007 15:01:51 +0100
We have abolished the distinction between base and additional tag sets.
But we have retained the idea that a conformant document must have a
header. This suggests that the minimal combination of modules needed for
TEI conformance must include the header. Furthermore, if a conformant
document must have a root of TEI or teiCorpus, we must include the
textstructure module. Since every element (I think without exception) in
those two modules makes use of at least one class defined by the TEI
module, you won't get far without that. And it's hard to see how you can
get by without at least one element from the Core module, though I am
not quite so sure of that as I am of the others.
SO, today's question : should we state that a minimal requirement for
TEI conformance is that the schema in question uses those four modules
(header, textstructure, tei, core)? I don't see that assertion spelled
out in the current draft, though there is reference to "the TEI basic
four modules" which is presumably the same thing.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Apr 07 2007 - 10:01:54 EDT
From Syd_Bauman at Brown.edu Sat Apr 7 10:31:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 10:31:24 -0400 Subject: [tei-council] Minimal TEI schema In-Reply-To: <4617A44F.50705@computing-services.oxford.ac.uk> Message-ID: <17943.43836.477780.598730@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 7 Apr 2007 10:31:24 -0400
> And it's hard to see how you can get by without at least one
> element from the Core module, though I am not quite so sure of that
> as I am of the others.
By default if you load only tei, header, and textstructure (but not
core) you get an invalid schema.
You could, of course, delete the elements that are referenced but not
declared. You would get a valid schema, but it wouldn't have the
element, and <sourceDesc> would have to contain a <br /> <recordingStmt> with any number of nested empty <recording> and <br /> <broadcast> elements. <br /> <p><em class="quotelev1">> SO, today's question : should we state that a minimal requirement </em><br /> <em class="quotelev1">> for TEI conformance is that the schema in question uses those four </em><br /> <em class="quotelev1">> modules (header, textstructure, tei, core)? I don't see that </em><br /> <em class="quotelev1">> assertion spelled out in the current draft, though there is </em><br /> <em class="quotelev1">> reference to "the TEI basic four modules" which is presumably the </em><br /> <em class="quotelev1">> same thing. </em><br /> While it isn't strictly necessary (I think I can come up with an ODD <br /> that would not use core, but otherwise would make sense to call <br /> conformant), I think it would be much easier on everyone involved <br /> (users, editors, council members) to just say core is required. After <br /> all, the schema generated from an ODD that does not use core cannot <br /> be used to encode anything, it's just an oddity :-) Only those of us <br /> who are interested in writing papers about literate schema-building <br /> and the interaction between prose and formal rules are going to care. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 10:31:28 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 12:40:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 17:40:35 +0100 Subject: [tei-council] namespaces and modifications Message-ID: <4617C983.4040502@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 17:40:35 +0100</span><br /> </address> The consensus seems to be that if I add a completely new element, it <br /> makes sense to define it as belonging to a new namespace. Presumably the <br /> same also applies if I define a new attribute for an existing element, <br /> so I could get by with just putting the new attribute in a non-TEI <br /> namespace. But hold on, what if I get the new attribute by adding the <br /> element to an existing attribute class which it wasn't in before? Now I <br /> have to distinguish the @type I get from att.<!--nospam-->typed in a kosher manner <br /> from the exact same attribute which I got by modification! <br /> It seems to me that the only sane thing to do is to say that my newly <br /> modified element is in a new namespace, and leave it at that. So if <br /> there is a TEI:foo, and a my:foo, and even the bits of my:foo which are <br /> unchanged from the TEI scheme are still in a different namespace as soon <br /> as I tweak any part of it. <br /> <p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 12:40:38 EDT</span> </div> From daniel.odonnell at uleth.ca Sat Apr 7 13:18:41 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 07 Apr 2007 11:18:41 -0600 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617C983.4040502@computing-services.oxford.ac.uk> Message-ID: <1175966322.6824.2.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 11:18:41 -0600</span><br /> </address> As somebody has done both of these things, I can say that this sounds <br /> reasonable--in fact is probably helpful as it reminds one constantly of <br /> the modifications. <br /> When I did some of these kind of modifications in P3 SGML (I messed <br /> around with w and added a couple of other things) it was an issue to <br /> remember what had changed and how. I think this is a useful conformance <br /> approach. <br /> -dan <br /> On Sat, 2007-04-07 at 17:40 +0100, Lou Burnard wrote: <br /> <em class="quotelev1">> The consensus seems to be that if I add a completely new element, it </em><br /> <em class="quotelev1">> makes sense to define it as belonging to a new namespace. Presumably the </em><br /> <em class="quotelev1">> same also applies if I define a new attribute for an existing element, </em><br /> <em class="quotelev1">> so I could get by with just putting the new attribute in a non-TEI </em><br /> <em class="quotelev1">> namespace. But hold on, what if I get the new attribute by adding the </em><br /> <em class="quotelev1">> element to an existing attribute class which it wasn't in before? Now I </em><br /> <em class="quotelev1">> have to distinguish the @type I get from att.<!--nospam-->typed in a kosher manner </em><br /> <em class="quotelev1">> from the exact same attribute which I got by modification! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> It seems to me that the only sane thing to do is to say that my newly </em><br /> <em class="quotelev1">> modified element is in a new namespace, and leave it at that. So if </em><br /> <em class="quotelev1">> there is a TEI:foo, and a my:foo, and even the bits of my:foo which are </em><br /> <em class="quotelev1">> unchanged from the TEI scheme are still in a different namespace as soon </em><br /> <em class="quotelev1">> as I tweak any part of it. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 13:18:46 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 13:31:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 18:31:33 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617C983.4040502@computing-services.oxford.ac.uk> Message-ID: <4617D575.7090503@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 18:31:33 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> The consensus seems to be that if I add a completely new element, it </em><br /> <em class="quotelev1">> makes sense to define it as belonging to a new namespace. Presumably the </em><br /> <em class="quotelev1">> same also applies if I define a new attribute for an existing element, </em><br /> <em class="quotelev1">> so I could get by with just putting the new attribute in a non-TEI </em><br /> <em class="quotelev1">> namespace. But hold on, what if I get the new attribute by adding the </em><br /> <em class="quotelev1">> element to an existing attribute class which it wasn't in before? Now I </em><br /> <em class="quotelev1">> have to distinguish the @type I get from att.<!--nospam-->typed in a kosher manner </em><br /> <em class="quotelev1">> from the exact same attribute which I got by modification! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> It seems to me that the only sane thing to do is to say that my newly </em><br /> <em class="quotelev1">> modified element is in a new namespace, and leave it at that. So if </em><br /> <em class="quotelev1">> there is a TEI:foo, and a my:foo, and even the bits of my:foo which are </em><br /> <em class="quotelev1">> unchanged from the TEI scheme are still in a different namespace as soon </em><br /> <em class="quotelev1">> as I tweak any part of it. </em><br /> Hrmmm. If I've added a brand new element, my:foo, I've done so in my own <br /> namespace, of course. But if I add it to class att.typed, it joins that club <br /> and gets the TEI element tei:typed, right? So, playing devil's advocate, why <br /> should that attribute be in any other namespace than the TEI? As long as it is <br /> still a TEI attribute, it should be in the TEI namespace, right? Just like we <br /> use xml:id and xml:lang. <br /> <tei:div xmlns:tei="http://www.tei-c.org/ns/1.0" my:newAtt="blort"> <br /> <my:foo xmlns:my="http://my-new-namespace.info/" tei:type="wibble"/> <br /> </tei:div> <br /> <p>I'm happy to be argued down about this, I just want to make sure we are clear on <br /> the reasons why. So explain it to me again like I'm even more ignorant than I <br /> am.... <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 13:31:37 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 13:46:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 18:46:52 +0100 Subject: [tei-council] Minimal TEI schema In-Reply-To: <17943.43836.477780.598730@emt.wwp.brown.edu> Message-ID: <4617D90C.2090508@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 18:46:52 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> SO, today's question : should we state that a minimal requirement </em><br /> <em class="quotelev2">>> for TEI conformance is that the schema in question uses those four </em><br /> <em class="quotelev2">>> modules (header, textstructure, tei, core)? I don't see that </em><br /> <em class="quotelev2">>> assertion spelled out in the current draft, though there is </em><br /> <em class="quotelev2">>> reference to "the TEI basic four modules" which is presumably the </em><br /> <em class="quotelev2">>> same thing. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> While it isn't strictly necessary (I think I can come up with an ODD </em><br /> <em class="quotelev1">> that would not use core, but otherwise would make sense to call </em><br /> <em class="quotelev1">> conformant), I think it would be much easier on everyone involved </em><br /> <em class="quotelev1">> (users, editors, council members) to just say core is required. After </em><br /> <em class="quotelev1">> all, the schema generated from an ODD that does not use core cannot </em><br /> <em class="quotelev1">> be used to encode anything, it's just an oddity :-) Only those of us </em><br /> <em class="quotelev1">> who are interested in writing papers about literate schema-building </em><br /> <em class="quotelev1">> and the interaction between prose and formal rules are going to care. </em><br /> Do we need our definition of Conformance to necessarily reference what modules <br /> you must use? While I can't picture anything other than 99.9% TEI Conformant <br /> documents using Core, I'm not as sure that we need to specify that XYZ modules <br /> must be included in the ODD for your document (that validates against the schema <br /> generated from that ODD) to be Conformant. While almost everyone is going to do <br /> this anyway, does it benefit us to make it a requirement? <br /> To be honest, I'm ambivalent, but wondered why this should be a requirement. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 13:46:57 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 14:06:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 19:06:54 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617D575.7090503@computing-services.oxford.ac.uk> Message-ID: <4617DDBE.9070506@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 19:06:54 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">>> The consensus seems to be that if I add a completely new element, it </em><br /> <em class="quotelev2">>> makes sense to define it as belonging to a new namespace. Presumably </em><br /> <em class="quotelev2">>> the same also applies if I define a new attribute for an existing </em><br /> <em class="quotelev2">>> element, so I could get by with just putting the new attribute in a </em><br /> <em class="quotelev2">>> non-TEI namespace. But hold on, what if I get the new attribute by </em><br /> <em class="quotelev2">>> adding the element to an existing attribute class which it wasn't in </em><br /> <em class="quotelev2">>> before? Now I have to distinguish the @type I get from att.<!--nospam-->typed in a </em><br /> <em class="quotelev2">>> kosher manner from the exact same attribute which I got by modification! </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> It seems to me that the only sane thing to do is to say that my newly </em><br /> <em class="quotelev2">>> modified element is in a new namespace, and leave it at that. So if </em><br /> <em class="quotelev2">>> there is a TEI:foo, and a my:foo, and even the bits of my:foo which </em><br /> <em class="quotelev2">>> are unchanged from the TEI scheme are still in a different namespace </em><br /> <em class="quotelev2">>> as soon as I tweak any part of it. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Hrmmm. If I've added a brand new element, my:foo, I've done so in my </em><br /> <em class="quotelev1">> own namespace, of course. But if I add it to class att.typed, it </em><br /> <em class="quotelev1">> joins that club and gets the TEI element tei:typed, right? So, </em><br /> <em class="quotelev1">> playing devil's advocate, why should that </em><br /> eh? do you mean it gets the TEI attribute tei:type? <br /> <em class="quotelev1">> attribute be in any other namespace than the TEI? As long as it is </em><br /> <em class="quotelev1">> still a TEI attribute, it should be in the TEI namespace, right? Just </em><br /> <em class="quotelev1">> like we use xml:id and xml:lang. </em><br /> <em class="quotelev1">> </em><br /> well, yes that was the point of my query. It's just that my head started <br /> to hurt when I started thinking about how to document the rules here. <br /> <em class="quotelev1">> <tei:div xmlns:tei="http://www.tei-c.org/ns/1.0" my:newAtt="blort"> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <my:foo xmlns:my="http://my-new-namespace.info/" tei:type="wibble"/> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </tei:div> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm happy to be argued down about this, I just want to make sure we </em><br /> <em class="quotelev1">> are clear on the reasons why. So explain it to me again like I'm even </em><br /> <em class="quotelev1">> more ignorant than I am.... </em><br /> just about to check in a revised version of MD which maybe will help... <br /> <p><em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 14:06:57 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 14:35:41 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 19:35:41 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617DDBE.9070506@computing-services.oxford.ac.uk> Message-ID: <4617E47D.8080408@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 19:35:41 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev2">>> Hrmmm. If I've added a brand new element, my:foo, I've done so in my </em><br /> <em class="quotelev2">>> own namespace, of course. But if I add it to class att.typed, it </em><br /> <em class="quotelev2">>> joins that club and gets the TEI element tei:typed, right? So, </em><br /> <em class="quotelev2">>> playing devil's advocate, why should that </em><br /> <em class="quotelev1">> eh? do you mean it gets the TEI attribute tei:type? </em><br /> erm yes, exactly. Sorry, typo. <br /> <em class="quotelev1">> well, yes that was the point of my query. It's just that my head started </em><br /> <em class="quotelev1">> to hurt when I started thinking about how to document the rules here. </em><br /> Yes, I can understand that. All existing TEI elements and attributes are in the <br /> TEI namespace, even if used on new elements in a different namespace? <br /> <p><em class="quotelev1">> just about to check in a revised version of MD which maybe will help... </em><br /> I look forward to it. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 14:35:45 EDT</span> </div> From Syd_Bauman at Brown.edu Sat Apr 7 18:18:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 18:18:18 -0400 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617D575.7090503@computing-services.oxford.ac.uk> Message-ID: <17944.6314.687475.774701@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 7 Apr 2007 18:18:18 -0400</span><br /> </address> <em class="quotelev1">> Hrmmm. If I've added a brand new element, my:foo, I've done so in </em><br /> <em class="quotelev1">> my own namespace, of course. But if I add it to class att.typed, it </em><br /> <em class="quotelev1">> joins that club and gets the TEI element tei:typed, right? </em><br /> This turns out not to be the case. Being added to class att.typed <br /> gets you the TEI attribute type=, *not* the attribute tei:type=. <br /> Attributes, unless explicitly qualified, are in no namespace. <br /> "The namespace name for an unprefixed attribute name always has no <br /> value." -- http://www.w3.org/TR/REC-xml-names/#defaulting <br /> <p>But Lou has pointed out some of the major headaches I was referring <br /> to when this came up. Things like the following. <br /> * What if user adds new attribute to existing TEI element? Does she <br /> have to put it in her namespace, or can it be in no namespace like <br /> the other attributes? <br /> * What if a user deletes attributes from a standard TEI element -- <br /> does that element now have to get moved from the TEI namespace to <br /> her namespace? Especially if it was a required attribute, normal <br /> TEI software may not be able to process that element anymore. <br /> * If she deletes an attribute from an attribute class, do all members <br /> of that class now have to change namespace? <br /> * What if a user adds an existing TEI element to an existing TEI <br /> attribute class, such that it now has attributes it doesn't have in <br /> vanilla? <br /> * What about the reverse: she removes an element from an existing <br /> attribute class? <br /> And we haven't even started to think about changing model classes and <br /> content models yet! <br /> Issues like this are why I think this general idea that putting new <br /> elements in a different namespace will help in processing TEI <br /> documents is tenuous at best. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 07 2007 - 18:18:22 EDT</span> </div> From daniel.odonnell at uleth.ca Sun Apr 8 00:16:06 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 07 Apr 2007 22:16:06 -0600 Subject: [tei-council] namespaces and modifications In-Reply-To: <17944.6314.687475.774701@emt.wwp.brown.edu> Message-ID: <1176005766.6261.6.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 07 Apr 2007 22:16:06 -0600</span><br /> </address> On Sat, 2007-04-07 at 18:18 -0400, Syd Bauman wrote: <br /> <em class="quotelev2">> > Hrmmm. If I've added a brand new element, my:foo, I've done so in </em><br /> <em class="quotelev2">> > my own namespace, of course. But if I add it to class att.typed, it </em><br /> <em class="quotelev2">> > joins that club and gets the TEI element tei:typed, right? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This turns out not to be the case. Being added to class att.typed </em><br /> <em class="quotelev1">> gets you the TEI attribute type=, *not* the attribute tei:type=. </em><br /> <em class="quotelev1">> Attributes, unless explicitly qualified, are in no namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> "The namespace name for an unprefixed attribute name always has no </em><br /> <em class="quotelev1">> value." -- http://www.w3.org/TR/REC-xml-names/#defaulting </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> But Lou has pointed out some of the major headaches I was referring </em><br /> <em class="quotelev1">> to when this came up. Things like the following. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * What if user adds new attribute to existing TEI element? Does she </em><br /> <em class="quotelev1">> have to put it in her namespace, </em><br /> Yes. <br /> <em class="quotelev1">> or can it be in no namespace like </em><br /> <em class="quotelev1">> the other attributes? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * What if a user deletes attributes from a standard TEI element -- </em><br /> <em class="quotelev1">> does that element now have to get moved from the TEI namespace to </em><br /> <em class="quotelev1">> her namespace? </em><br /> Yes. <br /> <em class="quotelev1">> Especially if it was a required attribute, normal </em><br /> <em class="quotelev1">> TEI software may not be able to process that element anymore. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * If she deletes an attribute from an attribute class, do all members </em><br /> <em class="quotelev1">> of that class now have to change namespace? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * What if a user adds an existing TEI element to an existing TEI </em><br /> <em class="quotelev1">> attribute class, such that it now has attributes it doesn't have in </em><br /> <em class="quotelev1">> vanilla? </em><br /> I think yes--own namespace <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * What about the reverse: she removes an element from an existing </em><br /> <em class="quotelev1">> attribute class? </em><br /> I think yes, --own namespace <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> And we haven't even started to think about changing model classes and </em><br /> <em class="quotelev1">> content models yet! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Issues like this are why I think this general idea that putting new </em><br /> <em class="quotelev1">> elements in a different namespace will help in processing TEI </em><br /> <em class="quotelev1">> documents is tenuous at best. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 08 2007 - 00:16:10 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 9 15:50:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Apr 2007 15:50:23 -0400 Subject: [tei-council] ISO 8601 ambiguity Message-ID: <17946.39167.37543.189412@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 9 Apr 2007 15:50:23 -0400</span><br /> </address> This is mostly aimed at James, who I think has an interest in this <br /> stuff, but others may be interested as well. <br /> I've been reading ISO 8601:2004 lately, and it seems to me there is a <br /> glaring ambiguity. <br /> <date value="1948"> <!-- calendar year basic format, reduced <br /> accuracy; see 4.1.2.3(b); represents the <br /> year Mahatma Gandhi was assassinated --> <br /> <time value="1948"> <!-- local time basic format, reduced accuracy; <br /> see 4.2.2.3(a); represents a good time to <br /> clear the dinner table and get ready for <br /> bed: 19.8 hours into the day --> <br /> (Of course, if you were to use the extended format for the time, <br /> i.e. "19:48", no ambiguity exists.) <br /> I have *never* liked the basic formats, and the current draft of the <br /> Guidelines says <br /> <p>For all representations for which ISO 8601 describes both a <br /> <soCalled>basic</soCalled> and an <soCalled>extended</soCalled> <br /> format, these Guidelines recommend use of the extended <br /> format.</p> <br /> I'm wondering if this shouldn't be worded more strongly. (And those <br /> <soCalled>s should probably be <term>s or <name>s.) I note that the <br /> Wikipedia says "The extended formats are preferred over basic formats <br /> because some basic formats are ambiguous." <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 09 2007 - 15:50:26 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Mon Apr 9 16:20:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Apr 2007 21:20:30 +0100 Subject: [tei-council] MD chapter revised: namespace rules Message-ID: <461AA00E.50405@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 09 Apr 2007 21:20:30 +0100</span><br /> </address> I have now checked in a completely rewritten version of chapter MD. Its <br /> content (I now realize) overlaps somewhat with the ODD Customization <br /> Manual that Sebastian wrote many moons ago, which foolishly I did not <br /> think of using as source material, until too late; instead I tried to <br /> stick to the original goal of describing just as much as is necessary to <br /> motivate the following discussion of what conformance means. <br /> Inter alia, and as a straw man, I'd like to propose for discussion the <br /> following draconian rules about the use of namespaces in modification: <br /> 1. New elements may not be placed in the TEI namespace <br /> 2. If new attributes are added to a TEI element, the resulting element <br /> must be moved out of the TEI namespace. <br /> 3. Only modified elements which have undergone a clean modification [1] <br /> may remain in the TEI namespace. <br /> 4. If a TEI element is renamed, it may not remain in the TEI namespace, <br /> except that TEI namespaces are defined for systematic renaming of TEI <br /> elements into different languages. <br /> [1]A "clean" modification is defined in chapter MD as one which results <br /> in a schema that matches a proper subset of the documents matched by an <br /> unmodified schema. <br /> Comments? Alternative proposals? <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 09 2007 - 16:20:33 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Mon Apr 9 18:16:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Apr 2007 23:16:28 +0100 Subject: [tei-council] Conformance draft checked in Message-ID: <461ABB3C.2090308@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 09 Apr 2007 23:16:28 +0100</span><br /> </address> Working through James's draft definition of conformance, I've made the <br /> following substantive changes (plus a bunch of minor stylistic changes) <br /> 1. I've added the requirement that a tei conformant document must <br /> respect the semantics embodied in the Guidelines to the discussion of <br /> the TEI abstract model and moved that up the list of conformance <br /> pre-requisites a bit. <br /> 2. I've reinstated the requirement for a sourceDesc. Even James says <br /> that this is "recommended practice" for documents born digital, and <br /> since conformance is a prerequisite for "recommended practice".... <br /> 3. I've combined the three varieties of nonconformance into one section, <br /> and turned around the comment about the use of TEI namespace in such <br /> documents (James had it expressed as a pious hope, and I have made it an <br /> opportunity not to be missed) <br /> I got tired at the point that James started talking about namespaces <br /> (section CFNS to be exact) and haven't revised that or following <br /> subsections. I'm minded to delete the last section (on funding bodies) <br /> completely, as aforesaid. And I am sorry, but I haven't reviewed all the <br /> comments made so far to make sure I've addressed them all. <br /> I am handing the draft over to James to do that! <br /> I have also removed completely what used to be chapter IN. It's possible <br /> that we might need to add a new section following CF, which says <br /> (a) Use Unicode and use <g> if unicode doesnt do it for you <br /> (b) Use XML <br /> but that shouldn't amount to more than a paragraph or two. <br /> I am still not sure what (if anything) should replace the current <br /> chapter DT. <br /> And, John, where are we with the updates for the current section SH? <br /> Anyway, a new HTML version of all this stuff is now available for your <br /> reading pleasure at <br /> http://www.tei-c.org/Drafts/USE.html <br /> Please read through this as soon as possible and comment here. We need <br /> to get our story on this sorted out before Berlin, in my opinion. <br /> <p><p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 09 2007 - 18:16:31 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Tue Apr 10 08:13:19 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 10 Apr 2007 13:13:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461AA00E.50405@computing-services.oxford.ac.uk> Message-ID: <461B7F5F.1000502@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 13:13:19 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev1">> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 1. New elements may not be placed in the TEI namespace </em><br /> I can agree with that, though we may disagree on what is a 'new' element. <br /> <em class="quotelev1">> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev1">> must be moved out of the TEI namespace. </em><br /> I'm not convinced by that. If I add a new attribute to a TEI element, the <br /> TEI element is still a TEI element. It just has a new attribute and that <br /> attribute is signalled as not being part of the TEI by itself being in a <br /> different namespace. my:newAtt="foo". I don't see that the element is now <br /> so changed that it is no longer the TEI element. <br /> <em class="quotelev1">> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev1">> may remain in the TEI namespace. </em><br /> Agreed, but I think adding an attribute which is in a different namespace <br /> is a clean modification. You are right that changed content models, etc. <br /> are dirty changes. However, if the change is to remove an element from <br /> some classes, or limit an open attribute value list, or anything similar <br /> which constrains it, then that is a clean modification because the TEI <br /> content still validates against tei_all. <br /> <em class="quotelev1">> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev1">> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev1">> elements into different languages. </em><br /> I'm still not convinced that TEI translations need separate namespaces. <br /> They should be conformant according to the Renaming Subset schema. If <br /> something is simply a renamed element/attribute and it otherwise is <br /> identical to the TEI original (and documented with ODD/equiv) then I do not <br /> feel it needs to be in a different namespace. It is, for all intents and <br /> purposes, the TEI element. If I have <div type="chapter"> and instead <br /> rename this <chapter> keeping everything else the same, does this really <br /> need a new namespace? The original view of the Renaming Subset was that it <br /> didn't. <br /> <em class="quotelev1">> [1]A "clean" modification is defined in chapter MD as one which results </em><br /> <em class="quotelev1">> in a schema that matches a proper subset of the documents matched by an </em><br /> <em class="quotelev1">> unmodified schema. </em><br /> I think clean should include reversal of renamings, and that translations <br /> are just a specialised form of renamings. <br /> <em class="quotelev1">> Comments? Alternative proposals? </em><br /> Alternative proposal: <br /> 1. Entirely new elements should be in a new namespace <br /> 2. Renamed elements, properly documented should remain in TEI namespace <br /> 3. Translations are just a form of renaming. <br /> 4. Adding new (namespaced) attributes to a TEI element, does not stop that <br /> TEI element being TEI. <br /> 5. Our definition of 'clean' modification should include renamings. <br /> <p>-James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 08:13:23 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Tue Apr 10 08:38:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Apr 2007 13:38:35 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B7F5F.1000502@oucs.ox.ac.uk> Message-ID: <461B854B.60704@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 13:38:35 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">>> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev2">>> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I can agree with that, though we may disagree on what is a 'new' element. </em><br /> By "new" I mean an element not already defined by the Guidelines. What <br /> fiendishly cunning other case do you have in mind Dr Cummings? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev2">>> must be moved out of the TEI namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm not convinced by that. If I add a new attribute to a TEI element, the </em><br /> <em class="quotelev1">> TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev1">> attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev1">> different namespace. my:newAtt="foo". I don't see that the element is now </em><br /> <em class="quotelev1">> so changed that it is no longer the TEI element. </em><br /> <p>OK, this is a plausible argument and I am disposed to agree with you. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev2">>> may remain in the TEI namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev1">> is a clean modification. </em><br /> Yes, though only if I agree with you on (2) above. <br /> You are right that changed content models, etc. <br /> <em class="quotelev1">> are dirty changes. However, if the change is to remove an element from </em><br /> <em class="quotelev1">> some classes, or limit an open attribute value list, or anything similar </em><br /> <em class="quotelev1">> which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev1">> content still validates against tei_all. </em><br /> <em class="quotelev1">> </em><br /> Yes. The draft does try to make this distinction clear. <br /> <p><em class="quotelev2">>> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev2">>> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev2">>> elements into different languages. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm still not convinced that TEI translations need separate namespaces. </em><br /> Well, let us wait for reactions from others, because I currently still <br /> think that separate namespaces for separate translations makes a whole <br /> lot of sense, organizationally, politically, and technically. If we dont <br /> do that, then every new translation has to watch out for name collision <br /> with every other language now and in the future! I am less sure about <br /> individual renamings, but still feel that basically if you don't use the <br /> names we have chosen for our elements, whether or not you make explicit <br /> the relationship between your name and ours, you are polluting the TEI <br /> namespace. And you have all the headaches about name collision. And my <br /> dimwitted TEI application has to go and read the ODD every time it <br /> processes a document to know what to do with your renaming. <br /> <p><p><em class="quotelev1">> They should be conformant according to the Renaming Subset schema. If </em><br /> <em class="quotelev1">> something is simply a renamed element/attribute and it otherwise is </em><br /> <em class="quotelev1">> identical to the TEI original (and documented with ODD/equiv) then I do not </em><br /> <em class="quotelev1">> feel it needs to be in a different namespace. It is, for all intents and </em><br /> <em class="quotelev1">> purposes, the TEI element. If I have <div type="chapter"> and instead </em><br /> <em class="quotelev1">> rename this <chapter> keeping everything else the same, does this really </em><br /> <em class="quotelev1">> need a new namespace? The original view of the Renaming Subset was that it </em><br /> <em class="quotelev1">> didn't. </em><br /> <p>I'm happy with the concept of a renaming subset schema. I just think it <br /> ought to use a different namespace for the renamed elements. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> [1]A "clean" modification is defined in chapter MD as one which results </em><br /> <em class="quotelev2">>> in a schema that matches a proper subset of the documents matched by an </em><br /> <em class="quotelev2">>> unmodified schema. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think clean should include reversal of renamings, and that translations </em><br /> <em class="quotelev1">> are just a specialised form of renamings. </em><br /> <em class="quotelev1">> </em><br /> I think adding this level of complexity may be just a level too far for <br /> many simple-minded processors. But, as I said, let's wait to see what <br /> others think. <br /> <p><em class="quotelev2">>> Comments? Alternative proposals? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Alternative proposal: </em><br /> <em class="quotelev1">> 1. Entirely new elements should be in a new namespace </em><br /> yes <br /> <em class="quotelev1">> 2. Renamed elements, properly documented should remain in TEI namespace </em><br /> no <br /> <em class="quotelev1">> 3. Translations are just a form of renaming. </em><br /> yes, except that they are systematic <br /> <em class="quotelev1">> 4. Adding new (namespaced) attributes to a TEI element, does not stop that </em><br /> <em class="quotelev1">> TEI element being TEI. </em><br /> yes <br /> <em class="quotelev1">> 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev1">> </em><br /> no! <br /> <p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 08:40:34 EDT</span> </div> From laurent.romary at loria.fr Tue Apr 10 08:48:18 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Apr 2007 14:48:18 +0200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B7F5F.1000502@oucs.ox.ac.uk> Message-ID: <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 14:48:18 +0200</span><br /> </address> Hi all, <br /> I have kept track of the discussion fo a while and could not see how <br /> to enter it... now I have it. <br /> I am completely in line with James on his arguments related to points <br /> 2 and 3. The requirements that adding an attribute too an element <br /> (especially an existing TEI attribute by the way) should force the <br /> element to change namespace is slightly too strong. <br /> I am thinking of people who may want to add a simple type attribute <br /> to an element and would not want to bother about namespaces though. <br /> Laurent <br /> Le 10 avr. 07 ? 14:13, James Cummings a ?crit : <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">>> 2. If new attributes are added to a TEI element, the resulting </em><br /> <em class="quotelev2">>> element </em><br /> <em class="quotelev2">>> must be moved out of the TEI namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm not convinced by that. If I add a new attribute to a TEI </em><br /> <em class="quotelev1">> element, the </em><br /> <em class="quotelev1">> TEI element is still a TEI element. It just has a new attribute </em><br /> <em class="quotelev1">> and that </em><br /> <em class="quotelev1">> attribute is signalled as not being part of the TEI by itself being </em><br /> <em class="quotelev1">> in a </em><br /> <em class="quotelev1">> different namespace. my:newAtt="foo". I don't see that the </em><br /> <em class="quotelev1">> element is now </em><br /> <em class="quotelev1">> so changed that it is no longer the TEI element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 3. Only modified elements which have undergone a clean </em><br /> <em class="quotelev2">>> modification [1] </em><br /> <em class="quotelev2">>> may remain in the TEI namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Agreed, but I think adding an attribute which is in a different </em><br /> <em class="quotelev1">> namespace </em><br /> <em class="quotelev1">> is a clean modification. You are right that changed content </em><br /> <em class="quotelev1">> models, etc. </em><br /> <em class="quotelev1">> are dirty changes. However, if the change is to remove an element </em><br /> <em class="quotelev1">> from </em><br /> <em class="quotelev1">> some classes, or limit an open attribute value list, or anything </em><br /> <em class="quotelev1">> similar </em><br /> <em class="quotelev1">> which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev1">> content still validates against tei_all. </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 08:49:40 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Tue Apr 10 08:55:43 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 10 Apr 2007 13:55:43 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B854B.60704@oucs.ox.ac.uk> Message-ID: <461B894F.7080000@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 13:55:43 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> Lou Burnard wrote: </em><br /> <em class="quotelev3">>>> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev3">>>> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I can agree with that, though we may disagree on what is a 'new' element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> By "new" I mean an element not already defined by the Guidelines. What </em><br /> <em class="quotelev1">> fiendishly cunning other case do you have in mind Dr Cummings? </em><br /> A properly documented renaming, of course, whether by means of translation <br /> or otherwise. <br /> <em class="quotelev3">>>> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev3">>>> must be moved out of the TEI namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I'm not convinced by that. If I add a new attribute to a TEI element, </em><br /> <em class="quotelev2">>> the </em><br /> <em class="quotelev2">>> TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev2">>> attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev2">>> different namespace. my:newAtt="foo". I don't see that the element </em><br /> <em class="quotelev2">>> is now </em><br /> <em class="quotelev2">>> so changed that it is no longer the TEI element. </em><br /> <em class="quotelev1">> OK, this is a plausible argument and I am disposed to agree with you. </em><br /> Oh good, that was easy. <br /> <em class="quotelev3">>>> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev3">>>> may remain in the TEI namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev2">>> is a clean modification. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes, though only if I agree with you on (2) above. </em><br /> Didn't you just agree to that above? <br /> <p><em class="quotelev1">> Yes. The draft does try to make this distinction clear. </em><br /> Indeed it does. <br /> <em class="quotelev3">>>> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev3">>>> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev3">>>> elements into different languages. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I'm still not convinced that TEI translations need separate namespaces. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Well, let us wait for reactions from others, because I currently still </em><br /> <em class="quotelev1">> think that separate namespaces for separate translations makes a whole </em><br /> <em class="quotelev1">> lot of sense, organizationally, politically, and technically. If we dont </em><br /> <em class="quotelev1">> do that, then every new translation has to watch out for name collision </em><br /> <em class="quotelev1">> with every other language now and in the future! </em><br /> Well, I'd argue that it should only worry about it for the set of <br /> guidelines from which it derives (and that version number should be <br /> stored). The guidelines for renaming should state that you can't rename <br /> something to an existing name in another module (or translation?) I <br /> suppose translation namespaces would solve this problem. :-( <br /> <em class="quotelev1">> I am less sure about </em><br /> <em class="quotelev1">> individual renamings, but still feel that basically if you don't use the </em><br /> <em class="quotelev1">> names we have chosen for our elements, whether or not you make explicit </em><br /> <em class="quotelev1">> the relationship between your name and ours, you are polluting the TEI </em><br /> <em class="quotelev1">> namespace. And you have all the headaches about name collision. And my </em><br /> <em class="quotelev1">> dimwitted TEI application has to go and read the ODD every time it </em><br /> <em class="quotelev1">> processes a document to know what to do with your renaming. </em><br /> Or you need to interchange your documents in TEI Interchange Format where <br /> these renamings should have been un-done? <br /> <em class="quotelev1">> I'm happy with the concept of a renaming subset schema. I just think it </em><br /> <em class="quotelev1">> ought to use a different namespace for the renamed elements. </em><br /> I suppose I could be convinced of this, but it certainly wasn't the way I <br /> had envisioned it. <br /> <p><em class="quotelev2">>> I think clean should include reversal of renamings, and that translations </em><br /> <em class="quotelev2">>> are just a specialised form of renamings. </em><br /> <em class="quotelev1">> I think adding this level of complexity may be just a level too far for </em><br /> <em class="quotelev1">> many simple-minded processors. But, as I said, let's wait to see what </em><br /> <em class="quotelev1">> others think. </em><br /> I'll be interested to hear what other council members think as well. <br /> -James <br /> <p><p><em class="quotelev3">>>> Comments? Alternative proposals? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Alternative proposal: </em><br /> <em class="quotelev2">>> 1. Entirely new elements should be in a new namespace </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 2. Renamed elements, properly documented should remain in TEI namespace </em><br /> <em class="quotelev1">> no </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 3. Translations are just a form of renaming. </em><br /> <em class="quotelev1">> yes, except that they are systematic </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 4. Adding new (namespaced) attributes to a TEI element, does not stop </em><br /> <em class="quotelev2">>> that </em><br /> <em class="quotelev2">>> TEI element being TEI. </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> no! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 08:55:46 EDT</span> </div> From dporter at uky.edu Tue Apr 10 08:57:24 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 10 Apr 2007 08:57:24 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B854B.60704@oucs.ox.ac.uk> Message-ID: <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 08:57:24 -0400</span><br /> </address> I also agree with James on points 1, 2, and 3. I'm on the fence on <br /> point 4 - whether renamed elements should be in a different namespace <br /> - but I think Lou makes a very good point about name collision which <br /> has me leaning towards renaming = different namespace. It's a little <br /> more work up front, perhaps, but would save a lot of headache in the <br /> long run. <br /> Dot <br /> On 4/10/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">> > Lou Burnard wrote: </em><br /> <em class="quotelev3">> >> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev3">> >> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I can agree with that, though we may disagree on what is a 'new' element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> By "new" I mean an element not already defined by the Guidelines. What </em><br /> <em class="quotelev1">> fiendishly cunning other case do you have in mind Dr Cummings? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev3">> >> must be moved out of the TEI namespace. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm not convinced by that. If I add a new attribute to a TEI element, the </em><br /> <em class="quotelev2">> > TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev2">> > attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev2">> > different namespace. my:newAtt="foo". I don't see that the element is now </em><br /> <em class="quotelev2">> > so changed that it is no longer the TEI element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> OK, this is a plausible argument and I am disposed to agree with you. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev3">> >> may remain in the TEI namespace. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev2">> > is a clean modification. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes, though only if I agree with you on (2) above. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> You are right that changed content models, etc. </em><br /> <em class="quotelev2">> > are dirty changes. However, if the change is to remove an element from </em><br /> <em class="quotelev2">> > some classes, or limit an open attribute value list, or anything similar </em><br /> <em class="quotelev2">> > which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev2">> > content still validates against tei_all. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes. The draft does try to make this distinction clear. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">> >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev3">> >> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev3">> >> elements into different languages. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm still not convinced that TEI translations need separate namespaces. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Well, let us wait for reactions from others, because I currently still </em><br /> <em class="quotelev1">> think that separate namespaces for separate translations makes a whole </em><br /> <em class="quotelev1">> lot of sense, organizationally, politically, and technically. If we dont </em><br /> <em class="quotelev1">> do that, then every new translation has to watch out for name collision </em><br /> <em class="quotelev1">> with every other language now and in the future! I am less sure about </em><br /> <em class="quotelev1">> individual renamings, but still feel that basically if you don't use the </em><br /> <em class="quotelev1">> names we have chosen for our elements, whether or not you make explicit </em><br /> <em class="quotelev1">> the relationship between your name and ours, you are polluting the TEI </em><br /> <em class="quotelev1">> namespace. And you have all the headaches about name collision. And my </em><br /> <em class="quotelev1">> dimwitted TEI application has to go and read the ODD every time it </em><br /> <em class="quotelev1">> processes a document to know what to do with your renaming. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > They should be conformant according to the Renaming Subset schema. If </em><br /> <em class="quotelev2">> > something is simply a renamed element/attribute and it otherwise is </em><br /> <em class="quotelev2">> > identical to the TEI original (and documented with ODD/equiv) then I do not </em><br /> <em class="quotelev2">> > feel it needs to be in a different namespace. It is, for all intents and </em><br /> <em class="quotelev2">> > purposes, the TEI element. If I have <div type="chapter"> and instead </em><br /> <em class="quotelev2">> > rename this <chapter> keeping everything else the same, does this really </em><br /> <em class="quotelev2">> > need a new namespace? The original view of the Renaming Subset was that it </em><br /> <em class="quotelev2">> > didn't. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm happy with the concept of a renaming subset schema. I just think it </em><br /> <em class="quotelev1">> ought to use a different namespace for the renamed elements. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> [1]A "clean" modification is defined in chapter MD as one which results </em><br /> <em class="quotelev3">> >> in a schema that matches a proper subset of the documents matched by an </em><br /> <em class="quotelev3">> >> unmodified schema. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I think clean should include reversal of renamings, and that translations </em><br /> <em class="quotelev2">> > are just a specialised form of renamings. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think adding this level of complexity may be just a level too far for </em><br /> <em class="quotelev1">> many simple-minded processors. But, as I said, let's wait to see what </em><br /> <em class="quotelev1">> others think. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">> >> Comments? Alternative proposals? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Alternative proposal: </em><br /> <em class="quotelev2">> > 1. Entirely new elements should be in a new namespace </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 2. Renamed elements, properly documented should remain in TEI namespace </em><br /> <em class="quotelev1">> no </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 3. Translations are just a form of renaming. </em><br /> <em class="quotelev1">> yes, except that they are systematic </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 4. Adding new (namespaced) attributes to a TEI element, does not stop that </em><br /> <em class="quotelev2">> > TEI element being TEI. </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> no! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 08:57:28 EDT</span> </div> From arianna.ciula at kcl.ac.uk Tue Apr 10 10:09:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 10 Apr 2007 15:09:43 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> Message-ID: <461B9AA7.5040107@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 15:09:43 +0100</span><br /> </address> Laurent Romary wrote: <br /> <em class="quotelev1">> I am completely in line with James on his arguments related to points 2 </em><br /> <em class="quotelev1">> and 3. The requirements that adding an attribute too an element </em><br /> <em class="quotelev1">> (especially an existing TEI attribute by the way) should force the </em><br /> <em class="quotelev1">> element to change namespace is slightly too strong. </em><br /> I agree with these points as well (2 and 3). <br /> I am not sure what to say about the translated element names though. It <br /> probably makes sense to have other TEI namespaces for those for <br /> pragmatical reasons as Lou suggested, even if, conceptually, I still <br /> think they are a sort of a priori approved renaming and therefore <br /> shouldn't be perceived as different from what is in the TEI namespace. <br /> Arianna <br /> <em class="quotelev1">> I am thinking of people who may want to add a simple type attribute to </em><br /> <em class="quotelev1">> an element and would not want to bother about namespaces though. </em><br /> <em class="quotelev1">> Laurent </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Le 10 avr. 07 ?? 14:13, James Cummings a ??crit : </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Lou Burnard wrote: </em><br /> <em class="quotelev3">>>> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev3">>>> must be moved out of the TEI namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I'm not convinced by that. If I add a new attribute to a TEI element, </em><br /> <em class="quotelev2">>> the </em><br /> <em class="quotelev2">>> TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev2">>> attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev2">>> different namespace. my:newAtt="foo". I don't see that the element </em><br /> <em class="quotelev2">>> is now </em><br /> <em class="quotelev2">>> so changed that it is no longer the TEI element. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev3">>>> may remain in the TEI namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev2">>> is a clean modification. You are right that changed content models, etc. </em><br /> <em class="quotelev2">>> are dirty changes. However, if the change is to remove an element from </em><br /> <em class="quotelev2">>> some classes, or limit an open attribute value list, or anything similar </em><br /> <em class="quotelev2">>> which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev2">>> content still validates against tei_all. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 10:10:50 EDT</span> </div> From laurent.romary at loria.fr Tue Apr 10 10:26:16 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Apr 2007 16:26:16 +0200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B9AA7.5040107@kcl.ac.uk> Message-ID: <42B07763-0BED-424E-8979-6073E2BB8421@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 16:26:16 +0200</span><br /> </address> I would support the idea to have translated elements in another <br /> namespace: they really represent a different "vocabulary" and as such <br /> should not interfere with the reference TEI one. <br /> Laurent <br /> Le 10 avr. 07 ? 16:09, Arianna Ciula a ?crit : <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Laurent Romary wrote: </em><br /> <em class="quotelev2">>> I am completely in line with James on his arguments related to </em><br /> <em class="quotelev2">>> points 2 and 3. The requirements that adding an attribute too an </em><br /> <em class="quotelev2">>> element (especially an existing TEI attribute by the way) should </em><br /> <em class="quotelev2">>> force the element to change namespace is slightly too strong. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I agree with these points as well (2 and 3). </em><br /> <em class="quotelev1">> I am not sure what to say about the translated element names </em><br /> <em class="quotelev1">> though. It probably makes sense to have other TEI namespaces for </em><br /> <em class="quotelev1">> those for pragmatical reasons as Lou suggested, even if, </em><br /> <em class="quotelev1">> conceptually, I still think they are a sort of a priori approved </em><br /> <em class="quotelev1">> renaming and therefore shouldn't be perceived as different from </em><br /> <em class="quotelev1">> what is in the TEI namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Arianna </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> I am thinking of people who may want to add a simple type </em><br /> <em class="quotelev2">>> attribute to an element and would not want to bother about </em><br /> <em class="quotelev2">>> namespaces though. </em><br /> <em class="quotelev2">>> Laurent </em><br /> <em class="quotelev2">>> Le 10 avr. 07 ? 14:13, James Cummings a ?crit : </em><br /> <em class="quotelev3">>>> Lou Burnard wrote: </em><br /> <em class="quotelev4">>>>> 2. If new attributes are added to a TEI element, the resulting </em><br /> <em class="quotelev4">>>>> element </em><br /> <em class="quotelev4">>>>> must be moved out of the TEI namespace. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I'm not convinced by that. If I add a new attribute to a TEI </em><br /> <em class="quotelev3">>>> element, the </em><br /> <em class="quotelev3">>>> TEI element is still a TEI element. It just has a new attribute </em><br /> <em class="quotelev3">>>> and that </em><br /> <em class="quotelev3">>>> attribute is signalled as not being part of the TEI by itself </em><br /> <em class="quotelev3">>>> being in a </em><br /> <em class="quotelev3">>>> different namespace. my:newAtt="foo". I don't see that the </em><br /> <em class="quotelev3">>>> element is now </em><br /> <em class="quotelev3">>>> so changed that it is no longer the TEI element. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> 3. Only modified elements which have undergone a clean </em><br /> <em class="quotelev4">>>>> modification [1] </em><br /> <em class="quotelev4">>>>> may remain in the TEI namespace. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Agreed, but I think adding an attribute which is in a different </em><br /> <em class="quotelev3">>>> namespace </em><br /> <em class="quotelev3">>>> is a clean modification. You are right that changed content </em><br /> <em class="quotelev3">>>> models, etc. </em><br /> <em class="quotelev3">>>> are dirty changes. However, if the change is to remove an </em><br /> <em class="quotelev3">>>> element from </em><br /> <em class="quotelev3">>>> some classes, or limit an open attribute value list, or anything </em><br /> <em class="quotelev3">>>> similar </em><br /> <em class="quotelev3">>>> which constrains it, then that is a clean modification because </em><br /> <em class="quotelev3">>>> the TEI </em><br /> <em class="quotelev3">>>> content still validates against tei_all. </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> Dr Arianna Ciula </em><br /> <em class="quotelev1">> Research Associate </em><br /> <em class="quotelev1">> Centre for Computing in the Humanities </em><br /> <em class="quotelev1">> King's College London </em><br /> <em class="quotelev1">> Strand </em><br /> <em class="quotelev1">> London WC2R 2LS (UK) </em><br /> <em class="quotelev1">> Tel: +44 (0)20 78481945 </em><br /> <em class="quotelev1">> http://www.kcl.ac.uk/cch </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 10:27:48 EDT</span> </div> From djbpitt+tei at pitt.edu Tue Apr 10 10:44:38 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 10 Apr 2007 10:44:38 -0400 Subject: [tei-council] renaming and namespaces Message-ID: <461BA2D6.6070501@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 10:44:38 -0400</span><br /> </address> Dear TEI Council, <br /> I'm also with Lou on the question of renaming. Since namespaces are <br /> intended to avoid collision and renaming can create collision, it would <br /> seem wisest not to put renamed elements in the tei namespace. <br /> Best, <br /> David <br /> Dot Porter wrote: <br /> <em class="quotelev1">> I also agree with James on points 1, 2, and 3. I'm on the fence on </em><br /> <em class="quotelev1">> point 4 - whether renamed elements should be in a different namespace </em><br /> <em class="quotelev1">> - but I think Lou makes a very good point about name collision which </em><br /> <em class="quotelev1">> has me leaning towards renaming = different namespace. It's a little </em><br /> <em class="quotelev1">> more work up front, perhaps, but would save a lot of headache in the </em><br /> <em class="quotelev1">> long run. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Dot </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On 4/10/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> </em><br /> <em class="quotelev1">> wrote: </em><br /> <em class="quotelev2">>> James Cummings wrote: </em><br /> <em class="quotelev3">>> > Lou Burnard wrote: </em><br /> <em class="quotelev4">>> >> Inter alia, and as a straw man, I'd like to propose for discussion </em><br /> <em class="quotelev2">>> the </em><br /> <em class="quotelev4">>> >> following draconian rules about the use of namespaces in </em><br /> <em class="quotelev2">>> modification: </em><br /> <em class="quotelev4">>> >> </em><br /> <em class="quotelev4">>> >> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > I can agree with that, though we may disagree on what is a 'new' </em><br /> <em class="quotelev2">>> element. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> By "new" I mean an element not already defined by the Guidelines. What </em><br /> <em class="quotelev2">>> fiendishly cunning other case do you have in mind Dr Cummings? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev4">>> >> 2. If new attributes are added to a TEI element, the resulting </em><br /> <em class="quotelev2">>> element </em><br /> <em class="quotelev4">>> >> must be moved out of the TEI namespace. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > I'm not convinced by that. If I add a new attribute to a TEI </em><br /> <em class="quotelev2">>> element, the </em><br /> <em class="quotelev3">>> > TEI element is still a TEI element. It just has a new attribute </em><br /> <em class="quotelev2">>> and that </em><br /> <em class="quotelev3">>> > attribute is signalled as not being part of the TEI by itself being </em><br /> <em class="quotelev2">>> in a </em><br /> <em class="quotelev3">>> > different namespace. my:newAtt="foo". I don't see that the </em><br /> <em class="quotelev2">>> element is now </em><br /> <em class="quotelev3">>> > so changed that it is no longer the TEI element. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> OK, this is a plausible argument and I am disposed to agree with you. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev4">>> >> 3. Only modified elements which have undergone a clean </em><br /> <em class="quotelev2">>> modification [1] </em><br /> <em class="quotelev4">>> >> may remain in the TEI namespace. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > Agreed, but I think adding an attribute which is in a different </em><br /> <em class="quotelev2">>> namespace </em><br /> <em class="quotelev3">>> > is a clean modification. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Yes, though only if I agree with you on (2) above. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> You are right that changed content models, etc. </em><br /> <em class="quotelev3">>> > are dirty changes. However, if the change is to remove an element </em><br /> <em class="quotelev2">>> from </em><br /> <em class="quotelev3">>> > some classes, or limit an open attribute value list, or anything </em><br /> <em class="quotelev2">>> similar </em><br /> <em class="quotelev3">>> > which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev3">>> > content still validates against tei_all. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Yes. The draft does try to make this distinction clear. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev4">>> >> 4. If a TEI element is renamed, it may not remain in the TEI </em><br /> <em class="quotelev2">>> namespace, </em><br /> <em class="quotelev4">>> >> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev4">>> >> elements into different languages. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > I'm still not convinced that TEI translations need separate </em><br /> <em class="quotelev2">>> namespaces. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Well, let us wait for reactions from others, because I currently still </em><br /> <em class="quotelev2">>> think that separate namespaces for separate translations makes a whole </em><br /> <em class="quotelev2">>> lot of sense, organizationally, politically, and technically. If we dont </em><br /> <em class="quotelev2">>> do that, then every new translation has to watch out for name collision </em><br /> <em class="quotelev2">>> with every other language now and in the future! I am less sure about </em><br /> <em class="quotelev2">>> individual renamings, but still feel that basically if you don't use the </em><br /> <em class="quotelev2">>> names we have chosen for our elements, whether or not you make explicit </em><br /> <em class="quotelev2">>> the relationship between your name and ours, you are polluting the TEI </em><br /> <em class="quotelev2">>> namespace. And you have all the headaches about name collision. And my </em><br /> <em class="quotelev2">>> dimwitted TEI application has to go and read the ODD every time it </em><br /> <em class="quotelev2">>> processes a document to know what to do with your renaming. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > They should be conformant according to the Renaming Subset schema. If </em><br /> <em class="quotelev3">>> > something is simply a renamed element/attribute and it otherwise is </em><br /> <em class="quotelev3">>> > identical to the TEI original (and documented with ODD/equiv) then </em><br /> <em class="quotelev2">>> I do not </em><br /> <em class="quotelev3">>> > feel it needs to be in a different namespace. It is, for all </em><br /> <em class="quotelev2">>> intents and </em><br /> <em class="quotelev3">>> > purposes, the TEI element. If I have <div type="chapter"> and instead </em><br /> <em class="quotelev3">>> > rename this <chapter> keeping everything else the same, does this </em><br /> <em class="quotelev2">>> really </em><br /> <em class="quotelev3">>> > need a new namespace? The original view of the Renaming Subset was </em><br /> <em class="quotelev2">>> that it </em><br /> <em class="quotelev3">>> > didn't. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I'm happy with the concept of a renaming subset schema. I just think it </em><br /> <em class="quotelev2">>> ought to use a different namespace for the renamed elements. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev4">>> >> [1]A "clean" modification is defined in chapter MD as one which </em><br /> <em class="quotelev2">>> results </em><br /> <em class="quotelev4">>> >> in a schema that matches a proper subset of the documents matched </em><br /> <em class="quotelev2">>> by an </em><br /> <em class="quotelev4">>> >> unmodified schema. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > I think clean should include reversal of renamings, and that </em><br /> <em class="quotelev2">>> translations </em><br /> <em class="quotelev3">>> > are just a specialised form of renamings. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I think adding this level of complexity may be just a level too far for </em><br /> <em class="quotelev2">>> many simple-minded processors. But, as I said, let's wait to see what </em><br /> <em class="quotelev2">>> others think. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev4">>> >> Comments? Alternative proposals? </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev3">>> > Alternative proposal: </em><br /> <em class="quotelev3">>> > 1. Entirely new elements should be in a new namespace </em><br /> <em class="quotelev2">>> yes </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > 2. Renamed elements, properly documented should remain in TEI </em><br /> <em class="quotelev2">>> namespace </em><br /> <em class="quotelev2">>> no </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > 3. Translations are just a form of renaming. </em><br /> <em class="quotelev2">>> yes, except that they are systematic </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > 4. Adding new (namespaced) attributes to a TEI element, does not </em><br /> <em class="quotelev2">>> stop that </em><br /> <em class="quotelev3">>> > TEI element being TEI. </em><br /> <em class="quotelev2">>> yes </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>> > 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev3">>> > </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> no! </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 10:44:41 EDT</span> </div> From daniel.odonnell at uleth.ca Tue Apr 10 11:02:10 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 10 Apr 2007 09:02:10 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> Message-ID: <1176217330.21190.40.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 09:02:10 -0600</span><br /> </address> It seems to me that we can refine the set of principles: <br /> 1. New elements may not be placed in the TEI namespace. <br /> 3. Only modified elements which have undergone a clean modification may <br /> remain in the TEI namespace. The addition of attributes to a TEI element <br /> is clean as long as the new attribute itself is identified as coming <br /> from a different namespace. <br /> 4. Official translations have their own TEI namespace as long as they <br /> represent a 1:1 translation of the entire standard and remain <br /> up-to-date. <br /> Like everybody else, I'm having trouble with simple project-based <br /> renamings, since they can remain in the TEI namespace under principle 3. <br /> The same is also true of translations if you see them as being in <br /> essence renamings (about which more below), since they should also be <br /> clean--though I can see the practical and political argument in favour <br /> of using distinct (sub) namespaces for official translations as long as <br /> they reflect a complete, up-to-date, and 1:1 translation of the <br /> standard. <br /> I think my own leaning is that the clean modification principle 3 is <br /> key. The use of the TEI namespace says: "I am identical to or have been <br /> cleanly modified from the TEI standard; you can process me with the <br /> assurance that you understand what I am"--i.e. the question of whether <br /> something stays in the namespace is not only a negative decision <br /> identifying elements that have diverged from the standard, but a <br /> positive one identifying elements that have not. So under this, cleanly <br /> renamed elements would remain in the namespace, even if that adds a <br /> processing cost in figuring out what they are an alias of. Of course the <br /> addition of a processing cost is an argument against renaming elements <br /> for interchange that projects might want to pay attention to. Avoiding <br /> conflicts is the responsibility of the renamer, and a conflicting name <br /> is not a clean modification IMO (except for translations of the entire <br /> standard, see below). <br /> If we take the view that the TEI namespace is a positive assertion, then <br /> translations are a bit of an issue: presumably they are by definition <br /> clean modifications (except that unlike modifications of individual <br /> elements, there is always the possibility that individual translated <br /> elements might conflict with English language ones), in which case they <br /> should under principle 3 be in the TEI namespace. We don't want <br /> translations by implication or practice to be or be seen as <br /> substantively different from the standard in anyway. Perhaps the way to <br /> see this is that "renaming" and "translation" are not exactly the same <br /> thing: a "renaming" may involve less than all the element names and may <br /> occur with other extensions and additions; a "translation" involves the <br /> entire standard and may not involve other additions and extensions. <br /> Renamed elements remain in the TEI space from which they have been <br /> renamed; translations are given a (sub) TEI namespace of their own to <br /> indicate that they are 1:1 but may have name conflicts with the standard <br /> names. Individuals and projects can rename, extend, or otherwise modify <br /> translations, subject to the same rules about names spaces that apply to <br /> modifications of the standard as long as we replace "tei namespace" with <br /> the name of the specific translation. <br /> Finally a question: what happens if I extend a tei attribute to a new <br /> element (or make it global). <br /> In this case it seems to me that the "extended" attributes have to go in <br /> a different namespace; but I'm not sure about the "original" <br /> tei:namespaced attributes: presumably I'm extending the element because <br /> I want additional elements to share the attribute with original tei <br /> elements. I'm leaning towards saying that the "original" tei attribute <br /> has also changed in this case. Or in other words: if I make @type <br /> global, I am actually removing tei:type from the elements on which it is <br /> found and replacing it with mynamespace:type throughout the whole tei. <br /> -dan <br /> On Tue, 2007-10-04 at 08:57 -0400, Dot Porter wrote: <br /> <em class="quotelev1">> I also agree with James on points 1, 2, and 3. I'm on the fence on </em><br /> <em class="quotelev1">> point 4 - whether renamed elements should be in a different namespace </em><br /> <em class="quotelev1">> - but I think Lou makes a very good point about name collision which </em><br /> <em class="quotelev1">> has me leaning towards renaming = different namespace. It's a little </em><br /> <em class="quotelev1">> more work up front, perhaps, but would save a lot of headache in the </em><br /> <em class="quotelev1">> long run. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Dot </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On 4/10/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> wrote: </em><br /> <em class="quotelev2">> > James Cummings wrote: </em><br /> <em class="quotelev3">> > > Lou Burnard wrote: </em><br /> <em class="quotelev4">> > >> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev4">> > >> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev4">> > >> </em><br /> <em class="quotelev4">> > >> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > I can agree with that, though we may disagree on what is a 'new' element. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > By "new" I mean an element not already defined by the Guidelines. What </em><br /> <em class="quotelev2">> > fiendishly cunning other case do you have in mind Dr Cummings? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev4">> > >> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev4">> > >> must be moved out of the TEI namespace. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > I'm not convinced by that. If I add a new attribute to a TEI element, the </em><br /> <em class="quotelev3">> > > TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev3">> > > attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev3">> > > different namespace. my:newAtt="foo". I don't see that the element is now </em><br /> <em class="quotelev3">> > > so changed that it is no longer the TEI element. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > OK, this is a plausible argument and I am disposed to agree with you. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev4">> > >> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev4">> > >> may remain in the TEI namespace. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev3">> > > is a clean modification. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Yes, though only if I agree with you on (2) above. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > You are right that changed content models, etc. </em><br /> <em class="quotelev3">> > > are dirty changes. However, if the change is to remove an element from </em><br /> <em class="quotelev3">> > > some classes, or limit an open attribute value list, or anything similar </em><br /> <em class="quotelev3">> > > which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev3">> > > content still validates against tei_all. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Yes. The draft does try to make this distinction clear. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev4">> > >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev4">> > >> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev4">> > >> elements into different languages. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > I'm still not convinced that TEI translations need separate namespaces. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Well, let us wait for reactions from others, because I currently still </em><br /> <em class="quotelev2">> > think that separate namespaces for separate translations makes a whole </em><br /> <em class="quotelev2">> > lot of sense, organizationally, politically, and technically. If we dont </em><br /> <em class="quotelev2">> > do that, then every new translation has to watch out for name collision </em><br /> <em class="quotelev2">> > with every other language now and in the future! I am less sure about </em><br /> <em class="quotelev2">> > individual renamings, but still feel that basically if you don't use the </em><br /> <em class="quotelev2">> > names we have chosen for our elements, whether or not you make explicit </em><br /> <em class="quotelev2">> > the relationship between your name and ours, you are polluting the TEI </em><br /> <em class="quotelev2">> > namespace. And you have all the headaches about name collision. And my </em><br /> <em class="quotelev2">> > dimwitted TEI application has to go and read the ODD every time it </em><br /> <em class="quotelev2">> > processes a document to know what to do with your renaming. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > They should be conformant according to the Renaming Subset schema. If </em><br /> <em class="quotelev3">> > > something is simply a renamed element/attribute and it otherwise is </em><br /> <em class="quotelev3">> > > identical to the TEI original (and documented with ODD/equiv) then I do not </em><br /> <em class="quotelev3">> > > feel it needs to be in a different namespace. It is, for all intents and </em><br /> <em class="quotelev3">> > > purposes, the TEI element. If I have <div type="chapter"> and instead </em><br /> <em class="quotelev3">> > > rename this <chapter> keeping everything else the same, does this really </em><br /> <em class="quotelev3">> > > need a new namespace? The original view of the Renaming Subset was that it </em><br /> <em class="quotelev3">> > > didn't. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm happy with the concept of a renaming subset schema. I just think it </em><br /> <em class="quotelev2">> > ought to use a different namespace for the renamed elements. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev4">> > >> [1]A "clean" modification is defined in chapter MD as one which results </em><br /> <em class="quotelev4">> > >> in a schema that matches a proper subset of the documents matched by an </em><br /> <em class="quotelev4">> > >> unmodified schema. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > I think clean should include reversal of renamings, and that translations </em><br /> <em class="quotelev3">> > > are just a specialised form of renamings. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I think adding this level of complexity may be just a level too far for </em><br /> <em class="quotelev2">> > many simple-minded processors. But, as I said, let's wait to see what </em><br /> <em class="quotelev2">> > others think. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev4">> > >> Comments? Alternative proposals? </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev3">> > > Alternative proposal: </em><br /> <em class="quotelev3">> > > 1. Entirely new elements should be in a new namespace </em><br /> <em class="quotelev2">> > yes </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > 2. Renamed elements, properly documented should remain in TEI namespace </em><br /> <em class="quotelev2">> > no </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > 3. Translations are just a form of renaming. </em><br /> <em class="quotelev2">> > yes, except that they are systematic </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > 4. Adding new (namespaced) attributes to a TEI element, does not stop that </em><br /> <em class="quotelev3">> > > TEI element being TEI. </em><br /> <em class="quotelev2">> > yes </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> > > 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > no! </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > _______________________________________________ </em><br /> <em class="quotelev2">> > tei-council mailing list </em><br /> <em class="quotelev2">> > tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 10:58:50 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Tue Apr 10 11:12:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Apr 2007 16:12:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> Message-ID: <461BA953.5070003@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 16:12:19 +0100</span><br /> </address> Dan O'Donnell wrote: <br /> <em class="quotelev1">> Finally a question: what happens if I extend a tei attribute to a new </em><br /> <em class="quotelev1">> element (or make it global). </em><br /> <em class="quotelev1">> </em><br /> That's an unclean modification -- the set of documents matched by the <br /> extended schema is not a pure subset of the set of documents matched by <br /> the unextended one -- ergo you must put a namespace on something, <br /> presumably the attribute you've now defined as global. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 11:14:19 EDT</span> </div> From daniel.odonnell at uleth.ca Tue Apr 10 11:26:33 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 10 Apr 2007 09:26:33 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461BA953.5070003@oucs.ox.ac.uk> Message-ID: <1176218793.24696.10.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 09:26:33 -0600</span><br /> </address> On Tue, 2007-10-04 at 16:12 +0100, Lou Burnard wrote: <br /> <em class="quotelev1">> Dan O'Donnell wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > Finally a question: what happens if I extend a tei attribute to a new </em><br /> <em class="quotelev2">> > element (or make it global). </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> That's an unclean modification -- the set of documents matched by the </em><br /> <em class="quotelev1">> extended schema is not a pure subset of the set of documents matched by </em><br /> <em class="quotelev1">> the unextended one -- ergo you must put a namespace on something, </em><br /> <em class="quotelev1">> presumably the attribute you've now defined as global. </em><br /> Thanks. That's the solution I slouched towards myself. <br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 11:23:13 EDT</span> </div> From Conal.Tuohy at vuw.ac.nz Tue Apr 10 16:43:33 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 11 Apr 2007 08:43:33 +1200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D7C@STAWINCOMAILCL1.staff.vuw.ac.nz> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Conal Tuohy <Conal.Tuohy_at_vuw.ac.nz> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 08:43:33 +1200</span><br /> </address> For the record I am with Lou 100%. <br /> I think TEI-processing software can safely ignore attributes which it does not understand. <br /> Regarding translation and renaming in general, it's clear to me that a new namespace must be used whenever a name is changed, for whatever reason. Otherwise I will change <text> to <chapter> and you will change <div> to <chapter>, and we will have the potential for confusion. Or 2 languages will have the same word meaning 2 different things, and again we have a confusion. <br /> On a positive note, distinct XML namespaces should actually help to clarify the distinction between the distinct vocabularies, and allow for simple transformation mechanisms (for canonicalisation into TEI interchange form). <br /> Con <br /> <p>-----Original Message----- <br /> From: tei-council-bounces_at_lists.<!--nospam-->village.Virginia.EDU on behalf of Dot Porter <br /> Sent: Wed 11/04/07 0:57 <br /> To: Lou Burnard <br /> Cc: TEI Council; James.Cummings_at_oucs.<!--nospam-->ox.ac.uk <br /> Subject: Re: [tei-council] MD chapter revised: namespace rules <br /> <br /> I also agree with James on points 1, 2, and 3. I'm on the fence on <br /> point 4 - whether renamed elements should be in a different namespace <br /> - but I think Lou makes a very good point about name collision which <br /> has me leaning towards renaming = different namespace. It's a little <br /> more work up front, perhaps, but would save a lot of headache in the <br /> long run. <br /> Dot <br /> On 4/10/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">> > Lou Burnard wrote: </em><br /> <em class="quotelev3">> >> Inter alia, and as a straw man, I'd like to propose for discussion the </em><br /> <em class="quotelev3">> >> following draconian rules about the use of namespaces in modification: </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> 1. New elements may not be placed in the TEI namespace </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I can agree with that, though we may disagree on what is a 'new' element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> By "new" I mean an element not already defined by the Guidelines. What </em><br /> <em class="quotelev1">> fiendishly cunning other case do you have in mind Dr Cummings? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> 2. If new attributes are added to a TEI element, the resulting element </em><br /> <em class="quotelev3">> >> must be moved out of the TEI namespace. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm not convinced by that. If I add a new attribute to a TEI element, the </em><br /> <em class="quotelev2">> > TEI element is still a TEI element. It just has a new attribute and that </em><br /> <em class="quotelev2">> > attribute is signalled as not being part of the TEI by itself being in a </em><br /> <em class="quotelev2">> > different namespace. my:newAtt="foo". I don't see that the element is now </em><br /> <em class="quotelev2">> > so changed that it is no longer the TEI element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> OK, this is a plausible argument and I am disposed to agree with you. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> 3. Only modified elements which have undergone a clean modification [1] </em><br /> <em class="quotelev3">> >> may remain in the TEI namespace. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Agreed, but I think adding an attribute which is in a different namespace </em><br /> <em class="quotelev2">> > is a clean modification. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes, though only if I agree with you on (2) above. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> You are right that changed content models, etc. </em><br /> <em class="quotelev2">> > are dirty changes. However, if the change is to remove an element from </em><br /> <em class="quotelev2">> > some classes, or limit an open attribute value list, or anything similar </em><br /> <em class="quotelev2">> > which constrains it, then that is a clean modification because the TEI </em><br /> <em class="quotelev2">> > content still validates against tei_all. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes. The draft does try to make this distinction clear. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">> >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, </em><br /> <em class="quotelev3">> >> except that TEI namespaces are defined for systematic renaming of TEI </em><br /> <em class="quotelev3">> >> elements into different languages. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm still not convinced that TEI translations need separate namespaces. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Well, let us wait for reactions from others, because I currently still </em><br /> <em class="quotelev1">> think that separate namespaces for separate translations makes a whole </em><br /> <em class="quotelev1">> lot of sense, organizationally, politically, and technically. If we dont </em><br /> <em class="quotelev1">> do that, then every new translation has to watch out for name collision </em><br /> <em class="quotelev1">> with every other language now and in the future! I am less sure about </em><br /> <em class="quotelev1">> individual renamings, but still feel that basically if you don't use the </em><br /> <em class="quotelev1">> names we have chosen for our elements, whether or not you make explicit </em><br /> <em class="quotelev1">> the relationship between your name and ours, you are polluting the TEI </em><br /> <em class="quotelev1">> namespace. And you have all the headaches about name collision. And my </em><br /> <em class="quotelev1">> dimwitted TEI application has to go and read the ODD every time it </em><br /> <em class="quotelev1">> processes a document to know what to do with your renaming. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > They should be conformant according to the Renaming Subset schema. If </em><br /> <em class="quotelev2">> > something is simply a renamed element/attribute and it otherwise is </em><br /> <em class="quotelev2">> > identical to the TEI original (and documented with ODD/equiv) then I do not </em><br /> <em class="quotelev2">> > feel it needs to be in a different namespace. It is, for all intents and </em><br /> <em class="quotelev2">> > purposes, the TEI element. If I have <div type="chapter"> and instead </em><br /> <em class="quotelev2">> > rename this <chapter> keeping everything else the same, does this really </em><br /> <em class="quotelev2">> > need a new namespace? The original view of the Renaming Subset was that it </em><br /> <em class="quotelev2">> > didn't. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm happy with the concept of a renaming subset schema. I just think it </em><br /> <em class="quotelev1">> ought to use a different namespace for the renamed elements. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> [1]A "clean" modification is defined in chapter MD as one which results </em><br /> <em class="quotelev3">> >> in a schema that matches a proper subset of the documents matched by an </em><br /> <em class="quotelev3">> >> unmodified schema. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I think clean should include reversal of renamings, and that translations </em><br /> <em class="quotelev2">> > are just a specialised form of renamings. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think adding this level of complexity may be just a level too far for </em><br /> <em class="quotelev1">> many simple-minded processors. But, as I said, let's wait to see what </em><br /> <em class="quotelev1">> others think. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">> >> Comments? Alternative proposals? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Alternative proposal: </em><br /> <em class="quotelev2">> > 1. Entirely new elements should be in a new namespace </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 2. Renamed elements, properly documented should remain in TEI namespace </em><br /> <em class="quotelev1">> no </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 3. Translations are just a form of renaming. </em><br /> <em class="quotelev1">> yes, except that they are systematic </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 4. Adding new (namespaced) attributes to a TEI element, does not stop that </em><br /> <em class="quotelev2">> > TEI element being TEI. </em><br /> <em class="quotelev1">> yes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > 5. Our definition of 'clean' modification should include renamings. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> no! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 16:43:56 EDT</span> </div> From cwittern at gmail.com Tue Apr 10 21:13:18 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 11 Apr 2007 10:13:18 +0900 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> Message-ID: <461C362E.2010704@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 10:13:18 +0900</span><br /> </address> Dan O'Donnell wrote: <br /> <em class="quotelev1">> It seems to me that we can refine the set of principles: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 1. New elements may not be placed in the TEI namespace. </em><br /> <em class="quotelev1">> 3. Only modified elements which have undergone a clean modification may </em><br /> <em class="quotelev1">> remain in the TEI namespace. The addition of attributes to a TEI element </em><br /> <em class="quotelev1">> is clean as long as the new attribute itself is identified as coming </em><br /> <em class="quotelev1">> from a different namespace. </em><br /> <em class="quotelev1">> 4. Official translations have their own TEI namespace as long as they </em><br /> <em class="quotelev1">> represent a 1:1 translation of the entire standard and remain </em><br /> <em class="quotelev1">> up-to-date. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> This is what I would agree to as well. <br /> <em class="quotelev1">> Like everybody else, I'm having trouble with simple project-based </em><br /> <em class="quotelev1">> renamings, since they can remain in the TEI namespace under principle 3. </em><br /> <em class="quotelev1">> </em><br /> I do not have a problem here. For interchange, it would be a matter of <br /> courtesy to restore the original TEI form. <br /> <em class="quotelev1">> The same is also true of translations if you see them as being in </em><br /> <em class="quotelev1">> essence renamings (about which more below), since they should also be </em><br /> <em class="quotelev1">> clean--though I can see the practical and political argument in favour </em><br /> <em class="quotelev1">> of using distinct (sub) namespaces for official translations as long as </em><br /> <em class="quotelev1">> they reflect a complete, up-to-date, and 1:1 translation of the </em><br /> <em class="quotelev1">> standard. </em><br /> <em class="quotelev1">> </em><br /> It might be better just to indicate the "valid as of" date. <br /> <em class="quotelev1">> I think my own leaning is that the clean modification principle 3 is </em><br /> <em class="quotelev1">> key. The use of the TEI namespace says: "I am identical to or have been </em><br /> <em class="quotelev1">> cleanly modified from the TEI standard; you can process me with the </em><br /> <em class="quotelev1">> assurance that you understand what I am"--i.e. the question of whether </em><br /> <em class="quotelev1">> something stays in the namespace is not only a negative decision </em><br /> <em class="quotelev1">> identifying elements that have diverged from the standard, but a </em><br /> <em class="quotelev1">> positive one identifying elements that have not. So under this, cleanly </em><br /> <em class="quotelev1">> renamed elements would remain in the namespace, even if that adds a </em><br /> <em class="quotelev1">> processing cost in figuring out what they are an alias of. Of course the </em><br /> <em class="quotelev1">> addition of a processing cost is an argument against renaming elements </em><br /> <em class="quotelev1">> for interchange that projects might want to pay attention to. Avoiding </em><br /> <em class="quotelev1">> conflicts is the responsibility of the renamer, and a conflicting name </em><br /> <em class="quotelev1">> is not a clean modification IMO (except for translations of the entire </em><br /> <em class="quotelev1">> standard, see below). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If we take the view that the TEI namespace is a positive assertion, then </em><br /> <em class="quotelev1">> translations are a bit of an issue: presumably they are by definition </em><br /> <em class="quotelev1">> clean modifications (except that unlike modifications of individual </em><br /> <em class="quotelev1">> elements, there is always the possibility that individual translated </em><br /> <em class="quotelev1">> elements might conflict with English language ones), in which case they </em><br /> <em class="quotelev1">> should under principle 3 be in the TEI namespace. </em><br /> Translations *are* in a TEI namespace, just a different one from the <br /> canonical TEI. <br /> All the best, <br /> Christian <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 21:13:37 EDT</span> </div> From conal.tuohy at vuw.ac.nz Tue Apr 10 21:39:28 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 11 Apr 2007 13:39:28 +1200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> Message-ID: <1176255568.3766.333.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Conal Tuohy <conal.tuohy_at_vuw.ac.nz> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 13:39:28 +1200</span><br /> </address> On Tue, 2007-04-10 at 09:02 -0600, Dan O'Donnell wrote: <br /> <em class="quotelev1">> The use of the TEI namespace says: "I am identical to or have been </em><br /> <em class="quotelev1">> cleanly modified from the TEI standard; you can process me with the </em><br /> <em class="quotelev1">> assurance that you understand what I am"--i.e. the question of whether </em><br /> <em class="quotelev1">> something stays in the namespace is not only a negative decision </em><br /> <em class="quotelev1">> identifying elements that have diverged from the standard, but a </em><br /> <em class="quotelev1">> positive one identifying elements that have not. So under this, cleanly </em><br /> <em class="quotelev1">> renamed elements would remain in the namespace, even if that adds a </em><br /> <em class="quotelev1">> processing cost in figuring out what they are an alias of. </em><br /> I don't think this can work, really. IMHO if an element is renamed, it <br /> MUST go into a different namespace. Remember, the namespace URI is an <br /> identifier for a vocabulary. If you rename a TEI element, e.g. renaming <br /> <div> to <chapter>, then you are using a different vocabulary from the <br /> TEI standard, and you should use a different namespace URI. Otherwise, <br /> if I rename <text> to <chapter>, how can we tell whether your <chapter> <br /> and my <chapter> elements are the same? <br /> <em class="quotelev1">> If we take the view that the TEI namespace is a positive assertion, then </em><br /> <em class="quotelev1">> translations are a bit of an issue: presumably they are by definition </em><br /> <em class="quotelev1">> clean modifications (except that unlike modifications of individual </em><br /> <em class="quotelev1">> elements, there is always the possibility that individual translated </em><br /> <em class="quotelev1">> elements might conflict with English language ones) </em><br /> Indeed there would be that possibility, because the English-based TEI <br /> vocabulary and the other non-English TEI translations are by definition <br /> different vocabularies. But we simply must not allow this possibility - <br /> we mustn't define a namespace in which names are ambiguous. Hence we <br /> must have distinct namespaces for the localised TEI tagsets. <br /> <em class="quotelev1">> , in which case they </em><br /> <em class="quotelev1">> should under principle 3 be in the TEI namespace. We don't want </em><br /> <em class="quotelev1">> translations by implication or practice to be or be seen as </em><br /> <em class="quotelev1">> substantively different from the standard in anyway. </em><br /> I suggest that we need to "bite the bullet" and define official TEI <br /> namespaces for all the translated versions. <br /> Con <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 21:41:22 EDT</span> </div> From daniel.odonnell at uleth.ca Tue Apr 10 22:54:38 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 10 Apr 2007 20:54:38 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176255568.3766.333.camel@localhost> Message-ID: <1176260078.6262.3.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 10 Apr 2007 20:54:38 -0600</span><br /> </address> Good enough. I don't feel it strongly and the renamed elements are the <br /> only ones that I thought might be in the same space. But then we need to <br /> redefine the principle. It is not "clean" but not change for element <br /> names that we allow in the same namespace then? <br /> On Wed, 2007-04-11 at 13:39 +1200, Conal Tuohy wrote: <br /> <em class="quotelev1">> On Tue, 2007-04-10 at 09:02 -0600, Dan O'Donnell wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > The use of the TEI namespace says: "I am identical to or have been </em><br /> <em class="quotelev2">> > cleanly modified from the TEI standard; you can process me with the </em><br /> <em class="quotelev2">> > assurance that you understand what I am"--i.e. the question of whether </em><br /> <em class="quotelev2">> > something stays in the namespace is not only a negative decision </em><br /> <em class="quotelev2">> > identifying elements that have diverged from the standard, but a </em><br /> <em class="quotelev2">> > positive one identifying elements that have not. So under this, cleanly </em><br /> <em class="quotelev2">> > renamed elements would remain in the namespace, even if that adds a </em><br /> <em class="quotelev2">> > processing cost in figuring out what they are an alias of. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I don't think this can work, really. IMHO if an element is renamed, it </em><br /> <em class="quotelev1">> MUST go into a different namespace. Remember, the namespace URI is an </em><br /> <em class="quotelev1">> identifier for a vocabulary. If you rename a TEI element, e.g. renaming </em><br /> <em class="quotelev1">> <div> to <chapter>, then you are using a different vocabulary from the </em><br /> <em class="quotelev1">> TEI standard, and you should use a different namespace URI. Otherwise, </em><br /> <em class="quotelev1">> if I rename <text> to <chapter>, how can we tell whether your <chapter> </em><br /> <em class="quotelev1">> and my <chapter> elements are the same? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > If we take the view that the TEI namespace is a positive assertion, then </em><br /> <em class="quotelev2">> > translations are a bit of an issue: presumably they are by definition </em><br /> <em class="quotelev2">> > clean modifications (except that unlike modifications of individual </em><br /> <em class="quotelev2">> > elements, there is always the possibility that individual translated </em><br /> <em class="quotelev2">> > elements might conflict with English language ones) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Indeed there would be that possibility, because the English-based TEI </em><br /> <em class="quotelev1">> vocabulary and the other non-English TEI translations are by definition </em><br /> <em class="quotelev1">> different vocabularies. But we simply must not allow this possibility - </em><br /> <em class="quotelev1">> we mustn't define a namespace in which names are ambiguous. Hence we </em><br /> <em class="quotelev1">> must have distinct namespaces for the localised TEI tagsets. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > , in which case they </em><br /> <em class="quotelev2">> > should under principle 3 be in the TEI namespace. We don't want </em><br /> <em class="quotelev2">> > translations by implication or practice to be or be seen as </em><br /> <em class="quotelev2">> > substantively different from the standard in anyway. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I suggest that we need to "bite the bullet" and define official TEI </em><br /> <em class="quotelev1">> namespaces for all the translated versions. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Con </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 10 2007 - 22:54:44 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 05:00:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 10:00:10 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461C362E.2010704@gmail.com> Message-ID: <461CA39A.806@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 10:00:10 +0100</span><br /> </address> Wittern Christian wrote: <br /> <em class="quotelev1">> Dan O'Donnell wrote: </em><br /> <em class="quotelev2">>> It seems to me that we can refine the set of principles: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> 1. New elements may not be placed in the TEI namespace. </em><br /> <em class="quotelev2">>> 3. Only modified elements which have undergone a clean modification may </em><br /> <em class="quotelev2">>> remain in the TEI namespace. The addition of attributes to a TEI element </em><br /> <em class="quotelev2">>> is clean as long as the new attribute itself is identified as coming </em><br /> <em class="quotelev2">>> from a different namespace. </em><br /> <em class="quotelev2">>> 4. Official translations have their own TEI namespace as long as they </em><br /> <em class="quotelev2">>> represent a 1:1 translation of the entire standard and remain </em><br /> <em class="quotelev2">>> up-to-date. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> This is what I would agree to as well. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Like everybody else, I'm having trouble with simple project-based </em><br /> <em class="quotelev2">>> renamings, since they can remain in the TEI namespace under principle 3. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> I think there's a misunderstanding here. Renaming an element is *not* a <br /> clean modification, since the set of documents now regarded as valid is <br /> not a pure subset of the documents regarded as valid before the <br /> modification. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 05:02:15 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 05:05:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 10:05:57 +0100 Subject: [tei-council] TRAC system down Message-ID: <461CA4F5.8020602@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 10:05:57 +0100</span><br /> </address> Apologies for the inconvenience, but the machine tei.oucs.ox.ac.uk is <br /> currently feeling a bit peaky. This means that Roma, Trac, and <br /> TEI-at-Oxford are all inaccessible until I find out what's wrong. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 05:07:59 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Wed Apr 11 06:37:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 11 Apr 2007 11:37:27 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CA39A.806@oucs.ox.ac.uk> Message-ID: <461CBA67.6050105@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 11:37:27 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> Wittern Christian wrote: </em><br /> <em class="quotelev3">>>> Like everybody else, I'm having trouble with simple project-based </em><br /> <em class="quotelev3">>>> renamings, since they can remain in the TEI namespace under principle 3. </em><br /> <em class="quotelev1">> I think there's a misunderstanding here. Renaming an element is *not* a </em><br /> <em class="quotelev1">> clean modification, since the set of documents now regarded as valid is </em><br /> <em class="quotelev1">> not a pure subset of the documents regarded as valid before the </em><br /> <em class="quotelev1">> modification. </em><br /> <p>I think this misunderstanding arises from my proposal... <br /> I was suggesting that TEI Conformant documents could have renamings in the <br /> TEI namespace, as long as they could be reverted according to the <br /> information in the referenced ODD. And then TEI Interchange Format would <br /> insist that any such renamings be reverted before interchange. <br /> However, it seems like a majority of people now do not see renamings as a <br /> clean modification, so renamings must then appear in a new namespace. <br /> So: <br /> 1) Any new element must be in user-defined namespace (UDN) <br /> 2) Any new attribute must be in UDN <br /> 3) If you make a dirty (i.e. non-subsetting) change to an element it must <br /> move to a UDN (and possibly be renamed) <br /> 4) If you make a dirty change to an attribute it must move to a UDN (and <br /> possibly be renamed) <br /> 5) The only changes to elements or attributes which do not result in them <br /> being moved to a UDN are subsetting changes. That is, changes with further <br /> restrict content models, attribute value lists, or datatypes, in such a <br /> manner that a document which validates against this schema also continues <br /> to validate against tei_all. <br /> Is that a fair summary? <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 06:37:31 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 07:19:07 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 12:19:07 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CBA67.6050105@computing-services.oxford.ac.uk> Message-ID: <461CC42B.8050200@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 12:19:07 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">>> Wittern Christian wrote: </em><br /> <em class="quotelev4">>>>> Like everybody else, I'm having trouble with simple project-based </em><br /> <em class="quotelev4">>>>> renamings, since they can remain in the TEI namespace under principle 3. </em><br /> <em class="quotelev2">>> I think there's a misunderstanding here. Renaming an element is *not* a </em><br /> <em class="quotelev2">>> clean modification, since the set of documents now regarded as valid is </em><br /> <em class="quotelev2">>> not a pure subset of the documents regarded as valid before the </em><br /> <em class="quotelev2">>> modification. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think this misunderstanding arises from my proposal... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I was suggesting that TEI Conformant documents could have renamings in the </em><br /> <em class="quotelev1">> TEI namespace, as long as they could be reverted according to the </em><br /> <em class="quotelev1">> information in the referenced ODD. And then TEI Interchange Format would </em><br /> <em class="quotelev1">> insist that any such renamings be reverted before interchange. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> However, it seems like a majority of people now do not see renamings as a </em><br /> <em class="quotelev1">> clean modification, so renamings must then appear in a new namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So: </em><br /> <em class="quotelev1">> 1) Any new element must be in user-defined namespace (UDN) </em><br /> <em class="quotelev1">> 2) Any new attribute must be in UDN </em><br /> <em class="quotelev1">> 3) If you make a dirty (i.e. non-subsetting) change to an element it must </em><br /> <em class="quotelev1">> move to a UDN (and possibly be renamed) </em><br /> <em class="quotelev1">> 4) If you make a dirty change to an attribute it must move to a UDN (and </em><br /> <em class="quotelev1">> possibly be renamed) </em><br /> <em class="quotelev1">> 5) The only changes to elements or attributes which do not result in them </em><br /> <em class="quotelev1">> being moved to a UDN are subsetting changes. That is, changes with further </em><br /> <em class="quotelev1">> restrict content models, attribute value lists, or datatypes, in such a </em><br /> <em class="quotelev1">> manner that a document which validates against this schema also continues </em><br /> <em class="quotelev1">> to validate against tei_all. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Is that a fair summary? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> tick. vg. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 07:21:09 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 07:20:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 12:20:41 +0100 Subject: [tei-council] TRAC system down In-Reply-To: <461CA4F5.8020602@oucs.ox.ac.uk> Message-ID: <461CC489.1080501@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 12:20:41 +0100</span><br /> </address> All systems are back now. Apologies for the interruption to service. <br /> L <br /> <p>Lou Burnard wrote: <br /> <em class="quotelev1">> Apologies for the inconvenience, but the machine tei.oucs.ox.ac.uk is </em><br /> <em class="quotelev1">> currently feeling a bit peaky. This means that Roma, Trac, and </em><br /> <em class="quotelev1">> TEI-at-Oxford are all inaccessible until I find out what's wrong. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 07:22:42 EDT</span> </div> From daniel.odonnell at uleth.ca Wed Apr 11 10:54:09 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 08:54:09 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CBA67.6050105@computing-services.oxford.ac.uk> Message-ID: <1176303249.4952.3.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 08:54:09 -0600</span><br /> </address> On Wed, 2007-04-11 at 11:37 +0100, James Cummings wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">> > Wittern Christian wrote: </em><br /> <em class="quotelev4">> >>> Like everybody else, I'm having trouble with simple project-based </em><br /> <em class="quotelev4">> >>> renamings, since they can remain in the TEI namespace under principle 3. </em><br /> <em class="quotelev2">> > I think there's a misunderstanding here. Renaming an element is *not* a </em><br /> <em class="quotelev2">> > clean modification, since the set of documents now regarded as valid is </em><br /> <em class="quotelev2">> > not a pure subset of the documents regarded as valid before the </em><br /> <em class="quotelev2">> > modification. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think this misunderstanding arises from my proposal... </em><br /> Oh good--it's not just me. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I was suggesting that TEI Conformant documents could have renamings in the </em><br /> <em class="quotelev1">> TEI namespace, as long as they could be reverted according to the </em><br /> <em class="quotelev1">> information in the referenced ODD. And then TEI Interchange Format would </em><br /> <em class="quotelev1">> insist that any such renamings be reverted before interchange. </em><br /> This is what I understood as well. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> However, it seems like a majority of people now do not see renamings as a </em><br /> <em class="quotelev1">> clean modification, so renamings must then appear in a new namespace. </em><br /> The only issue I have with that is that it seems to vitiate any reason <br /> for following canonical methods of altering or renaming elements. It <br /> seems to me that your original explanation in the paragraph above <br /> represents a case where people are working "within" the TEI. If the ODD <br /> references the changes and they are reverted before interchange, then it <br /> seems to me that non-conflicting renamings are suitable for remaining in <br /> the namespace of the version or translation to which they belong. <br /> -dan <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So: </em><br /> <em class="quotelev1">> 1) Any new element must be in user-defined namespace (UDN) </em><br /> <em class="quotelev1">> 2) Any new attribute must be in UDN </em><br /> <em class="quotelev1">> 3) If you make a dirty (i.e. non-subsetting) change to an element it must </em><br /> <em class="quotelev1">> move to a UDN (and possibly be renamed) </em><br /> <em class="quotelev1">> 4) If you make a dirty change to an attribute it must move to a UDN (and </em><br /> <em class="quotelev1">> possibly be renamed) </em><br /> <em class="quotelev1">> 5) The only changes to elements or attributes which do not result in them </em><br /> <em class="quotelev1">> being moved to a UDN are subsetting changes. That is, changes with further </em><br /> <em class="quotelev1">> restrict content models, attribute value lists, or datatypes, in such a </em><br /> <em class="quotelev1">> manner that a document which validates against this schema also continues </em><br /> <em class="quotelev1">> to validate against tei_all. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Is that a fair summary? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 10:54:16 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 11:46:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 16:46:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176303249.4952.3.camel@caedmon> Message-ID: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 16:46:37 +0100</span><br /> </address> In message <1176303249.4952.3.camel_at_caedmon> daniel.<!--nospam-->odonnell_at_uleth.<!--nospam-->ca writes: <br /> <em class="quotelev2">> > I was suggesting that TEI Conformant documents could have renamings in the </em><br /> <em class="quotelev2">> > TEI namespace, as long as they could be reverted according to the </em><br /> <em class="quotelev2">> > information in the referenced ODD. And then TEI Interchange Format would </em><br /> <em class="quotelev2">> > insist that any such renamings be reverted before interchange. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This is what I understood as well. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <p>OK, it's time to get radical. What do we need "TEI Interchange format" for? Why <br /> do we need to define it at all? <br /> TEI-conformant documents must be valid XML and must have an ODD. Why do we need <br /> to go beyond that? <br /> So far after much scratching of heads, I don't think I have come up with any <br /> need for the concept beyond the possibility of non-TEI names cluttering up the <br /> namespace (which I also think we have now agreed to get rid of). <br /> The keen eyed readers amongst you will have noticed that chapter IN has now <br /> disappeared from P5. I see no need to bring it back, since it is of purely <br /> antiquarian interest. <br /> So, TEI Conformant documents are ipso facto in the interchange format. End of <br /> story. We don't need to worry about non TEI conformant (but interchangeable) XML <br /> documents. <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 11:46:40 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Wed Apr 11 12:30:19 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Apr 2007 17:30:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> Message-ID: <461D0D1B.8000204@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 17:30:19 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> In message <1176303249.4952.3.camel_at_caedmon> daniel.<!--nospam-->odonnell_at_uleth.<!--nospam-->ca writes: </em><br /> <em class="quotelev3">>>> I was suggesting that TEI Conformant documents could have renamings in the </em><br /> <em class="quotelev3">>>> TEI namespace, as long as they could be reverted according to the </em><br /> <em class="quotelev3">>>> information in the referenced ODD. And then TEI Interchange Format would </em><br /> <em class="quotelev3">>>> insist that any such renamings be reverted before interchange. </em><br /> <em class="quotelev2">>> This is what I understood as well. </em><br /> <em class="quotelev1">> OK, it's time to get radical. What do we need "TEI Interchange format" for? Why </em><br /> <em class="quotelev1">> do we need to define it at all? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> TEI-conformant documents must be valid XML and must have an ODD. Why do we need </em><br /> <em class="quotelev1">> to go beyond that? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So far after much scratching of heads, I don't think I have come up with any </em><br /> <em class="quotelev1">> need for the concept beyond the possibility of non-TEI names cluttering up the </em><br /> <em class="quotelev1">> namespace (which I also think we have now agreed to get rid of). </em><br /> In my mind it was solely there to insist on TEI Pure Subset versions of <br /> documents for interchange. I.e. to revert all renamings etc. <br /> I suppose that idea still *could* have some small merit, in that if I <br /> have renamed tei:div[@type='chapter'] to my:chapter then in a TEI <br /> Interchange Format it would, one assume be renamed back. This is why I <br /> never viewed renaming changes as being as dirty as content model <br /> changes...there was always a possibility of them being switched back. <br /> Once you change the content model you can't really do that in most <br /> cases. Does that mean those documents should never be interchanged? <br /> No, of course not. Thus, TEI Interchange Format really becomes <br /> meaningless, just another way to say TEI Pure Subset. <br /> <em class="quotelev1">> The keen eyed readers amongst you will have noticed that chapter IN has now </em><br /> <em class="quotelev1">> disappeared from P5. I see no need to bring it back, since it is of purely </em><br /> <em class="quotelev1">> antiquarian interest. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So, TEI Conformant documents are ipso facto in the interchange format. End of </em><br /> <em class="quotelev1">> story. We don't need to worry about non TEI conformant (but interchangeable) XML </em><br /> <em class="quotelev1">> documents. </em><br /> I think I can agree with that now. <br /> -James <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 12:23:18 EDT</span> </div> From laurent.romary at loria.fr Wed Apr 11 14:35:04 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 11 Apr 2007 20:35:04 +0200 Subject: [tei-council] DTD or schema Message-ID: <C2D97EDD-7E28-4737-AAEC-27CE21FB37D3@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 20:35:04 +0200</span><br /> </address> Hi all (editors?), <br /> A small and quick question: in the PD chapter I find the expression <br /> "in the following DTD fragment", which actually refers to a RelaxNG <br /> fragment. What wording should we use in the guidelines: <br /> - in the following schema fragment <br /> - in the following RelaxNG schema fragment <br /> - ... <br /> Laurent <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 14:36:56 EDT</span> </div> From laurent.romary at loria.fr Wed Apr 11 14:35:24 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 11 Apr 2007 20:35:24 +0200 Subject: [tei-council] DTD or schema Message-ID: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 20:35:24 +0200</span><br /> </address> Hi all (editors?), <br /> A small and quick question: in the PD chapter I find the expression <br /> "in the following DTD fragment", which actually refers to a RelaxNG <br /> fragment. What wording should we use in the guidelines: <br /> - in the following schema fragment <br /> - in the following RelaxNG schema fragment <br /> - ... <br /> Laurent <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 14:37:17 EDT</span> </div> From daniel.odonnell at uleth.ca Wed Apr 11 14:50:37 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 12:50:37 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461D0D1B.8000204@oucs.ox.ac.uk> Message-ID: <1176317437.4952.18.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 12:50:37 -0600</span><br /> </address> On Wed, 2007-04-11 at 17:30 +0100, James Cummings wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">> > In message <1176303249.4952.3.camel_at_caedmon> daniel.<!--nospam-->odonnell_at_uleth.<!--nospam-->ca writes: </em><br /> <em class="quotelev4">> >>> I was suggesting that TEI Conformant documents could have renamings in the </em><br /> <em class="quotelev4">> >>> TEI namespace, as long as they could be reverted according to the </em><br /> <em class="quotelev4">> >>> information in the referenced ODD. And then TEI Interchange Format would </em><br /> <em class="quotelev4">> >>> insist that any such renamings be reverted before interchange. </em><br /> <em class="quotelev3">> >> This is what I understood as well. </em><br /> <em class="quotelev2">> > OK, it's time to get radical. What do we need "TEI Interchange format" for? Why </em><br /> <em class="quotelev2">> > do we need to define it at all? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > TEI-conformant documents must be valid XML and must have an ODD. Why do we need </em><br /> <em class="quotelev2">> > to go beyond that? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > So far after much scratching of heads, I don't think I have come up with any </em><br /> <em class="quotelev2">> > need for the concept beyond the possibility of non-TEI names cluttering up the </em><br /> <em class="quotelev2">> > namespace (which I also think we have now agreed to get rid of). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In my mind it was solely there to insist on TEI Pure Subset versions of </em><br /> <em class="quotelev1">> documents for interchange. I.e. to revert all renamings etc. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I suppose that idea still *could* have some small merit, in that if I </em><br /> <em class="quotelev1">> have renamed tei:div[@type='chapter'] to my:chapter then in a TEI </em><br /> <em class="quotelev1">> Interchange Format it would, one assume be renamed back. This is why I </em><br /> <em class="quotelev1">> never viewed renaming changes as being as dirty as content model </em><br /> <em class="quotelev1">> changes...there was always a possibility of them being switched back. </em><br /> <em class="quotelev1">> Once you change the content model you can't really do that in most </em><br /> <em class="quotelev1">> cases. Does that mean those documents should never be interchanged? </em><br /> <em class="quotelev1">> No, of course not. Thus, TEI Interchange Format really becomes </em><br /> <em class="quotelev1">> meaningless, just another way to say TEI Pure Subset. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > The keen eyed readers amongst you will have noticed that chapter IN has now </em><br /> <em class="quotelev2">> > disappeared from P5. I see no need to bring it back, since it is of purely </em><br /> <em class="quotelev2">> > antiquarian interest. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > So, TEI Conformant documents are ipso facto in the interchange format. End of </em><br /> <em class="quotelev2">> > story. We don't need to worry about non TEI conformant (but interchangeable) XML </em><br /> <em class="quotelev2">> > documents. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think I can agree with that now.\ </em><br /> My only question is why to we discuss renaming elements as distinct from <br /> just creating new ones at all then? I.e. why raise the possibility at <br /> all? It sounds like we now have the following principles: <br /> 1) Only official TEI subsets and translations or clean subsets thereof <br /> may use the official TEI namespaces <br /> 2) All new or renamed elements, attributes, or non-clean modifications <br /> of elements or attributes, must be in a user defined namespace. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 14:50:41 EDT</span> </div> From Syd_Bauman at Brown.edu Wed Apr 11 15:04:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Apr 2007 15:04:09 -0400 Subject: [tei-council] DTD or schema In-Reply-To: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> Message-ID: <17949.12585.803142.804630@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 15:04:09 -0400</span><br /> </address> <em class="quotelev1">> A small and quick question: in the PD chapter I find the expression </em><br /> <em class="quotelev1">> "in the following DTD fragment", which actually refers to a RelaxNG </em><br /> <em class="quotelev1">> fragment. What wording should we use in the guidelines: </em><br /> <em class="quotelev1">> - in the following schema fragment </em><br /> <em class="quotelev1">> - in the following RelaxNG schema fragment </em><br /> The latter is what we've been using. But in truth, at some point we <br /> need to go through and fix all the references to that schema language <br /> to "RELAX NG"[1]. <br /> Note <br /> ---- [1] I am pretty sure the correct name is "RELAX NG", even though quite a few people, including Eric van der Vlist and I, call it "Relax NG". But the authors of the language pretty consistently call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and ISO/IEC (it is becoming an international standard). _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 15:04:14 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:13:25 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:13:25 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <C2D97EDD-7E28-4737-AAEC-27CE21FB37D3@loria.fr> Message-ID: <461D4165.6080804@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 21:13:25 +0100</span><br /> </address> Laurent Romary wrote: <br /> <em class="quotelev1">> Hi all (editors?), </em><br /> <em class="quotelev1">> A small and quick question: in the PD chapter I find the expression </em><br /> <em class="quotelev1">> "in the following DTD fragment", which actually refers to a RelaxNG </em><br /> <em class="quotelev1">> fragment. What wording should we use in the guidelines: </em><br /> <em class="quotelev1">> - in the following schema fragment </em><br /> My preference would be for this. <br /> <em class="quotelev1">> - in the following RelaxNG schema fragment </em><br /> The trouble is that it is actually a Relax NG schema fragment in compact <br /> syntax notation, which is a bit of a mouthful. <br /> <p><p><em class="quotelev1">> - ... </em><br /> <em class="quotelev1">> Laurent </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 16:13:29 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:19:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:19:49 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <17949.12585.803142.804630@emt.wwp.brown.edu> Message-ID: <461D42E5.5030009@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 21:19:49 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> ---- </em><br /> <em class="quotelev1">> [1] I am pretty sure the correct name is "RELAX NG", even though </em><br /> <em class="quotelev1">> quite a few people, including Eric van der Vlist and I, call it </em><br /> <em class="quotelev1">> "Relax NG". But the authors of the language pretty consistently </em><br /> <em class="quotelev1">> call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and </em><br /> <em class="quotelev1">> ISO/IEC (it is becoming an international standard). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> At http://www.relaxng.org/ it is "pretty consistently" called "RELAX <br /> NG". Also throughout the text of Eric van Vlist's book. So that's <br /> definitely what it should be, even though the lower casing does look <br /> sort of cute. And, btw, fwiw, it *is* an ISO standard isn't it (or at <br /> least a DIS)? 19757-2 <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 16:19:53 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:26:22 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:26:22 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176317437.4952.18.camel@caedmon> Message-ID: <461D446E.8060800@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 21:26:22 +0100</span><br /> </address> Daniel O'Donnell wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> My only question is why to we discuss renaming elements as distinct from </em><br /> <em class="quotelev1">> just creating new ones at all then? I.e. why raise the possibility at </em><br /> <em class="quotelev1">> all? </em><br /> Renaming, like translation, is a specific kind of user mod which may <br /> greatly improve usability for some applications. In TEI-Tite, for <br /> example, they have introduced lots of renaming mods of the kind <xx> <br /> which are defined as renamings for <hi rend="xx">. It seems helpful to <br /> identify this as a possibility which is not quite the same as <br /> *inventing* a tag <xx>, even though in conformance terms they are much <br /> of a muchness -- if only because, as James points out, it's a Simple <br /> Matter Of Programming to canonicalise the renaming. <br /> <p><em class="quotelev1">> 1) Only official TEI subsets and translations or clean subsets thereof </em><br /> <em class="quotelev1">> may use the official TEI namespaces </em><br /> <em class="quotelev1">> </em><br /> what exactly is an "official" TEI subset? I think you mean "only schemas <br /> derived from the TEI modules either without modification or using only <br /> "clean" modification" <br /> <em class="quotelev1">> 2) All new or renamed elements, attributes, or non-clean modifications </em><br /> <em class="quotelev1">> of elements or attributes, must be in a user defined namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> that's about the size of it. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 16:26:25 EDT</span> </div> From Syd_Bauman at Brown.edu Wed Apr 11 16:45:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Apr 2007 16:45:04 -0400 Subject: [tei-council] DTD or schema In-Reply-To: <461D42E5.5030009@computing-services.oxford.ac.uk> Message-ID: <17949.18640.40107.20630@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 16:45:04 -0400</span><br /> </address> <em class="quotelev2">> > - in the following schema fragment </em><br /> <em class="quotelev1">> My preference would be for this. </em><br /> And then we'd use the same phrase if it were a Schematron fragment? <br /> Sounds OK to me, actually, as the two don't look in the least alike. <br /> (And, as long as prefixes are used, wouldn't look alike even if we <br /> used the XML syntax.) <br /> <p><em class="quotelev1">> And, btw, fwiw, it *is* an ISO standard isn't it (or at least a </em><br /> <em class="quotelev1">> DIS)? 19757-2 </em><br /> Last I knew it was a DIS, but ... whadayaknow, I just checked, and <br /> yes, it is indeed now a full-fledged ISO standard (stage "60.60", aka <br /> "International Standard published"). And it has been so since early <br /> 2004 or so, which shows you how well I was paying attention! <br /> So if you want to spend just over USD 100, you can get your very own <br /> copy. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 16:45:06 EDT</span> </div> From daniel.odonnell at uleth.ca Wed Apr 11 17:43:03 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 15:43:03 -0600 Subject: [tei-council] 2007 Members Meeting Message-ID: <1176327783.5222.33.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 11 Apr 2007 15:43:03 -0600</span><br /> </address> Hi all, <br /> The Members Meeting Committee met today and it looks like we are going <br /> to have a very interesting programme--in addition to plenary speakers <br /> and poster sessions as in past years, we also have what is shaping up to <br /> be a very full series of conference-style sessions on various TEI and <br /> other markup issues. <br /> We also can accept up to 25 posters. Currently we have about proposals <br /> for about half that number. Given the amount of work currently been done <br /> by members of the council as we push towards finishing P5, however, we <br /> thought members of the council may also have interesting ideas that they <br /> would like to share in the poster session. <br /> As council members are currently preparing for our Berlin meeting, let <br /> this be an initial invitation. While we expect to close the poster <br /> session at some point, we can consider proposals for the next month or <br /> so. <br /> -dan <br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 17:43:06 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 11 19:53:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 00:53:18 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <17949.12585.803142.804630@emt.wwp.brown.edu> Message-ID: <461D74EE.1000102@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 00:53:18 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and </em><br /> <em class="quotelev1">> ISO/IEC (it is becoming an international standard). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> it has been an ISO standard since 1st December 2003 :-} <br /> and I agree, "RELAX NG" is the moniker. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 11 2007 - 19:53:22 EDT</span> </div> From laurent.romary at loria.fr Thu Apr 12 04:52:53 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 12 Apr 2007 10:52:53 +0200 Subject: [tei-council] DTD or schema In-Reply-To: <17949.18640.40107.20630@emt.wwp.brown.edu> Message-ID: <2D7C3512-3C5E-4790-8BFD-7A30AF1EE96C@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:52:53 +0200</span><br /> </address> Le 11 avr. 07 ? 22:45, Syd Bauman a ?crit : <br /> <em class="quotelev3">>>> - in the following schema fragment </em><br /> <em class="quotelev2">>> My preference would be for this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> And then we'd use the same phrase if it were a Schematron fragment? </em><br /> <em class="quotelev1">> Sounds OK to me, actually, as the two don't look in the least alike. </em><br /> <em class="quotelev1">> (And, as long as prefixes are used, wouldn't look alike even if we </em><br /> <em class="quotelev1">> used the XML syntax.) </em><br /> <em class="quotelev1">> </em><br /> OK. I stick to this. <br /> Laurent <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 04:54:16 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:23:07 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:23:07 +0100 Subject: [tei-council] "TEI Interchange" chapter Message-ID: <461DFA7B.1090002@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:23:07 +0100</span><br /> </address> This was one of the chapters I found inside my chocolate egg last Sunday. <br /> Interesting as it is for connoisseurs of technology archaeology, <br /> I can find more or less nothing in it worth saving for P5. <br /> My recommendation is that we simply drop it. <br /> Could I hear opinions to the contrary? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 05:23:10 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 05:25:03 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 10:25:03 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFA7B.1090002@oucs.ox.ac.uk> Message-ID: <461DFAEF.3060008@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:25:03 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> This was one of the chapters I found inside my chocolate egg last Sunday. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Interesting as it is for connoisseurs of technology archaeology, </em><br /> <em class="quotelev1">> I can find more or less nothing in it worth saving for P5. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> My recommendation is that we simply drop it. </em><br /> Hasn't Lou already done this? See his message from 2007-04-11T16:46 <br /> <em class="quotelev1">> Could I hear opinions to the contrary? </em><br /> Not from me. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 05:25:07 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 05:31:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 10:31:10 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFA7B.1090002@oucs.ox.ac.uk> Message-ID: <461DFC5E.3040703@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:31:10 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> This was one of the chapters I found inside my chocolate egg last Sunday. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Interesting as it is for connoisseurs of technology archaeology, </em><br /> <em class="quotelev1">> I can find more or less nothing in it worth saving for P5. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> My recommendation is that we simply drop it. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Could I hear opinions to the contrary? </em><br /> <em class="quotelev1">> </em><br /> When you get a bit further on in your email backlog, you'll see that <br /> this has already been done. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 05:33:14 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:37:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:37:12 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFAEF.3060008@computing-services.oxford.ac.uk> Message-ID: <461DFDC8.1030606@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:37:12 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Hasn't Lou already done this? See his message from 2007-04-11T16:46 </em><br /> <em class="quotelev1">> </em><br /> Why, so he has. By commenting it out, sigh, <br /> rather than removing it.... when will people <br /> start to trust version control... grumble.... <br /> So I have to read that backlog of email, eh. <br /> Drat. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 05:37:17 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:49:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:49:19 +0100 Subject: [tei-council] formatting of guidelines - schema fragments Message-ID: <461E009F.5040007@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:49:19 +0100</span><br /> </address> I know we have a work task on this, but that <br /> may not address a fundamental issue I have. <br /> When reading one of my allocated chapters, <br /> I was struck by the inclusion of schema fragments <br /> in the section with the formal definition <br /> of elements. What is the point of them, I wondered? <br /> The technical details are available in the <br /> alphabetical list of elements etc (the "second <br /> volume", if you like), for those who can read <br /> this stuff, so why repeat it here? <br /> More importantly, <br /> the code shown is simply one interpretation <br /> of the ODD (ie it divides each element into <br /> two patterns, foo.content and foo.attributes), <br /> which is not normative. <br /> Has this bothered anyone else? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 05:49:24 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 06:19:39 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 11:19:39 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E009F.5040007@oucs.ox.ac.uk> Message-ID: <461E07BB.7060804@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 11:19:39 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> I know we have a work task on this, but that </em><br /> <em class="quotelev1">> may not address a fundamental issue I have. </em><br /> Probably not, so we'd appreciate hearing of any other issues you have. <br /> <em class="quotelev1">> When reading one of my allocated chapters, </em><br /> <em class="quotelev1">> I was struck by the inclusion of schema fragments </em><br /> <em class="quotelev1">> in the section with the formal definition </em><br /> <em class="quotelev1">> of elements. What is the point of them, I wondered? </em><br /> <em class="quotelev1">> The technical details are available in the </em><br /> <em class="quotelev1">> alphabetical list of elements etc (the "second </em><br /> <em class="quotelev1">> volume", if you like), for those who can read </em><br /> <em class="quotelev1">> this stuff, so why repeat it here? </em><br /> I assume so that readers don't have to go elsewhere to find out the <br /> nitty-gritty of the elements they have been reading about. Might it be <br /> better to move these all to the end of the chapter? i.e. each chapter has <br /> section at the end for all the formal declarations? <br /> <em class="quotelev1">> More importantly, </em><br /> <em class="quotelev1">> the code shown is simply one interpretation </em><br /> <em class="quotelev1">> of the ODD (ie it divides each element into </em><br /> <em class="quotelev1">> two patterns, foo.content and foo.attributes), </em><br /> <em class="quotelev1">> which is not normative. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Has this bothered anyone else? </em><br /> No, I hadn't even considered it. (tbh) However, I do see that it is a bit <br /> strange that we are saying ODD is the way and then showing one particular <br /> interpretation of that ODD as Relax NG Compact Syntax throughout the <br /> guidelines. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 06:19:45 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu Apr 12 07:00:31 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 12 Apr 2007 12:00:31 +0100 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD6538.1060002@computing-services.oxford.ac.uk> Message-ID: <461E114F.8060600@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 12:00:31 +0100</span><br /> </address> Hi, <br /> my third Easter egg is the proofreading of ND. I wander now, should I <br /> just read/edit the xml on sourceforge at <br /> P5-Council\Source\Guidelines\en\ND-NamesDates.xml or should I also look <br /> at the proposed additions after Vilnius somewhere within P5-Council\Test? <br /> If the latter, could I please have the reference to the exact most up to <br /> date file? <br /> Thank-you, <br /> Arianna <br /> Lou Burnard wrote: <br /> <em class="quotelev1">> Christian Wittern wrote: </em><br /> <em class="quotelev2">>> Matthew James Driscoll wrote: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <listNym> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> does that mean you also proposa a <gi>listNym</gi> for TEI? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes. Matthew's report doesn't mention that there is a draft ODD, </em><br /> <em class="quotelev1">> probably because I have not yet got round to putting it anywhere where </em><br /> <em class="quotelev1">> Council members can see it easily. But if you look in the P5/Test </em><br /> <em class="quotelev1">> directory on sourceforge, you will see a file called testndextra.odd, </em><br /> <em class="quotelev1">> which contains the current state of the draft. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I've just put a copy of the HTML generated from this by Roma on the </em><br /> <em class="quotelev1">> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep </em><br /> <em class="quotelev1">> this up to date as the draft progresses </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">>>> Our principal task at this meeting was to develop mechanisms for </em><br /> <em class="quotelev3">>>> encoding </em><br /> <em class="quotelev3">>>> place-names, analogous to those which were developed for personal </em><br /> <em class="quotelev3">>>> names at </em><br /> <em class="quotelev3">>>> the meeting in Oxford last year, which would allow for the recording of </em><br /> <em class="quotelev3">>>> abstracted information about a place, such as map coordinate, GIS </em><br /> <em class="quotelev3">>>> information etc., as well as variant forms of the name, in different </em><br /> <em class="quotelev3">>>> languages (e.g. Praha, Prague, Praga) and/or different forms over </em><br /> <em class="quotelev3">>>> time (e.g. </em><br /> <em class="quotelev3">>>> Lundunum, London). On the analogy with <person>, we propose a <place> </em><br /> <em class="quotelev3">>>> element, which will usually contain at least one, and possibly several, </em><br /> <em class="quotelev3">>>> <placeName> elements, followed by one or more <location> elements to </em><br /> <em class="quotelev3">>>> provide </em><br /> <em class="quotelev3">>>> geographical and/or geo-political information about the location of the </em><br /> <em class="quotelev3">>>> place. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Why would you need more than one <location>? I had the impression </em><br /> <em class="quotelev2">>> that the place is what stays constant? Is it because it also stands in </em><br /> <em class="quotelev2">>> for the geopolitical information? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Because a place might be located in more than one way (e.g. by its </em><br /> <em class="quotelev1">> geopolitical status, or by its co-ordinates), and may also move its </em><br /> <em class="quotelev1">> location over time. </em><br /> <em class="quotelev2">>> However, if we talk about administrative geography here, you will also </em><br /> <em class="quotelev2">>> have to account for changes in the size and super/sub components of a </em><br /> <em class="quotelev2">>> place and a way to link this to coordinates defining the polygon. </em><br /> <em class="quotelev2">>> Would the tagset be up to this task? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> probably... because we embed GML! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 07:00:30 EDT</span> </div> From daniel.odonnell at uleth.ca Thu Apr 12 10:36:40 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 08:36:40 -0600 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E07BB.7060804@computing-services.oxford.ac.uk> Message-ID: <1176388600.25445.2.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 08:36:40 -0600</span><br /> </address> On Thu, 2007-12-04 at 11:19 +0100, James Cummings wrote: <br /> <em class="quotelev1">> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">> > I know we have a work task on this, but that </em><br /> <em class="quotelev2">> > may not address a fundamental issue I have. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Probably not, so we'd appreciate hearing of any other issues you have. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > When reading one of my allocated chapters, </em><br /> <em class="quotelev2">> > I was struck by the inclusion of schema fragments </em><br /> <em class="quotelev2">> > in the section with the formal definition </em><br /> <em class="quotelev2">> > of elements. What is the point of them, I wondered? </em><br /> <em class="quotelev2">> > The technical details are available in the </em><br /> <em class="quotelev2">> > alphabetical list of elements etc (the "second </em><br /> <em class="quotelev2">> > volume", if you like), for those who can read </em><br /> <em class="quotelev2">> > this stuff, so why repeat it here? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I assume so that readers don't have to go elsewhere to find out the </em><br /> <em class="quotelev1">> nitty-gritty of the elements they have been reading about. Might it be </em><br /> <em class="quotelev1">> better to move these all to the end of the chapter? i.e. each chapter has </em><br /> <em class="quotelev1">> section at the end for all the formal declarations? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > More importantly, </em><br /> <em class="quotelev2">> > the code shown is simply one interpretation </em><br /> <em class="quotelev2">> > of the ODD (ie it divides each element into </em><br /> <em class="quotelev2">> > two patterns, foo.content and foo.attributes), </em><br /> <em class="quotelev2">> > which is not normative. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Has this bothered anyone else? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> No, I hadn't even considered it. (tbh) However, I do see that it is a bit </em><br /> <em class="quotelev1">> strange that we are saying ODD is the way and then showing one particular </em><br /> <em class="quotelev1">> interpretation of that ODD as Relax NG Compact Syntax throughout the </em><br /> <em class="quotelev1">> guidelines. </em><br /> I agree. Good catch, Sebastian--although you don't seem to do any other <br /> kind! <br /> <p><em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 10:33:06 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 10:37:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 15:37:42 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <1176388600.25445.2.camel@odonned-eng06> Message-ID: <461E4436.8040001@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 15:37:42 +0100</span><br /> </address> Dan O'Donnell wrote: <br /> I do see that it is a bit <br /> <em class="quotelev2">>> strange that we are saying ODD is the way and then showing one particular </em><br /> <em class="quotelev2">>> interpretation of that ODD as Relax NG Compact Syntax throughout the </em><br /> <em class="quotelev2">>> guidelines. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I agree. Good catch, Sebastian--although you don't seem to do any other </em><br /> <em class="quotelev1">> kind! </em><br /> <em class="quotelev1">> </em><br /> Coincidentamentally, only yesterday I was asked by the person currently <br /> rewriting the FSD spec for ISO why we used this funny syntax (he meant <br /> RelaxNC) to express constraints on the element structures. I told him <br /> that we had to use some formal language or other, and that the compact <br /> syntax was felt to be simpler to take in than the comparatively verbose <br /> relaxng syntax used in the ODDs. <br /> While I take the point, I don't see any sensible alternative. BNF anyone? <br /> <p><p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 10:39:48 EDT</span> </div> From laurent.romary at loria.fr Thu Apr 12 10:47:21 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 12 Apr 2007 16:47:21 +0200 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E4436.8040001@oucs.ox.ac.uk> Message-ID: <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 16:47:21 +0200</span><br /> </address> BNF: Yearrrk. <br /> I must admit I do read RelaxNG fragment to check the content models <br /> and their presence inliine within chapters is quite a nice feature <br /> for me. I have more problems with the fact that for each class <br /> description, we get the various variants of linearisation (ordered, <br /> unordered, optional, etc.). Could we get rid of that? <br /> Laurent <br /> Le 12 avr. 07 ? 16:37, Lou Burnard a ?crit : <br /> <em class="quotelev1">> Dan O'Donnell wrote: </em><br /> <em class="quotelev1">> I do see that it is a bit </em><br /> <em class="quotelev3">>>> strange that we are saying ODD is the way and then showing one </em><br /> <em class="quotelev3">>>> particular </em><br /> <em class="quotelev3">>>> interpretation of that ODD as Relax NG Compact Syntax throughout the </em><br /> <em class="quotelev3">>>> guidelines. </em><br /> <em class="quotelev2">>> I agree. Good catch, Sebastian--although you don't seem to do any </em><br /> <em class="quotelev2">>> other </em><br /> <em class="quotelev2">>> kind! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Coincidentamentally, only yesterday I was asked by the person </em><br /> <em class="quotelev1">> currently rewriting the FSD spec for ISO why we used this funny </em><br /> <em class="quotelev1">> syntax (he meant RelaxNC) to express constraints on the element </em><br /> <em class="quotelev1">> structures. I told him that we had to use some formal language or </em><br /> <em class="quotelev1">> other, and that the compact syntax was felt to be simpler to take </em><br /> <em class="quotelev1">> in than the comparatively verbose relaxng syntax used in the ODDs. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> While I take the point, I don't see any sensible alternative. BNF </em><br /> <em class="quotelev1">> anyone? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 10:48:49 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 11:02:16 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 16:02:16 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> Message-ID: <461E49F8.60001@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 16:02:16 +0100</span><br /> </address> Laurent Romary wrote: <br /> <em class="quotelev1">> BNF: Yearrrk. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I must admit I do read RelaxNG fragment to check the content models and </em><br /> <em class="quotelev1">> their presence inliine within chapters is quite a nice feature for me. I </em><br /> <em class="quotelev1">> have more problems with the fact that for each class description, we get </em><br /> <em class="quotelev1">> the various variants of linearisation (ordered, unordered, optional, </em><br /> <em class="quotelev1">> etc.). Could we get rid of that? </em><br /> <em class="quotelev1">> </em><br /> Since we're in the process of re-examining how the guidelines should be <br /> displayed, there is of course another possibility. That is, this <br /> information could be hidden from view until some expansion text is click by <br /> the user. (c.f. recent TEI-L discussion on inline display of marginal <br /> annotations) This would allow the majority of users just to ignore their <br /> existence, and the interested few to expand the CSS-hidden specifications <br /> when they desire. <br /> How much are we wedded to the notion of avoiding use of javascript and similar? <br /> Although I was going to wait until after Dot and I had our brainstorming <br /> meeting, if anyone has any other suggestions for how the display of the <br /> guidelines can be improved do let us know (preferably on-list to encourage <br /> debate). <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:02:20 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 11:10:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 16:10:41 +0100 Subject: [tei-council] class struggle continues Message-ID: <461E4BF1.4040909@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 16:10:41 +0100</span><br /> </address> I've just fallen over what looks to be a mistake in the way a couple of <br /> classes are defined. The two are: <br /> att.personal "common attributes for those elements which form part of a <br /> personal name" which gives you @type @full and @sort <br /> att.naming "provides attributes common to elements which refer to <br /> named persons, places, organizations etc." which just gives you @key <br /> (and will also shortly give you @nymKey) <br /> Members of att.personal: addName forename genName nameLink roleName <br /> surname <br /> Members of att.naming: affiliation birth bloc collection country <br /> death district education geog geogName institution name <br /> nationality occupation persEvent persName persState persTrait <br /> placeName pubPlace region relation repository residence rs <br /> settlement socecStatus <br /> Seems to me that <br /> * persName ought to be a member of att.personal (definitely) <br /> * @full and @sort ought to be separated from @type (maybe) <br /> * att.naming is a silly name if all it does is give you @key, especially <br /> as some of its members are not by any stretch of the imagination names <br /> at all <br /> * att.personal ought to be a member of att.naming (definitely) <br /> I propose to make the changes marked "(definitely)" above since without <br /> them I won't be able to validate the new version of ND I have promised <br /> Arianna for tomorrow... <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:12:46 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 11:37:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 16:37:33 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E4436.8040001@oucs.ox.ac.uk> Message-ID: <461E523D.8090701@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 16:37:33 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> While I take the point, I don't see any sensible alternative. BNF anyone? </em><br /> look at <br /> http://www.w3.org/TR/its/#translatability-markup <br /> and you'll see that generating a sort of BNF from <br /> ODD is not that hard. I did a variant <br /> stylesheet for W3C purposes. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:37:35 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 11:37:49 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 11:37:49 -0400 Subject: [tei-council] class struggle continues In-Reply-To: <461E4BF1.4040909@oucs.ox.ac.uk> Message-ID: <17950.21069.979640.94940@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 11:37:49 -0400</span><br /> </address> <em class="quotelev1">> * persName ought to be a member of att.personal (definitely) </em><br /> I agree, definitely. <br /> <p><em class="quotelev1">> * @full and @sort ought to be separated from @type (maybe) </em><br /> My instinct (w/o actually looking at 'em) is that either type= should <br /> be dropped from att.personal (and members of it likely should be <br /> members of att.typed, too), or att.personal should itself be a member <br /> of att.typed. <br /> <p><em class="quotelev1">> * att.naming is a silly name if all it does is give you @key, </em><br /> <em class="quotelev1">> especially as some of its members are not by any stretch of the </em><br /> <em class="quotelev1">> imagination names at all </em><br /> Agreed. IIRC it is a legacy name. <br /> <p><em class="quotelev1">> * att.personal ought to be a member of att.naming (definitely) </em><br /> I'm less convinced. You don't think it is useful to have an element <br /> that has key= but not full= & sort=? I'm not sure, to be honest. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:37:52 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 11:39:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 16:39:46 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <461E52C2.9020003@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 16:39:46 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Since we're in the process of re-examining how the guidelines should be </em><br /> <em class="quotelev1">> displayed, there is of course another possibility. That is, this </em><br /> <em class="quotelev1">> information could be hidden from view until some expansion text is click by </em><br /> <em class="quotelev1">> the user. </em><br /> I came at this while reading paper on holiday; <br /> maybe the PDF should diverge more radically <br /> from the HTML <br /> <em class="quotelev1">> How much are we wedded to the notion of avoiding use of javascript and similar? </em><br /> <em class="quotelev1">> </em><br /> not at all in this case; ie if they disable JS, they see everything, <br /> which is a good fallback. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:39:49 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 11:48:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 11:48:04 -0400 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <17950.21684.810181.28894@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 11:48:04 -0400</span><br /> </address> Without paying strict attention to the thread so far <br /> * The current formatting in the HTML is of almost no use to most <br /> users. <br /> * This is not a technical issue which needs to be dealt with before <br /> Berlin, and so I don't think we should spend time & effort on it <br /> now. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 11:48:08 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 12:01:18 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 17:01:18 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E4BF1.4040909@oucs.ox.ac.uk> Message-ID: <461E57CE.4050508@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 17:01:18 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> I've just fallen over what looks to be a mistake in the way a couple of </em><br /> <em class="quotelev1">> classes are defined. The two are: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> att.personal "common attributes for those elements which form part of a </em><br /> <em class="quotelev1">> personal name" which gives you @type @full and @sort </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> att.naming "provides attributes common to elements which refer to </em><br /> <em class="quotelev1">> named persons, places, organizations etc." which just gives you @key </em><br /> <em class="quotelev1">> (and will also shortly give you @nymKey) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Members of att.personal: addName forename genName nameLink roleName </em><br /> <em class="quotelev1">> surname </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Members of att.naming: affiliation birth bloc collection country </em><br /> <em class="quotelev1">> death district education geog geogName institution name </em><br /> <em class="quotelev1">> nationality occupation persEvent persName persState persTrait </em><br /> <em class="quotelev1">> placeName pubPlace region relation repository residence rs </em><br /> <em class="quotelev1">> settlement socecStatus </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Seems to me that </em><br /> <em class="quotelev1">> * persName ought to be a member of att.personal (definitely) </em><br /> agreed <br /> <em class="quotelev1">> * @full and @sort ought to be separated from @type (maybe) </em><br /> Is there anything special about @type here compared to that provided by <br /> att.typed? Or maybe I should be asking, what is the difference? <br /> <em class="quotelev1">> * att.naming is a silly name if all it does is give you @key, especially </em><br /> <em class="quotelev1">> as some of its members are not by any stretch of the imagination names </em><br /> <em class="quotelev1">> at all </em><br /> If we rename it, is it really the right place for @nymKey? I have no <br /> suggestions for better names, but agree that one isn't really right. <br /> <em class="quotelev1">> * att.personal ought to be a member of att.naming (definitely) </em><br /> agreed. <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:01:22 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu Apr 12 12:07:24 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 12 Apr 2007 17:07:24 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <461E593C.30601@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 17:07:24 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Laurent Romary wrote: </em><br /> <em class="quotelev2">>> BNF: Yearrrk. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I must admit I do read RelaxNG fragment to check the content models and </em><br /> <em class="quotelev2">>> their presence inliine within chapters is quite a nice feature for me. I </em><br /> <em class="quotelev2">>> have more problems with the fact that for each class description, we get </em><br /> <em class="quotelev2">>> the various variants of linearisation (ordered, unordered, optional, </em><br /> <em class="quotelev2">>> etc.). Could we get rid of that? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Since we're in the process of re-examining how the guidelines should be </em><br /> <em class="quotelev1">> displayed, there is of course another possibility. That is, this </em><br /> <em class="quotelev1">> information could be hidden from view until some expansion text is click by </em><br /> <em class="quotelev1">> the user. (c.f. recent TEI-L discussion on inline display of marginal </em><br /> <em class="quotelev1">> annotations) This would allow the majority of users just to ignore their </em><br /> <em class="quotelev1">> existence, and the interested few to expand the CSS-hidden specifications </em><br /> <em class="quotelev1">> when they desire. </em><br /> This is exactly what I was going to suggest. Indeed, as Laurent, I find <br /> these formal descriptions useful myself. If people perceive this as too <br /> obtrusive we could have an expandable section, whatever the preferred <br /> format of the formal description is going to be. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> How much are we wedded to the notion of avoiding use of javascript and similar? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Although I was going to wait until after Dot and I had our brainstorming </em><br /> <em class="quotelev1">> meeting, if anyone has any other suggestions for how the display of the </em><br /> <em class="quotelev1">> guidelines can be improved do let us know (preferably on-list to encourage </em><br /> <em class="quotelev1">> debate). </em><br /> I have addedd some chapter-specific suggestions in Trac under my tickets <br /> with the title "Output issues". <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:07:39 EDT</span> </div> From daniel.odonnell at uleth.ca Thu Apr 12 12:26:36 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 10:26:36 -0600 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E52C2.9020003@oucs.ox.ac.uk> Message-ID: <1176395196.25445.23.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 10:26:36 -0600</span><br /> </address> I'm pretty sure you can handle that with pure CSS as well, btw. Don't <br /> know how myself, but I could swear I read that somewhere. <br /> On Thu, 2007-12-04 at 16:39 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Since we're in the process of re-examining how the guidelines should be </em><br /> <em class="quotelev2">> > displayed, there is of course another possibility. That is, this </em><br /> <em class="quotelev2">> > information could be hidden from view until some expansion text is click by </em><br /> <em class="quotelev2">> > the user. </em><br /> <em class="quotelev1">> I came at this while reading paper on holiday; </em><br /> <em class="quotelev1">> maybe the PDF should diverge more radically </em><br /> <em class="quotelev1">> from the HTML </em><br /> <em class="quotelev2">> > How much are we wedded to the notion of avoiding use of javascript and similar? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> not at all in this case; ie if they disable JS, they see everything, </em><br /> <em class="quotelev1">> which is a good fallback. </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:23:01 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 12:26:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 17:26:01 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <17950.21684.810181.28894@emt.wwp.brown.edu> Message-ID: <461E5D99.5000105@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 17:26:01 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> * The current formatting in the HTML is of almost no use to most </em><br /> <em class="quotelev1">> users. </em><br /> <em class="quotelev1">> </em><br /> I hope you mean just the schema frags... <br /> <em class="quotelev1">> * This is not a technical issue which needs to be dealt with before </em><br /> <em class="quotelev1">> Berlin, and so I don't think we should spend time & effort on it </em><br /> <em class="quotelev1">> now. </em><br /> <em class="quotelev1">> </em><br /> I don't disagree. its light relief for anyone who has finished <br /> their chapters :-} <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:26:04 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 12:42:09 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 17:42:09 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E57CE.4050508@computing-services.oxford.ac.uk> Message-ID: <461E6161.5060001@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 17:42:09 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Seems to me that </em><br /> <em class="quotelev2">>> * persName ought to be a member of att.personal (definitely) </em><br /> <em class="quotelev1">> agreed </em><br /> Unfortunately, this causes everything to break, since persName <br /> explicitly defines its own @type <br /> <p><em class="quotelev2">>> * @full and @sort ought to be separated from @type (maybe) </em><br /> <em class="quotelev1">> Is there anything special about @type here compared to that provided by </em><br /> <em class="quotelev1">> att.typed? Or maybe I should be asking, what is the difference? </em><br /> <em class="quotelev1">> </em><br /> Sometimes (about 40%) when an element has a @type, it has inherited it <br /> from att.typed. Other times it defines it for itself. Usually this is <br /> because the locally-defined variant has a helpful valList associated <br /> with it. We looked at this problem, gingerly, at the class meeting in <br /> Oxford and then ran away from it. att.typed also gives you @subtype <br /> which you may not want, but that seems to be less of an issue to me. <br /> <p><em class="quotelev2">>> * att.naming is a silly name if all it does is give you @key, especially </em><br /> <em class="quotelev2">>> as some of its members are not by any stretch of the imagination names </em><br /> <em class="quotelev2">>> at all </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If we rename it, is it really the right place for @nymKey? I have no </em><br /> <em class="quotelev1">> suggestions for better names, but agree that one isn't really right. </em><br /> <em class="quotelev1">> </em><br /> I think it definitely is the right place for @nymKey.<!--nospam--> One gives you a <br /> pointer to the thing being named, the other gives you a pointer to the <br /> canonical name used for the naming. <br /> <em class="quotelev2">>> * att.personal ought to be a member of att.naming (definitely) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> agreed. </em><br /> <em class="quotelev1">> </em><br /> but vide supra... <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:44:15 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 12:59:00 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 12:59:00 -0400 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E5D99.5000105@oucs.ox.ac.uk> Message-ID: <17950.25940.251219.26596@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 12:59:00 -0400</span><br /> </address> <em class="quotelev2">> > * The current formatting in the HTML is of almost no use to most </em><br /> <em class="quotelev2">> > users. </em><br /> <em class="quotelev1">> I hope you mean just the schema frags... </em><br /> Yes, that is what I meant. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 12:59:03 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 13:00:10 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 18:00:10 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E6161.5060001@oucs.ox.ac.uk> Message-ID: <461E659A.3020604@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 18:00:10 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> Seems to me that </em><br /> <em class="quotelev3">>>> * persName ought to be a member of att.personal (definitely) </em><br /> <em class="quotelev2">>> agreed </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Unfortunately, this causes everything to break, since persName </em><br /> <em class="quotelev1">> explicitly defines its own @type </em><br /> And I assume, as below, that is because it has a useful valList? Oh wait, <br /> when I look it up it allows anything that is data.enumerated. Maybe this <br /> should change? So I guess the problem is also partly that you want to have <br /> descriptive prose that is different for this @type compared to the one that <br /> is in att.typed? <br /> <p><em class="quotelev3">>>> * @full and @sort ought to be separated from @type (maybe) </em><br /> <em class="quotelev1">> Sometimes (about 40%) when an element has a @type, it has inherited it </em><br /> <em class="quotelev1">> from att.typed. Other times it defines it for itself. Usually this is </em><br /> <em class="quotelev1">> because the locally-defined variant has a helpful valList associated </em><br /> <em class="quotelev1">> with it. We looked at this problem, gingerly, at the class meeting in </em><br /> <em class="quotelev1">> Oxford and then ran away from it. att.typed also gives you @subtype </em><br /> <em class="quotelev1">> which you may not want, but that seems to be less of an issue to me. </em><br /> Yes, I remember that. I have little problem with subtype being there <br /> whenever type is, even if minorly inappropriate in some instances. <br /> <em class="quotelev1">> I think it definitely is the right place for @nymKey.<!--nospam--> One gives you a </em><br /> <em class="quotelev1">> pointer to the thing being named, the other gives you a pointer to the </em><br /> <em class="quotelev1">> canonical name used for the naming. </em><br /> Fair enough, thanks for the explanation, then I say rename it... but to what? <br /> <em class="quotelev3">>>> * att.personal ought to be a member of att.naming (definitely) </em><br /> <em class="quotelev2">>> agreed. </em><br /> <em class="quotelev1">> but vide supra... </em><br /> What is best to do about that? These darn type attributes. <br /> -James <br /> <p><p> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 13:00:15 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 13:07:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 18:07:56 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E659A.3020604@computing-services.oxford.ac.uk> Message-ID: <461E676C.3050609@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 18:07:56 +0100</span><br /> </address> James Cummings wrote: <br /> ? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev4">>>>> * att.personal ought to be a member of att.naming (definitely) </em><br /> <em class="quotelev3">>>> agreed. </em><br /> <em class="quotelev2">>> but vide supra... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> What is best to do about that? These darn type attributes. </em><br /> <em class="quotelev1">> </em><br /> (a) removed @type from att.<!--nospam-->personal <br /> (b) make all current members of att.personal also members of att.typed <br /> That's what I've done, anyway. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 13:10:03 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 13:17:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 13:17:46 -0400 Subject: [tei-council] development version of Guidelines In-Reply-To: <4616C5BE.3010803@computing-services.oxford.ac.uk> Message-ID: <17950.27066.429563.334026@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 13:17:46 -0400</span><br /> </address> LB> Don't expect any of the links in it to work as I haven't put any <br /> LB> of the other chapters there! <br /> I don't know, but if I had to hazard a guess, I'd bet Lou didn't put <br /> the other chapters, etc., there because doing so with Perforce would <br /> be a pain. (Probably not all that bad, but once you've used <br /> Subversion ... :-) <br /> <p>I often like to have a current version of the development version of <br /> the Guidelines available in HTML. Usually it's sitting on my local <br /> hard drive, but on occasion it's useful to have on the web. As we run <br /> up to Berlin I'm betting some Council members would find this <br /> helpful, too. Current version (as of this morning, my time) is at <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html <br /> Note that what makes this easy for me also makes it comparatively <br /> unreliable: that server is in my basement, and will blink out if the <br /> power goes out at my house (several times a year), my cable company <br /> suffers a snag (several times a year), or my son decides to see what <br /> that glowing button on the front does (hasn't since he was 4, but who <br /> knows.) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 13:17:53 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 14:22:08 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 14:22:08 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> Message-ID: <17950.30928.5625.745800@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 14:22:08 -0400</span><br /> </address> <em class="quotelev1">> OK, it's time to get radical. What do we need "TEI Interchange </em><br /> <em class="quotelev1">> format" for? Why do we need to define it at all? </em><br /> So that we can move all these draconian restrictions out of the <br /> definition of "conformance", but still put them somewhere useful. <br /> Remember that this marvelous capability to differentiate those XML <br /> structures that come from the TEI namespace from those that do not is <br /> only helpful if you both have software that can process the generic <br /> TEI structures and find it useful. That is, a lot of TEI users will <br /> have to go through a lot of hoops to generate documents that fit the <br /> current namespace-concerned definition of conformance, with no <br /> benefit to themselves at all. <br /> On the other hand, when they want to exchange that document with <br /> someone else (say, an archive), following the more draconian rules is <br /> likely to be quite helpful. <br /> <p>Some further thoughts. If we insist that TEI conformant documents <br /> follow draconian namespace rules, there are some pretty predictable <br /> potentially problematic probable consequences: <br /> * Most projects will not use TEI for document capture -- dealing with <br /> those namespaces will just be too annoying. E.g., imagine the <br /> project that expected to capture TEI P5 texts using a customization <br /> that replaced <choice> with the old Janus attributes (because they <br /> know they are dealing with only 1 language and have no characters <br /> out of Unicode), and want to change xml:id= to id= and target= to <br /> an IDREF attribute for capture so that their XML editor will do the <br /> right thing. <br /> * Many projects will not even bother to store their texts locally in <br /> TEI, and will either abandon TEI conformance completely, or only <br /> trot out the namesaced-conformant version for funding agencies and <br /> blind interchange. <br /> * We will never have a conformant <soCalled>TEI Tite</soCalled> for <br /> vendor use. I don't see this as a major problem, personally, as the <br /> goal has always been to use Tite as a capture format, and transform <br /> into more canonical TEI later. <br /> <p>I really think that this is an issue about which users should be <br /> canvassed before we commit to constraining conformance, as opposed to <br /> interchange format. <br /> <p>BTW, if we are going to go this route of force-feeding namespaces <br /> which impart no direct benefit on users, we had better make it as <br /> easy as possible. That is, roma and webRoma should do the right thing <br /> w/o significant extra work. This may not be easy. For example, roma <br /> will need to know that changing an attribute from data.numeric to <br /> data.count is a clean change, but from data.name to data.word is not. <br /> (There are things we may not be able to expect roma to do, of course, <br /> like read users' regular expressions and figure out if it represents <br /> a clean subset of a datatype or not.) <br /> <p>I just asked a colleague what he thought of all this. He suggested a <br /> different likely pattern of behavior for users. He suggested that <br /> many users would tolerate the namespace business, but would not make <br /> the effort to, or not be able to, figure out which customizations are <br /> clean subsets and which are not, and thus would stick all <br /> customizations into their own namespace. He left me with a very <br /> insightful parting thought: "Boy, I hope the Council doesn't make TEI <br /> into W3C Schema". <br /> <p>P.S. As it applies to interchange format, as opposed to conformance, <br /> I think I agree with the direction this thread is headed, <br /> including that translated or renamed elements should be in <br /> another namespace. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 14:22:11 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 14:48:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 19:48:56 +0100 Subject: [tei-council] New version of ND checked in Message-ID: <461E7F18.8030502@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 19:48:56 +0100</span><br /> </address> There having been no comment on the nym proposals since I announced them <br /> here over a month ago, I have now integrated them into a new version of <br /> chapter ND. I took the opportunity also of correcting a few anomalies in <br /> the class system, as discussed on this list earlier today. <br /> I haven't, however, done anything yet with the proposed changes to <br /> introduce <place> and <listPlace>. I think this needs more discussion. <br /> The new version and associated changes are, as ever, checked into the <br /> trunk of the svn <br /> repository, rather than the council branch. If no one is currently <br /> working on files in the latter, maybe someone ought to bring it up to <br /> date with the trunk, since there have been quite a few minor and not so <br /> minor tweaks since it was forked. <br /> I will put an updated HTML version of the new chapter into the Drafts <br /> web page later this evening. Dinner first. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 14:48:59 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 15:49:37 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 15:49:37 -0400 Subject: [tei-council] New version of ND checked in In-Reply-To: <461E7F18.8030502@computing-services.oxford.ac.uk> Message-ID: <17950.36177.285828.727857@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 15:49:37 -0400</span><br /> </address> <em class="quotelev1">> I will put an updated HTML version of the new chapter into the </em><br /> <em class="quotelev1">> Drafts web page later this evening. Dinner first. </em><br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html <br /> updated completely. (I never update this site file-by-file, I just <br /> plop a newly generated complete copy in there, so to read Lou's <br /> latest and greatest, you can go to <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html.) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 15:49:45 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 16:24:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 21:24:41 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.30928.5625.745800@emt.wwp.brown.edu> Message-ID: <461E9589.3080100@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 21:24:41 +0100</span><br /> </address> I think this is a matter of roses smelling as sweet <br /> by any other name. If all the draconian prose <br /> moves to "interchange", fine; but in that case, <br /> just quietly lose the "conformance" chapter entirely. <br /> Let's not have *two* distinct barriers, or one so low ("if you <br /> want to be TEI conformant, BE GOOD") that it <br /> doesn't merit more than a paragraph of text. <br /> As far as I am concerned, you can either be inspired <br /> by the TEI, or conform to the TEI. Call that "interchangeable with <br /> the TEI" if preferred. <br /> <em class="quotelev1">> Some further thoughts. If we insist that TEI conformant documents </em><br /> <em class="quotelev1">> follow draconian namespace rules, there are some pretty predictable </em><br /> <em class="quotelev1">> potentially problematic probable consequences </em><br /> <em class="quotelev1">> </em><br /> your nightmare scenarios are possible, I agree, but <br /> not inevitable. Let's stop trying to second guess <br /> what people will say, but publish a conformance <br /> draft quickly and let them comment. <br /> <em class="quotelev1">> * Most projects will not use TEI for document capture -- dealing with </em><br /> <em class="quotelev1">> those namespaces will just be too annoying. E.g., imagine the </em><br /> <em class="quotelev1">> project that expected to capture TEI P5 texts using a customization </em><br /> <em class="quotelev1">> that replaced <choice> with the old Janus attributes (because they </em><br /> <em class="quotelev1">> know they are dealing with only 1 language and have no characters </em><br /> <em class="quotelev1">> out of Unicode), and want to change xml:id= to id= and target= to </em><br /> <em class="quotelev1">> an IDREF attribute for capture so that their XML editor will do the </em><br /> <em class="quotelev1">> right thing. </em><br /> <em class="quotelev1">> </em><br /> sounds like they won't be conformant, poor people. <br /> <em class="quotelev1">> * Many projects will not even bother to store their texts locally in </em><br /> <em class="quotelev1">> TEI, and will either abandon TEI conformance completely, or only </em><br /> <em class="quotelev1">> trot out the namesaced-conformant version for funding agencies and </em><br /> <em class="quotelev1">> blind interchange </em><br /> <em class="quotelev1">> </em><br /> if they have a route to get conformant texts for when <br /> it comes out of their vaults, sounds great. just <br /> what the doctor ordered <br /> <em class="quotelev1">> * We will never have a conformant <soCalled>TEI Tite</soCalled> for </em><br /> <em class="quotelev1">> vendor use. </em><br /> why not? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I really think that this is an issue about which users should be </em><br /> <em class="quotelev1">> canvassed before we commit to constraining conformance, as opposed to </em><br /> <em class="quotelev1">> interchange format. </em><br /> <em class="quotelev1">> </em><br /> agreed. if we can get the users to speak, rather <br /> have just expose ourselves to another public <br /> shouting match between Wendell and me.... <br /> <em class="quotelev1">> This may not be easy. For example, roma </em><br /> <em class="quotelev1">> will need to know that changing an attribute from data.numeric to </em><br /> <em class="quotelev1">> data.count is a clean change, but from data.name to data.word is not. </em><br /> <em class="quotelev1">> (There are things we may not be able to expect roma to do, of course, </em><br /> <em class="quotelev1">> like read users' regular expressions and figure out if it represents </em><br /> <em class="quotelev1">> a clean subset of a datatype or not.) </em><br /> <em class="quotelev1">> </em><br /> you could implement some of this with a free-standing <br /> TEI conformance checked for an ODD? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I just asked a colleague what he thought of all this. He suggested a </em><br /> <em class="quotelev1">> different likely pattern of behavior for users. He suggested that </em><br /> <em class="quotelev1">> many users would tolerate the namespace business, but would not make </em><br /> <em class="quotelev1">> the effort to, or not be able to, figure out which customizations are </em><br /> <em class="quotelev1">> clean subsets and which are not, and thus would stick all </em><br /> <em class="quotelev1">> customizations into their own namespace. </em><br /> you'll have to expand that for me. can you give an example <br /> of what you think he meant? <br /> <em class="quotelev1">> He left me with a very </em><br /> <em class="quotelev1">> insightful parting thought: "Boy, I hope the Council doesn't make TEI </em><br /> <em class="quotelev1">> into W3C Schema". </em><br /> <em class="quotelev1">> </em><br /> you'll have to gloss that a little further, too. did he mean <br /> "make the TEI as Byzantine as Schema", or "make the TEI <br /> use Schema"? if the former, its far too late, it already is :-} <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> P.S. As it applies to interchange format, as opposed to conformance, </em><br /> <em class="quotelev1">> I think I agree with the direction this thread is headed, </em><br /> <em class="quotelev1">> including that translated or renamed elements should be in </em><br /> <em class="quotelev1">> another namespace. </em><br /> <em class="quotelev1">> </em><br /> I thought the opposite was agreed? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 16:24:46 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 16:38:25 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 21:38:25 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E9589.3080100@oucs.ox.ac.uk> Message-ID: <461E98C1.7020809@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 21:38:25 +0100</span><br /> </address> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> P.S. As it applies to interchange format, as opposed to conformance, </em><br /> <em class="quotelev2">>> I think I agree with the direction this thread is headed, </em><br /> <em class="quotelev2">>> including that translated or renamed elements should be in </em><br /> <em class="quotelev2">>> another namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> I thought the opposite was agreed? </em><br /> <em class="quotelev1">> </em><br /> Just for the avoidance of doubt, my belief is that we agreed that <br /> - the TEI systematic translations should be in a different TEI namespace <br /> - user-defined renaming should be in a user-defined namespace <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 16:38:28 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 16:48:07 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 21:48:07 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E98C1.7020809@computing-services.oxford.ac.uk> Message-ID: <461E9B07.8090208@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 21:48:07 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> Just for the avoidance of doubt, my belief is that we agreed that </em><br /> <em class="quotelev1">> - the TEI systematic translations should be in a different TEI namespace </em><br /> <em class="quotelev1">> - user-defined renaming should be in a user-defined namespace </em><br /> <em class="quotelev1">> </em><br /> oh, I haven't paid attention, then. You want <br /> syntactic sugar renaming in a new namespace? <br /> Yikes. I don't know how on earth I am going to <br /> program that in Roma-land. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 16:48:18 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 18:28:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 18:28:10 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E9589.3080100@oucs.ox.ac.uk> Message-ID: <17950.45690.802744.758277@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 18:28:10 -0400</span><br /> </address> <em class="quotelev1">> I think this is a matter of roses smelling as sweet by any other </em><br /> <em class="quotelev1">> name. If all the draconian prose moves to "interchange", fine; but </em><br /> <em class="quotelev1">> in that case, just quietly lose the "conformance" chapter entirely. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Let's not have *two* distinct barriers, or one so low ("if you want </em><br /> <em class="quotelev1">> to be TEI conformant, BE GOOD") that it doesn't merit more than a </em><br /> <em class="quotelev1">> paragraph of text. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As far as I am concerned, you can either be inspired by the TEI, or </em><br /> <em class="quotelev1">> conform to the TEI. Call that "interchangeable with the TEI" if </em><br /> <em class="quotelev1">> preferred. </em><br /> Your logic completely escapes me. What's wrong with two different <br /> barriers? After all, we are talking about two completely different <br /> use cases. The first, well thought out, documented, and dealt with by <br /> the creators of P3, is the barrier for document creation, processing, <br /> and to a lesser extent, interchange. This is the barrier called <br /> "conformance", which I would like to see set reasonably low. The <br /> other is the barrier for interoperability, a goal that has never <br /> really been discussed in previous versions of the Guidelines, and <br /> which requires a much higher barrier. <br /> <p>Remember that with P3/P4 we set the barrier to conformant <br /> customization too high, and the result was that most projects used <br /> TEI Lite, and many hacked it directly. (Mind you, I'm not saying we <br /> made a mistake in doing so -- given the technology of the day I'm not <br /> sure there was much other choice.) <br /> <p>The barrier to proper customization of P5, although a *lot* better <br /> than with P4 (thanks in large part to you, Sebastian), is still <br /> pretty high. <br /> <p><em class="quotelev2">> > E.g., imagine the project that expected to capture TEI P5 texts </em><br /> <em class="quotelev2">> > using a customization that replaced <choice> with the old Janus </em><br /> <em class="quotelev2">> > attributes (because they know they are dealing with only 1 </em><br /> <em class="quotelev2">> > language and have no characters out of Unicode), and want to </em><br /> <em class="quotelev2">> > change xml:id= to id= and target= to an IDREF attribute for </em><br /> <em class="quotelev2">> > capture so that their XML editor will do the right thing. </em><br /> <em class="quotelev1">> sounds like they won't be conformant, poor people. </em><br /> That's my point. This is the very kind of customization we have been <br /> telling people they could do, or might even be available directly <br /> from the TEI as an example ODD or some such, all along. People liked <br /> the idea. <br /> <p><em class="quotelev1">> if they have a route to get conformant texts for when it comes out </em><br /> <em class="quotelev1">> of their vaults, sounds great. just what the doctor ordered </em><br /> I disagree. I think there are advantages both for the TEI and for <br /> users to using the Guidelines for text encoding, not just for <br /> interchange with the hope of interoperability. For starters, such <br /> projects will have both less incentive to be TEI-C members, and less <br /> ammunition when they talk to their deans about becoming TEI-C members. <br /> ("OK, so you transform it to TEI to put it in an archive, so what? <br /> You transform it into HTML for web delivery, do you want us to become <br /> W3C members, too?") <br /> <p><em class="quotelev2">> > * We will never have a conformant <soCalled>TEI Tite</soCalled> for </em><br /> <em class="quotelev2">> > vendor use. </em><br /> <em class="quotelev1">> why not? </em><br /> The point of much of the syntactic sugar renaming in Tite is to <br /> reduce keystrokes. Requiring even a 1-character namespace prefix <br /> would negate any advantages. <br /> <p><em class="quotelev2">> > This may not be easy. For example, roma will need to know that </em><br /> <em class="quotelev2">> > changing an attribute from data.numeric to data.count is a clean </em><br /> <em class="quotelev2">> > change, but from data.name to data.word is not. (There are things </em><br /> <em class="quotelev2">> > we may not be able to expect roma to do, of course, like read </em><br /> <em class="quotelev2">> > users' regular expressions and figure out if it represents a </em><br /> <em class="quotelev2">> > clean subset of a datatype or not.) </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> you could implement some of this with a free-standing </em><br /> <em class="quotelev1">> TEI conformance checked for an ODD? </em><br /> Well, yes, but my point was <br /> a) it should be integrated into roma / webRoma; <br /> b) it isn't easy. <br /> <p><em class="quotelev1">> you'll have to expand that for me. can you give an example of what </em><br /> <em class="quotelev1">> you think he meant? </em><br /> Sure. The Imaginary Project creates a schema with half a dozen <br /> changes vs. vanilla TEI. Rather than expend the effort to figure out <br /> which things affected by the changes should be in tei: namespace and <br /> which should be in ip: namespace, they will just put every element <br /> and attribute affected by the change into the ip: namespace. <br /> <p><em class="quotelev2">> > He left me with a very insightful parting thought: "Boy, I hope </em><br /> <em class="quotelev2">> > the Council doesn't make TEI into W3C Schema". </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> you'll have to gloss that a little further, too. did he mean </em><br /> <em class="quotelev1">> "make the TEI as Byzantine as Schema", or "make the TEI </em><br /> <em class="quotelev1">> use Schema"? if the former, its far too late, it already is :-} </em><br /> He meant the former, and he obviously does not think it is far too <br /> late. Nor do I, for that matter. I doubt you really do, either, <br /> Sebastian, as you understand TEI, but IIRC still have trouble <br /> wrapping your mind around W3C Schema (although you certainly do <br /> better than I with it :-) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 18:28:14 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 18:45:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 23:45:48 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.45690.802744.758277@emt.wwp.brown.edu> Message-ID: <461EB69C.8050106@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 23:45:48 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> After all, we are talking about two completely different </em><br /> <em class="quotelev1">> use cases. The first, well thought out, documented, and dealt with by </em><br /> <em class="quotelev1">> the creators of P3, is the barrier for document creation, processing, </em><br /> <em class="quotelev1">> and to a lesser extent, interchange. This is the barrier called </em><br /> <em class="quotelev1">> "conformance", which I would like to see set reasonably low. </em><br /> we do have that fundamental difference in our views :-} <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Remember that with P3/P4 we set the barrier to conformant </em><br /> <em class="quotelev1">> customization too high, and the result was that most projects used </em><br /> <em class="quotelev1">> TEI Lite, and many hacked it directly. </em><br /> <em class="quotelev1">> </em><br /> that was a technology barrier, not a policy one, I suspect <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I disagree. I think there are advantages both for the TEI and for </em><br /> <em class="quotelev1">> users to using the Guidelines for text encoding, not just for </em><br /> <em class="quotelev1">> interchange with the hope of interoperability. For starters, such </em><br /> <em class="quotelev1">> projects will have both less incentive to be TEI-C members, and less </em><br /> <em class="quotelev1">> ammunition when they talk to their deans about becoming TEI-C members. </em><br /> <em class="quotelev1">> ("OK, so you transform it to TEI to put it in an archive, so what? </em><br /> <em class="quotelev1">> You transform it into HTML for web delivery, do you want us to become </em><br /> <em class="quotelev1">> W3C members, too?") </em><br /> <em class="quotelev1">> </em><br /> if they're interested in the TEI, they'll join, even though <br /> they abuse it in their dark inner sanctums. <br /> <em class="quotelev1">> The point of much of the syntactic sugar renaming in Tite is to </em><br /> <em class="quotelev1">> reduce keystrokes. Requiring even a 1-character namespace prefix </em><br /> <em class="quotelev1">> would negate any advantages. </em><br /> <em class="quotelev1">> </em><br /> yes, I had not grasped that these syntactic sugars <br /> would be in a different namespace until a few hours ago. <br /> I agree, I personally think that's simply unworkable. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Sure. The Imaginary Project creates a schema with half a dozen </em><br /> <em class="quotelev1">> changes vs. vanilla TEI. Rather than expend the effort to figure out </em><br /> <em class="quotelev1">> which things affected by the changes should be in tei: namespace and </em><br /> <em class="quotelev1">> which should be in ip: namespace, they will just put every element </em><br /> <em class="quotelev1">> and attribute affected by the change into the ip: namespace. </em><br /> <em class="quotelev1">> </em><br /> I think I get you. You mean that when they constrain <br /> the @type on <div>, they'll put <div> in the ip: space, <br /> because they think they have to? yes, that would be <br /> absurd. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> He meant the former, and he obviously does not think it is far too </em><br /> <em class="quotelev1">> late. Nor do I, for that matter. I doubt you really do, either, </em><br /> <em class="quotelev1">> Sebastian, as you understand TEI, but IIRC still have trouble </em><br /> <em class="quotelev1">> wrapping your mind around W3C Schema (although you certainly do </em><br /> <em class="quotelev1">> better than I with it :-) </em><br /> <em class="quotelev1">> </em><br /> after a few hours studying an XSD recently, I think <br /> I finally realized how the demented brains <br /> of the designers were working. I still don't <br /> fully understand the ODD processing model, <br /> and I am the one who has to document it :-{ <br /> anyway, forget this side meander. The issue is <br /> whether conformance and interchange <br /> are the same thing or not. I conflate them, <br /> you clearly separate them. <br /> we definitely agree that whatever happens, <br /> this is a case where the user community needs <br /> a thorough consultation. And the good news <br /> is that this does not stop us doing other <br /> work in the meanwhile - the definition of conformance <br /> can be revisited again and again (god help us) <br /> over the next 3 or 4 months if <br /> it really has to, I think. <br /> <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 18:45:53 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:20:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:20:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.45690.802744.758277@emt.wwp.brown.edu> Message-ID: <461EBEC5.6050106@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 00:20:37 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Your logic completely escapes me. What's wrong with two different </em><br /> <em class="quotelev1">> barriers? After all, we are talking about two completely different </em><br /> <em class="quotelev1">> use cases. The first, well thought out, documented, and dealt with by </em><br /> <em class="quotelev1">> the creators of P3, is the barrier for document creation, processing, </em><br /> <em class="quotelev1">> and to a lesser extent, interchange. This is the barrier called </em><br /> <em class="quotelev1">> "conformance", which I would like to see set reasonably low. The </em><br /> <em class="quotelev1">> other is the barrier for interoperability, a goal that has never </em><br /> <em class="quotelev1">> really been discussed in previous versions of the Guidelines, and </em><br /> <em class="quotelev1">> which requires a much higher barrier. </em><br /> <em class="quotelev1">> </em><br /> Where on earth did you get the idea that P3 doesn't talk about <br /> "interoperability"? <br /> There's a whole chapter on it! The point though is that everything in it <br /> is redundant in the world of XML. <br /> I also think that you're unlikely to persuade anyone to agree with you <br /> until you come up with some definition of what *you* think <br /> TEI-conformance means. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Remember that with P3/P4 we set the barrier to conformant </em><br /> <em class="quotelev1">> customization too high, and the result was that most projects used </em><br /> <em class="quotelev1">> TEI Lite, and many hacked it directly. </em><br /> What barrier did we set? you just said there was nothing about <br /> conformance in P3, and now you're saying that we made it too difficult? <br /> make your mind up! <br /> <em class="quotelev1">> I disagree. I think there are advantages both for the TEI and for </em><br /> <em class="quotelev1">> users to using the Guidelines for text encoding, not just for </em><br /> <em class="quotelev1">> interchange with the hope of interoperability. For starters, such </em><br /> <em class="quotelev1">> projects will have both less incentive to be TEI-C members, and less </em><br /> <em class="quotelev1">> ammunition when they talk to their deans about becoming TEI-C members. </em><br /> <em class="quotelev1">> ("OK, so you transform it to TEI to put it in an archive, so what? </em><br /> <em class="quotelev1">> You transform it into HTML for web delivery, do you want us to become </em><br /> <em class="quotelev1">> W3C members, too?") </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> Yes, I agree that being TEI conformant for purposes other than <br /> interchange is a desirable goal. But designing an encoding scheme that <br /> fits every possible project's needs is a quixotic goal we never set <br /> ourselves. So there has to be room for compromise -- which is why we <br /> distinguish conformance/interoperable format from local practice. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">>>> * We will never have a conformant <soCalled>TEI Tite</soCalled> for </em><br /> <em class="quotelev3">>>> vendor use. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> why not? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The point of much of the syntactic sugar renaming in Tite is to </em><br /> <em class="quotelev1">> reduce keystrokes. Requiring even a 1-character namespace prefix </em><br /> <em class="quotelev1">> would negate any advantages. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> I don't get this. If you want 1 character tag names, don't use the TEI. <br /> Write your own schema, define a mapping between it and the TEI. You have <br /> attained conformance without confusing the TEI namespace. Next. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Sure. The Imaginary Project creates a schema with half a dozen </em><br /> <em class="quotelev1">> changes vs. vanilla TEI. Rather than expend the effort to figure out </em><br /> <em class="quotelev1">> which things affected by the changes should be in tei: namespace and </em><br /> <em class="quotelev1">> which should be in ip: namespace, they will just put every element </em><br /> <em class="quotelev1">> and attribute affected by the change into the ip: namespace. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> There's no telling what foolishness some people will get up to. But I <br /> repeat -- what's your alternative proposal? If we are going to use <br /> namespaces at all, we must use them properly. No-one has yet proposed <br /> reversing the decision to define a TEI namespace. A namespace is, by <br /> definition, fixed, isn't it? <br /> <em class="quotelev3">>>> He left me with a very insightful parting thought: "Boy, I hop e </em><br /> <em class="quotelev3">>>> the Council doesn't make TEI into W3C Schema". </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> you'll have to gloss that a little further, too. did he mean </em><br /> <em class="quotelev2">>> "make the TEI as Byzantine as Schema", or "make the TEI </em><br /> <em class="quotelev2">>> use Schema"? if the former, its far too late, it already is :-} </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> He meant the former, and he obviously does not think it is far too </em><br /> <em class="quotelev1">> late. Nor do I, for that matter. I doubt you really do, either, </em><br /> <em class="quotelev1">> Sebastian, as you understand TEI, but IIRC still have trouble </em><br /> <em class="quotelev1">> wrapping your mind around W3C Schema (although you certainly do </em><br /> <em class="quotelev1">> better than I with it :-) </em><br /> <em class="quotelev1">> </em><br /> I don't see any sense in which we are making the TEI byzantine. We are <br /> making it a lot clearer what we mean and what the boundaries are. <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:20:40 EDT</span> </div> From daniel.odonnell at uleth.ca Thu Apr 12 19:34:34 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 17:34:34 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <1176420874.23247.2.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 17:34:34 -0600</span><br /> </address> On Thu, 2007-12-04 at 23:45 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> yes, I had not grasped that these syntactic sugars </em><br /> <em class="quotelev1">> would be in a different namespace until a few hours ago. </em><br /> <em class="quotelev1">> I agree, I personally think that's simply unworkable. </em><br /> This I agree with as well. Sugar is a way of simplifying things. I'm <br /> still in favour of "TEI namespace if your renaming doesn't conflict and <br /> can be undone cleanly" <br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Sure. The Imaginary Project creates a schema with half a dozen </em><br /> <em class="quotelev2">> > changes vs. vanilla TEI. Rather than expend the effort to figure out </em><br /> <em class="quotelev2">> > which things affected by the changes should be in tei: namespace and </em><br /> <em class="quotelev2">> > which should be in ip: namespace, they will just put every element </em><br /> <em class="quotelev2">> > and attribute affected by the change into the ip: namespace. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> I think I get you. You mean that when they constrain </em><br /> <em class="quotelev1">> the @type on <div>, they'll put <div> in the ip: space, </em><br /> <em class="quotelev1">> because they think they have to? yes, that would be </em><br /> <em class="quotelev1">> absurd. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > He meant the former, and he obviously does not think it is far too </em><br /> <em class="quotelev2">> > late. Nor do I, for that matter. I doubt you really do, either, </em><br /> <em class="quotelev2">> > Sebastian, as you understand TEI, but IIRC still have trouble </em><br /> <em class="quotelev2">> > wrapping your mind around W3C Schema (although you certainly do </em><br /> <em class="quotelev2">> > better than I with it :-) </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> after a few hours studying an XSD recently, I think </em><br /> <em class="quotelev1">> I finally realized how the demented brains </em><br /> <em class="quotelev1">> of the designers were working. I still don't </em><br /> <em class="quotelev1">> fully understand the ODD processing model, </em><br /> <em class="quotelev1">> and I am the one who has to document it :-{ </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> anyway, forget this side meander. The issue is </em><br /> <em class="quotelev1">> whether conformance and interchange </em><br /> <em class="quotelev1">> are the same thing or not. I conflate them, </em><br /> <em class="quotelev1">> you clearly separate them. </em><br /> But do you Sebastian? If you think Sugar is not a namespace issue, <br /> surely you think it needs to be undoable for interchange? <br /> <p> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:31:00 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:32:26 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:32:26 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <461EC18A.6060105@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 00:32:26 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> The point of much of the syntactic sugar renaming in Tite is to </em><br /> <em class="quotelev2">>> reduce keystrokes. Requiring even a 1-character namespace prefix </em><br /> <em class="quotelev2">>> would negate any advantages. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> yes, I had not grasped that these syntactic sugars </em><br /> <em class="quotelev1">> would be in a different namespace until a few hours ago. </em><br /> <em class="quotelev1">> I agree, I personally think that's simply unworkable. </em><br /> I don't see any alternative. If you decide to rename <div <br /> type="chapter"> as <chapter> and James decides to rename <div <br /> type="section"> as <chapter> how will I tell them apart? Am I really <br /> going to go to the trouble of canonicalizing every document I receive <br /> (using tools I haven't got, and reference to the ODD you probably forgot <br /> to send me)?. Surely it's less work for me to deal with different <br /> namespaces, which my current toolkit *has* to be able to deal with anyway? <br /> Maybe the way to approach this is, as for different languages, for the <br /> TEI to define yet another namespace for sugarred variants? <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:32:29 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 19:35:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 00:35:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EBEC5.6050106@computing-services.oxford.ac.uk> Message-ID: <461EC237.7020407@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 00:35:19 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> I don't get this. If you want 1 character tag names, don't use the </em><br /> <em class="quotelev1">> TEI. Write your own schema, define a mapping between it and the TEI. </em><br /> <em class="quotelev1">> You have attained conformance without confusing the TEI namespace. Next. </em><br /> I think you're maybe misunderstanding Syd here. <br /> Tite proposes (eg) <sup> as syntactic sugar for <hi rend="sup">. <br /> I think you are saying that <sup> will have to be either <sup <br /> xmlns="......"> <br /> or <x:sup>, where "x" is defined up front. Given the usage of <sup>, <br /> you _will_ end up doing one or other on every occasion, at a minimum <br /> extra cost of 4 characters per use (start and end tag). Given that <br /> the aim is to save money, it does seem undesirable. <br /> Me, I think that if <sup> has an <equiv> doing the mapping, <br /> it can stay in the TEI namespace, but I still haven't read the discussion <br /> of you lot over Easter. <br /> As Syd says, no sane Tite user would pay for <x:sup> over <sup>, <br /> so Tite won't conform; unlike Lite, which _will_ be OK. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:35:24 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 19:40:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 00:40:50 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC18A.6060105@computing-services.oxford.ac.uk> Message-ID: <461EC382.4040607@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 00:40:50 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> I don't see any alternative. If you decide to rename <div </em><br /> <em class="quotelev1">> type="chapter"> as <chapter> and James decides to rename <div </em><br /> <em class="quotelev1">> type="section"> as <chapter> how will I tell them apart? </em><br /> God gave you <equiv> for this purpose <br /> <em class="quotelev1">> Am I really going to go to the trouble of canonicalizing every </em><br /> <em class="quotelev1">> document I receive (using tools I haven't got, and reference to the </em><br /> <em class="quotelev1">> ODD you probably forgot to send me)? </em><br /> no ODD, no conformance. the tool you want, I wrote for my TEI MM 2005 talk. <br /> <em class="quotelev1">> Surely it's less work for me to deal with different namespaces, which </em><br /> <em class="quotelev1">> my current toolkit *has* to be able to deal with anyway? </em><br /> for you, maybe, but what about me? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Maybe the way to approach this is, as for different languages, for the </em><br /> <em class="quotelev1">> TEI to define yet another namespace for sugarred variants? </em><br /> <em class="quotelev1">> </em><br /> that doesn't really help, asI haven't bought the "different namespace <br /> for language translations" thing yet either. <br /> I have a horrible feeling I am coming to the idea that "interchange <br /> format" means <br /> "expanding the <equiv> information". <br /> I had better go to bed before I end up agreeing to anything else. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:40:53 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:46:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:46:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC237.7020407@oucs.ox.ac.uk> Message-ID: <461EC4ED.9070606@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 00:46:53 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Tite proposes (eg) <sup> as syntactic sugar for <hi rend="sup">. </em><br /> <em class="quotelev1">> I think you are saying that <sup> will have to be either <sup </em><br /> <em class="quotelev1">> xmlns="......"> </em><br /> <em class="quotelev1">> or <x:sup>, where "x" is defined up front. Given the usage of <sup>, </em><br /> <em class="quotelev1">> you _will_ end up doing one or other on every occasion, at a minimum </em><br /> <em class="quotelev1">> extra cost of 4 characters per use (start and end tag). </em><br /> That is correct. <br /> <em class="quotelev1">> Given that </em><br /> <em class="quotelev1">> the aim is to save money, it does seem undesirable. </em><br /> The aim of the TEI is not to make the smallest possible tagset. If you <br /> want small tags and few keystrokes, you can't be TEI conformant. It <br /> doesn't mean you can't have a jolly good schema, nor indeed one that <br /> can't be automatically made TEI conformant. (James proposed a special <br /> name for such a beast, which I've now forgotten). Have you *read* the <br /> draft yet? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Me, I think that if <sup> has an <equiv> doing the mapping, </em><br /> <em class="quotelev1">> it can stay in the TEI namespace, but I still haven't read the discussion </em><br /> <em class="quotelev1">> of you lot over Easter. </em><br /> <em class="quotelev1">> </em><br /> But that mapping isn't accessible to anyone's normal document processing <br /> tools is it? We don't have TEIFORM anymore. Of course if you can whip <br /> out of the bag some foolproof way of implementing something equivalent <br /> using standard XML processing tools, I'll stop complaining... <br /> <em class="quotelev1">> As Syd says, no sane Tite user would pay for <x:sup> over <sup>, </em><br /> <em class="quotelev1">> so Tite won't conform; unlike Lite, which _will_ be OK. </em><br /> <em class="quotelev1">> </em><br /> If the primary objective of Tite (or any schema) is to save keystrokes, <br /> then TEI conformance/interoperability is going to be a secondary <br /> objective for it. <br /> (I Dont see what Lite has to do with the price of fish) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 19:46:57 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 20:10:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 01:10:26 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC4ED.9070606@computing-services.oxford.ac.uk> Message-ID: <461ECA72.5010202@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 01:10:26 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> But that mapping isn't accessible to anyone's normal document </em><br /> <em class="quotelev1">> processing tools is it? We don't have TEIFORM anymore. Of course if </em><br /> <em class="quotelev1">> you can whip out of the bag some foolproof way of implementing </em><br /> <em class="quotelev1">> something equivalent using standard XML processing tools, I'll stop </em><br /> <em class="quotelev1">> complaining... </em><br /> well, as I say, I did demonstrate this in Sofia! <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> As Syd says, no sane Tite user would pay for <x:sup> over <sup>, </em><br /> <em class="quotelev2">>> so Tite won't conform; unlike Lite, which _will_ be OK. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> If the primary objective of Tite (or any schema) is to save </em><br /> <em class="quotelev1">> keystrokes, then TEI conformance/interoperability is going to be a </em><br /> <em class="quotelev1">> secondary objective for it. </em><br /> hmm, better explain that to Big John U. He thinks <br /> Tite will be the TEI's next big thing. And here we are <br /> saying it won't even be TEI conformant.... <br /> <em class="quotelev1">> (I Dont see what Lite has to do with the price of fish) </em><br /> <em class="quotelev1">> </em><br /> you vaguely wondered if Tite could replace Lite. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 20:10:30 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 20:12:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 01:12:15 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176420874.23247.2.camel@odonned-eng06> Message-ID: <461ECADF.4090508@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 01:12:15 +0100</span><br /> </address> Dan O'Donnell wrote: <br /> <em class="quotelev1">> But do you Sebastian? If you think Sugar is not a namespace issue, </em><br /> <em class="quotelev1">> surely you think it needs to be undoable for interchange? </em><br /> <em class="quotelev1">> </em><br /> I *still* haven't gone to bed, and I admit that <br /> I am backing myself slowly into an interchange corner..... <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 20:12:20 EDT</span> </div> From cwittern at gmail.com Thu Apr 12 21:14:27 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 13 Apr 2007 10:14:27 +0900 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.30928.5625.745800@emt.wwp.brown.edu> Message-ID: <461ED973.1090009@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 10:14:27 +0900</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> OK, it's time to get radical. What do we need "TEI Interchange </em><br /> <em class="quotelev2">>> format" for? Why do we need to define it at all? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Some further thoughts. If we insist that TEI conformant documents </em><br /> <em class="quotelev1">> follow draconian namespace rules, there are some pretty predictable </em><br /> <em class="quotelev1">> potentially problematic probable consequences: </em><br /> <em class="quotelev1">> </em><br /> [...] <br /> <p>Syd, what you are saying here reminds me of the kind of statements I <br /> heard from die-hard SGML users when they first heard about XML and its <br /> "draconian" error-checking rules. <br /> My prediction is quite contrary to yours: I think we will *finally* see <br /> some kind of TEI Software that is worth being called so, since an <br /> implementer now has a way to know what to deal with. -- Well, the bets <br /> are open. Lets look at the results in three years time. <br /> <p><p>Christian <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 21:14:48 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 12 21:35:19 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 21:35:19 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <17950.56919.510899.582380@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 12 Apr 2007 21:35:19 -0400</span><br /> </address> <em class="quotelev1">> And the good news is that this does not stop us doing other work in </em><br /> <em class="quotelev1">> the meanwhile - the definition of conformance can be revisited </em><br /> <em class="quotelev1">> again and again (god help us) over the next 3 or 4 months if it </em><br /> <em class="quotelev1">> really has to, I think. </em><br /> Oh! I had thought conformance was one of those things that could not <br /> be changed after Berlin. Good. While I obviously have some work cut <br /> out for me responding to this evening's posts on this thread, I am <br /> going to deliberately defer until after Berlin, and get back to work <br /> on those phrase-level classes. <br /> G'night. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 12 2007 - 21:35:23 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 13 05:11:37 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 10:11:37 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461E7F18.8030502@computing-services.oxford.ac.uk> Message-ID: <461F4949.5090405@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 10:11:37 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I will put an updated HTML version of the new chapter into the Drafts </em><br /> <em class="quotelev1">> web page later this evening. Dinner first. </em><br /> I assume I can update the trunk and get going with it now then. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 05:12:03 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 05:45:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 10:45:05 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461ECADF.4090508@oucs.ox.ac.uk> Message-ID: <461F5121.9040905@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 10:45:05 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1"> > Dan O'Donnell wrote: </em><br /> <em class="quotelev2"> >> But do you Sebastian? If you think Sugar is not a namespace issue, </em><br /> <em class="quotelev2"> >> surely you think it needs to be undoable for interchange? </em><br /> <em class="quotelev2"> >> </em><br /> <em class="quotelev1"> > I *still* haven't gone to bed, and I admit that </em><br /> <em class="quotelev1"> > I am backing myself slowly into an interchange corner..... </em><br /> <em class="quotelev1"> > </em><br /> <em class="quotelev1"> > </em><br /> I, on the other hand, did go to bed at a sensible time, and thus have <br /> had the opportunity to sleep on it. <br /> Let me try to reformulate the issues here: <br /> 1. "Conformance" means, fundamentally, conformance to the TEI abstract <br /> model. The markup scheme defined by or applied in a TEI conformant <br /> document marks up abstract concepts which are also present in the TEI <br /> abstract model, and with the same meaning. <br /> 2. The particular part of the TEI abstract model which a set of document <br /> uses can be expressed in three ways, only two of which can be <br /> automatically checked: <br /> a) the application of the elements is something that a human reader <br /> recognizes as plausible i.e. the thing tagged <l> does actually contain <br /> a line of verse <br /> b) particular things are called by particular names i.e. the thing <br /> containing a line of verse is called <l> (in the TEI namespace) and not <br /> <line>. Namespaces are a useful way of asserting whether the "l" here <br /> is the TEI "<l>" or some other one. <br /> c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but <br /> not vice versa. Validating this is what schemas are for. <br /> 3. Modification/customization/personalization is something we do in <br /> order to generate and document a schema, so it is about both (a) and <br /> (c). A modification which replaces the <desc> of <l> to say that it is <br /> for typographic lines is an unclean one, as is one which modifies its <br /> content model to permit <div>s within it -- in the same way and for <br /> the same reasons. Only "clean"[1] modifications are conformant (this <br /> doesnt mean that unclean modifications are evil, just that they are <br /> different. Most improvements to the TEI scheme start off life as unclean <br /> modifications.) <br /> 4. We are disagreeing about whether or not a modification which is a <br /> simple renaming is unclean, i.e. about whether 2(b) is somehow different <br /> from the other kinds of conformance constraint. I can identify the <br /> following reasons for this disagreement: <br /> i/ We are so used to seeing different names for the same thing that it <br /> just doesn't seem important to insist on using a specific name, or to <br /> insist that names declare their namespace. (cf the pain of going from <br /> case-insensitive to case-sensitive identifiers which some of us old'uns <br /> are still suffering from). <br /> ii/ We think many people will find namespace technology a step too far <br /> and that this fear will lead them (or us) into all manner of folly <br /> iii/ We know how to easily convert document instances which use renaming <br /> into ones which don't (whereas conversion of other kinds of uncleanly <br /> modified documents is in general problematic or impossible) <br /> iiii/ We (or me at least) are not quite sure how to support extra <br /> namespaces for renaming modifications with the current tool kit <br /> v/ Namespaces are just not the same kind of constraint as schemas -- in <br /> particular they are open-ended: any element can assert that it belongs <br /> to a given namespace and the assertion cannot be validated <br /> <p>Of these I think all but iii are fairly weak. If we take iii seriously <br /> though, maybe what it shows is that we do need an extra concept. We have <br /> previously spoken about "conformance" and "interchange format" and <br /> havered somewhat about the distinction between the two. Maybe what we <br /> need instead is a concept of "canonical representation". <br /> How about this as a compromise: <br /> A conformant TEI document can take either of two forms <br /> * local form -- in which ODD-documented renamings are permitted to join <br /> the TEI namespace <br /> * canonical form -- in which ODD-documented renamings must either be <br /> converted to their equivalent TEI form, or must be assigned to some <br /> other namespace <br /> Probably enough to be going on with, but I would appreciate some <br /> indication of where in this diatribe you stopped saying "yeah yeah we <br /> know that" <br /> <p>L <br /> <p>[1] "clean" as defined in the current draft for MD <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 05:47:14 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 13 06:11:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 11:11:15 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17950.36177.285828.727857@emt.wwp.brown.edu> Message-ID: <461F5743.9000302@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 11:11:15 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> I will put an updated HTML version of the new chapter into the </em><br /> <em class="quotelev2">>> Drafts web page later this evening. Dinner first. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html </em><br /> <em class="quotelev1">> updated completely. (I never update this site file-by-file, I just </em><br /> <em class="quotelev1">> plop a newly generated complete copy in there, so to read Lou's </em><br /> <em class="quotelev1">> latest and greatest, you can go to </em><br /> <em class="quotelev1">> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html.) </em><br /> mh...before continuing proofreading, I have a doubt here. In Lou's <br /> latest XML (downloaded from the trunk) I can see: <br /> <specList><specDesc key="att.naming" atts="key nimKey"/></specList> <br /> However, on Syd's server (at <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html) I only <br /> see: <br /> att.naming provides attributes common to elements which refer to named <br /> persons, places, organizations etc. <br /> key provides a means of locating a full definition for the entity being <br /> named such as a database record key or a URI. <br /> i.e. nimKey is not there. <br /> Why is that? Are the two files real mirrors? <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 06:11:33 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 13 07:21:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 07:21:10 -0400 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F5743.9000302@kcl.ac.uk> Message-ID: <17951.26534.891669.875211@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 07:21:10 -0400</span><br /> </address> <em class="quotelev1">> mh...before continuing proofreading, I have a doubt here. In Lou's </em><br /> <em class="quotelev1">> latest XML (downloaded from the trunk) I can see: </em><br /> <em class="quotelev1">> <specList><specDesc key="att.naming" atts="key nimKey"/></specList> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> However, on Syd's server (at </em><br /> <em class="quotelev1">> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html) I only </em><br /> <em class="quotelev1">> see: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> att.naming provides attributes common to elements which refer to named </em><br /> <em class="quotelev1">> persons, places, organizations etc. </em><br /> <em class="quotelev1">> key provides a means of locating a full definition for the entity being </em><br /> <em class="quotelev1">> named such as a database record key or a URI. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> i.e. nimKey is not there. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Why is that? Are the two files real mirrors? </em><br /> I think because of a mis-match in spelling. The <specDesc> in <br /> ND-namesdates.xml is asking for information about the attribute <br /> nimKey=. The <classSpec> in att.naming.xml defines the nymKey= <br /> attribute. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 07:21:15 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 13 07:31:03 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 12:31:03 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17951.26534.891669.875211@emt.wwp.brown.edu> Message-ID: <461F69F7.1030908@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 12:31:03 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> I think because of a mis-match in spelling. The <specDesc> in </em><br /> <em class="quotelev1">> ND-namesdates.xml is asking for information about the attribute </em><br /> <em class="quotelev1">> nimKey=. The <classSpec> in att.naming.xml defines the nymKey= </em><br /> <em class="quotelev1">> attribute. </em><br /> ops...you are right, thanks. Will change the XML then. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 07:31:27 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 07:40:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 12:40:18 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17951.26534.891669.875211@emt.wwp.brown.edu> Message-ID: <461F6C22.7070708@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 12:40:18 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> i.e. nimKey is not there. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Why is that? Are the two files real mirrors? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think because of a mis-match in spelling. The <specDesc> in </em><br /> <em class="quotelev1">> ND-namesdates.xml is asking for information about the attribute </em><br /> <em class="quotelev1">> nimKey=. The <classSpec> in att.naming.xml defines the nymKey= </em><br /> <em class="quotelev1">> attribute. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> Not quite. The problem is that the HTML on Syd's site was generated from <br /> an older version of the XML source in which the nimKey attribute is <br /> erroneously referred to as "nimkey". This error has been corrected in <br /> the XML source in SVN, but Syd hasn't yet regenerated his HTML to <br /> reflect the correction. <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 07:42:26 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 07:45:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 12:45:08 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F6C22.7070708@oucs.ox.ac.uk> Message-ID: <461F6D44.9060300@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 12:45:08 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Not quite. The problem is that the HTML on Syd's site was generated from </em><br /> <em class="quotelev1">> an older version of the XML source in which the nimKey attribute is </em><br /> <em class="quotelev1">> erroneously referred to as "nimkey". This error has been corrected in </em><br /> <em class="quotelev1">> the XML source in SVN, but Syd hasn't yet regenerated his HTML to </em><br /> <em class="quotelev1">> reflect the correction. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> Ooops. No, I am wrong. <br /> Spellyng never was my strong poynt. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 07:47:16 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 07:50:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 12:50:31 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F6D44.9060300@oucs.ox.ac.uk> Message-ID: <461F6E87.8050001@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 12:50:31 +0100</span><br /> </address> it can't be beyond the wit of man to generate the HTML dynamically on <br /> a web server. its silly to have to depend on Syd's basement server <br /> when we pay good money for managed ones..... <br /> <p><p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 07:50:35 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 13 08:32:19 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 08:32:19 -0400 Subject: [tei-council] dating attrs Message-ID: <17951.30803.46014.797703@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 08:32:19 -0400</span><br /> </address> BTW, the development version of the Guidelines (the one which is in <br /> https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5/Source/ and <br /> available as HTML at <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html) <br /> also has all the new dating attributes in it. Since we all voted on <br /> it, I don't think there is much controversial there, except as listed <br /> below. On the other hand, paying close attention for class errors, <br /> typos, etc., would be helpful. <br /> Possible Issues <br /> -------- ------ <br /> * Rather than create a new module for ISO dating attributes, I stuck <br /> 'em directly into the namesdates module. <br /> * We never decided on the names of the ISO attributes. I called them <br /> value-iso= <br /> dur-iso= <br /> notBefore-iso= <br /> etc. My thinking (what little there was) was that it would be nice <br /> if these attributes sorted near their "simple" W3C counterparts. <br /> * We should perhaps discuss how strong the warnings against using <br /> "24:00" and basic formats (i.e., no colons or hyphens in some <br /> cases) should be. Currently the remarks say <br /> <p>For all representations for which ISO 8601 describes both a <br /> <term>basic</term> and an <term>extended</term> format, these <br /> Guidelines recommend use of the extended format.</p> <br /> <p>While ISO 8601 permits the use of both <code>00:00</code> and <br /> <code>24:00</code> to represent midnight, these Guidelines <br /> strongly recommend against the use of <code>24:00</code>. <!-- As <br /> there are only 24 hours in a day, numbered "00" through "23", use <br /> of "24:00" implies a 25th hour, and some software may be confused. <br /> Note that when there is a leap second, it should be indicated <br /> with 23:59:60. --></p> <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 08:32:22 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 08:42:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 13:42:13 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <461F7AA5.70505@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 13:42:13 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> Since we all voted on </em><br /> <em class="quotelev1">> it, I don't think there is much controversial there, except as listed </em><br /> <em class="quotelev1">> below. On the other hand, paying close attention for class errors, </em><br /> <em class="quotelev1">> typos, etc., would be helpful. </em><br /> <em class="quotelev1">> </em><br /> The summary of outstanding issues here is useful but I must admit that I <br /> for one have long since forgotten the rationale for making these <br /> changes, and there doesn't seem to be any prose added to the Guidelines <br /> to explain them <br /> Could you perhaps remind us why we needed to make this change and how <br /> exactly it is meant to be used? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * Rather than create a new module for ISO dating attributes, I stuck </em><br /> <em class="quotelev1">> 'em directly into the namesdates module. </em><br /> I don't think see them there, unless I'm missing something. There's a <br /> specList which mentions the attributes' names, but no text discussing <br /> them, and the actual classSpec is in ST, where it probably belongs. <br /> However, since I've now handed the ND chapter over to Arianna for <br /> review, I expect she will comment on this too. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * We never decided on the names of the ISO attributes. I called them </em><br /> <em class="quotelev1">> value-iso= </em><br /> <em class="quotelev1">> dur-iso= </em><br /> <em class="quotelev1">> notBefore-iso= </em><br /> <em class="quotelev1">> etc. My thinking (what little there was) was that it would be nice </em><br /> <em class="quotelev1">> </em><br /> ounds plausible to me <br /> if these attributes sorted near their "simple" W3C counterparts. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * We should perhaps discuss how strong the warnings against using </em><br /> <em class="quotelev1">> "24:00" and basic formats (i.e., no colons or hyphens in some </em><br /> <em class="quotelev1">> cases) should be. Currently the remarks say </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <p>For all representations for which ISO 8601 describes both a </em><br /> <em class="quotelev1">> <term>basic</term> and an <term>extended</term> format, these </em><br /> <em class="quotelev1">> Guidelines recommend use of the extended format.</p> </em><br /> <em class="quotelev1">> <p>While ISO 8601 permits the use of both <code>00:00</code> and </em><br /> <em class="quotelev1">> <code>24:00</code> to represent midnight, these Guidelines </em><br /> <em class="quotelev1">> strongly recommend against the use of <code>24:00</code>. </em><br /> <p>I think "recommend" is enough: it's not so big a deal surely? <br /> The notion of "recommended practice" is something we explicitly talk <br /> about in the context of conformance, so having a quick checklist of <br /> occasions, like this, where we *do* make a recommendation would be very <br /> useful. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 08:44:21 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 13 08:50:23 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 13:50:23 +0100 Subject: [tei-council] dating attrs In-Reply-To: <461F7AA5.70505@oucs.ox.ac.uk> Message-ID: <461F7C8F.7050502@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 13:50:23 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> Syd Bauman wrote: </em><br /> <em class="quotelev2">>> Since we all voted on </em><br /> <em class="quotelev2">>> it, I don't think there is much controversial there, except as listed </em><br /> <em class="quotelev2">>> below. On the other hand, paying close attention for class errors, </em><br /> <em class="quotelev2">>> typos, etc., would be helpful. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The summary of outstanding issues here is useful but I must admit that I </em><br /> <em class="quotelev1">> for one have long since forgotten the rationale for making these </em><br /> <em class="quotelev1">> changes, and there doesn't seem to be any prose added to the Guidelines </em><br /> <em class="quotelev1">> to explain them </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Could you perhaps remind us why we needed to make this change and how </em><br /> <em class="quotelev1">> exactly it is meant to be used? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> * Rather than create a new module for ISO dating attributes, I stuck </em><br /> <em class="quotelev2">>> 'em directly into the namesdates module. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I don't think see them there, unless I'm missing something. There's a </em><br /> <em class="quotelev1">> specList which mentions the attributes' names, but no text discussing </em><br /> <em class="quotelev1">> them, and the actual classSpec is in ST, where it probably belongs. </em><br /> I can seem them in ND <br /> as <specList> <specDesc key="data.temporal.iso"/> <br /> <specDesc key="data.duration.iso"/></specList> <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> However, since I've now handed the ND chapter over to Arianna for </em><br /> <em class="quotelev1">> review, I expect she will comment on this too. </em><br /> Will make comments once I'll get there if will be able to. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> * We never decided on the names of the ISO attributes. I called them </em><br /> <em class="quotelev2">>> value-iso= </em><br /> <em class="quotelev2">>> dur-iso= </em><br /> <em class="quotelev2">>> notBefore-iso= </em><br /> <em class="quotelev2">>> etc. My thinking (what little there was) was that it would be nice </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> sounds plausible to me </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> if these attributes sorted near their "simple" W3C counterparts. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> * We should perhaps discuss how strong the warnings against using </em><br /> <em class="quotelev2">>> "24:00" and basic formats (i.e., no colons or hyphens in some </em><br /> <em class="quotelev2">>> cases) should be. Currently the remarks say </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <p>For all representations for which ISO 8601 describes both a </em><br /> <em class="quotelev2">>> <term>basic</term> and an <term>extended</term> format, these </em><br /> <em class="quotelev2">>> Guidelines recommend use of the extended format.</p> </em><br /> <em class="quotelev2">>> <p>While ISO 8601 permits the use of both <code>00:00</code> and </em><br /> <em class="quotelev2">>> <code>24:00</code> to represent midnight, these Guidelines </em><br /> <em class="quotelev2">>> strongly recommend against the use of <code>24:00</code>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think "recommend" is enough: it's not so big a deal surely? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The notion of "recommended practice" is something we explicitly talk </em><br /> <em class="quotelev1">> about in the context of conformance, so having a quick checklist of </em><br /> <em class="quotelev1">> occasions, like this, where we *do* make a recommendation would be very </em><br /> <em class="quotelev1">> useful. </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 08:50:36 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 08:58:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 13:58:58 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <461F7E92.8080201@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 13:58:58 +0100</span><br /> </address> I think I am reaching a little closer to understanding; and I think <br /> I am now happy that anything which makes a document unclean <br /> must not be in the TEI namespace. <br /> * The case where a customization adds an entirely new element, <br /> and how to deal with the namespace there, seems clear. <br /> * The language translations seem clear too. <br /> * The case where I rename "div1" to "section" <br /> is less clear, because the document can go four ways: <br /> a) distributed in pure TEI form, back to <div1>, via a canonicalizer <br /> b) foreign namespace form, to <myspace:section> <br /> c) non-conformant, with <section> in TEI namespace <br /> d) put entire document in foreign namespace <br /> (syntactic sugar similarly, assuming we understand <equiv>) <br /> The detailed ramifications and recommendations are what <br /> concern me, because the person currently doing this <br /> will naturally say "OK, so what is the Right Thing <br /> for me to do now". <br /> Can someone tell me the story of what how <br /> the div1/section thing will pan out in real-life <br /> workflow? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 08:59:02 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Fri Apr 13 09:49:37 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 14:49:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <461F8A71.6090904@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 14:49:37 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> 1. "Conformance" means, fundamentally, conformance to the TEI abstract </em><br /> <em class="quotelev1">> model. The markup scheme defined by or applied in a TEI conformant </em><br /> <em class="quotelev1">> document marks up abstract concepts which are also present in the TEI </em><br /> <em class="quotelev1">> abstract model, and with the same meaning. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 2. The particular part of the TEI abstract model which a set of document </em><br /> <em class="quotelev1">> uses can be expressed in three ways, only two of which can be </em><br /> <em class="quotelev1">> automatically checked: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> a) the application of the elements is something that a human reader </em><br /> <em class="quotelev1">> recognizes as plausible i.e. the thing tagged <l> does actually contain </em><br /> <em class="quotelev1">> a line of verse </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> b) particular things are called by particular names i.e. the thing </em><br /> <em class="quotelev1">> containing a line of verse is called <l> (in the TEI namespace) and not </em><br /> <em class="quotelev1">> <line>. Namespaces are a useful way of asserting whether the "l" here </em><br /> <em class="quotelev1">> is the TEI "<l>" or some other one. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but </em><br /> <em class="quotelev1">> not vice versa. Validating this is what schemas are for. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 3. Modification/customization/personalization is something we do in </em><br /> <em class="quotelev1">> order to generate and document a schema, so it is about both (a) and </em><br /> <em class="quotelev1">> (c). A modification which replaces the <desc> of <l> to say that it is </em><br /> <em class="quotelev1">> for typographic lines is an unclean one, as is one which modifies its </em><br /> <em class="quotelev1">> content model to permit <div>s within it -- in the same way and for </em><br /> <em class="quotelev1">> the same reasons. Only "clean"[1] modifications are conformant (this </em><br /> <em class="quotelev1">> doesnt mean that unclean modifications are evil, just that they are </em><br /> <em class="quotelev1">> different. Most improvements to the TEI scheme start off life as unclean </em><br /> <em class="quotelev1">> modifications.) </em><br /> All of this seems reasonable to me so far. And I agree that we should <br /> highlight that non-conformance is not evil, and is where useful development <br /> takes place. <br /> <em class="quotelev1">> 4. We are disagreeing about whether or not a modification which is a </em><br /> <em class="quotelev1">> simple renaming is unclean, i.e. about whether 2(b) is somehow different </em><br /> <em class="quotelev1">> from the other kinds of conformance constraint. I can identify the </em><br /> <em class="quotelev1">> following reasons for this disagreement: ... iii/ We know how to easily </em><br /> <em class="quotelev1">> convert document instances which use renaming into ones which don't </em><br /> <em class="quotelev1">> (whereas conversion of other kinds of uncleanly modified documents is in </em><br /> <em class="quotelev1">> general problematic or impossible) ... Of these I think all but iii are </em><br /> <em class="quotelev1">> fairly weak. If we take iii seriously though, maybe what it shows is </em><br /> <em class="quotelev1">> that we do need an extra concept. We have previously spoken about </em><br /> <em class="quotelev1">> "conformance" and "interchange format" and havered somewhat about the </em><br /> <em class="quotelev1">> distinction between the two. Maybe what we need instead is a concept of </em><br /> <em class="quotelev1">> "canonical representation". </em><br /> Ok, I'm not sure that I follow the logic here. Yes, we know how to easily <br /> convert document instances which use syntactic sugar renaming into ones <br /> which don't. I don't see that it necessarily follows that the necessary <br /> solution to this is two types of Conformance. I think in the rigid use of <br /> namespaces that Conal argues for, that even these renamings should be in a <br /> separate namespace. Otherwise the TEI namespace is polluted. If there is <br /> local vs canonical versions, <br /> <em class="quotelev1">> How about this as a compromise: A conformant TEI document can take </em><br /> <em class="quotelev1">> either of two forms * local form -- in which ODD-documented renamings </em><br /> <em class="quotelev1">> are permitted to join the TEI namespace * canonical form -- in which </em><br /> <em class="quotelev1">> ODD-documented renamings must either be converted to their equivalent </em><br /> <em class="quotelev1">> TEI form, or must be assigned to some other namespace </em><br /> While it was part of my original draft that because we know how to undo <br /> renamings, that these be allowed to pollute the TEI namespace, I'm still <br /> not convinced by these two types of conformance. I want to know that when <br /> a document is conformant it is one type of thing, not two possible types of <br /> things. That is, I think the canonical form is Conformant, and the local <br /> form is not. All of the arguments you posted as to why the local form <br /> should be acceptable are reasonable, but as I understand it that we know <br /> how to easily convert back renamings isn't a good reason to step down from <br /> the Namespace Moral High Ground. If the local form uses a user-defined <br /> namespace for all these modifications, than it suddenly becomes conformant. <br /> I understand 'clean' modifications to be those which constrain the TEI <br /> further so that a resulting document instance would still validate against <br /> tei_all. Renamings, by definition, don't do this. Unless, yes, we pass <br /> them through some sort of canonicalising processing step. But because they <br /> are able to be put through this processing doesn't make them any more TEI <br /> elements than ones I've added by hand. There are other unclean <br /> modifications I can make, say expressing my date attributes values in a <br /> form of "07/04/13", which we can all agree are unclean. I can write an <br /> xslt stylesheet (if I've been consistent) which changes these into <br /> 2007-04-13, but that doesn't mean my document deserves some special status <br /> as Conformant, even if I've documented my change in an ODD. Or does it? <br /> While I agree that syntactic sugar renamings are a specialised case of <br /> this, I'm not convinced they are truly a different thing. <br /> But maybe I'm not fully understanding what your definition of 'clean' is. <br /> The MD draft says: <br /> <em class="quotelev1">> Each schema resulting from a modified combination of TEI modules will </em><br /> <em class="quotelev1">> define a different set of documents. The set of documents valid </em><br /> <em class="quotelev1">> according to the unmodified schema may be properly contained in the set </em><br /> <em class="quotelev1">> of documents considered to be valid according to the modified schema, or </em><br /> <em class="quotelev1">> vice versa. Modifications that have either of these two results are </em><br /> <em class="quotelev1">> called clean modifications. Alternatively, the set of documents </em><br /> <em class="quotelev1">> considered valid by the original schema might overlap the set of </em><br /> <em class="quotelev1">> documents considered valid by the modified schema with neither being </em><br /> <em class="quotelev1">> properly contained in the other. Modifications that have this result are </em><br /> <em class="quotelev1">> called unclean modifications. </em><br /> Clear as mud. If I'm understanding it right, this means documents that <br /> validate against tei_all must also validate against the modified schema, or <br /> the documents that validate against the modified schema, must also validate <br /> against tei_all. Or am I misunderstanding? (In either case, more <br /> explanation of these two concepts would be useful to readers.) I don't see <br /> that renamings fit into that definition of clean, and I don't want to <br /> introduce and extra step (canonicalisation) that users need to go through. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 09:49:42 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 10:19:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 15:19:21 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F7E92.8080201@oucs.ox.ac.uk> Message-ID: <461F9169.5040401@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 15:19:21 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> * The case where I rename "div1" to "section" </em><br /> <em class="quotelev1">> is less clear, because the document can go four ways: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> a) distributed in pure TEI form, back to <div1>, via a canonicalizer </em><br /> <em class="quotelev1">> b) foreign namespace form, to <myspace:section> </em><br /> <em class="quotelev1">> c) non-conformant, with <section> in TEI namespace </em><br /> <em class="quotelev1">> d) put entire document in foreign namespace </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> (syntactic sugar similarly, assuming we understand <equiv>) </em><br /> It is c) that I think I disagree with Lou about. I am convinced now that <br /> if you rename tei:div1 to tei:section you are now non-conformant because <br /> you provide an element in the TEI namespace that the TEI has not defined. <br /> Namespaces say 'we are part of this' and if the TEI buys the concept of <br /> namespaces I think it needs to also accept that then only it can define TEI <br /> elements. (i.e. all the rest are in another namespace or not 'official' <br /> (i.e. non-conformant).) <br /> <em class="quotelev1">> The detailed ramifications and recommendations are what </em><br /> <em class="quotelev1">> concern me, because the person currently doing this </em><br /> <em class="quotelev1">> will naturally say "OK, so what is the Right Thing </em><br /> <em class="quotelev1">> for me to do now". </em><br /> Yes, I agree that these concern me as well, and that more time than we <br /> think is going to have to be spent on making the default process as clear <br /> and painless for users. <br /> <em class="quotelev1">> Can someone tell me the story of what how </em><br /> <em class="quotelev1">> the div1/section thing will pan out in real-life </em><br /> <em class="quotelev1">> workflow? </em><br /> Here is how I'd want it to work: <br /> Johannes Projektmann after reading a lot about the TEI, comes to webRoma <br /> and wants to rename div1 to section. This is the only change he wants to <br /> make. Johannes fills in the form and Roma puts this 'section' element in a <br /> new namespace which he has an option of customising. He saves his ODD file <br /> so he can come back and customise it later, and generates a Relax NG XML <br /> schema which is able to validate his documents (including the my:section <br /> elements and the tei elements they contain). Because his documents <br /> validate against schemas that Roma produces from this ODD, they are <br /> Conformant, and he doesn't have to worry about doing anything to his <br /> document instances to make them so. (Other, perhaps, of making the ODD <br /> available.) Later, after much more experience, he decides he really needs <br /> a 'thingy' element, for something the TEI doesn't really know about. So he <br /> feeds his ODD back in, and adds a new element, optionally placing it in the <br /> same namespace as his earlier change. The my:thingy element has a complex <br /> content model that includes references to TEI classes and pointers to <br /> outside schemas like SVG. He saves his ODD, and regenerates his schemas and <br /> they produce a Relax NG schema which validates his documents including his <br /> my:thingy elements and their funny contents which are part TEI and part <br /> SVG. His documents are still Conformant (though perhaps a different <br /> 'variety' of conformance). If Johannes needs to run something else to make <br /> his documents fully conformant, then he won't bother doing so. But if it <br /> "just works", then he'll happily be conformant. <br /> I recognise I'm side stepping some of the issues there. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 10:19:26 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 10:21:58 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 15:21:58 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F8A71.6090904@oucs.ox.ac.uk> Message-ID: <461F9206.1080204@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 15:21:58 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> solution to this is two types of Conformance. I think in the rigid use of </em><br /> <em class="quotelev1">> namespaces that Conal argues for, that even these renamings should be in a </em><br /> <em class="quotelev1">> separate namespace. Otherwise the TEI namespace is polluted. If there is </em><br /> <em class="quotelev1">> local vs canonical versions, </em><br /> (I seemed to have stopped in mid thought there, I probably meant to <br /> continue something like:) <br /> "... then the namespace is still polluted. (Which I think it shouldn't be <br /> on grounds of principle, rather than on anticipation of actual collision, <br /> etc.)" <br /> -james <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 10:22:02 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:07:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:07:25 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F9169.5040401@computing-services.oxford.ac.uk> Message-ID: <461F9CAD.6040106@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 16:07:25 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I recognise I'm side stepping some of the issues there. </em><br /> <em class="quotelev1">> </em><br /> When you contact Johannes and say "can you send me your <br /> document for my corpus", what does he do? <br /> I am rapidly coming to the conclusion that Roma <br /> should seriously downplay the use of <altIdent>, <br /> and use it mainly for the full-scale language <br /> translations, where the whole doc changes <br /> namespace. Using <altIdent> to rename <br /> div1 to section, and then forcing JP to <br /> use <my:section> seems unfriendly and <br /> unhelpful. If he really wants to use alternate <br /> notation for the TEI abstract model, better if <br /> he switches namespace for the whole document. <br /> I shudder to think about the work needed on <br /> Roma to support the last 2 weeks discussion <br /> properly. <br /> I am now assuming that, inter alia, <br /> Roma should support a "canonical mode", in which <br /> <altIdent> and <equiv> follow a different <br /> route, in which the schema created is canonical, <br /> but as a side effect an ad hoc canonicaliser <br /> is created for you, to apply to documents <br /> which are valid against a non-canonical <br /> schema. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:07:29 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:11:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:11:08 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <461F9D8C.90604@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 16:11:08 +0100</span><br /> </address> I am a little bothered by the variation in names of *Spec. <br /> It seems to me that "att.dateTime.iso" does not follow <br /> TEI naming practice? <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:11:11 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 13 11:19:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 11:19:58 -0400 Subject: [tei-council] dating attrs In-Reply-To: <461F9D8C.90604@oucs.ox.ac.uk> Message-ID: <17951.40862.894630.161583@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 11:19:58 -0400</span><br /> </address> <em class="quotelev1">> I am a little bothered by the variation in names of *Spec. It seems </em><br /> <em class="quotelev1">> to me that "att.dateTime.iso" does not follow TEI naming practice? </em><br /> What would you suggest? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:20:07 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:29:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:29:10 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.40862.894630.161583@emt.wwp.brown.edu> Message-ID: <461FA1C6.1020106@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 16:29:10 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> I am a little bothered by the variation in names of *Spec. It seems </em><br /> <em class="quotelev2">>> to me that "att.dateTime.iso" does not follow TEI naming practice? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> What would you suggest? </em><br /> <em class="quotelev1">> </em><br /> att.isoDateTime, unfortunately <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:29:13 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 13 11:40:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 11:40:45 -0400 Subject: [tei-council] dating attrs In-Reply-To: <461FA1C6.1020106@oucs.ox.ac.uk> Message-ID: <17951.42109.547286.804926@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 11:40:45 -0400</span><br /> </address> <em class="quotelev1">> att.isoDateTime, unfortunately </em><br /> If it's so unfortunate, perhaps the practice should change (in this <br /> case, to more closely resemble the naming practices of model <br /> classes). <br /> I thought you were going to complain that "dateTime" is not <br /> adjectival. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:40:48 EDT</span> </div> From daniel.odonnell at uleth.ca Fri Apr 13 11:44:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 09:44:07 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <1176479048.6268.21.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 09:44:07 -0600</span><br /> </address> On Fri, 2007-04-13 at 10:45 +0100, Lou Burnard wrote: <br /> <em class="quotelev1">> Let me try to reformulate the issues here: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 1. "Conformance" means, fundamentally, conformance to the TEI abstract </em><br /> <em class="quotelev1">> model. The markup scheme defined by or applied in a TEI conformant </em><br /> <em class="quotelev1">> document marks up abstract concepts which are also present in the TEI </em><br /> <em class="quotelev1">> abstract model, and with the same meaning. </em><br /> This is a definition of identity, not conformance, IMO. For me <br /> conformance means the same as what I've always understood "clean" to <br /> mean: not necessarily identity, but any changes that have been made <br /> a) can be undone using canonical tools that must be provided with the <br /> document (i.e. <equiv> and the like and ODDs) <br /> b) are made using provided mechanisms for making such changes. <br /> a) is fundamental; b) is slightly less so since the end of SGML days. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 2. The particular part of the TEI abstract model which a set of document </em><br /> <em class="quotelev1">> uses can be expressed in three ways, only two of which can be </em><br /> <em class="quotelev1">> automatically checked: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> a) the application of the elements is something that a human reader </em><br /> <em class="quotelev1">> recognizes as plausible i.e. the thing tagged <l> does actually contain </em><br /> <em class="quotelev1">> a line of verse </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> b) particular things are called by particular names i.e. the thing </em><br /> <em class="quotelev1">> containing a line of verse is called <l> (in the TEI namespace) and not </em><br /> <em class="quotelev1">> <line>. Namespaces are a useful way of asserting whether the "l" here </em><br /> <em class="quotelev1">> is the TEI "<l>" or some other one. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but </em><br /> <em class="quotelev1">> not vice versa. Validating this is what schemas are for. </em><br /> Or you could have renamed <l> <line> and <br /> i) properly documented this with <equiv> (a local renaming) and/or <br /> ii) built it into an ODD (as in Tite, as proposed in this discussion) <br /> or <br /> iii) changed it back before shipping it to somebody else (interchange). <br /> All three of these methods are essentially methods of achieving your <br /> states b) and/or c) and are open to automatic checking. <br /> I hasten to note moreover, that I am saying these should be allowed ONLY <br /> on the condition that they can be reversed on a 1:1 basis and reversed <br /> using supplied information. I.e. if you don't use equiv, introduce a <br /> conflict to the existing TEI namespace you are using, and/or don't <br /> supply the ODD, the document is not conformant. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 3. Modification/customization/personalization is something we do in </em><br /> <em class="quotelev1">> order to generate and document a schema, so it is about both (a) and </em><br /> <em class="quotelev1">> (c). A modification which replaces the <desc> of <l> to say that it is </em><br /> <em class="quotelev1">> for typographic lines is an unclean one, as is one which modifies its </em><br /> <em class="quotelev1">> content model to permit <div>s within it -- in the same way and for </em><br /> <em class="quotelev1">> the same reasons. Only "clean"[1] modifications are conformant (this </em><br /> <em class="quotelev1">> doesnt mean that unclean modifications are evil, just that they are </em><br /> <em class="quotelev1">> different. Most improvements to the TEI scheme start off life as unclean </em><br /> <em class="quotelev1">> modifications.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 4. We are disagreeing about whether or not a modification which is a </em><br /> <em class="quotelev1">> simple renaming is unclean, i.e. about whether 2(b) is somehow different </em><br /> <em class="quotelev1">> from the other kinds of conformance constraint. I can identify the </em><br /> <em class="quotelev1">> following reasons for this disagreement: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> i/ We are so used to seeing different names for the same thing that it </em><br /> <em class="quotelev1">> just doesn't seem important to insist on using a specific name, or to </em><br /> <em class="quotelev1">> insist that names declare their namespace. (cf the pain of going from </em><br /> <em class="quotelev1">> case-insensitive to case-sensitive identifiers which some of us old'uns </em><br /> <em class="quotelev1">> are still suffering from). </em><br /> Not a great reason, but not a bad one either for projects that have <br /> invested immense amount of time in legacy training and/or data. And not <br /> by any means a fatal error--it allows more things to be acceptable P5 <br /> without polluting the namespace because it is automatically undoable if <br /> the document is conformant in the way I've described it. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> ii/ We think many people will find namespace technology a step too far </em><br /> <em class="quotelev1">> and that this fear will lead them (or us) into all manner of folly </em><br /> Not a good reason in my view. I agree with whoever it was who pointed to <br /> the parallel with SGMLers attitude towards the question of throwing <br /> errors in XML. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> iii/ We know how to easily convert document instances which use renaming </em><br /> <em class="quotelev1">> into ones which don't (whereas conversion of other kinds of uncleanly </em><br /> <em class="quotelev1">> modified documents is in general problematic or impossible) </em><br /> This is THE crucial distinction in my view. I still thing "conformant <br /> documents are identical to canonical TEI or cleanly and recoverably <br /> modified from it" is the principle we should have. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> iiii/ We (or me at least) are not quite sure how to support extra </em><br /> <em class="quotelev1">> namespaces for renaming modifications with the current tool kit </em><br /> Not such a good reason in my view. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> v/ Namespaces are just not the same kind of constraint as schemas -- in </em><br /> <em class="quotelev1">> particular they are open-ended: any element can assert that it belongs </em><br /> <em class="quotelev1">> to a given namespace and the assertion cannot be validated </em><br /> <p>Not really an issue. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Of these I think all but iii are fairly weak. If we take iii seriously </em><br /> <em class="quotelev1">> though, maybe what it shows is that we do need an extra concept. We have </em><br /> <em class="quotelev1">> previously spoken about "conformance" and "interchange format" and </em><br /> <em class="quotelev1">> havered somewhat about the distinction between the two. Maybe what we </em><br /> <em class="quotelev1">> need instead is a concept of "canonical representation". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> How about this as a compromise: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A conformant TEI document can take either of two forms </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * local form -- in which ODD-documented renamings are permitted to join </em><br /> <em class="quotelev1">> the TEI namespace </em><br /> <em class="quotelev1">> * canonical form -- in which ODD-documented renamings must either be </em><br /> <em class="quotelev1">> converted to their equivalent TEI form, or must be assigned to some </em><br /> <em class="quotelev1">> other namespace </em><br /> Basically this looks like "conformant" (in my non-"identical" sense <br /> above) and "identical" (in your "conformant" sense, above). I think <br /> "local" is a misnomer, however, since that implies that it is for local <br /> use only, whereas your tagging it as "conformant" and the provisos you <br /> add make it clear that it is useful for interchange. If you revise the <br /> definition of local to "in which ODD-documented renamings THAT DO NOT <br /> CONFLICT WITH CANONICAL FORMS" to you definition of local (capitals = <br /> <hi> not <shout>), then you have a form that can be pretty freely <br /> circulated as long as the ODD is included--which given the big deal we <br /> are making of it, seems not unreasonable. <br /> As I read this, what is striking to me that the difference between what <br /> you call "local" (if you edit it as I suggest) and "canonical" forms <br /> really involves where the processing is done: on my computer or on <br /> yours. This suggests to me they may be from an XML point of more much of <br /> a more-or-less-ness. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Probably enough to be going on with, but I would appreciate some </em><br /> <em class="quotelev1">> indication of where in this diatribe you stopped saying "yeah yeah we </em><br /> <em class="quotelev1">> know that" </em><br /> Hopefully the annotations will help ;) <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> L </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> [1] "clean" as defined in the current draft for MD </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:44:16 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 11:49:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 16:49:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F9CAD.6040106@oucs.ox.ac.uk> Message-ID: <461FA6A1.7000308@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 16:49:53 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I recognise I'm side stepping some of the issues there. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> When you contact Johannes and say "can you send me your </em><br /> <em class="quotelev1">> document for my corpus", what does he do? </em><br /> He says "My document is freely available at the following URI: <br /> http://www.projektmann.de/meinDokument.xml <br /> It's teiHeader includes a pointer to the licence it is released under, and <br /> also a pointer to the ODD, just where the Guidelines say I should include <br /> such things." <br /> <em class="quotelev1">> I am rapidly coming to the conclusion that Roma </em><br /> <em class="quotelev1">> should seriously downplay the use of <altIdent>, </em><br /> <em class="quotelev1">> and use it mainly for the full-scale language </em><br /> <em class="quotelev1">> translations, where the whole doc changes </em><br /> <em class="quotelev1">> namespace. Using <altIdent> to rename </em><br /> <em class="quotelev1">> div1 to section, and then forcing JP to </em><br /> <em class="quotelev1">> use <my:section> seems unfriendly and </em><br /> <em class="quotelev1">> unhelpful. If he really wants to use alternate </em><br /> <em class="quotelev1">> notation for the TEI abstract model, better if </em><br /> <em class="quotelev1">> he switches namespace for the whole document. </em><br /> So you are suggesting that if I want to rename 'div1' to 'section' then the <br /> entire document is no longer TEI, doesn't use TEI elements and so shouldn't <br /> be in the TEI namespace??! That seems much more extreme than anything <br /> we've been suggesting, doesn't it? <br /> <em class="quotelev1">> I shudder to think about the work needed on </em><br /> <em class="quotelev1">> Roma to support the last 2 weeks discussion </em><br /> <em class="quotelev1">> properly. </em><br /> Yes, that is my worry as well. <br /> <em class="quotelev1">> I am now assuming that, inter alia, </em><br /> <em class="quotelev1">> Roma should support a "canonical mode", in which </em><br /> <em class="quotelev1">> <altIdent> and <equiv> follow a different </em><br /> <em class="quotelev1">> route, in which the schema created is canonical, </em><br /> <em class="quotelev1">> but as a side effect an ad hoc canonicaliser </em><br /> <em class="quotelev1">> is created for you, to apply to documents </em><br /> <em class="quotelev1">> which are valid against a non-canonical </em><br /> <em class="quotelev1">> schema. </em><br /> I'm not sure I buy this two types of conformant documents, a local <br /> non-namespaced one and a canonical one. While command-line Roma maybe <br /> should have this distinction, I'm convinced that we should strive to have <br /> webRoma only produce ODDs (to generate schemas) to validate Conformant <br /> documents. <br /> -james <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:49:58 EDT</span> </div> From daniel.odonnell at uleth.ca Fri Apr 13 11:57:44 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 09:57:44 -0600 Subject: [tei-council] dating attrs In-Reply-To: <17951.42109.547286.804926@emt.wwp.brown.edu> Message-ID: <1176479864.6268.32.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 09:57:44 -0600</span><br /> </address> On Fri, 2007-04-13 at 11:40 -0400, Syd Bauman wrote: <br /> <em class="quotelev2">> > att.isoDateTime, unfortunately </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If it's so unfortunate, perhaps the practice should change (in this </em><br /> <em class="quotelev1">> case, to more closely resemble the naming practices of model </em><br /> <em class="quotelev1">> classes). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I thought you were going to complain that "dateTime" is not </em><br /> <em class="quotelev1">> adjectival. </em><br /> Since dating has come up, I'd like to ask a question that seems to have <br /> got lost in our placename discussion: should we not have an @at <br /> attribute as well as @from, @to, @notbefore and @notafter? <br /> Fort Whoop Up near Lethbridge was founded not before 1869 (they were <br /> rumrunners, so they didn't make an official announcement) and it washed <br /> away in the flood of the Old Man river of 1915, though I don't know the <br /> date, so notBefore="1869"/to="1915" are acceptable values. <br /> Opening cermonies, however, happen at specific times and do not <br /> represent a range. The North West Mounted Police arrived at Fort Whoop <br /> Up on, let's say, November 11, 1874. If my placeEvent is that they <br /> arrived (as opposed to that they arrived and stayed for a while), @from <br /> is not really an appropriate attribute. Likewise with incorporations. <br /> The birth element has @date for birth dates for exactly this reason.<!--nospam--> <br /> Since people are not the only things that have exactlyAt events in their <br /> lives, I wonder if we shouldn't have this as a generalisable attribute. <br /> <p><em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 11:57:47 EDT</span> </div> From daniel.odonnell at uleth.ca Fri Apr 13 12:22:11 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 10:22:11 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC237.7020407@oucs.ox.ac.uk> Message-ID: <1176481331.6268.49.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 10:22:11 -0600</span><br /> </address> On Fri, 2007-04-13 at 00:35 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">> > I don't get this. If you want 1 character tag names, don't use the </em><br /> <em class="quotelev2">> > TEI. Write your own schema, define a mapping between it and the TEI. </em><br /> <em class="quotelev2">> > You have attained conformance without confusing the TEI namespace. Next. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As Syd says, no sane Tite user would pay for <x:sup> over <sup>, </em><br /> <em class="quotelev1">> so Tite won't conform; unlike Lite, which _will_ be OK. </em><br /> Also, this is running against what I've always seen as the customisation <br /> principle of the TEI: we provide a standard and methods of customising <br /> that standard to your specific needs. ROMA provide you with custom ODDs <br /> that fit your precise encoding situation and keep you conformant, <br /> renaming provides a mechanism for meeting your keyboarding and/or <br /> training needs while remaining conformant. <br /> While I am not at all against being quite strict about minimum <br /> requirements, I think we don't need to go out of our way to ban <br /> behaviour that can be easily reconciled with the canonical standard. <br /> -dan <br /> <p><p><p><p><em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 12:22:15 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 13 12:52:53 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 17:52:53 +0100 Subject: [tei-council] dating attrs In-Reply-To: <1176479864.6268.32.camel@caedmon> Message-ID: <461FB565.40905@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 17:52:53 +0100</span><br /> </address> Daniel O'Donnell wrote: <br /> <em class="quotelev1">> On Fri, 2007-04-13 at 11:40 -0400, Syd Bauman wrote: </em><br /> <em class="quotelev3">>>> att.isoDateTime, unfortunately </em><br /> <em class="quotelev2">>> If it's so unfortunate, perhaps the practice should change (in this </em><br /> <em class="quotelev2">>> case, to more closely resemble the naming practices of model </em><br /> <em class="quotelev2">>> classes). </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I thought you were going to complain that "dateTime" is not </em><br /> <em class="quotelev2">>> adjectival. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Since dating has come up, I'd like to ask a question that seems to have </em><br /> <em class="quotelev1">> got lost in our placename discussion: should we not have an @at </em><br /> <em class="quotelev1">> attribute as well as @from, @to, @notbefore and @notafter? </em><br /> Before creating yet another attribute for specifying dates, I would see <br /> whether some or all the elements related to place names (and person <br /> names as well?) could be members of the new class att.dateTime. Or am I <br /> not understanding where we are going at all? <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Fort Whoop Up near Lethbridge was founded not before 1869 (they were </em><br /> <em class="quotelev1">> rumrunners, so they didn't make an official announcement) and it washed </em><br /> <em class="quotelev1">> away in the flood of the Old Man river of 1915, though I don't know the </em><br /> <em class="quotelev1">> date, so notBefore="1869"/to="1915" are acceptable values. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Opening cermonies, however, happen at specific times and do not </em><br /> <em class="quotelev1">> represent a range. The North West Mounted Police arrived at Fort Whoop </em><br /> <em class="quotelev1">> Up on, let's say, November 11, 1874. If my placeEvent is that they </em><br /> <em class="quotelev1">> arrived (as opposed to that they arrived and stayed for a while), @from </em><br /> <em class="quotelev1">> is not really an appropriate attribute. Likewise with incorporations. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The birth element has @date for birth dates for exactly this reason.<!--nospam--> </em><br /> <em class="quotelev1">> Since people are not the only things that have exactlyAt events in their </em><br /> <em class="quotelev1">> lives, I wonder if we shouldn't have this as a generalisable attribute. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 12:52:58 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 16:39:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 21:39:47 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17942.57589.177531.95758@emt.wwp.brown.edu> Message-ID: <461FEA93.5020604@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 13 Apr 2007 21:39:47 +0100</span><br /> </address> apropos of a thread I saw somewhere, the cognoscenti will <br /> remember that I gave a talk at XML Europe in 2004 demonstrating <br /> how to merge TEI and Docbook, using pure RELAX NG fragments <br /> tuff like this: <br /> include "Schema/figures.rnc" { <br /> datatype.Formula = mathml.math <br /> formula.attributes = <br /> attribute id { datatype.ID }?, <br /> attribute notation { formulaNotations }?, <br /> attribute type { text }? <br /> } <br /> (not up to date, obviously). <br /> Just in case anyone doubted that customizing the TEI <br /> in pure RELAX NG is relatively easy, and has been done. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 13 2007 - 16:39:51 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 03:49:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 08:49:51 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <461FEA93.5020604@oucs.ox.ac.uk> Message-ID: <4620879F.1020907@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 08:49:51 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> apropos of a thread I saw somewhere, the cognoscenti will </em><br /> <em class="quotelev1">> remember that I gave a talk at XML Europe in 2004 demonstrating </em><br /> <em class="quotelev1">> how to merge TEI and Docbook, using pure RELAX NG fragments </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> stuff like this: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> include "Schema/figures.rnc" { </em><br /> <em class="quotelev1">> datatype.Formula = mathml.math </em><br /> <em class="quotelev1">> formula.attributes = </em><br /> <em class="quotelev1">> attribute id { datatype.ID }?, </em><br /> <em class="quotelev1">> attribute notation { formulaNotations }?, </em><br /> <em class="quotelev1">> attribute type { text }? </em><br /> <em class="quotelev1">> } </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> (not up to date, obviously). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Just in case anyone doubted that customizing the TEI </em><br /> <em class="quotelev1">> in pure RELAX NG is relatively easy, and has been done. </em><br /> <p>I never doubt that this was possible or something that some people would <br /> do. Because your subject line relates this to conformance, I'm assuming <br /> that your implication is that we should reconsider the requirement of <br /> ODD for conformance? Does the fact that this is fairly easy, and has <br /> been done previously, affect the council's decision that an ODD is <br /> required for conformance? <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 03:42:47 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 06:40:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 11:40:39 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620879F.1020907@oucs.ox.ac.uk> Message-ID: <4620AFA7.605@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 11:40:39 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Because your subject line relates this to conformance, I'm assuming </em><br /> <em class="quotelev1">> that your implication is that we should reconsider the requirement of </em><br /> <em class="quotelev1">> ODD for conformance? Does the fact that this is fairly easy, and has </em><br /> <em class="quotelev1">> been done previously, affect the council's decision that an ODD is </em><br /> <em class="quotelev1">> required for conformance? </em><br /> not really. I am generally happy with TEI Conformance being a serious <br /> target, <br /> including ODD (though see below). <br /> I do want to remember the debate, though, about what we should deliver. <br /> It seriously affects the description of what an ODD processor should do if <br /> I say that it must generate a parameterized schema with clearly defined <br /> entry points. Can the user guarentee that for every "model.foo" she reads <br /> about in the guidelines there is a corresponding RELAX NG pattern <br /> "model.foo" <br /> in a RELAXNG schema published by the TEI? there is no apriori reason <br /> why R_ODD (ie the XSL stylesheets which are beyond Roma, and are our <br /> defacto definition of what an ODD processor should do) <br /> _should_ preserve those names, you understand, or even preserve the <br /> knowledge <br /> of classes in the schemas it generates. <br /> In the flurry of emails over Easter which I finally read (don't you guys <br /> have <br /> holidays?), I see a pretty clear consensus that conformance and ODD are <br /> closely <br /> linked, and that modification via DTD or RELAX NG fragments is simply not <br /> on. I am not sure I see a clear conclusion as to whether we continue to <br /> generate <br /> the DTD and RELAX NG modules for those who don't give a dang about <br /> conformance. <br /> Can I introduce you to someone? This person (let's call him Wohann :-}) <br /> shuns ODD entirely, and maintains his customization by writing <br /> a wrapper RELAX NG schema which does just what he wants, pulling <br /> in bits of TEI RELAX NG schemas. It is readable, <br /> documented, efficient and expressive. He uses extra features of RELAX NG <br /> or other ISO DSDL standards to manage his documents to a high standard. <br /> He is, you may say, non-conformant. He cannot show his "workings" <br /> in the approved form, and gets an F. <br /> HOWEVER, when you get Wohann's document, <br /> it validates fine against tei_all. If he could be bothered, he could write <br /> an ODD equivalent of his hand-crafted schema, and the document would <br /> validate against that too. The document validates against _many_ schemas, <br /> and breaks no TEI semantic or syntactic rules. It adds no new elements <br /> or does any renaming, or breaks any models. <br /> So two questions: <br /> a) Can Wohann put the "TEI Conformant" badge on his web site, by the <br /> fiction <br /> that his ODD is the implicit tei_all? Even though he and all his workers <br /> use the evil little hand-crafted schema, and the document contains a PI <br /> linking to that? <br /> b) do we encourage/support/allow Wohann's working method by generating <br /> the schemas for him? <br /> Or I am just going the mulberry bush again? <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 06:40:43 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 07:00:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 12:00:16 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461FA6A1.7000308@computing-services.oxford.ac.uk> Message-ID: <4620B440.604@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 12:00:16 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So you are suggesting that if I want to rename 'div1' to 'section' then the </em><br /> <em class="quotelev1">> entire document is no longer TEI, doesn't use TEI elements and so shouldn't </em><br /> <em class="quotelev1">> be in the TEI namespace??! That seems much more extreme than anything </em><br /> <em class="quotelev1">> we've been suggesting, doesn't it? </em><br /> <em class="quotelev1">> </em><br /> no, I am saying that Johann might prefer to see it this <br /> way, to avoid the chop and change of namespaces <br /> every other line. His choice. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> While command-line Roma maybe </em><br /> <em class="quotelev1">> should have this distinction, I'm convinced that we should strive to have </em><br /> <em class="quotelev1">> webRoma only produce ODDs (to generate schemas) to validate Conformant </em><br /> <em class="quotelev1">> documents. </em><br /> <em class="quotelev1">> </em><br /> yes, whichever way you do it, conformant documents <br /> are involved. the distinction is between conformant <br /> and interchangeable, ie where the <altIdent>s have <br /> been reversed. all conformant documents have <br /> the potential to be canonical as well, after a transformation. <br /> So how about Roma shows you a new paradigm? <br /> Instead of "renaming div1 to section", it <br /> only lets you add a new element called "section"; <br /> however, when you create it, you have the short-form <br /> option of saying "I want it to be a *move* of div1, <br /> but I want to change the name, <br /> the description and the examples". So you get <br /> the "edit element" screen, but with no chance <br /> to change classes or content model; you are <br /> *forced* to use a new namespace. <br /> This removes the possibility in webRoma (command <br /> line Roma is just an ODD processor, so not <br /> relevant) of doing simple renames. Internally, <br /> we manage the "move of div1to section" as <br /> a change of div1 and an <altIdent>. <br /> I am groping here towards a work plan <br /> for rewriting Roma. If we can make the use <br /> of <altIdent> much harder, that strange <br /> case which bothers us arises less often; either <br /> way, a new namespace for a moved or new <br /> element is mandatory; and the algorithm for that <br /> is that we start off forcing you to think one up, <br /> and thereafter propose the same as you said <br /> last time. <br /> Whether newly added attributes are forced to a <br /> namespace, as opposed to the default null one, <br /> is tricky. I am personally inclined to think <br /> that this is <soCalled>political <br /> correctness gone mad</soCalled>. <br /> I still believe that we have an option in Roma <br /> (maybe just on the desktop version for advanced <br /> use) which ignores the <altIdent>s <br /> and generates a script to reverse them and <br /> <equiv>s you have stuck in, probably by hand, <br /> in documents. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 07:00:19 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 07:56:05 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 12:56:05 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620AFA7.605@oucs.ox.ac.uk> Message-ID: <4620C155.1080907@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 12:56:05 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> on. I am not sure I see a clear conclusion as to whether we continue to </em><br /> <em class="quotelev1">> generate </em><br /> <em class="quotelev1">> the DTD and RELAX NG modules for those who don't give a dang about </em><br /> <em class="quotelev1">> conformance. </em><br /> I feel this is optional but nice -- does it take much effort to produce <br /> them? Yes they can be used as you describe below, but I don't think <br /> that is reason to no produce them if this is done automatically. <br /> <em class="quotelev1">> Can I introduce you to someone? This person (let's call him Wohann :-}) </em><br /> <em class="quotelev1">> shuns ODD entirely, and maintains his customization by writing </em><br /> <em class="quotelev1">> a wrapper RELAX NG schema which does just what he wants, pulling </em><br /> <em class="quotelev1">> in bits of TEI RELAX NG schemas. It is readable, </em><br /> <em class="quotelev1">> documented, efficient and expressive. He uses extra features of RELAX NG </em><br /> <em class="quotelev1">> or other ISO DSDL standards to manage his documents to a high standard. </em><br /> <em class="quotelev1">> He is, you may say, non-conformant. He cannot show his "workings" </em><br /> <em class="quotelev1">> in the approved form, and gets an F. </em><br /> Students are customers these days and thus rarely receive Fs. He would <br /> be given some credit for his obvious understanding of the system. I'd <br /> give him a C- or a D. :-) <br /> <em class="quotelev1">> HOWEVER, when you get Wohann's document, </em><br /> <em class="quotelev1">> it validates fine against tei_all. If he could be bothered, he could write </em><br /> <em class="quotelev1">> an ODD equivalent of his hand-crafted schema, and the document would </em><br /> <em class="quotelev1">> validate against that too. The document validates against _many_ schemas, </em><br /> <em class="quotelev1">> and breaks no TEI semantic or syntactic rules. It adds no new elements </em><br /> <em class="quotelev1">> or does any renaming, or breaks any models. </em><br /> Sounds like the document is conformant, even if his schema is not a <br /> conformantly created one. <br /> <em class="quotelev1">> So two questions: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> a) Can Wohann put the "TEI Conformant" badge on his web site, by the </em><br /> <em class="quotelev1">> fiction </em><br /> <em class="quotelev1">> that his ODD is the implicit tei_all? Even though he and all his workers </em><br /> <em class="quotelev1">> use the evil little hand-crafted schema, and the document contains a PI </em><br /> <em class="quotelev1">> linking to that? </em><br /> Yes. Wohann's documents are conformant with reference to the tei_all ODD <br /> and schemas. This situation is also true of all TEI Pure Subset <br /> Schemas... they do not *need* to provide their ODD because they can <br /> claim they are using tei_all (or another existing subset like tei_lite <br /> if it contains the entirety of their subset). They are encouraged to <br /> provide their ODD as documentation and use ODD to customise the TEI to <br /> constrain it to their purposes. But this is like taking your <br /> non-namespaced non-conformant documents and then adding in the namespace <br /> -- Conformance has nothing to say on how your documents got to the state <br /> they are in, simply whether they are conformant at the point or not. <br /> <em class="quotelev1">> b) do we encourage/support/allow Wohann's working method by generating </em><br /> <em class="quotelev1">> the schemas for him? </em><br /> I'm ambivalent about that. If it is a pain to do, then let's not, <br /> knowing Wohann's skills I'm sure he could do this himself, if it isn't a <br /> pain to do this, then I don't see that doing so really affects the <br /> conformance message. There are always other non-conformant ways to do <br /> things which may end up in giving you Conformant documents. <br /> <em class="quotelev1">> Or I am just going the mulberry bush again? </em><br /> Always useful to check for needed pruning. <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 07:49:00 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 08:07:00 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 13:07:00 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620B440.604@oucs.ox.ac.uk> Message-ID: <4620C3E4.2070206@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 13:07:00 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> no, I am saying that Johann might prefer to see it this </em><br /> <em class="quotelev1">> way, to avoid the chop and change of namespaces </em><br /> <em class="quotelev1">> every other line. His choice. </em><br /> Oh that's fine then. So he produces a non-conformant document which he <br /> can then transform back at some stage should he desire. <br /> <em class="quotelev1">> yes, whichever way you do it, conformant documents </em><br /> <em class="quotelev1">> are involved. the distinction is between conformant </em><br /> <em class="quotelev1">> and interchangeable, ie where the <altIdent>s have </em><br /> <em class="quotelev1">> been reversed. </em><br /> Yes, I see what you mean. <br /> <em class="quotelev1">> all conformant documents have </em><br /> <em class="quotelev1">> the potential to be canonical as well, after a transformation. </em><br /> If canonical only means that renamings are reversed, then this is true. <br /> But remember there will still be all those extensions in the <br /> user-defined namespace(s) which can't be transformed back (reliably) to <br /> PureTEI (tm). <br /> <p><em class="quotelev1">> So how about Roma shows you a new paradigm? </em><br /> <em class="quotelev1">> Instead of "renaming div1 to section", it </em><br /> <em class="quotelev1">> only lets you add a new element called "section"; </em><br /> <em class="quotelev1">> however, when you create it, you have the short-form </em><br /> <em class="quotelev1">> option of saying "I want it to be a *move* of div1, </em><br /> <em class="quotelev1">> but I want to change the name, </em><br /> <em class="quotelev1">> the description and the examples". So you get </em><br /> <em class="quotelev1">> the "edit element" screen, but with no chance </em><br /> <em class="quotelev1">> to change classes or content model; you are </em><br /> <em class="quotelev1">> *forced* to use a new namespace. </em><br /> This seems reasonable to me. Would I also have a short-form of saying I <br /> want my element not to be a *move* but a *copy*? I.e. given me the same <br /> content model/class affiliations as element X? <br /> <em class="quotelev1">> This removes the possibility in webRoma (command </em><br /> <em class="quotelev1">> line Roma is just an ODD processor, so not </em><br /> <em class="quotelev1">> relevant) of doing simple renames. Internally, </em><br /> <em class="quotelev1">> we manage the "move of div1to section" as </em><br /> <em class="quotelev1">> a change of div1 and an <altIdent>. </em><br /> Seems reasonable. <br /> <em class="quotelev1">> I am groping here towards a work plan </em><br /> <em class="quotelev1">> for rewriting Roma. </em><br /> Yes, I recognise that, and think there will be a lot more work here than <br /> perhaps originally conceived. <br /> <em class="quotelev1">> If we can make the use </em><br /> <em class="quotelev1">> of <altIdent> much harder, that strange </em><br /> <em class="quotelev1">> case which bothers us arises less often; either </em><br /> <em class="quotelev1">> way, a new namespace for a moved or new </em><br /> <em class="quotelev1">> element is mandatory; and the algorithm for that </em><br /> <em class="quotelev1">> is that we start off forcing you to think one up, </em><br /> <em class="quotelev1">> and thereafter propose the same as you said </em><br /> <em class="quotelev1">> last time. </em><br /> Sounds good to me, I'm sure Johannes would be happy with that, don't <br /> know about Wohann though, but he's doing his own thing. <br /> <em class="quotelev1">> Whether newly added attributes are forced to a </em><br /> <em class="quotelev1">> namespace, as opposed to the default null one, </em><br /> <em class="quotelev1">> is tricky. I am personally inclined to think </em><br /> <em class="quotelev1">> that this is <soCalled>political </em><br /> <em class="quotelev1">> correctness gone mad</soCalled>. </em><br /> Current consensus seems to be that they should so they don't collide <br /> with existing elements, etc. <br /> <em class="quotelev1">> I still believe that we have an option in Roma </em><br /> <em class="quotelev1">> (maybe just on the desktop version for advanced </em><br /> <em class="quotelev1">> use) which ignores the <altIdent>s </em><br /> <em class="quotelev1">> and generates a script to reverse them and </em><br /> <em class="quotelev1">> <equiv>s you have stuck in, probably by hand, </em><br /> <em class="quotelev1">> in documents. </em><br /> That would be nice. (But 'nice' taking less priority than other Roma <br /> development I think.) <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 07:59:53 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 08:33:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 13:33:32 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620C155.1080907@oucs.ox.ac.uk> Message-ID: <4620CA1C.4080502@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 13:33:32 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I feel this is optional but nice -- does it take much effort to </em><br /> <em class="quotelev1">> produce them? Yes they can be used as you describe below, but I don't </em><br /> <em class="quotelev1">> think that is reason to no produce them if this is done automatically. </em><br /> The modules were, until recently, what we regarded <br /> as the primary output of the Guidelines. The "compiled <br /> schema" came later. So, yes, the work is all done. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm ambivalent about that. If it is a pain to do, then let's not, </em><br /> <em class="quotelev1">> knowing Wohann's skills I'm sure he could do this himself, </em><br /> when someone writes the first non-Consortium ODD processor, <br /> oh frabjous day. <br /> So my critical question is whether the form of the <br /> generated schema and DTD fragments is normative <br /> or merely indicative. Can I break the format <br /> at P5.1? <br /> In case anyone is wondering, it really is not that obvious <br /> what to model in the RELAX NG schemas. CUrrently <br /> I say <br /> foo = foo.content, foo.attributes <br /> because that lets you say <br /> foo.attributes = empty <br /> but I could equally say <br /> foo = foo.content, attribute bar ( text) <br /> and miss out the intermediate stage. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 08:34:13 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 08:39:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 13:39:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620C3E4.2070206@oucs.ox.ac.uk> Message-ID: <4620CB99.7090207@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 13:39:53 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This seems reasonable to me. Would I also have a short-form of saying </em><br /> <em class="quotelev1">> I want my element not to be a *move* but a *copy*? I.e. given me the </em><br /> <em class="quotelev1">> same content model/class affiliations as element X? </em><br /> I'd regard it as a luxury, but not that hard to do, I suppose. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> I am groping here towards a work plan </em><br /> <em class="quotelev2">>> for rewriting Roma. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yes, I recognise that, and think there will be a lot more work here </em><br /> <em class="quotelev1">> than perhaps originally conceived. </em><br /> too right. its going to be a major pain. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Whether newly added attributes are forced to a </em><br /> <em class="quotelev2">>> namespace, as opposed to the default null one, </em><br /> <em class="quotelev2">>> is tricky. I am personally inclined to think </em><br /> <em class="quotelev2">>> that this is <soCalled>political </em><br /> <em class="quotelev2">>> correctness gone mad</soCalled>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Current consensus seems to be that they should so they don't collide </em><br /> <em class="quotelev1">> with existing elements, etc. </em><br /> how can attributes collide with elements? <br /> it seems to me that in XML world attributes are regarded differently, <br /> for instance in not being followed by default in XSLT. So <br /> I'd regard it as plausible to leave them alone, and let all <br /> attributes (including TEI ones) wallow in the default null mudpool <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 08:39:57 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 08:57:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 13:57:51 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620CA1C.4080502@oucs.ox.ac.uk> Message-ID: <4620CFCF.5030207@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 13:57:51 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> when someone writes the first non-Consortium ODD processor, </em><br /> <em class="quotelev1">> oh frabjous day. </em><br /> I'm not holding my breath. <br /> <em class="quotelev1">> So my critical question is whether the form of the </em><br /> <em class="quotelev1">> generated schema and DTD fragments is normative </em><br /> <em class="quotelev1">> or merely indicative. Can I break the format </em><br /> <em class="quotelev1">> at P5.1? </em><br /> I think you can, they are an output and just as we are changing the <br /> organisation of the guidelines (which will change again if we add a <br /> chapter in P5.1) then other outputs can change. We're committed to <br /> avoiding breaking backwards compatibility in the recommendations the <br /> guidelines provide (etc.), but if the form of the generated schemas <br /> change from one version to the next, I think only Wohann would complain. <br /> <em class="quotelev1">> In case anyone is wondering, it really is not that obvious </em><br /> <em class="quotelev1">> what to model in the RELAX NG schemas. CUrrently </em><br /> <em class="quotelev1">> I say </em><br /> <em class="quotelev1">> foo = foo.content, foo.attributes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> because that lets you say </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> foo.attributes = empty </em><br /> Which seems like a good thing to me. <br /> <p><em class="quotelev1">> but I could equally say </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> foo = foo.content, attribute bar ( text) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> and miss out the intermediate stage. </em><br /> But loses you the indirection and just doesn't seem to be a good thing. <br /> Does not creating this intermediate stage save lots of work? What is <br /> gained by it? <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 08:50:45 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 09:03:42 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 14:03:42 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620CB99.7090207@oucs.ox.ac.uk> Message-ID: <4620D12E.8060309@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 14:03:42 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> I'd regard it as a luxury, but not that hard to do, I suppose. </em><br /> True, further down the list than the other nice things. <br /> <em class="quotelev1">> too right. its going to be a major pain. </em><br /> Yup. <br /> <em class="quotelev2">>> Current consensus seems to be that they should so they don't collide </em><br /> <em class="quotelev2">>> with existing elements, etc. </em><br /> <em class="quotelev1">> how can attributes collide with elements? </em><br /> erm, typo, I meant attributes. I.e. we don't want someone creating a <br /> new attribute 'where' if possible because the TEI already defines one <br /> (on <move>), and we want to avoid confusion if possible. Obviously <br /> @where added to tei:div and @where on tei:move are different, but since <br /> this is an addition of something new to the TEI, it shouldn't be in the <br /> the TEI namespace so should be @mynew:where.<!--nospam--> <br /> <em class="quotelev1">> it seems to me that in XML world attributes are regarded differently, </em><br /> <em class="quotelev1">> for instance in not being followed by default in XSLT. So </em><br /> <em class="quotelev1">> I'd regard it as plausible to leave them alone, and let all </em><br /> <em class="quotelev1">> attributes (including TEI ones) wallow in the default null mudpool </em><br /> I think I need to look into that more before I can comment with any <br /> assurance. <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 08:56:35 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 09:09:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 14:09:01 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620CFCF.5030207@oucs.ox.ac.uk> Message-ID: <4620D26D.7050706@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 14:09:01 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> but I could equally say </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> foo = foo.content, attribute bar ( text) </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> and miss out the intermediate stage. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> But loses you the indirection and just doesn't seem to be a good </em><br /> <em class="quotelev1">> thing. Does not creating this intermediate stage save lots of work? </em><br /> <em class="quotelev1">> What is gained by it? </em><br /> neither gain nor loss. I just have to decide when I meet an attList whether <br /> I <br /> - make a new object with the attributes and then reference it <br /> - put the attributes right here <br /> Is this my decision as an ODD programmer, or will the Guidelines <br /> tell me what to do? <br /> James, if I install Debian on my slug, will it attempt to <br /> repartition/reformat my disk? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 09:09:04 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sat Apr 14 11:47:44 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 14 Apr 2007 16:47:44 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620D12E.8060309@oucs.ox.ac.uk> Message-ID: <4620F7A0.4040906@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou's Laptop <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 16:47:44 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> erm, typo, I meant attributes. I.e. we don't want someone creating a </em><br /> <em class="quotelev1">> new attribute 'where' if possible because the TEI already defines one </em><br /> <em class="quotelev1">> (on <move>), and we want to avoid confusion if possible. Obviously </em><br /> <em class="quotelev1">> @where added to tei:div and @where on tei:move are different, but </em><br /> <em class="quotelev1">> since this is an addition of something new to the TEI, it shouldn't be </em><br /> <em class="quotelev1">> in the the TEI namespace so should be @mynew:where.<!--nospam--> </em><br /> Just to be pernickety for a moment (moi!): attribute names on different <br /> elements in the same namespace don't have to be distinct per XML. The <br /> @where on tei:foo and the @where on tei:bar can have completely <br /> different semantics and datatypes. TEI *recommended practice* however <br /> is that they ought to be the same. And if you put @myspace:where on <br /> tei:foo it *has* to be the same thing as say a @myspace:where on <br /> tei:bar, because there's no way of saying otherwise. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 11:47:51 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 11:53:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 16:53:36 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F7A0.4040906@computing-services.oxford.ac.uk> Message-ID: <4620F900.8060005@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 16:53:36 +0100</span><br /> </address> Lou's Laptop wrote: <br /> <em class="quotelev1">> Just to be pernickety for a moment (moi!): attribute names on </em><br /> <em class="quotelev1">> different elements in the same namespace don't have to be distinct per </em><br /> <em class="quotelev1">> XML. The @where on tei:foo and the @where on tei:bar can have </em><br /> <em class="quotelev1">> completely different semantics and datatypes. TEI *recommended </em><br /> <em class="quotelev1">> practice* however is that they ought to be the same. </em><br /> yet we don't stick to this in our own Guidelines, as I just found to my cost <br /> (check out uses of eg @value).<!--nospam--> <br /> <em class="quotelev1">> And if you put @myspace:where on tei:foo it *has* to be the same </em><br /> <em class="quotelev1">> thing as say a @myspace:where on tei:bar, because there's no way of </em><br /> <em class="quotelev1">> saying otherwise. </em><br /> I lost the will to live during this sentence. can you say it more slowly? <br /> <p><p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 11:53:39 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sat Apr 14 12:48:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 14 Apr 2007 17:48:54 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F900.8060005@oucs.ox.ac.uk> Message-ID: <462105F6.6070707@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou's Laptop <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 17:48:54 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Lou's Laptop wrote: </em><br /> <em class="quotelev2">>> Just to be pernickety for a moment (moi!): attribute names on </em><br /> <em class="quotelev2">>> different elements in the same namespace don't have to be distinct </em><br /> <em class="quotelev2">>> per XML. The @where on tei:foo and the @where on tei:bar can have </em><br /> <em class="quotelev2">>> completely different semantics and datatypes. TEI *recommended </em><br /> <em class="quotelev2">>> practice* however is that they ought to be the same. </em><br /> <em class="quotelev1">> yet we don't stick to this in our own Guidelines, as I just found to </em><br /> <em class="quotelev1">> my cost </em><br /> <em class="quotelev1">> (check out uses of eg @value).<!--nospam--> </em><br /> Such cases should be hunted down and extirpated with extreme prejeducie <br /> then! <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> And if you put @myspace:where on tei:foo it *has* to be the same </em><br /> <em class="quotelev2">>> thing as say a @myspace:where on tei:bar, because there's no way of </em><br /> <em class="quotelev2">>> saying otherwise. </em><br /> <em class="quotelev1">> I lost the will to live during this sentence. can you say it more slowly? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> the way tony puts it is that all explicitly namespaced attributes are <br /> global because you cannot necessarily tell what elements they are <br /> defined for. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 12:49:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 12:55:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 17:55:10 +0100 Subject: [tei-council] incompatible datatypes for same-named attributes Message-ID: <4621076E.1090407@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 17:55:10 +0100</span><br /> </address> There are 32 occasions in the TEI where two attributes of the same <br /> name have different datatypes (leaving aside semantics). <br /> I know we went all over these some time back and decided <br /> some variations were inevitable, but <br /> some are, I suspect, oversights which we could now correct. <br /> There are two types of situation: <br /> a) Surely @type should consistently enumerated or word? (though the <br /> effect is the same, in practice) <br /> b) something niche like @cRef must surely mean the same in all 4 <br /> places? simply an error <br /> on ptr and ref. similarly, @resp is such a characeristic TEI attribute, <br /> it must surely <br /> behave consistently? <br /> Is this an important matter? It seems so to me. <br /> Shall I add a specific ticket to trac and assign to (Syd?)? <br /> BTW, Syd, note the remaining "targets". is that deliberate, <br /> or a smidgeon of unfinished business? <br /> active: data.pointer: relation <br /> active: data.enumerated: interaction <br /> cRef: data.pointer: gloss <br /> cRef: data.pointer: term <br /> cRef: data.word: ptr <br /> cRef: data.word: ref <br /> degree: data.probability: certainty <br /> degree: data.count: node <br /> degree: data.certainty: purpose <br /> extent: data.word: gap <br /> extent: data.enumerated: orth <br /> extent: data.enumerated: pron <br /> extent: data.word: damage <br /> extent: data.word: space <br /> form: data.enumerated: objectDesc <br /> from: data.temporal.w3c: att.datable.w3c <br /> from: data.word: locus <br /> from: data.pointer: span <br /> from: data.pointer: app <br /> from: data.pointer: arc <br /> ident: data.language: language <br /> ident: data.name: att.identified <br /> level: data.numeric: sense <br /> level: data.code: langKnown <br /> ink: data.enumerated: hand <br /> ink: data.enumerated: handShift <br /> name: data.namespace: namespace <br /> name: data.name: equiv <br /> name: data.name: f <br /> name: data.word: vLabel <br /> name: data.enumerated: relation <br /> name: data.name: fDecl <br /> name: data.word: attRef <br /> new: data.enumerated: shift <br /> new: data.code: handShift <br /> notation: data.enumerated: pron <br /> notation: data.code: formula <br /> ord: data.enumerated: tree <br /> ord: data.truthValue: root <br /> ord: data.truthValue: iNode <br /> passive: data.pointer: relation <br /> passive: data.enumerated: interaction <br /> perf: data.pointer: move <br /> perf: data.enumerated: tech <br /> reg: data.code: country <br /> reg: data.code: nationality <br /> resp: data.pointer: att.editLike <br /> resp: data.pointer: att.interpLike <br /> resp: data.pointer: note <br /> resp: data.pointer: respons <br /> resp: data.code: hand <br /> resp: data.code: handShift <br /> resp: data.pointer: space <br /> resp: data.pointer: att.textCritical <br /> resp: data.pointer: witDetail <br /> role: data.enumerated: att.tableDecoration <br /> role: data.enumerated: editor <br /> role: data.word: person <br /> role: data.code: personGrp <br /> scheme: data.pointer: keywords <br /> scheme: data.pointer: classCode <br /> scheme: data.pointer: catRef <br /> scheme: data.enumerated: locus <br /> scheme: data.pointer: occupation <br /> scheme: data.pointer: socecStatus <br /> scheme: data.enumerated: att <br /> scheme: data.enumerated: gi <br /> scheme: data.enumerated: tag <br /> scribe: data.name: handNote <br /> scribe: data.code: hand <br /> script: data.code: writing <br /> script: data.name: handNote <br /> size: data.word: personGrp <br /> size: data.count: graph <br /> source: data.pointer: normalization <br /> source: data.word: supplied <br /> start: data.pointer: att.timed <br /> start: data.name: schemaSpec <br /> target: data.pointer: catRef <br /> target: data.pointer: gloss <br /> target: data.pointer: term <br /> target: data.pointer: ptr <br /> target: data.pointer: ref <br /> target: data.pointer: note <br /> target: data.pointer: att.ptrLike.form <br /> target: data.pointer: certainty <br /> target: data.pointer: respons <br /> target: data.pointer: witDetail <br /> target: data.pointer: specGrpRef <br /> targets: data.pointer: locus <br /> targets: data.pointer: link <br /> targets: data.pointer: join <br /> targets: data.pointer: alt <br /> to: data.temporal.w3c: att.datable.w3c <br /> to: data.word: locus <br /> to: data.pointer: span <br /> to: data.pointer: app <br /> to: data.pointer: arc <br /> type: data.enumerated: att.authorialIntervention <br /> type: data.enumerated: att.divLike <br /> type: data.enumerated: att.interpLike <br /> type: data.enumerated: att.segLike <br /> type: data.word: att.typed <br /> type: data.enumerated: teiHeader <br /> type: data.enumerated: idno <br /> type: data.enumerated: fsdDecl <br /> type: data.enumerated: metDecl <br /> type: data.enumerated: distinct <br /> type: data.enumerated: q <br /> type: data.enumerated: name <br /> type: data.enumerated: rs <br /> type: data.enumerated: num <br /> type: data.enumerated: measure <br /> type: data.enumerated: abbr <br /> type: data.enumerated: list <br /> type: data.enumerated: head <br /> type: data.enumerated: note <br /> type: data.enumerated: divGen <br /> type: data.enumerated: title <br /> type: data.enumerated: biblScope <br /> type: data.enumerated: stage <br /> type: data.enumerated: titlePage <br /> type: data.enumerated: titlePart <br /> type: data.enumerated: move <br /> type: data.enumerated: sound <br /> type: data.enumerated: writing <br /> type: data.enumerated: att.entryLike <br /> type: data.enumerated: form <br /> type: data.enumerated: orth <br /> type: data.enumerated: gram <br /> type: data.enumerated: iType <br /> type: data.word: colloc <br /> type: data.enumerated: usg <br /> type: data.word: lbl <br /> type: data.enumerated: xr <br /> type: data.word: re <br /> type: data.enumerated: oRef <br /> type: data.enumerated: oVar <br /> type: data.enumerated: dimensions <br /> type: data.word: att.pointing <br /> type: data.enumerated: fs <br /> type: data.name: restore <br /> type: data.enumerated: damage <br /> type: data.enumerated: fw <br /> type: data.enumerated: att.textCritical <br /> type: data.enumerated: app <br /> type: data.word: witDetail <br /> type: data.enumerated: persName <br /> type: data.enumerated: geogName <br /> type: data.enumerated: orgName <br /> type: data.enumerated: orgTitle <br /> type: data.enumerated: orgType <br /> type: data.enumerated: orgDivn <br /> type: data.enumerated: relation <br /> type: data.enumerated: graph <br /> type: data.enumerated: node <br /> type: data.enumerated: forest <br /> type: data.enumerated: forestGrp <br /> type: data.enumerated: derivation <br /> type: data.enumerated: domain <br /> type: data.enumerated: preparedness <br /> type: data.enumerated: purpose <br /> type: data.enumerated: fsDecl <br /> value: data.temporal.w3c: att.dateTime.w3c <br /> value: data.word: metSym <br /> value: data.numeric: num <br /> value: data.temporal.w3c: docDate <br /> value: data.truthValue: binary <br /> value: data.word: symbol <br /> value: data.numeric: numeric <br /> value: data.count: age <br /> value: data.sex: sex <br /> value: data.pointer: node <br /> value: data.pointer: root <br /> value: data.pointer: iNode <br /> value: data.pointer: leaf <br /> value: data.pointer: eTree <br /> value: data.pointer: triangle <br /> value: data.pointer: eLeaf <br /> version: data.word: att.translatable <br /> version: data.numeric: unicodeName <br /> wit: data.pointer: att.rdgPart <br /> wit: data.pointer: att.textCritical <br /> wit: data.code: witDetail <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 12:55:14 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 13:01:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 18:01:08 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <462105F6.6070707@computing-services.oxford.ac.uk> Message-ID: <462108D4.6000406@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 18:01:08 +0100</span><br /> </address> Lou's Laptop wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Such cases should be hunted down and extirpated with extreme </em><br /> <em class="quotelev1">> prejeducie then! </em><br /> I bet you are sorry you said that after you read my later mail showing how <br /> many there are... never mind, you don't want to watch Dr Who anyway. <br /> <em class="quotelev1">> the way tony puts it is that all explicitly namespaced attributes are </em><br /> <em class="quotelev1">> global because you cannot necessarily tell what elements they are </em><br /> <em class="quotelev1">> defined for. </em><br /> is that the same Tony who lied about the war? this is lie too. An <br /> attribute is defined in the <br /> context of an element, or a group of elements. Whether the attribute is <br /> in a namespace <br /> is irrelevant. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 13:01:13 EDT</span> </div> From Syd_Bauman at Brown.edu Sat Apr 14 13:07:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 14 Apr 2007 13:07:35 -0400 Subject: [tei-council] incompatible datatypes for same-named attributes In-Reply-To: <4621076E.1090407@oucs.ox.ac.uk> Message-ID: <17953.2647.641184.464887@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 13:07:35 -0400</span><br /> </address> <em class="quotelev1">> a) Surely @type should consistently enumerated or word? (though the </em><br /> <em class="quotelev1">> effect is the same, in practice) </em><br /> Yes, type= should always be data.enumerated. <br /> <p><em class="quotelev1">> b) something niche like @cRef must surely mean the same in all 4 </em><br /> <em class="quotelev1">> places? simply an error </em><br /> Yes, I think so, but would have to check <br /> <p><em class="quotelev1">> Is this an important matter? It seems so to me. Shall I add a </em><br /> <em class="quotelev1">> specific ticket to trac and assign to (Syd?)? </em><br /> Yes, it is important, but since it's error-checking and not new <br /> stuff, it should be deferred until after Berlin. <br /> <p><em class="quotelev1">> BTW, Syd, note the remaining "targets". is that deliberate, or a </em><br /> <em class="quotelev1">> smidgeon of unfinished business? </em><br /> Completely deliberate, and importantly so. (A targets= attribute <br /> requires 2 or more pointers as its value.) <br /> <p>In great haste ... <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 13:07:38 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 13:12:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 18:12:50 +0100 Subject: [tei-council] incompatible datatypes for same-named attributes In-Reply-To: <17953.2647.641184.464887@emt.wwp.brown.edu> Message-ID: <46210B92.4020508@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 18:12:50 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> BTW, Syd, note the remaining "targets". is that deliberate, or a </em><br /> <em class="quotelev2">>> smidgeon of unfinished business? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Completely deliberate, and importantly so. (A targets= attribute </em><br /> <em class="quotelev1">> requires 2 or more pointers as its value.) </em><br /> <em class="quotelev1">> </em><br /> isnt that catered for with our new list and its minOccurs/maxOccurs? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 13:12:54 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 17:20:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 22:20:52 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620D26D.7050706@oucs.ox.ac.uk> Message-ID: <462145B4.1000203@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 22:20:52 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> neither gain nor loss. I just have to decide when I meet an attList whether </em><br /> <em class="quotelev1">> I </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> - make a new object with the attributes and then reference it </em><br /> <em class="quotelev1">> - put the attributes right here </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Is this my decision as an ODD programmer, or will the Guidelines </em><br /> <em class="quotelev1">> tell me what to do? </em><br /> I think that is an implementation thing, and thus up to you. <br /> <em class="quotelev1">> James, if I install Debian on my slug, will it attempt to </em><br /> <em class="quotelev1">> repartition/reformat my disk? </em><br /> I attached two 500GB drives to mine (one on a usb hub). Format and/or <br /> partition the drives as you might desire on a different machine first. <br /> (Otherwise it might hang being out of memory.) Obviously it will need <br /> somewhere to install root, but during the install you can simple choose <br /> to use the existing partitions rather than reformat them. (i.e. <br /> manually partitioning, not guided.) (Apologies to the rest of council <br /> who won't understand this...google for "NSLU2 Debian" if you are <br /> interested.) <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 17:13:47 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 14 17:23:34 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 22:23:34 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F7A0.4040906@computing-services.oxford.ac.uk> Message-ID: <46214656.7040802@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 22:23:34 +0100</span><br /> </address> Lou's Laptop wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> erm, typo, I meant attributes. I.e. we don't want someone creating a </em><br /> <em class="quotelev2">>> new attribute 'where' if possible because the TEI already defines one </em><br /> <em class="quotelev2">>> (on <move>), and we want to avoid confusion if possible. Obviously </em><br /> <em class="quotelev2">>> @where added to tei:div and @where on tei:move are different, but </em><br /> <em class="quotelev2">>> since this is an addition of something new to the TEI, it shouldn't be </em><br /> <em class="quotelev2">>> in the the TEI namespace so should be @mynew:where.<!--nospam--> </em><br /> <em class="quotelev1">> Just to be pernickety for a moment (moi!): attribute names on different </em><br /> <em class="quotelev1">> elements in the same namespace don't have to be distinct per XML. The </em><br /> <em class="quotelev1">> @where on tei:foo and the @where on tei:bar can have completely </em><br /> <em class="quotelev1">> different semantics and datatypes. TEI *recommended practice* however </em><br /> <em class="quotelev1">> is that they ought to be the same. And if you put @myspace:where on </em><br /> <em class="quotelev1">> tei:foo it *has* to be the same thing as say a @myspace:where on </em><br /> <em class="quotelev1">> tei:bar, because there's no way of saying otherwise. </em><br /> Yup, I understand and agree with all of that. So by suggesting that <br /> people use namespaces for their new attributes we encourage the good <br /> practice that TEI already follows of not having @myspace:where mean <br /> something on one element and @myspace:where mean something else on <br /> another element. <br /> -James <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 17:16:27 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 17:32:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 22:32:11 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46214656.7040802@oucs.ox.ac.uk> Message-ID: <4621485B.6020809@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 14 Apr 2007 22:32:11 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yup, I understand and agree with all of that. So by suggesting that </em><br /> <em class="quotelev1">> people use namespaces for their new attributes we encourage the good </em><br /> <em class="quotelev1">> practice that TEI already follows of not having @myspace:where mean </em><br /> <em class="quotelev1">> something on one element and @myspace:where mean something else on </em><br /> <em class="quotelev1">> another element. </em><br /> what if add the TEI-consonant @type to an element which doesnt have it <br /> already? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 14 2007 - 17:32:16 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sun Apr 15 05:32:13 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 15 Apr 2007 10:32:13 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4621485B.6020809@oucs.ox.ac.uk> Message-ID: <4621F11D.9080703@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 10:32:13 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Yup, I understand and agree with all of that. So by suggesting that </em><br /> <em class="quotelev2">>> people use namespaces for their new attributes we encourage the good </em><br /> <em class="quotelev2">>> practice that TEI already follows of not having @myspace:where mean </em><br /> <em class="quotelev2">>> something on one element and @myspace:where mean something else on </em><br /> <em class="quotelev2">>> another element. </em><br /> <em class="quotelev1">> what if add the TEI-consonant @type to an element which doesnt have it </em><br /> <em class="quotelev1">> already? </em><br /> I believe consensus was that this was an 'unclean' change, and thus <br /> element and attribute are put in a user-defined namespace. <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 05:25:08 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 16:00:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 21:00:59 +0100 Subject: [tei-council] question about <char> Message-ID: <4622847B.8020204@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 21:00:59 +0100</span><br /> </address> The description of the <char> element includes the following example: <br /> <p><char xml:id="circledU4EBA"> <br /> <charName>CIRCLED IDEOGRAPH 4EBA</charName> <br /> <charProp> <br /> <unicodeName>character-decomposition-mapping</unicodeName> <br /> <value>circle</value> <br /> </charProp> <br /> <charProp> <br /> <localName>daikanwa</localName> <br /> <value>36</value>is a standard mapping why is it using a <g> element? <br /> What's wrong with just using <br /> </charProp> <br /> <mapping type="standard"> <br /> <g ref="#U4EBA">???</g> <br /> </mapping> <br /> </char> <br /> I am puzzled by the <g> within the <mapping>. If this is a standard <br /> mapping why is it using a <g> element? What's wrong with just using the <br /> character, or an NCR like this? <br /> <mapping type="standard"> <br /> 人 <br /> </mapping> <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 16:01:04 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 16:34:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 21:34:08 +0100 Subject: [tei-council] @scheme datatype Message-ID: <46228C40.70408@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 21:34:08 +0100</span><br /> </address> The scheme attribute is variously used with more or less the same <br /> semantics to give a short name for some external classification <br /> scheme, values from which are being deployed in a TEI document <br /> It has the datatype data.pointer on <keywords>, <classCode>, <catRef>, <br /> <occupation> and <socecStatus>, and the datatype data.enumerated on <br /> <locus>, <att>, <gi>,<tag> <br /> This inconsistency seems undesirable. Changing them all to data.pointer <br /> means that they can provide URLs for the schemes concerned which seems <br /> more useful than encouraging people to go on using arbitrary opaque <br /> codes like "LCSH" (for which now read http://classificationweb.net). <br /> Dissenters please speak up! <br /> <p><p><p><p><p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 16:34:12 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 17:01:15 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 22:01:15 +0100 Subject: [tei-council] @source again Message-ID: <4622929B.30301@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 22:01:15 +0100</span><br /> </address> The source attribute on <att>, <gi>, and <tag> seems to me ripe for the <br /> chop. It duplicates a function better performed by namespaces (as the <br /> descriptive prose in the relevant tagdocs already points out)... I think <br /> it has survived so long solely for reasons of historical sentiment. <br /> Unless anyone objects therefore, I propose to remove it. You have 48 <br /> hours to object, starting now! <br /> <p> <br /> <p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 17:01:19 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 17:10:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 15 Apr 2007 22:10:03 +0100 Subject: [tei-council] @source again In-Reply-To: <4622929B.30301@computing-services.oxford.ac.uk> Message-ID: <462294AB.9090105@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 22:10:03 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> The source attribute on <att>, <gi>, and <tag> seems to me ripe for </em><br /> <em class="quotelev1">> the chop. It duplicates a function better performed by namespaces (as </em><br /> <em class="quotelev1">> the descriptive prose in the relevant tagdocs already points out)... I </em><br /> <em class="quotelev1">> think it has survived so long solely for reasons of historical sentiment. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Unless anyone objects therefore, I propose to remove it. You have 48 </em><br /> <em class="quotelev1">> hours to object, starting now! </em><br /> I assume you mean @scheme.<!--nospam--> <br /> what if I want to say <gi scheme="unknown">? <gi scheme="TEI"> (any TEI)? <br /> I don't care much, but schema and namespace are <br /> not _quite_ the same. <br /> I can't imagine many tears if you drop it. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 17:10:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 17:16:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 15 Apr 2007 22:16:13 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <46228C40.70408@computing-services.oxford.ac.uk> Message-ID: <4622961D.4030704@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 22:16:13 +0100</span><br /> </address> what would @schema on <locus> point to? <br /> I see we have no example of its use :-} <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 17:16:16 EDT</span> </div> From Syd_Bauman at Brown.edu Sun Apr 15 17:29:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 17:29:23 -0400 Subject: [tei-council] @scheme datatype In-Reply-To: <46228C40.70408@computing-services.oxford.ac.uk> Message-ID: <17954.39219.955701.862122@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 17:29:23 -0400</span><br /> </address> If it's going to be a URL on <att>, <gi>, and <tag>, shouldn't it be <br /> the namespace of the tagset being used? And if so, shouldn't it be <br /> namespace= or ns= isnstead of scheme=? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 17:29:27 EDT</span> </div> From Syd_Bauman at Brown.edu Sun Apr 15 18:44:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 18:44:20 -0400 Subject: [tei-council] quotation marks, quotes, etc. Message-ID: <17954.43716.870610.6618@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 18:44:20 -0400</span><br /> </address> I'd like to address Trac ticket #304. <br /> Passages offset by quotation marks in the source may be encoded as <br /> a specific type of feature, e.g. mentioned not used (<mentioned>), <br /> authorial distancing (<soCalled>), quotation (<quote>), speech or <br /> thought (<q>); or may be encoded as "taken from elsewhere, details <br /> unknown or unsaid" (<q>). <br /> The problem here is that <q> is overloaded, serving two purposes. <br /> Need to develop a proposal to leave <q> as a generic (perhaps even <br /> more generic?) element, and introduce a new element for the "speech <br /> or thought" function. <br /> I think the way forward here is pretty clear, and Lou & I agree to <br /> the basic game-plan sketched out above. But there are still a couple <br /> of potentially controversial issues. So here is a slightly more <br /> detailed proposal, followed by questions. <br /> * Retain <quote> as it is: passage attributed to some agency external <br /> to the text, i.e. a quotation from a written source. Remains a <br /> member of model.quoteLike, also a member of new model.quoted. <br /> * New element <quo> for direct speech or thought. (I.e., not a <br /> quotation of a written source, not authorial distancing, not an <br /> example in a dictionary entry.) A member of new model.quoted. <br /> * Change semantics of <q> to be a bit more broad, basically covering <br /> anything that was indicated in the source with quotation marks, but <br /> about which the encoder does not wish to say more. Essentially <br /> syntactic sugar for <hi rend="quotation marks">. A member of <br /> model.hiLike. <br /> * <cit> remains as is, becomes a member of new model.quoted <br /> This system has the advantage of a clean break between quoting of <br /> passages external to the text and direct speech or thought of, e.g., <br /> a character. But it also permits <q> to be used quite loosely, which <br /> is good, because it reflects what lots of projects already do. <br /> That is, <br /> - quotation could be encoded with <quote> or <q> <br /> - that which a character speaks could be encoded with <quo> or <q> <br /> - authorial distance could be encoded with <soCalled> or <q> <br /> - words mentioned not used could be encoded with <mentioned> or <q> <br /> - dictionary examples could be encoded with <quote> or <q> (what if <br /> they are contrived?) <br /> - a filename that appeared in quotes could be encoded as <name> or <br /> <q> <br /> - a filepath that appeared in quotes could be encoded as <ident> or <br /> <q> <br /> - a newly introduced term could be encoded as <term> or <q> <br /> You can well imagine projects that encode all this stuff with <q> on <br /> the first pass (because it is easier and thus less expensive), and <br /> then on a second pass convert to more nuanced encoding for those <br /> aspects they care about, and not others. <br /> Questions: <br /> * Does anyone strongly object to the basic idea? <br /> * Is the name <quo> OK? (If not, please provide a suggested <br /> alternative :-) <br /> * Have I got the model divisions correct? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 18:44:25 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 19:01:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 00:01:30 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17954.43716.870610.6618@emt.wwp.brown.edu> Message-ID: <4622AECA.40505@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 00:01:30 +0100</span><br /> </address> While I confess that I don't feel very opinionated on this, <br /> I kind of like the idea of <q> being a lowest common denominator, <br /> with more specialist elements for serious encoding. <br /> I don't much like <quo>. Its neither a word not a decent abbreviation <br /> in English, but has a meaning in Latin, which seems unwise. <br /> <speech> and <spoken> are available but not perfect. <br /> <quotedSpeech>? <br /> <p>I think that airing this on TEI-L next week, <br /> if people agree, would be no bad thing. <br /> ebastian <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 19:01:34 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 19:02:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 00:02:36 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17954.43716.870610.6618@emt.wwp.brown.edu> Message-ID: <4622AF0C.8050001@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 00:02:36 +0100</span><br /> </address> oh, and <qs>, as an abbreviation for quoted speech <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 19:02:39 EDT</span> </div> From Syd_Bauman at Brown.edu Sun Apr 15 21:01:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 21:01:40 -0400 (EDT) Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <4622AF0C.8050001@oucs.ox.ac.uk> Message-ID: <200704160101.l3G11eiw026283@perseus.services.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 21:01:40 -0400 (EDT)</span><br /> </address> <em class="quotelev1">> I don't much like <quo>. Its neither a word not a decent </em><br /> <em class="quotelev1">> abbreviation in English, but has a meaning in Latin, which seems </em><br /> <em class="quotelev1">> unwise. </em><br /> Oh, good point about the Latin. According to one dictionary "quo" is <br /> an archaic version of "quoth" (somewhat archaic itself), as in "Quoth <br /> the the raven, 'Nevermore'". But I'm pretty sure that doesn't trump <br /> the disadvantage of the Latin. <br /> <p><em class="quotelev1">> <speech> and <spoken> are available but not perfect. </em><br /> <em class="quotelev1">> <quotedSpeech>? oh, and <qs>, as an abbreviation for quoted speech </em><br /> I don't wonder if <qs> looks to much like <ps>, which element I hope <br /> to add next week. Probably not a good argument against. <br /> How about <br /> - <sot>: speech or thought <br /> - <qst>: quoted speech or thought <br /> - <said>: said <br /> <p><em class="quotelev1">> I think that airing this on TEI-L next week, if people agree, would </em><br /> <em class="quotelev1">> be no bad thing. </em><br /> I agree. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 21:01:42 EDT</span> </div> From cwittern at gmail.com Sun Apr 15 21:52:12 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 16 Apr 2007 10:52:12 +0900 Subject: [tei-council] question about <char> In-Reply-To: <4622847B.8020204@computing-services.oxford.ac.uk> Message-ID: <4622D6CC.6040400@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 10:52:12 +0900</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> The description of the <char> element includes the following example: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <char xml:id="circledU4EBA"> </em><br /> <em class="quotelev1">> <charName>CIRCLED IDEOGRAPH 4EBA</charName> </em><br /> <em class="quotelev1">> <charProp> </em><br /> <em class="quotelev1">> <unicodeName>character-decomposition-mapping</unicodeName> </em><br /> <em class="quotelev1">> <value>circle</value> </em><br /> <em class="quotelev1">> </charProp> </em><br /> <em class="quotelev1">> <charProp> </em><br /> <em class="quotelev1">> <localName>daikanwa</localName> </em><br /> <em class="quotelev1">> <value>36</value>is a standard mapping why is it using a <g> element? </em><br /> <em class="quotelev1">> What's wrong with just using </em><br /> <em class="quotelev1">> </charProp> </em><br /> <em class="quotelev1">> <mapping type="standard"> </em><br /> <em class="quotelev1">> <g ref="#U4EBA">???</g> </em><br /> <em class="quotelev1">> </mapping> </em><br /> <em class="quotelev1">> </char> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I am puzzled by the <g> within the <mapping>. If this is a standard </em><br /> <em class="quotelev1">> mapping why is it using a <g> element? What's wrong with just using </em><br /> <em class="quotelev1">> the character, or an NCR like this? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <mapping type="standard"> </em><br /> <em class="quotelev1">> 人 </em><br /> <em class="quotelev1">> </mapping> </em><br /> <em class="quotelev1">> </em><br /> You are right, it is not necessary. If I remember correctly, this was <br /> put in to show to human readers both the character and the codepoint. <br /> If you find it confusing, your suggestion for replacement seems <br /> acceptable to me on this dark and rainy Monday morning. <br /> Christian <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 21:52:24 EDT</span> </div> From daniel.odonnell at uleth.ca Sun Apr 15 23:12:11 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 21:12:11 -0600 Subject: [tei-council] question about <char> In-Reply-To: <4622D6CC.6040400@gmail.com> Message-ID: <1176693131.7781.12.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 21:12:11 -0600</span><br /> </address> Not being part of the earlier discussions, the main reason I can see for <br /> the g are <br /> 1) To provide a mechanism for describing non-unicode characters <br /> 2) To keep the content model of mapping the same whether the character <br /> is unicode or not. <br /> Looking up mapping and g, and see the definition of mapping supports my <br /> hypothesis here, but the nomenclature and definition of g does not: <br /> In mapping: <br /> <em class="quotelev1">> The <g> elements contained by this element can point to either another </em><br /> <em class="quotelev1">> <char> or <glyph>element or contain a character that is intended to be </em><br /> <em class="quotelev1">> the target of this mapping. </em><br /> In g: <br /> <em class="quotelev1">> (character or glyph) represents a non-standard character or glyph. </em><br /> ... <br /> <em class="quotelev1">> The name g is short for gaiji, which is the Japanese term for a </em><br /> <em class="quotelev1">> non-standardized character or glyph.[1] </em><br /> Personally, I really like consistent content models for structures <br /> independent of specifics of the content--so I prefer requiring g for <br /> both standard and non-standard characters. But the name of g is <br /> misleading then in this case. Have we other places where you use cdata <br /> if the content is one thing and a structural element is the content is <br /> structurally the same thing but non-standard or the like? <br /> [1] I notice that others use gaiji in a slightly different sense as <br /> "supplemental" or "any glyph that's valid in your written language but <br /> is not in the font you are using" (both Adobe: <br /> http://www.adobe.com/products/indesign/sing_gaiji.html). "Any computer <br /> system can only provide a limited, finite set of characters. Additional <br /> characters are handled as <br /> 'gaiji'" (http://www.chibs.edu.tw/~chris/papers/ie/xml-gaiji/foil02.html). "A character not included in a standard set of characters" (Wiktionary). <br /> In these cases it is less of a stretch to use <g> for Unicode characters <br /> that need mapping: presumably you only map the ones that are relatively <br /> unusual and are not likely to be in a users usual character set or font. <br /> My preference is to leave it in and maybe amend the definition of <br /> g/gaiji. <br /> -dan <br /> <p>On Mon, 2007-04-16 at 10:52 +0900, Wittern Christian wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">> > The description of the <char> element includes the following example: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > <char xml:id="circledU4EBA"> </em><br /> <em class="quotelev2">> > <charName>CIRCLED IDEOGRAPH 4EBA</charName> </em><br /> <em class="quotelev2">> > <charProp> </em><br /> <em class="quotelev2">> > <unicodeName>character-decomposition-mapping</unicodeName> </em><br /> <em class="quotelev2">> > <value>circle</value> </em><br /> <em class="quotelev2">> > </charProp> </em><br /> <em class="quotelev2">> > <charProp> </em><br /> <em class="quotelev2">> > <localName>daikanwa</localName> </em><br /> <em class="quotelev2">> > <value>36</value>is a standard mapping why is it using a <g> element? </em><br /> <em class="quotelev2">> > What's wrong with just using </em><br /> <em class="quotelev2">> > </charProp> </em><br /> <em class="quotelev2">> > <mapping type="standard"> </em><br /> <em class="quotelev2">> > <g ref="#U4EBA">???</g> </em><br /> <em class="quotelev2">> > </mapping> </em><br /> <em class="quotelev2">> > </char> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I am puzzled by the <g> within the <mapping>. If this is a standard </em><br /> <em class="quotelev2">> > mapping why is it using a <g> element? What's wrong with just using </em><br /> <em class="quotelev2">> > the character, or an NCR like this? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > <mapping type="standard"> </em><br /> <em class="quotelev2">> > 人 </em><br /> <em class="quotelev2">> > </mapping> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> You are right, it is not necessary. If I remember correctly, this was </em><br /> <em class="quotelev1">> put in to show to human readers both the character and the codepoint. </em><br /> <em class="quotelev1">> If you find it confusing, your suggestion for replacement seems </em><br /> <em class="quotelev1">> acceptable to me on this dark and rainy Monday morning. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Christian </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 23:12:16 EDT</span> </div> From daniel.odonnell at uleth.ca Sun Apr 15 23:29:36 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 21:29:36 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704160101.l3G11eiw026283@perseus.services.brown.edu> Message-ID: <1176694176.7781.30.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 21:29:36 -0600</span><br /> </address> On Sun, 2007-04-15 at 21:01 -0400, Syd Bauman wrote: <br /> <em class="quotelev2">> > I don't much like <quo>. Its neither a word not a decent </em><br /> <em class="quotelev2">> > abbreviation in English, but has a meaning in Latin, which seems </em><br /> <em class="quotelev2">> > unwise. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Oh, good point about the Latin. According to one dictionary "quo" is </em><br /> <em class="quotelev1">> an archaic version of "quoth" (somewhat archaic itself), as in "Quoth </em><br /> <em class="quotelev1">> the the raven, 'Nevermore'". But I'm pretty sure that doesn't trump </em><br /> <em class="quotelev1">> the disadvantage of the Latin. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > <speech> and <spoken> are available but not perfect. </em><br /> <em class="quotelev2">> > <quotedSpeech>? oh, and <qs>, as an abbreviation for quoted speech </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I don't wonder if <qs> looks to much like <ps>, which element I hope </em><br /> <em class="quotelev1">> to add next week. Probably not a good argument against. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> How about </em><br /> <em class="quotelev1">> - <sot>: speech or thought </em><br /> <em class="quotelev1">> - <qst>: quoted speech or thought </em><br /> <em class="quotelev1">> - <said>: said </em><br /> Are these not all syntactic sugar for q_at_type? I am not at all keen on <br /> introducing more elements here, since the two we have are historically a <br /> place where people have a mess of a time. <br /> I agree with Sebastian that I like the idea of q as the default element. <br /> I'm less keen on trying to distinguish the others, partially because it <br /> is not a structural distinction people make in actually non-marked up <br /> running text--unlike, arguably q vs. socalled which is sometimes <br /> indicated by double or single quotations, though it is a bad habit, I'm <br /> told. I can see people having an immense amount of difficulty with this: <br /> is this a "speech or a thought" but not "quoted speech or thought" and <br /> not "said"? Do I need to tag every indirect quotation? ad infin. <br /> Another argument against it is the very nomenclature difficulty we are <br /> having: q/quote/qst and with a little extension, said, are all arguably <br /> short forms of the same word: quote/quotation. <br /> People who really need this level of granularity can surely use @type or <br /> some form of seg? If it turns out that there is a real need for this, <br /> treating q as the base element will allow us to introduce more later. <br /> But I think this may be a solution looking for a problem. <br /> If we do ask tei-l next week, I'd like to ask first whether we need more <br /> than q and optionally quote. My next preference would be for <br /> q-quote-said, and finally something like q-quote-said-iquote (for <br /> indirect quote). <br /> -dan <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > I think that airing this on TEI-L next week, if people agree, would </em><br /> <em class="quotelev2">> > be no bad thing. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I agree. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 15 2007 - 23:29:46 EDT</span> </div> From daniel.odonnell at uleth.ca Mon Apr 16 00:22:12 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 22:22:12 -0600 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4621F11D.9080703@oucs.ox.ac.uk> Message-ID: <1176697332.7781.73.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 15 Apr 2007 22:22:12 -0600</span><br /> </address> On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: <br /> <em class="quotelev1">> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">> > James Cummings wrote: </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Yup, I understand and agree with all of that. So by suggesting that </em><br /> <em class="quotelev3">> >> people use namespaces for their new attributes we encourage the good </em><br /> <em class="quotelev3">> >> practice that TEI already follows of not having @myspace:where mean </em><br /> <em class="quotelev3">> >> something on one element and @myspace:where mean something else on </em><br /> <em class="quotelev3">> >> another element. </em><br /> <em class="quotelev2">> > what if add the TEI-consonant @type to an element which doesnt have it </em><br /> <em class="quotelev2">> > already? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I believe consensus was that this was an 'unclean' change, and thus </em><br /> <em class="quotelev1">> element and attribute are put in a user-defined namespace. </em><br /> Indeed it was the consensus. And indeed if you added it to new elements <br /> because you wanted to have a global type element, we seemed to think <br /> that all types were my:type. <br /> -dan <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -James </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 00:22:19 EDT</span> </div> From cwittern at gmail.com Mon Apr 16 00:38:05 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 16 Apr 2007 13:38:05 +0900 Subject: [tei-council] question about <char> In-Reply-To: <1176693131.7781.12.camel@localhost> Message-ID: <4622FDAD.10708@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 13:38:05 +0900</span><br /> </address> Daniel O'Donnell wrote: <br /> <em class="quotelev1">> Not being part of the earlier discussions, the main reason I can see for </em><br /> <em class="quotelev1">> the g are </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 1) To provide a mechanism for describing non-unicode characters </em><br /> <em class="quotelev1">> 2) To keep the content model of mapping the same whether the character </em><br /> <em class="quotelev1">> is unicode or not. </em><br /> <em class="quotelev1">> </em><br /> I had the impression, Lou's question was not about changing the content <br /> model, but rather specifically about the example we provide. <br /> <em class="quotelev1">> Looking up mapping and g, and see the definition of mapping supports my </em><br /> <em class="quotelev1">> hypothesis here, but the nomenclature and definition of g does not: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In mapping: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> The <g> elements contained by this element can point to either another </em><br /> <em class="quotelev2">>> <char> or <glyph>element or contain a character that is intended to be </em><br /> <em class="quotelev2">>> the target of this mapping. </em><br /> <em class="quotelev2">>> </em><br /> The "pointing" to <char> and <glyph> is done via a <g> element. What <br /> this comes down to is that the content is either a character used <br /> directly, or a <g> element, which represents a otherwise not <br /> representable character. Mapping as such is used only within the <br /> structure of a <char> or <glyph> element to point to a related version <br /> of a character (for example from a lower case to a upper case version). <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In g: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> (character or glyph) represents a non-standard character or glyph. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> The name g is short for gaiji, which is the Japanese term for a </em><br /> <em class="quotelev2">>> non-standardized character or glyph.[1] </em><br /> <em class="quotelev2">>> </em><br /> The formulation is not ideal. I now prefer to merge this with the one <br /> from Wikipedia: <br /> "The name g is short for gaiji, which is the Japanese term for a character not included in a standard set of characters" <br /> <em class="quotelev1">> Personally, I really like consistent content models for structures </em><br /> <em class="quotelev1">> independent of specifics of the content--so I prefer requiring g for </em><br /> <em class="quotelev1">> both standard and non-standard characters. But the name of g is </em><br /> <em class="quotelev1">> misleading then in this case. Have we other places where you use cdata </em><br /> <em class="quotelev1">> if the content is one thing and a structural element is the content is </em><br /> <em class="quotelev1">> structurally the same thing but non-standard or the like? </em><br /> <em class="quotelev1">> </em><br /> The <g> is special here in that it uses markup to represent a <br /> character. In that sense, it is not comparable to other situations, I <br /> think. <br /> Christian <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 00:38:15 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 16 03:57:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 08:57:16 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704160101.l3G11eiw026283@perseus.services.brown.edu> Message-ID: <46232C5C.2090307@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 08:57:16 +0100</span><br /> </address> I like <said>. But if others feel that <q tyype="said"> will do, <br /> no tears here (having a dry day) <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 03:57:21 EDT</span> </div> From arianna.ciula at kcl.ac.uk Mon Apr 16 05:46:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 10:46:15 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <4622961D.4030704@oucs.ox.ac.uk> Message-ID: <462345E7.5070108@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 10:46:15 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> what would @schema on <locus> point to? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I see we have no example of its use :-} </em><br /> <em class="quotelev1">> </em><br /> mh...I don't agree with this. I can see lots of potential uses of <br /> @scheme for <gi>locus</gi> as it is defined in the guidelines: <br /> "identifies the foliation scheme in terms of which the location is being <br /> specified.". <br /> Indeed, as I am sure other people who have worked with manuscripts can <br /> confirm, the same codex, for instance, can include several systems of <br /> foliation/pagination added over the years and centuries, following <br /> different readings, different arrangements of the folios, different <br /> conventions, different interventions on the book itself. To encode these <br /> parallelisms or conflicts between folio numbers can be useful to study <br /> the tradition/reading of the text as well as to render various outputs <br /> of the same source. <br /> If you think another existing element can do the trick fine, but <br /> otherwise I would keep @scheme.<!--nospam--> <br /> Arianna <br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 05:46:28 EDT</span> </div> From arianna.ciula at kcl.ac.uk Mon Apr 16 06:12:55 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 11:12:55 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <462345E7.5070108@kcl.ac.uk> Message-ID: <46234C27.4010407@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 11:12:55 +0100</span><br /> </address> Arianna Ciula wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">>> what would @schema on <locus> point to? </em><br /> I forgot to say it would point to the foliation scheme as defined in the <br /> <foliation> element. <br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I see we have no example of its use :-} </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> mh...I don't agree with this. I can see lots of potential uses of </em><br /> <em class="quotelev1">> @scheme for <gi>locus</gi> as it is defined in the guidelines: </em><br /> <em class="quotelev1">> "identifies the foliation scheme in terms of which the location is being </em><br /> <em class="quotelev1">> specified.". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Indeed, as I am sure other people who have worked with manuscripts can </em><br /> <em class="quotelev1">> confirm, the same codex, for instance, can include several systems of </em><br /> <em class="quotelev1">> foliation/pagination added over the years and centuries, following </em><br /> <em class="quotelev1">> different readings, different arrangements of the folios, different </em><br /> <em class="quotelev1">> conventions, different interventions on the book itself. To encode these </em><br /> <em class="quotelev1">> parallelisms or conflicts between folio numbers can be useful to study </em><br /> <em class="quotelev1">> the tradition/reading of the text as well as to render various outputs </em><br /> <em class="quotelev1">> of the same source. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If you think another existing element can do the trick fine, but </em><br /> <em class="quotelev1">> otherwise I would keep @scheme.<!--nospam--> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Arianna </em><br /> <em class="quotelev1">> </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 06:13:57 EDT</span> </div> From arianna.ciula at kcl.ac.uk Mon Apr 16 06:25:19 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 11:25:19 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <46234F0F.1000104@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 11:25:19 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> BTW, the development version of the Guidelines (the one which is in </em><br /> <em class="quotelev1">> https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5/Source/ and </em><br /> <em class="quotelev1">> available as HTML at </em><br /> <em class="quotelev1">> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html) </em><br /> This must be down for some reasons today. Lou, could you please point me <br /> to the html draft of ND or could you make one please? I can't find it <br /> within the Draft folder. May be it's easy to produce one with the xsl on <br /> sourceforge, but don't want to risk to use the wrong stylesheet etc. <br /> Arianna <br /> <em class="quotelev1">> also has all the new dating attributes in it. Since we all voted on </em><br /> <em class="quotelev1">> it, I don't think there is much controversial there, except as listed </em><br /> <em class="quotelev1">> below. On the other hand, paying close attention for class errors, </em><br /> <em class="quotelev1">> typos, etc., would be helpful. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Possible Issues </em><br /> <em class="quotelev1">> -------- ------ </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * Rather than create a new module for ISO dating attributes, I stuck </em><br /> <em class="quotelev1">> 'em directly into the namesdates module. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * We never decided on the names of the ISO attributes. I called them </em><br /> <em class="quotelev1">> value-iso= </em><br /> <em class="quotelev1">> dur-iso= </em><br /> <em class="quotelev1">> notBefore-iso= </em><br /> <em class="quotelev1">> etc. My thinking (what little there was) was that it would be nice </em><br /> <em class="quotelev1">> if these attributes sorted near their "simple" W3C counterparts. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> * We should perhaps discuss how strong the warnings against using </em><br /> <em class="quotelev1">> "24:00" and basic formats (i.e., no colons or hyphens in some </em><br /> <em class="quotelev1">> cases) should be. Currently the remarks say </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <p>For all representations for which ISO 8601 describes both a </em><br /> <em class="quotelev1">> <term>basic</term> and an <term>extended</term> format, these </em><br /> <em class="quotelev1">> Guidelines recommend use of the extended format.</p> </em><br /> <em class="quotelev1">> <p>While ISO 8601 permits the use of both <code>00:00</code> and </em><br /> <em class="quotelev1">> <code>24:00</code> to represent midnight, these Guidelines </em><br /> <em class="quotelev1">> strongly recommend against the use of <code>24:00</code>. <!-- As </em><br /> <em class="quotelev1">> there are only 24 hours in a day, numbered "00" through "23", use </em><br /> <em class="quotelev1">> of "24:00" implies a 25th hour, and some software may be confused. </em><br /> <em class="quotelev1">> Note that when there is a leap second, it should be indicated </em><br /> <em class="quotelev1">> with 23:59:60. --></p> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 06:25:31 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 16 07:32:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 12:32:39 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <462345E7.5070108@kcl.ac.uk> Message-ID: <46235ED7.3040502@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 12:32:39 +0100</span><br /> </address> Arianna Ciula wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> what would @schema on <locus> point to? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I see we have no example of its use :-} </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> mh...I don't agree with this. I can see lots of potential uses of </em><br /> <em class="quotelev1">> @scheme for <gi>locus</gi> as it is defined in the guidelines: </em><br /> <em class="quotelev1">> "identifies the foliation scheme in terms of which the location is </em><br /> <em class="quotelev1">> being specified.". </em><br /> <em class="quotelev1">> </em><br /> sorry, misunderstanding. I just meant that the Guidelines have no example of <locus scheme=; Lou has now added one <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 07:32:42 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 16 09:52:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 09:52:58 -0400 Subject: [tei-council] question about <char> In-Reply-To: <4622D6CC.6040400@gmail.com> Message-ID: <17955.32698.492563.153935@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 09:52:58 -0400</span><br /> </address> <em class="quotelev1">> ... on this dark and rainy Monday morning. </em><br /> We are having a dark and rainy morning here, too ... in fact, we've <br /> been hit by a N'oreaster, and have been without power at my home for <br /> at least 5 hours now. This means 2 things: <br /> * I am quite behind in Council mail, etc. <br /> * The copy of the Guidelines I had on my server will probably not be <br /> available until circa 18:00 UTC. If folks want, I'll try to put a <br /> new copy up at another site in a few mins ... <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 09:53:01 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 16 10:18:32 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 10:18:32 -0400 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <1176694176.7781.30.camel@localhost> Message-ID: <17955.34232.705683.173662@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 10:18:32 -0400</span><br /> </address> <em class="quotelev1">> Are these not all syntactic sugar for q_at_type? I am not at all keen </em><br /> <em class="quotelev1">> on introducing more elements here, since the two we have are </em><br /> <em class="quotelev1">> historically a place where people have a mess of a time. </em><br /> I'm not sure which 'all' you are asking about, but the answer, I <br /> think, is yes, to some extent they are syntactic sugar for <q> with <br /> type=. But that doesn't change the need for a new element, which is <br /> very strong. The problem is that the Guidelines up to now have used <br /> <q> for more than one thing. <br /> But on further reading your reply, I think I may not have made myself <br /> clear. The following <br /> <em class="quotelev2">> > How about </em><br /> <em class="quotelev2">> > - <sot>: speech or thought </em><br /> <em class="quotelev2">> > - <qst>: quoted speech or thought </em><br /> <em class="quotelev2">> > - <said>: said </em><br /> was not meant as a recommendation for 3 new elements, but rather as 3 <br /> possible names for the 1 new element we need to add. <br /> The thought occured to me to use <said> with an aloud= attribute that <br /> would be data.xTruthValue. <br /> Thus you might see <br /> He was trying to butter her up in earnest now. She showed <br /> him a picture of her dog. <said>What a cutie! I bet he's smart, <br /> too.</said>, he said, as he thought <said aloud="false">gak, what <br /> an ugly dog</said> to himself. <br /> <p><em class="quotelev1">> If we do ask tei-l next week, I'd like to ask first whether we need </em><br /> <em class="quotelev1">> more than q and optionally quote. </em><br /> I think it's pretty important that we make this distinction. I have <br /> received quite a few complaints about the "<q> as speech or thought" <br /> vs "<q> as written quotation, speech, thought, or example" problem. <br /> While there are many (perhaps most) who don't care, there are a quite <br /> a few projects for which the difference between quotations of written <br /> passages external to the text and a character's spoken words in <br /> running prose are really quite important. <br /> I think the proposed solution brings the folks who don't care at all <br /> and use <q> for everything into the fold, while giving those for whom <br /> the nuances are important a mechanism for clean distinction. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 10:18:36 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 16 10:20:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 10:20:20 -0400 Subject: [tei-council] dating attrs In-Reply-To: <46234F0F.1000104@kcl.ac.uk> Message-ID: <17955.34340.44374.42774@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 10:20:20 -0400</span><br /> </address> <em class="quotelev1">> This must be down for some reasons today. Lou, could you please </em><br /> <em class="quotelev1">> point me to the html draft of ND or could you make one please? </em><br /> I'll take this as a "yes" :-) <br /> http://dev.stg.brown.edu/staff/Syd_Bauman/temp/Guidelines-web/en/html/ND.html <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 10:20:23 EDT</span> </div> From arianna.ciula at kcl.ac.uk Mon Apr 16 10:21:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 15:21:06 +0100 Subject: [tei-council] question about <char> In-Reply-To: <17955.32698.492563.153935@emt.wwp.brown.edu> Message-ID: <46238652.7010402@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 15:21:06 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> * The copy of the Guidelines I had on my server will probably not be </em><br /> <em class="quotelev1">> available until circa 18:00 UTC. If folks want, I'll try to put a </em><br /> <em class="quotelev1">> new copy up at another site in a few mins ... </em><br /> orry to hear about the disruption Syd. It would be good for me if you <br /> can pout another copy somewhere, unless there are other solutions for me <br /> to have an HTML view of that third Easter egg. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 10:21:06 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Mon Apr 16 11:02:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 16 Apr 2007 16:02:18 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17955.34232.705683.173662@emt.wwp.brown.edu> Message-ID: <46238FFA.7030900@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 16:02:18 +0100</span><br /> </address> Sorry, but I really do not agree with Syd on this issue, though I am <br /> pleased that he thinks I do! <br /> As I understand it, the proposal is to invent a new element, presumably <br /> to join the already over-burdened Core module, for the purpose of <br /> marking up representations of speech (but not thought) which are <br /> considered (by someone) to be "part of the text", and not quoted from <br /> somewhere else. It's less clear whether or not such representations are <br /> necessarily typographically distinct in the original but that seems to <br /> be relevant. <br /> I don't doubt that for some people and some applications these <br /> distinctions are important, and may even be useful, but I do doubt very <br /> much whether Mr or Ms TEI-average-user will want to make them. In the <br /> decade or more that people have been happily using <q> to mark <br /> "representation of speech or thought", I am not aware of anyone having <br /> the kind of major problem we are being told now exists. "representation <br /> of speech or thought" is an inherently vague concept (after all, that's <br /> what *all* text is!) It's true that some feel we can distinguish "rep <br /> of speech or thought" which is "internal" to a work from ditto when <br /> presented as external, but that's why we have both <q> and <quote>; I <br /> am happy with the idea of promoting <quote> as the tag to use if you <br /> want to make explicit that something is regarded as external, though I <br /> don't believe it to be strictly necessary. <br /> If you want to distinguish more finely within either of these elements, <br /> the attributes are there: in particular, @type is there precisely to <br /> indicate whether the material is "spoken" "thought" or "written", and <br /> speech can be further subdivided according to @direct.<!--nospam--> <br /> So the best interpretation I can put on this proposal is that it is <br /> arguing for a new bit of syntactic sugar. Less charitably, and to quote <br /> our esteemeed Board chair, this looks like "a solution looking for a <br /> problem". Hmm, should that have been a <q> or a <quote>? does what <br /> someone says in an email count as <q> or <said> or what? aaargh! <br /> Furthermore, I really don't think this is the most important issue for <br /> us to be consulting with Mr and Mrs TEI Average User about right now. <br /> They will say <said>not said but sad</said>... <br /> <p>Lou <br /> <p>Syd Bauman wrote: <br /> <em class="quotelev2">>> Are these not all syntactic sugar for q_at_type? I am not at all keen </em><br /> <em class="quotelev2">>> on introducing more elements here, since the two we have are </em><br /> <em class="quotelev2">>> historically a place where people have a mess of a time. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm not sure which 'all' you are asking about, but the answer, I </em><br /> <em class="quotelev1">> think, is yes, to some extent they are syntactic sugar for <q> with </em><br /> <em class="quotelev1">> type=. But that doesn't change the need for a new element, which is </em><br /> <em class="quotelev1">> very strong. The problem is that the Guidelines up to now have used </em><br /> <em class="quotelev1">> <q> for more than one thing. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> But on further reading your reply, I think I may not have made myself </em><br /> <em class="quotelev1">> clear. The following </em><br /> <em class="quotelev3">>>> How about </em><br /> <em class="quotelev3">>>> - <sot>: speech or thought </em><br /> <em class="quotelev3">>>> - <qst>: quoted speech or thought </em><br /> <em class="quotelev3">>>> - <said>: said </em><br /> <em class="quotelev1">> was not meant as a recommendation for 3 new elements, but rather as 3 </em><br /> <em class="quotelev1">> possible names for the 1 new element we need to add. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The thought occured to me to use <said> with an aloud= attribute that </em><br /> <em class="quotelev1">> would be data.xTruthValue. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Thus you might see </em><br /> <em class="quotelev1">> He was trying to butter her up in earnest now. She showed </em><br /> <em class="quotelev1">> him a picture of her dog. <said>What a cutie! I bet he's smart, </em><br /> <em class="quotelev1">> too.</said>, he said, as he thought <said aloud="false">gak, what </em><br /> <em class="quotelev1">> an ugly dog</said> to himself. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> If we do ask tei-l next week, I'd like to ask first whether we need </em><br /> <em class="quotelev2">>> more than q and optionally quote. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think it's pretty important that we make this distinction. I have </em><br /> <em class="quotelev1">> received quite a few complaints about the "<q> as speech or thought" </em><br /> <em class="quotelev1">> vs "<q> as written quotation, speech, thought, or example" problem. </em><br /> <em class="quotelev1">> While there are many (perhaps most) who don't care, there are a quite </em><br /> <em class="quotelev1">> a few projects for which the difference between quotations of written </em><br /> <em class="quotelev1">> passages external to the text and a character's spoken words in </em><br /> <em class="quotelev1">> running prose are really quite important. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think the proposed solution brings the folks who don't care at all </em><br /> <em class="quotelev1">> and use <q> for everything into the fold, while giving those for whom </em><br /> <em class="quotelev1">> the nuances are important a mechanism for clean distinction. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 11:04:36 EDT</span> </div> From cwittern at gmail.com Mon Apr 16 20:54:43 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 17 Apr 2007 09:54:43 +0900 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <1176697332.7781.73.camel@localhost> Message-ID: <46241AD3.9070000@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 09:54:43 +0900</span><br /> </address> Daniel O'Donnell wrote: <br /> <em class="quotelev1">> On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> James Cummings wrote: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> Yup, I understand and agree with all of that. So by suggesting that </em><br /> <em class="quotelev4">>>>> people use namespaces for their new attributes we encourage the good </em><br /> <em class="quotelev4">>>>> practice that TEI already follows of not having @myspace:where mean </em><br /> <em class="quotelev4">>>>> something on one element and @myspace:where mean something else on </em><br /> <em class="quotelev4">>>>> another element. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> what if add the TEI-consonant @type to an element which doesnt have it </em><br /> <em class="quotelev3">>>> already? </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> I believe consensus was that this was an 'unclean' change, and thus </em><br /> <em class="quotelev2">>> element and attribute are put in a user-defined namespace. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Indeed it was the consensus. And indeed if you added it to new elements </em><br /> <em class="quotelev1">> because you wanted to have a global type element, we seemed to think </em><br /> <em class="quotelev1">> that all types were my:type. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> Well, things are moving so fast it becomes difficult to keep track. Say <br /> I want to add @type to p.<!--nospam--> Does this mean my tei:p has to be changed to <br /> my:p? This seems quite drastic to me. It would be sufficient in my <br /> book simply to say @my:type and leave p as tei:p.<!--nospam--> <br /> Christian <br /> <p><p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 16 2007 - 20:54:55 EDT</span> </div> From daniel.odonnell at uleth.ca Tue Apr 17 00:23:28 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 16 Apr 2007 22:23:28 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <46238FFA.7030900@oucs.ox.ac.uk> Message-ID: <1176783808.7115.18.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 16 Apr 2007 22:23:28 -0600</span><br /> </address> While I may have been more pithy than politic, I certainly didn't mean <br /> to be uncharitable about the issue. I can certainly see how people might <br /> want to mark these distinctions. But I think the lack of traditional <br /> non-structural punctuation for this distinction is crucial. The <br /> distinctions are far finer than most of us *can* regularly make, let <br /> alone want to, and I agree with Lou here that type covers a lot of <br /> ground for more specialist uses. <br /> I'm still not convinced that q and quote are actually necessary, let <br /> alone said. I like said as an element name, but am not sure about its <br /> use being that necessary. <br /> -dan <br /> On Mon, 2007-04-16 at 16:02 +0100, Lou Burnard wrote: <br /> <em class="quotelev1">> Sorry, but I really do not agree with Syd on this issue, though I am </em><br /> <em class="quotelev1">> pleased that he thinks I do! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As I understand it, the proposal is to invent a new element, presumably </em><br /> <em class="quotelev1">> to join the already over-burdened Core module, for the purpose of </em><br /> <em class="quotelev1">> marking up representations of speech (but not thought) which are </em><br /> <em class="quotelev1">> considered (by someone) to be "part of the text", and not quoted from </em><br /> <em class="quotelev1">> somewhere else. It's less clear whether or not such representations are </em><br /> <em class="quotelev1">> necessarily typographically distinct in the original but that seems to </em><br /> <em class="quotelev1">> be relevant. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I don't doubt that for some people and some applications these </em><br /> <em class="quotelev1">> distinctions are important, and may even be useful, but I do doubt very </em><br /> <em class="quotelev1">> much whether Mr or Ms TEI-average-user will want to make them. In the </em><br /> <em class="quotelev1">> decade or more that people have been happily using <q> to mark </em><br /> <em class="quotelev1">> "representation of speech or thought", I am not aware of anyone having </em><br /> <em class="quotelev1">> the kind of major problem we are being told now exists. "representation </em><br /> <em class="quotelev1">> of speech or thought" is an inherently vague concept (after all, that's </em><br /> <em class="quotelev1">> what *all* text is!) It's true that some feel we can distinguish "rep </em><br /> <em class="quotelev1">> of speech or thought" which is "internal" to a work from ditto when </em><br /> <em class="quotelev1">> presented as external, but that's why we have both <q> and <quote>; I </em><br /> <em class="quotelev1">> am happy with the idea of promoting <quote> as the tag to use if you </em><br /> <em class="quotelev1">> want to make explicit that something is regarded as external, though I </em><br /> <em class="quotelev1">> don't believe it to be strictly necessary. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If you want to distinguish more finely within either of these elements, </em><br /> <em class="quotelev1">> the attributes are there: in particular, @type is there precisely to </em><br /> <em class="quotelev1">> indicate whether the material is "spoken" "thought" or "written", and </em><br /> <em class="quotelev1">> speech can be further subdivided according to @direct.<!--nospam--> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So the best interpretation I can put on this proposal is that it is </em><br /> <em class="quotelev1">> arguing for a new bit of syntactic sugar. Less charitably, and to quote </em><br /> <em class="quotelev1">> our esteemeed Board chair, this looks like "a solution looking for a </em><br /> <em class="quotelev1">> problem". Hmm, should that have been a <q> or a <quote>? does what </em><br /> <em class="quotelev1">> someone says in an email count as <q> or <said> or what? aaargh! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Furthermore, I really don't think this is the most important issue for </em><br /> <em class="quotelev1">> us to be consulting with Mr and Mrs TEI Average User about right now. </em><br /> <em class="quotelev1">> They will say <said>not said but sad</said>... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Lou </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Syd Bauman wrote: </em><br /> <em class="quotelev3">> >> Are these not all syntactic sugar for q_at_type? I am not at all keen </em><br /> <em class="quotelev3">> >> on introducing more elements here, since the two we have are </em><br /> <em class="quotelev3">> >> historically a place where people have a mess of a time. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm not sure which 'all' you are asking about, but the answer, I </em><br /> <em class="quotelev2">> > think, is yes, to some extent they are syntactic sugar for <q> with </em><br /> <em class="quotelev2">> > type=. But that doesn't change the need for a new element, which is </em><br /> <em class="quotelev2">> > very strong. The problem is that the Guidelines up to now have used </em><br /> <em class="quotelev2">> > <q> for more than one thing. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > But on further reading your reply, I think I may not have made myself </em><br /> <em class="quotelev2">> > clear. The following </em><br /> <em class="quotelev4">> >>> How about </em><br /> <em class="quotelev4">> >>> - <sot>: speech or thought </em><br /> <em class="quotelev4">> >>> - <qst>: quoted speech or thought </em><br /> <em class="quotelev4">> >>> - <said>: said </em><br /> <em class="quotelev2">> > was not meant as a recommendation for 3 new elements, but rather as 3 </em><br /> <em class="quotelev2">> > possible names for the 1 new element we need to add. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > The thought occured to me to use <said> with an aloud= attribute that </em><br /> <em class="quotelev2">> > would be data.xTruthValue. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Thus you might see </em><br /> <em class="quotelev2">> > He was trying to butter her up in earnest now. She showed </em><br /> <em class="quotelev2">> > him a picture of her dog. <said>What a cutie! I bet he's smart, </em><br /> <em class="quotelev2">> > too.</said>, he said, as he thought <said aloud="false">gak, what </em><br /> <em class="quotelev2">> > an ugly dog</said> to himself. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> If we do ask tei-l next week, I'd like to ask first whether we need </em><br /> <em class="quotelev3">> >> more than q and optionally quote. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I think it's pretty important that we make this distinction. I have </em><br /> <em class="quotelev2">> > received quite a few complaints about the "<q> as speech or thought" </em><br /> <em class="quotelev2">> > vs "<q> as written quotation, speech, thought, or example" problem. </em><br /> <em class="quotelev2">> > While there are many (perhaps most) who don't care, there are a quite </em><br /> <em class="quotelev2">> > a few projects for which the difference between quotations of written </em><br /> <em class="quotelev2">> > passages external to the text and a character's spoken words in </em><br /> <em class="quotelev2">> > running prose are really quite important. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I think the proposed solution brings the folks who don't care at all </em><br /> <em class="quotelev2">> > and use <q> for everything into the fold, while giving those for whom </em><br /> <em class="quotelev2">> > the nuances are important a mechanism for clean distinction. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > _______________________________________________ </em><br /> <em class="quotelev2">> > tei-council mailing list </em><br /> <em class="quotelev2">> > tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 00:23:32 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Tue Apr 17 04:30:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Apr 2007 09:30:12 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46241AD3.9070000@gmail.com> Message-ID: <46248594.1000408@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 09:30:12 +0100</span><br /> </address> Wittern Christian wrote: <br /> <em class="quotelev1">> Daniel O'Donnell wrote: </em><br /> <em class="quotelev2">>> On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> Sebastian Rahtz wrote: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> James Cummings wrote: </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev1">>>>>> Yup, I understand and agree with all of that. So by suggesting </em><br /> <em class="quotelev1">>>>>> that people use namespaces for their new attributes we encourage </em><br /> <em class="quotelev1">>>>>> the good practice that TEI already follows of not having </em><br /> <em class="quotelev1">>>>>> @myspace:where mean something on one element and @myspace:where </em><br /> <em class="quotelev1">>>>>> mean something else on another element. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev4">>>>> what if add the TEI-consonant @type to an element which doesnt have </em><br /> <em class="quotelev4">>>>> it already? </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> I believe consensus was that this was an 'unclean' change, and thus </em><br /> <em class="quotelev3">>>> element and attribute are put in a user-defined namespace. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Indeed it was the consensus. And indeed if you added it to new elements </em><br /> <em class="quotelev2">>> because you wanted to have a global type element, we seemed to think </em><br /> <em class="quotelev2">>> that all types were my:type. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> Well, things are moving so fast it becomes difficult to keep track. </em><br /> <em class="quotelev1">> Say I want to add @type to p.<!--nospam--> Does this mean my tei:p has to be </em><br /> <em class="quotelev1">> changed to my:p? This seems quite drastic to me. It would be </em><br /> <em class="quotelev1">> sufficient in my book simply to say @my:type and leave p as tei:p.<!--nospam--> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Christian </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> Well, as regards namespace, the options seems to be: <br /> 1. The line of least resistance: say that your schema is not in any <br /> namespace (by saying ns="" on your <schemaSpec>) <br /> 2. The odour of sanctity: say that the attribute is new (by saying <br /> ns="http://myspace.com" on the <attDef> in the <elementSpec> in your <br /> <schemaSpec>) <br /> 3. Political correctness gone mad: say that the element is new (by <br /> saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) <br /> Of these three, I believe (but I'm not sure) that (2) and (3) are both <br /> what we are currently calling "conformant", but obvious (2) makes more <br /> sense. <br /> We don't have a name for (1) yet. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 04:30:15 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 04:45:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 09:45:55 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46248594.1000408@computing-services.oxford.ac.uk> Message-ID: <46248943.2010500@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 09:45:55 +0100</span><br /> </address> Lou Burnard wrote: <br /> <em class="quotelev1">> Well, as regards namespace, the options seems to be: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 1. The line of least resistance: say that your schema is not in any </em><br /> <em class="quotelev1">> namespace (by saying ns="" on your <schemaSpec>) </em><br /> <em class="quotelev1">> 2. The odour of sanctity: say that the attribute is new (by saying </em><br /> <em class="quotelev1">> ns="http://myspace.com" on the <attDef> in the <elementSpec> in your </em><br /> <em class="quotelev1">> <schemaSpec>) </em><br /> <em class="quotelev1">> 3. Political correctness gone mad: say that the element is new (by </em><br /> <em class="quotelev1">> saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) </em><br /> and leave the attribute in the empty namespace in that case <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Of these three, I believe (but I'm not sure) that (2) and (3) are both </em><br /> <em class="quotelev1">> what we are currently calling "conformant", but obvious (2) makes more </em><br /> <em class="quotelev1">> sense. </em><br /> I agree. And note that the most interchangeable format is (2). <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> We don't have a name for (1) yet. </em><br /> "Overlap". The schema Christian makes for (1) overlaps the TEI mostly. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 04:45:58 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Tue Apr 17 09:26:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 17 Apr 2007 14:26:52 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46248943.2010500@oucs.ox.ac.uk> Message-ID: <4624CB1C.90105@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 14:26:52 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Lou Burnard wrote: </em><br /> <em class="quotelev2">>> Well, as regards namespace, the options seems to be: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> 1. The line of least resistance: say that your schema is not in any </em><br /> <em class="quotelev2">>> namespace (by saying ns="" on your <schemaSpec>) </em><br /> <em class="quotelev2">>> 2. The odour of sanctity: say that the attribute is new (by saying </em><br /> <em class="quotelev2">>> ns="http://myspace.com" on the <attDef> in the <elementSpec> in your </em><br /> <em class="quotelev2">>> <schemaSpec>) </em><br /> <em class="quotelev2">>> 3. Political correctness gone mad: say that the element is new (by </em><br /> <em class="quotelev2">>> saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) </em><br /> <em class="quotelev1">> and leave the attribute in the empty namespace in that case </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Of these three, I believe (but I'm not sure) that (2) and (3) are both </em><br /> <em class="quotelev2">>> what we are currently calling "conformant", but obvious (2) makes more </em><br /> <em class="quotelev2">>> sense. </em><br /> <em class="quotelev1">> I agree. And note that the most interchangeable format is (2). </em><br /> I agree, if Christian adds @type to tei:p, then it is tei:p/@my:type.<!--nospam-->.. <br /> only the attribute is in a different namespace, not the element. If he <br /> changes the content model of tei:p in any way which is not a pure subset, <br /> then it would become my:p. <br /> <em class="quotelev2">>> We don't have a name for (1) yet. </em><br /> <em class="quotelev1">> "Overlap". The schema Christian makes for (1) overlaps the TEI mostly. </em><br /> I believe on the little chart you produced recently (for an in-house <br /> discussion) of different aspects of Conformance, this might be 'Extended TEI'. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 09:26:56 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 09:36:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 14:36:46 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CB1C.90105@computing-services.oxford.ac.uk> Message-ID: <4624CD6E.8040702@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 14:36:46 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> I believe on the little chart you produced recently (for an in-house </em><br /> <em class="quotelev1">> discussion) of different aspects of Conformance, this might be 'Extended TEI'. </em><br /> <em class="quotelev1">> </em><br /> Yes, it is a sibling to Tite. <br /> I'll let Lou share the gory details of the classification <br /> system which arose from our discussion here. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 09:36:49 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Tue Apr 17 09:38:45 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 17 Apr 2007 14:38:45 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CD6E.8040702@oucs.ox.ac.uk> Message-ID: <4624CDE5.5060409@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 14:38:45 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev2">>> I believe on the little chart you produced recently (for an in-house </em><br /> <em class="quotelev2">>> discussion) of different aspects of Conformance, this might be </em><br /> <em class="quotelev2">>> 'Extended TEI'. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> Yes, it is a sibling to Tite. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'll let Lou share the gory details of the classification </em><br /> <em class="quotelev1">> system which arose from our discussion here. </em><br /> <em class="quotelev1">> </em><br /> Be aware that the printout you gave me has an error .. (in the heading of <br /> the last column, you've called it 'TEI conformant', when t'ain't since <br /> t'ain't no ODD.) <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 09:38:48 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 09:47:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 14:47:18 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CDE5.5060409@computing-services.oxford.ac.uk> Message-ID: <4624CFE6.4040802@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 14:47:18 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> Be aware that the printout you gave me has an error .. (in the heading of </em><br /> <em class="quotelev1">> the last column, you've called it 'TEI conformant', when t'ain't since </em><br /> <em class="quotelev1">> t'ain't no ODD.) </em><br /> <em class="quotelev1">> </em><br /> This is a document which was born without benefit of clergy, <br /> ie validated by its author against a hand-constructed schema. <br /> HOWEVER, since the document has no DOCTYPE or schema PI, <br /> we can't hold its bastardy against it, so we make it a ward of <br /> court and say that its ODD is teiall. <br /> Unless we mandate a link to an ODD, using a notation we <br /> don't have, we can never claim conformant documents must <br /> have an ODD. A TEI Conformant System has an ODD, as part of it, <br /> yes. <br /> You may say that the unnamed document's ODD being teiall <br /> is a legal fiction, but that may be true of any document. <br /> If I show you a XML doc, and an ODD, and claim the two <br /> relate, you're just taking my word for it. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 09:47:22 EDT</span> </div> From laurent.romary at loria.fr Tue Apr 17 12:41:16 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 17 Apr 2007 18:41:16 +0200 Subject: [tei-council] TEI Week in Berlin Message-ID: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 18:41:16 +0200</span><br /> </address> Dear all, <br /> Here's some update information about the TEI related events in Berlin <br /> next week. You will see below the outline of 3 events (you're not <br /> involved in the first one, but it's just to keep you informed), and I <br /> would like to ask at this stage for some volunteer to chair and ask <br /> as commentators for the workshop some of you have agreed to <br /> participate to (see program). <br /> Viele Gr??e, <br /> Laurent <br /> Summary of the TEI week in Berlin: <br /> ?eSciDoc-Textgrid TEI expert workshop? [you are not concerned by this <br /> - it's a joint tutorial between the two projects <br /> date: 24.04.07 <br /> place: <br /> Tagungsst?tte Harnack-Haus <br /> Ihnestra?e 16-20 <br /> 14195 Berlin <br /> http://www.harnackhaus-berlin.mpg.de <br /> timeframe: 13-17:30h <br /> ?Putting the TEI to the test? [see program below - I need two <br /> volunteers per session: one to chair and one to comment on the fly <br /> after the talks] <br /> date: 25.04.07 <br /> place: <br /> Tagungsst?tte Harnack-Haus <br /> Ihnestra?e 16-20 <br /> 14195 Berlin <br /> http://www.harnackhaus-berlin.mpg.de <br /> timeframe: 10:30 - 17:20h <br /> "TEI Council Meeting" [well you know about it, don't you?] <br /> date: 26.04.-27.04.07 <br /> place: <br /> Berlin-Brandenburgische Akademie der Wissenschaften <br /> Jaegerstr. 22/23 <br /> 10117 Berlin <br /> timeframe: 9-18h <br /> ---------------------------------------------------- <br /> Program TEI workshop Putting the TEI to the test, 25.04.07 <br /> 10:30 ? 11:00 <br /> Introductory Talk <br /> 10:30 ? 10:45 Christian Wittern: <br /> P5: current state and prospects <br /> 10:45 ? 11:00 Lou Burnard: <br /> P5: technical overview <br /> -------- <br /> 11:00 ? 13:10 <br /> 1. Session: Text-based projects <br /> Chair: N.N. <br /> 11:00 ? 11:15 Fotis Jannidis: <br /> Searching TEI texts in TextGrid using basic encodings <br /> 11:15 ? 11:30 Torsten Scha?an: <br /> Aspects of the integration of TEI in the workflows of the <br /> Wolfenbuettel digital library (WDB) <br /> 11:30 ? 12:00 <br /> joint discussion <br /> 12:00 ? 12:15 Christian Mahnke: <br /> Fulltext processing at the GDZ <br /> 12:15 ? 12:25 Bernhard Assmann: <br /> The application of TEI in the digitalization project of the work of <br /> Frederick the Great <br /> (status report, presentation in German) <br /> 12:25 ? 12:35 Thomas Burch: <br /> The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus <br /> (status report) <br /> 12:35 ? 13:10 <br /> joint discussion <br /> ----------- <br /> 13:10 - 14:00 <br /> lunch break <br /> --------- <br /> 14:00 ? 15:00 <br /> 2. Session: Charter <br /> Chair: N.N. <br /> 14:00 ? 14:30 Georg Vogeler: <br /> How to standardize XML-encoding of medieval and early modern charters <br /> and <br /> instruments <br /> 14:30 ? 15:00 <br /> discussion <br /> -------- <br /> 15:00 ? 16:00 <br /> 3. Session: Dictionaries <br /> Chair: N.N. <br /> 15:00 ? 15:15 Alexander Geyken: <br /> Representation of the German ?Woerterbuch der Gegenwartssprache? in TEI: <br /> encoding strategies and limitations <br /> 15:15 ? 15:30 Werner Wegstein: <br /> The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses <br /> 15:30 ? 16:00 <br /> joint discussion <br /> --------- <br /> 16:00 ? 16:20 <br /> coffee break <br /> ------- <br /> 16:20 ? 17:20 <br /> 4. Session: Linguistic Annotations <br /> Chair: N.N. <br /> 16:20 ? 16:35 Susanne Alt: <br /> TEI encoding of parallel texts: issues and proposals <br /> 16:35 ? 16:50 Andreas Witt: <br /> The Role of TEI-Annotations for the Sustainable Representation of <br /> Linguistic <br /> Resources <br /> 16:50 ? 17:20 <br /> joint discussion <br /> -------- <br /> 17:20 <br /> end of workshop <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 12:42:53 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 16:49:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 21:49:37 +0100 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <462532E1.2080304@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 21:49:37 +0100</span><br /> </address> I am happy to chair session 1 if you like <br /> ebastian <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 16:49:40 EDT</span> </div> From Syd_Bauman at Brown.edu Tue Apr 17 21:24:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Apr 2007 21:24:25 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <17957.29513.557381.774077@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 21:24:25 -0400</span><br /> </address> I am of course happy to assist you in any way I can; either chairing <br /> or commenting on any session would be fine. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 21:24:30 EDT</span> </div> From jawalsh at indiana.edu Tue Apr 17 22:10:35 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 17 Apr 2007 22:10:35 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <8D4537AF-D998-4FA6-BFF8-90F6184DB6CC@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 17 Apr 2007 22:10:35 -0400</span><br /> </address> Laurent, <br /> Feel free to plug me in as a chair or commentator for any session <br /> where you need people. <br /> John <br /> -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> On Apr 17, 2007, at 12:41 PM, Laurent Romary wrote: > Dear all, > Here's some update information about the TEI related events in > Berlin next week. You will see below the outline of 3 events > (you're not involved in the first one, but it's just to keep you > informed), and I would like to ask at this stage for some volunteer > to chair and ask as commentators for the workshop some of you have > agreed to participate to (see program). > Viele Gr??e, > Laurent > > Summary of the TEI week in Berlin: > > ?eSciDoc-Textgrid TEI expert workshop? [you are not concerned by > this - it's a joint tutorial between the two projects > date: 24.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 13-17:30h > > ?Putting the TEI to the test? [see program below - I need two > volunteers per session: one to chair and one to comment on the fly > after the talks] > date: 25.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 10:30 - 17:20h > > "TEI Council Meeting" [well you know about it, don't you?] > date: 26.04.-27.04.07 > place: > Berlin-Brandenburgische Akademie der Wissenschaften > Jaegerstr. 22/23 > 10117 Berlin > timeframe: 9-18h > > ---------------------------------------------------- > Program TEI workshop Putting the TEI to the test, 25.04.07 > > 10:30 ? 11:00 > Introductory Talk > 10:30 ? 10:45 Christian Wittern: > P5: current state and prospects > > 10:45 ? 11:00 Lou Burnard: > P5: technical overview > -------- > 11:00 ? 13:10 > 1. Session: Text-based projects > Chair: N.N. > > 11:00 ? 11:15 Fotis Jannidis: > Searching TEI texts in TextGrid using basic encodings > > 11:15 ? 11:30 Torsten Scha?an: > Aspects of the integration of TEI in the workflows of the > Wolfenbuettel digital library (WDB) > > 11:30 ? 12:00 > joint discussion > > 12:00 ? 12:15 Christian Mahnke: > Fulltext processing at the GDZ > > 12:15 ? 12:25 Bernhard Assmann: > The application of TEI in the digitalization project of the work of > Frederick the Great > (status report, presentation in German) > > 12:25 ? 12:35 Thomas Burch: > The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus > (status report) > > 12:35 ? 13:10 > joint discussion > ----------- > 13:10 - 14:00 > lunch break > --------- > 14:00 ? 15:00 > 2. Session: Charter > Chair: N.N. > > 14:00 ? 14:30 Georg Vogeler: > How to standardize XML-encoding of medieval and early modern > charters and > instruments > > 14:30 ? 15:00 > discussion > -------- > 15:00 ? 16:00 > 3. Session: Dictionaries > Chair: N.N. > > 15:00 ? 15:15 Alexander Geyken: > Representation of the German ?Woerterbuch der Gegenwartssprache? in > TEI: > encoding strategies and limitations > > 15:15 ? 15:30 Werner Wegstein: > The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses > > 15:30 ? 16:00 > joint discussion > --------- > 16:00 ? 16:20 > coffee break > ------- > 16:20 ? 17:20 > 4. Session: Linguistic Annotations > Chair: N.N. > > 16:20 ? 16:35 Susanne Alt: > TEI encoding of parallel texts: issues and proposals > > 16:35 ? 16:50 Andreas Witt: > The Role of TEI-Annotations for the Sustainable Representation of > Linguistic > Resources > > 16:50 ? 17:20 > joint discussion > -------- > 17:20 > end of workshop > > > _______________________________________________ > tei-council mailing list > tei-council_at_lists.<!--nospam-->village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 22:10:52 EDT</span> </div> From cwittern at gmail.com Tue Apr 17 22:55:33 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 18 Apr 2007 11:55:33 +0900 Subject: [tei-council] New elements in TEI Tite Message-ID: <462588A5.80307@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 11:55:33 +0900</span><br /> </address> Dear Council members, <br /> Users from the library community have submitted work done under the <br /> title "TEI Tite" to the TEI Board and Council. While I have hold off <br /> the announcement here to see what the Board thinks, it now seems to be <br /> justified to ask the Council's opinion on some specific items. <br /> The whole submission is available at <br /> http://artsci.wustl.edu/~ptrolard/tite.tgz. Within this archive, there <br /> is a document p5/teitite.odd, which is a P5 customization that defines a <br /> schema that is intended for the use of keyboarding companies, most <br /> likely with subsequent conversion to proper TEI. (More about the <br /> background of this is in preface/tei/preface-tei.pdf and <br /> preface/tei/preface-dlf.pdf, but I do not waste our time by requesting <br /> you to read it). <br /> Most of the modifications in Tite are deletions or syntactical sugar, <br /> but there are two elements newly defined. It seems worthwhile to ask <br /> the question, whether these should have a place in P5 as well. The two <br /> elements are defined as follows: <br /> <elementSpec ident="cols" mode="add"> <br /> <desc>(columns) with the "n" attribute (denoting new number of <br /> columns) is used to mark where a document changes columnar <br /> layout.</desc> <br /> <classes> <br /> <memberOf key="model.milestoneLike"/> <br /> </classes> <br /> <content> <br /> <rng:empty/> <br /> </content> <br /> <attList> <br /> <attDef ident="ed" mode="add"> <br /> <desc>indicates the edition or version in which the <br /> change in columnar layout is located at this <br /> point</desc> <br /> <datatype> <br /> <rng:ref name="data.code"/> <br /> </datatype> <br /> <!--<default value=""/> <br /> <valList type="open"/>--> <br /> </attDef> <br /> </attList> <br /> </elementSpec> <br /> <elementSpec ident="ornament" mode="add"> <br /> <desc>for capturing typographical feature: printer's ornament, <br /> horizontal line, strings of asterisks or periods, etc, <br /> indicating an informal division that does not call for a <br /> new <div> element. If a horizontal rule or <br /> printer's ornament, use appropriate "type" attribute and <br /> leave the element empty; if the ornament can be represented <br /> with characters, set "type" value to "characters" and <br /> include these in the element.</desc> <br /> <classes> <br /> <!-- <br /> ornament appears where figure can appear <br /> --> <br /> <memberOf key="model.inter"/> <br /> <memberOf key="model.titlepagePart"/> <br /> <memberOf key="model.common"/> <br /> <memberOf key="att.typed"/> <br /> </classes> <br /> <content> <br /> <rng:text/> <br /> </content> <br /> </elementSpec> <br /> <p><p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 22:55:40 EDT</span> </div> From cwittern at gmail.com Tue Apr 17 22:58:29 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 18 Apr 2007 11:58:29 +0900 Subject: [tei-council] Draft Agenda for Berlin meeting Message-ID: <46258955.4010705@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 11:58:29 +0900</span><br /> </address> Dear Council members, <br /> I am circulating the draft agenda. Please read through and report as <br /> indicated. If there are additional items that need to be added or other <br /> oversights, please say so. <br /> Christian <br /> <p>DRAFT Agenda for the TEI Council meeting in Berlin, April 26 to 27 <br /> <p>Expected to participate: <br /> Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna <br /> Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, <br /> Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian <br /> Wittern <br /> PART I <br /> 1) Adotion of Agenda <br /> 2) Minutes, work items, progress since last meeting: <br /> http://www.tei-c.org.uk/Council/tcm29.xml?style=printable <br /> Please look at the action items and report progress here before the <br /> meeting! <br /> <p>3) Reports on Chapter reviews <br /> Council members are expected to report on the outcome of the chapter <br /> review they have undertaken in the last weeks. It would be helpful, <br /> if you could provide a short summary of your findings, including the <br /> outstanding issues that have to be adressed. We will collect these <br /> issues during this phase and resolve them later. <br /> 4) Conformance Draft (JC) <br /> 5) Formatting of Guidelines (JC & DP) <br /> PART II <br /> 6) Resolution of outstanding issues: <br /> - proposal to add a metadata element to record application information <br /> (SR) <br /> - nyms (LB) <br /> - proposal for places & placenames (MD) <br /> - fascsimile markup (TC) <br /> - elements suggested for TEI Tite <br /> - ... (more to come? please remind me of other issues) <br /> <p>7) Adoption of Resolutions <br /> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 17 2007 - 22:58:37 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 03:59:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 08:59:34 +0100 Subject: [tei-council] New elements in TEI Tite In-Reply-To: <462588A5.80307@gmail.com> Message-ID: <4625CFE6.20008@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 08:59:34 +0100</span><br /> </address> I have made this ticket 321 in trac, to provide a context for resolution <br /> <em class="quotelev1">> </em><br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 03:59:37 EDT</span> </div> From Syd_Bauman at Brown.edu Wed Apr 18 05:44:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 18 Apr 2007 05:44:24 -0400 (EDT) Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <46238FFA.7030900@oucs.ox.ac.uk> Message-ID: <200704180944.l3I9iOBX009476@draco.services.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 05:44:24 -0400 (EDT)</span><br /> </address> In the following, I'm going to use "said" as the name of the proposed <br /> element for direct speech or thought only. The name is not carved in <br /> stone, but I think Sebastian, Dan, Julia and I all like it better <br /> than anything else that has been suggested. <br /> <p><em class="quotelev1">> I really do not agree with Syd on this issue </em><br /> <em class="quotelev1">> As I understand it, ... </em><br /> I'm curious then, Lou, whether you've changed your mind or it's just <br /> that I did such a bad job explaining the proposal, you didn't <br /> recognize it as the one to which we had already agreed! No matter, <br /> really, but I suspect I must have done a very poor job of explaining <br /> it, for your recap does not match the proposal well at all. Let me try <br /> again. <br /> <p>There were actually 2 proposals rolled up in my previous e-mail, so I <br /> will separate them explicitly here. <br /> In all cases here typographic distinction is no more important for <br /> these elements than it is for <soCalled> et al. That is, it is not <br /> relevant in the abstract, although it is important to some encoders & <br /> projects. <br /> <p>--- 1 --- <br /> Lou: this first proposal is exactly what we spoke at length about on <br /> the phone ~3 weeks ago. You were behind this proposal as long as we <br /> leave <q> as the general-purpose element. <br /> <said> is for direct speech (or its discursive equivalents: e.g. <br /> reported thought or speech, dialog, etc.), whether real or <br /> contrived, typically as part of the current text, although I <br /> suppose one could imagine otherwise. Most common usage is <br /> likely to be a character's spoken words in a novel or a <br /> person's spoken words reported in a non-fiction article. In <br /> English prose it will very often be associated with phrases <br /> like "he said", or "she asked". <said> would not be a viable <br /> child of <cit>. <br /> <quote> is for material that is quoted from sources outside the text, <br /> whether correctly or not, whether real or contrived, whether <br /> originally spoken or written. Most common usage is likely to <br /> be quoting passages from other documents. May be used in a <br /> dictionary for real or contrived examples of usage. <quote> <br /> would continue to be a viable child of <cit>. <br /> <q> is for passages quoted from elsewhere; in narrative, either <br /> direct or indirect speech or something being quoted from outside <br /> the text; in dictionaries, real or contrived examples of usage. <br /> <q> would continue to be a viable child of <cit>, for those who <br /> don't use the more specific <quote>. <br /> That is, <q> remains exactly as it was in P4; <quote> remains as it <br /> was in P4; <said> takes the role of only the "direct speech or thought" <br /> subset of what <q> handles. <br /> There are of course cases where people speak quotations or quotations <br /> include direct speech, in which case <quote> can go in <said> or <br /> vice-versa. <br /> Some people assert that they can't see the distinction between <quote> <br /> and the proposed <said>, and I'm sorry to say I simply can't <br /> understand this point of view. While there must be some difficult edge <br /> cases, as a general rule I do not think it is difficult to tell these <br /> two phenomena apart at all. I just picked up a mid-20th century <br /> science fiction novel and flipped through the pages. I had no trouble <br /> at all differentiating (the vast majority were <said>). I read an <br /> article in the NY Times over the weekend -- again, no trouble at all <br /> differentiating. I just asked Julia, and she said that in the creation <br /> of the entire WWP corpus so far there has never been a case where an <br /> encoder (most of whom are undergraduates) has had any difficulty making <br /> the distinction. There are 17,104 occurrences of <q> or <quote> <br /> start-tags in the distributed WWP corpus[2]. She said "it's harder to <br /> tell what is and isn't a <list> than it is to [differentiate between <br /> <said> and <quote>]". <br /> There is one definite hole in this proposal: as it is worded, the <br /> encoding of indirect speech (e.g. the bit about grapes in "He said <br /> that he doesn't like grapes") is forced into <q>. The only two <br /> reasonable solutions I see are: <br /> A. add indirect speech to semantics of <said> <br /> B. remove indirect speech from semantics of <q> <br /> Personally, I really don't care. I have never seen anyone encode <br /> indirect speech ever, but that doesn't mean there aren't cases out <br /> there. <br /> Here is a passage from an article about an anti-war protest that was <br /> held in Boston while we were in Sofia at the 2005 MM. <br /> <p>One demonstrator carried a sign that read, <quote>Bush Wants <br /> Your Children For Cannon Fodder,</quote> and another ...</p> <br /> <p>[Cindy Sheehan] mentioned a woman who had once e-mailed her <br /> after she cursed the Bush administration.</p> <br /> <p><said>She said, <said>Cindy, don't you want to use a little <br /> nicer language, because you know there might be people sitting on <br /> the fence that you offend,</said></said> Sheehan told the crowd. <br /> <said>And do you know what I said? I said, <said>Damn it, why is <br /> anybody on that fence still?</said></said> <br /> <p><said>A lot of people will come up to me and say, <said>My <br /> country right or wrong,</said></said> Sheehan added later. <br /> <said>And you know what I say? When my country is wrong, it is so <br /> wrong, and it is mandatory for us to stop it, to stop the killing, <br /> to stop the people in power.</said> <br /> -- http://www.commondreams.org/headlines05/1030-05.htm <br /> I will also note that off the top of my head I can't really see why an <br /> example of usage in a dictionary would be <q> instead of <quote>. <br /> Laurent? <br /> <p>--- 2 --- <br /> The second proposal is essentially an offshoot or amplification of the <br /> first. It stems from my observation that there are people out there <br /> who not only don't want to differentiate between <said> and <quote>, <br /> but who don't want to make the distinctions between <soCalled>, <br /> <mentioned>, <term>, etc., either. In many cases these encoders don't <br /> use any element (they just transcribe the quotation marks), but IIRC <br /> at least one library project used <q> for all of them. This second <br /> proposal leaves <said> and <quote> as they were in the first proposal, <br /> but expands the catchment of <q> to include all of these often- <br /> enclosed-in-quotation-marks sorts of phrase level phenomena: <br /> <q> id for any of a number of features when differentiating among <br /> them is not desired, e.g. because it is economically not feasible <br /> or simply not of interest for the current purpose. Items that may <br /> be encoded this way include <br /> - representation of speech or thought <br /> - quotation <br /> - technical terms and glosses <br /> - passages mentioned, not used <br /> - authorial distance <br /> and perhaps even <br /> - from a foreign language <br /> - linguistically distinct <br /> - emphasized <br /> - any other use of quotation marks in the source <br /> <p>Notes <br /> ----- <br /> [1] "Outside the text" here does not necessarily mean "not a <br /> descendant of my ancestor <text> element", but rather something <br /> quite a bit less precise, more along the lines of "not from 'round <br /> here". I.e., something in chapter 1 may be a <quote> even if the <br /> thing being quoted is a passage from chapter 3 of the same <br /> document. This, of course, blurs the line a bit, and may be worth <br /> consideration. <br /> [2] I did not say "elements" because many of these <q> and <quote> <br /> elements may be partial elements which, via next= and prev=, are <br /> only part of a complete aggregate element. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 05:44:27 EDT</span> </div> From cwittern at gmail.com Wed Apr 18 07:26:35 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 18 Apr 2007 20:26:35 +0900 Subject: [tei-council] Draft Agenda for Berlin meeting In-Reply-To: <CD07E394-DA40-4FB2-8CEA-99CD3C2A80F0@aksis.uib.no> Message-ID: <5268d87d0704180426x7f1db189q6a0e08deb97136df@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Christian Wittern <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 20:26:35 +0900</span><br /> </address> On 18/04/07, Tone Merete Bruvik <tone.bruvik_at_aksis.<!--nospam-->uib.no> wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Hello Christian, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Did you have in mind that we should do the reporting on "3) Reports on </em><br /> <em class="quotelev1">> Chapter reviews" before the meeting to the Council list or at the meeting, </em><br /> <em class="quotelev1">> or both? </em><br /> <em class="quotelev1">> </em><br /> Both :-) <br /> Thanks for the first part. <br /> All the best, <br /> Christian <br /> <p><em class="quotelev1">> To summaries that I have done: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> My chapters are "Ch. 1: Languages and Character Sets" and the last part of </em><br /> <em class="quotelev1">> ch. 24: "Using The TEI", that is "Multiple Hierarchies". I have done this by </em><br /> <em class="quotelev1">> adding comments to the trac system, as suggested in Lou's email "What to do </em><br /> <em class="quotelev1">> with an easter egg" as method "(b) add a comment to the TRAC ticket for </em><br /> <em class="quotelev1">> this chapter in this task, leaving the ticket open for someone else to </em><br /> <em class="quotelev1">> complete the required action". See the trac system for details. </em><br /> -- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 07:26:39 EDT</span> </div> From Syd_Bauman at Brown.edu Wed Apr 18 07:44:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 18 Apr 2007 07:44:09 -0400 Subject: [tei-council] Trac err, anyone? Message-ID: <17958.1161.251387.587569@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 07:44:09 -0400</span><br /> </address> Is anyone else getting "Oops... Trac detected an internal error:" <br /> followed by a Python traceback from <br /> http://tei.oucs.ox.ac.uk/trac/TEIP5 or <br /> http://tei.oucs.ox.ac.uk/trac/TEIP5/login? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 07:44:13 EDT</span> </div> From arianna.ciula at kcl.ac.uk Wed Apr 18 07:49:10 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 18 Apr 2007 12:49:10 +0100 Subject: [tei-council] Draft Agenda for Berlin meeting In-Reply-To: <5268d87d0704180426x7f1db189q6a0e08deb97136df@mail.gmail.com> Message-ID: <462605B6.6020203@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 12:49:10 +0100</span><br /> </address> Hi, <br /> you will find the comments on the chapters I was supposed to proofread <br /> in the tickets assigned to me in Trac. I am sorry these comments are <br /> very fragmentary, but I can make a brief summary for Berlin. <br /> I have sent only to Lou some additional comments about the extension <br /> proposed for places for ND with the suggestion to ask feedback from the <br /> council after he had a look through it. <br /> I believe work has started already on all these chapters, in part based <br /> on some of my comments, so it may be not that useful to report on my <br /> proofreading, but rather on the work that has been done by the editors <br /> on them. <br /> Arianna <br /> Christian Wittern wrote: <br /> <em class="quotelev1">> On 18/04/07, Tone Merete Bruvik <tone.bruvik_at_aksis.<!--nospam-->uib.no> wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Hello Christian, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Did you have in mind that we should do the reporting on "3) Reports on </em><br /> <em class="quotelev2">>> Chapter reviews" before the meeting to the Council list or at the </em><br /> <em class="quotelev2">>> meeting, </em><br /> <em class="quotelev2">>> or both? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> Both :-) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Thanks for the first part. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> All the best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Christian </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> To summaries that I have done: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> My chapters are "Ch. 1: Languages and Character Sets" and the last </em><br /> <em class="quotelev2">>> part of </em><br /> <em class="quotelev2">>> ch. 24: "Using The TEI", that is "Multiple Hierarchies". I have done </em><br /> <em class="quotelev2">>> this by </em><br /> <em class="quotelev2">>> adding comments to the trac system, as suggested in Lou's email "What </em><br /> <em class="quotelev2">>> to do </em><br /> <em class="quotelev2">>> with an easter egg" as method "(b) add a comment to the TRAC ticket for </em><br /> <em class="quotelev2">>> this chapter in this task, leaving the ticket open for someone else to </em><br /> <em class="quotelev2">>> complete the required action". See the trac system for details. </em><br /> <em class="quotelev1">> </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 07:49:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 09:04:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 14:04:21 +0100 Subject: [tei-council] Trac err, anyone? In-Reply-To: <17958.1161.251387.587569@emt.wwp.brown.edu> Message-ID: <46261755.8000104@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 14:04:21 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> Is anyone else getting "Oops... Trac detected an internal error:" </em><br /> <em class="quotelev1">> followed by a Python traceback from </em><br /> <em class="quotelev1">> http://tei.oucs.ox.ac.uk/trac/TEIP5 or </em><br /> <em class="quotelev1">> http://tei.oucs.ox.ac.uk/trac/TEIP5/login? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> sory about that, restored service now. <br /> <br /> it happens because we run kernel 2.6.15, <br /> and our SAN triggers a bug which existed from <br /> 2.6.13 to 2.6.15. <br /> Sigh. You did want to know, right? Am considering <br /> a dist-upgrade. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 09:04:25 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 12:01:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 17:01:06 +0100 Subject: [tei-council] trac Message-ID: <462640C2.2060202@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 17:01:06 +0100</span><br /> </address> sorry, this is off briefly after an upgrade. back very soon <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 12:01:09 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 12:48:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 17:48:14 +0100 Subject: [tei-council] trac Message-ID: <46264BCE.8050105@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 17:48:14 +0100</span><br /> </address> back now. <br /> hopefully the OS upgrade we just did will stop the problem which <br /> caused Roma and trac to fall over twice this month. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 12:48:18 EDT</span> </div> From daniel.odonnell at uleth.ca Wed Apr 18 14:04:00 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 18 Apr 2007 12:04:00 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704180944.l3I9iOBX009476@draco.services.brown.edu> Message-ID: <1176919440.12509.14.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 18 Apr 2007 12:04:00 -0600</span><br /> </address> I understand the point of this much more clearly now and see that it is <br /> not necessarily creating artificial or uncommon distinctions. For <br /> reasons that have never been clear to me (which may be where the problem <br /> lies) q:quote is one of the distinctions I always need to look up, and I <br /> can see me having to do the same with q:quote:said. But I think that's <br /> me rather than the element. <br /> So basically the idea is: <br /> a) if you don't care about distinguishing anything that might appear in <br /> quotations, or can't decide use q <br /> b) If you do care, use quote for things that are documentable in <br /> principle--i.e. quotations of speech or text or whatever from somewhere <br /> else. <br /> c) If you are reporting what was said, written, or thought <br /> spontaneously, use said. <br /> <p>President Bush read <quote>underestimate</quote> from the <br /> teleprompter, but said <said>misunderestimate</said>. He got the next <br /> bit right, though, when he said <said>us</us> which agreed exactly with <br /> the teleprompter's <quote>us</quote>.</p> <br /> <p>When I said <quote>The insurgency's in its last throes</quote>, I <br /> didn't say how long they'd last.</p> <br /> <p>I think that it is useful to keep open the possibility of marking <br /> indirect speech, though of course that could be done using <seg>, since <br /> I can think off the top of my head, as I was saying to Syd, of a <br /> research project that could usefully mark direct and indirect speech for <br /> analysis. <br /> -dan <br /> <p><p>On Wed, 2007-18-04 at 05:44 -0400, Syd Bauman wrote: <br /> <em class="quotelev1">> In the following, I'm going to use "said" as the name of the proposed </em><br /> <em class="quotelev1">> element for direct speech or thought only. The name is not carved in </em><br /> <em class="quotelev1">> stone, but I think Sebastian, Dan, Julia and I all like it better </em><br /> <em class="quotelev1">> than anything else that has been suggested. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > I really do not agree with Syd on this issue </em><br /> <em class="quotelev2">> > As I understand it, ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm curious then, Lou, whether you've changed your mind or it's just </em><br /> <em class="quotelev1">> that I did such a bad job explaining the proposal, you didn't </em><br /> <em class="quotelev1">> recognize it as the one to which we had already agreed! No matter, </em><br /> <em class="quotelev1">> really, but I suspect I must have done a very poor job of explaining </em><br /> <em class="quotelev1">> it, for your recap does not match the proposal well at all. Let me try </em><br /> <em class="quotelev1">> again. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> There were actually 2 proposals rolled up in my previous e-mail, so I </em><br /> <em class="quotelev1">> will separate them explicitly here. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In all cases here typographic distinction is no more important for </em><br /> <em class="quotelev1">> these elements than it is for <soCalled> et al. That is, it is not </em><br /> <em class="quotelev1">> relevant in the abstract, although it is important to some encoders & </em><br /> <em class="quotelev1">> projects. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --- 1 --- </em><br /> <em class="quotelev1">> Lou: this first proposal is exactly what we spoke at length about on </em><br /> <em class="quotelev1">> the phone ~3 weeks ago. You were behind this proposal as long as we </em><br /> <em class="quotelev1">> leave <q> as the general-purpose element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <said> is for direct speech (or its discursive equivalents: e.g. </em><br /> <em class="quotelev1">> reported thought or speech, dialog, etc.), whether real or </em><br /> <em class="quotelev1">> contrived, typically as part of the current text, although I </em><br /> <em class="quotelev1">> suppose one could imagine otherwise. Most common usage is </em><br /> <em class="quotelev1">> likely to be a character's spoken words in a novel or a </em><br /> <em class="quotelev1">> person's spoken words reported in a non-fiction article. In </em><br /> <em class="quotelev1">> English prose it will very often be associated with phrases </em><br /> <em class="quotelev1">> like "he said", or "she asked". <said> would not be a viable </em><br /> <em class="quotelev1">> child of <cit>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <quote> is for material that is quoted from sources outside the text, </em><br /> <em class="quotelev1">> whether correctly or not, whether real or contrived, whether </em><br /> <em class="quotelev1">> originally spoken or written. Most common usage is likely to </em><br /> <em class="quotelev1">> be quoting passages from other documents. May be used in a </em><br /> <em class="quotelev1">> dictionary for real or contrived examples of usage. <quote> </em><br /> <em class="quotelev1">> would continue to be a viable child of <cit>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <q> is for passages quoted from elsewhere; in narrative, either </em><br /> <em class="quotelev1">> direct or indirect speech or something being quoted from outside </em><br /> <em class="quotelev1">> the text; in dictionaries, real or contrived examples of usage. </em><br /> <em class="quotelev1">> <q> would continue to be a viable child of <cit>, for those who </em><br /> <em class="quotelev1">> don't use the more specific <quote>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> That is, <q> remains exactly as it was in P4; <quote> remains as it </em><br /> <em class="quotelev1">> was in P4; <said> takes the role of only the "direct speech or thought" </em><br /> <em class="quotelev1">> subset of what <q> handles. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> There are of course cases where people speak quotations or quotations </em><br /> <em class="quotelev1">> include direct speech, in which case <quote> can go in <said> or </em><br /> <em class="quotelev1">> vice-versa. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Some people assert that they can't see the distinction between <quote> </em><br /> <em class="quotelev1">> and the proposed <said>, and I'm sorry to say I simply can't </em><br /> <em class="quotelev1">> understand this point of view. While there must be some difficult edge </em><br /> <em class="quotelev1">> cases, as a general rule I do not think it is difficult to tell these </em><br /> <em class="quotelev1">> two phenomena apart at all. I just picked up a mid-20th century </em><br /> <em class="quotelev1">> science fiction novel and flipped through the pages. I had no trouble </em><br /> <em class="quotelev1">> at all differentiating (the vast majority were <said>). I read an </em><br /> <em class="quotelev1">> article in the NY Times over the weekend -- again, no trouble at all </em><br /> <em class="quotelev1">> differentiating. I just asked Julia, and she said that in the creation </em><br /> <em class="quotelev1">> of the entire WWP corpus so far there has never been a case where an </em><br /> <em class="quotelev1">> encoder (most of whom are undergraduates) has had any difficulty making </em><br /> <em class="quotelev1">> the distinction. There are 17,104 occurrences of <q> or <quote> </em><br /> <em class="quotelev1">> start-tags in the distributed WWP corpus[2]. She said "it's harder to </em><br /> <em class="quotelev1">> tell what is and isn't a <list> than it is to [differentiate between </em><br /> <em class="quotelev1">> <said> and <quote>]". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> There is one definite hole in this proposal: as it is worded, the </em><br /> <em class="quotelev1">> encoding of indirect speech (e.g. the bit about grapes in "He said </em><br /> <em class="quotelev1">> that he doesn't like grapes") is forced into <q>. The only two </em><br /> <em class="quotelev1">> reasonable solutions I see are: </em><br /> <em class="quotelev1">> A. add indirect speech to semantics of <said> </em><br /> <em class="quotelev1">> B. remove indirect speech from semantics of <q> </em><br /> <em class="quotelev1">> Personally, I really don't care. I have never seen anyone encode </em><br /> <em class="quotelev1">> indirect speech ever, but that doesn't mean there aren't cases out </em><br /> <em class="quotelev1">> there. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Here is a passage from an article about an anti-war protest that was </em><br /> <em class="quotelev1">> held in Boston while we were in Sofia at the 2005 MM. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <p>One demonstrator carried a sign that read, <quote>Bush Wants </em><br /> <em class="quotelev1">> Your Children For Cannon Fodder,</quote> and another ...</p> </em><br /> <em class="quotelev1">> <p>[Cindy Sheehan] mentioned a woman who had once e-mailed her </em><br /> <em class="quotelev1">> after she cursed the Bush administration.</p> </em><br /> <em class="quotelev1">> <p><said>She said, <said>Cindy, don't you want to use a little </em><br /> <em class="quotelev1">> nicer language, because you know there might be people sitting on </em><br /> <em class="quotelev1">> the fence that you offend,</said></said> Sheehan told the crowd. </em><br /> <em class="quotelev1">> <said>And do you know what I said? I said, <said>Damn it, why is </em><br /> <em class="quotelev1">> anybody on that fence still?</said></said> </em><br /> <em class="quotelev1">> <p><said>A lot of people will come up to me and say, <said>My </em><br /> <em class="quotelev1">> country right or wrong,</said></said> Sheehan added later. </em><br /> <em class="quotelev1">> <said>And you know what I say? When my country is wrong, it is so </em><br /> <em class="quotelev1">> wrong, and it is mandatory for us to stop it, to stop the killing, </em><br /> <em class="quotelev1">> to stop the people in power.</said> </em><br /> <em class="quotelev1">> -- http://www.commondreams.org/headlines05/1030-05.htm </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I will also note that off the top of my head I can't really see why an </em><br /> <em class="quotelev1">> example of usage in a dictionary would be <q> instead of <quote>. </em><br /> <em class="quotelev1">> Laurent? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --- 2 --- </em><br /> <em class="quotelev1">> The second proposal is essentially an offshoot or amplification of the </em><br /> <em class="quotelev1">> first. It stems from my observation that there are people out there </em><br /> <em class="quotelev1">> who not only don't want to differentiate between <said> and <quote>, </em><br /> <em class="quotelev1">> but who don't want to make the distinctions between <soCalled>, </em><br /> <em class="quotelev1">> <mentioned>, <term>, etc., either. In many cases these encoders don't </em><br /> <em class="quotelev1">> use any element (they just transcribe the quotation marks), but IIRC </em><br /> <em class="quotelev1">> at least one library project used <q> for all of them. This second </em><br /> <em class="quotelev1">> proposal leaves <said> and <quote> as they were in the first proposal, </em><br /> <em class="quotelev1">> but expands the catchment of <q> to include all of these often- </em><br /> <em class="quotelev1">> enclosed-in-quotation-marks sorts of phrase level phenomena: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <q> id for any of a number of features when differentiating among </em><br /> <em class="quotelev1">> them is not desired, e.g. because it is economically not feasible </em><br /> <em class="quotelev1">> or simply not of interest for the current purpose. Items that may </em><br /> <em class="quotelev1">> be encoded this way include </em><br /> <em class="quotelev1">> - representation of speech or thought </em><br /> <em class="quotelev1">> - quotation </em><br /> <em class="quotelev1">> - technical terms and glosses </em><br /> <em class="quotelev1">> - passages mentioned, not used </em><br /> <em class="quotelev1">> - authorial distance </em><br /> <em class="quotelev1">> and perhaps even </em><br /> <em class="quotelev1">> - from a foreign language </em><br /> <em class="quotelev1">> - linguistically distinct </em><br /> <em class="quotelev1">> - emphasized </em><br /> <em class="quotelev1">> - any other use of quotation marks in the source </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Notes </em><br /> <em class="quotelev1">> ----- </em><br /> <em class="quotelev1">> [1] "Outside the text" here does not necessarily mean "not a </em><br /> <em class="quotelev1">> descendant of my ancestor <text> element", but rather something </em><br /> <em class="quotelev1">> quite a bit less precise, more along the lines of "not from 'round </em><br /> <em class="quotelev1">> here". I.e., something in chapter 1 may be a <quote> even if the </em><br /> <em class="quotelev1">> thing being quoted is a passage from chapter 3 of the same </em><br /> <em class="quotelev1">> document. This, of course, blurs the line a bit, and may be worth </em><br /> <em class="quotelev1">> consideration. </em><br /> <em class="quotelev1">> [2] I did not say "elements" because many of these <q> and <quote> </em><br /> <em class="quotelev1">> elements may be partial elements which, via next= and prev=, are </em><br /> <em class="quotelev1">> only part of a complete aggregate element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 18 2007 - 13:59:45 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 19 10:09:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 10:09:57 -0400 Subject: [tei-council] proposed re-org of div wrapping Message-ID: <17959.30773.719929.754597@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 10:09:57 -0400</span><br /> </address> First, has anyone looked at or tested this limited phrase stuff yet? <br /> Second, in order to fix the content of <div> and permit an element <br /> for postscripts (which I propose to call <ps>), I am planning to <br /> re-organize the div wrapper classes. <br /> --------- current arrangement --------- <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> epigraph head opener salute <br /> model.divWrapper.bottom = closer signed trailer <br /> <p>model.divWrapper is in the content model of lots of things, typically <br /> both at the top & bottom. <br /> model.divWrapper is in the content model of almost all the same <br /> things (but not <divGen> nor <castList>), but only at the bottom. <br /> <p>--------- proposed arrangement --------- <br /> model.divTop = head opener salute epigraph <br /> model.divBottom = closed signed trailer ps <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> In general, model.divWrapper & model.divTop will be used near the <br /> tops of things; and correspondingly, model.divWrapper and <br /> model.divBottom would be used near the bottom. <br /> --------- <br /> This becomes a bit of a problem for <divGen>, which I just realized <br /> is permitted to have content. (It is required to be empty in P3 & P4, <br /> and was in P5 until we changed how the <index> element worked in <br /> summer 2005. I'm at a bit of a loss at the moment -- can someone <br /> explain to me why we did this? Why would <divGen> need content?) <br /> <p>Please speak up if you have any thoughts about this. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 10:10:00 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 19 10:16:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 19 Apr 2007 15:16:03 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <462779A3.3040105@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 15:16:03 +0100</span><br /> </address> Can you summarize how <div> is broken at present? it <br /> had some major surgery not too long ago already. <br /> I am wondering what problem your proposal is <br /> solving. Sleeping dogs and all that. <br /> Limited phrase - no. I was vaguely trusting <br /> the test suite. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 10:16:07 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 10:30:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 19 Apr 2007 15:30:29 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <46277D05.8090604@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 15:30:29 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> First, has anyone looked at or tested this limited phrase stuff yet? </em><br /> I'm still hoping for a report on what exactly you've done, but if you <br /> want it tested, the quickest method would be to hack together a quick <br /> test file in the tests directory, no? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Second, in order to fix the content of <div> and permit an element </em><br /> <em class="quotelev1">> for postscripts (which I propose to call <ps>), I am planning to </em><br /> <em class="quotelev1">> re-organize the div wrapper classes. </em><br /> Eh? Hang on! where did this postscript element come from? is there a <br /> sffr or trac item about it? why do you think the content model of div is <br /> broken? <br /> <p><p><em class="quotelev1">> </em><br /> <em class="quotelev1">> --------- current arrangement --------- </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> epigraph head opener salute </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divWrapper.bottom = closer signed trailer </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divWrapper is in the content model of lots of things, typically </em><br /> <em class="quotelev1">> both at the top & bottom. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divWrapper is in the content model of almost all the same </em><br /> ^.bottom, I presume <br /> <em class="quotelev1">> things (but not <divGen> nor <castList>), but only at the bottom. </em><br /> <p><em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --------- proposed arrangement --------- </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divTop = head opener salute epigraph </em><br /> <em class="quotelev1">> model.divBottom = closed signed trailer ps </em><br /> <em class="quotelev1">> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> </em><br /> this is not far from what we used to have, before (in Oxford) we decided <br /> to make divWrapper.bottom a subclass of divWrapper, and make divWrapper <br /> a combination of the old divTop and divBottom <br /> Why are you revisiting this issue? <br /> <em class="quotelev1">> In general, model.divWrapper & model.divTop will be used near the </em><br /> <em class="quotelev1">> tops of things; and correspondingly, model.divWrapper and </em><br /> <em class="quotelev1">> model.divBottom would be used near the bottom. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --------- </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This becomes a bit of a problem for <divGen>, which I just realized </em><br /> <em class="quotelev1">> is permitted to have content. (It is required to be empty in P3 & P4, </em><br /> <em class="quotelev1">> and was in P5 until we changed how the <index> element worked in </em><br /> <em class="quotelev1">> summer 2005. I'm at a bit of a loss at the moment -- can someone </em><br /> <em class="quotelev1">> explain to me why we did this? Why would <divGen> need content?) </em><br /> <em class="quotelev1">> </em><br /> divGen is supposed to behave just like a div, except that its content <br /> can be generated. If it's a div it has to be able to have divWrapper <br /> elements inside it. It's a convenience for the encoder if the divWrapper <br /> elements can be explicitly attached to the divGen rather than generated <br /> along with the content. I don't think it's anything to do with <index> <br /> particularly. <br /> <p><p><em class="quotelev1">> </em><br /> <em class="quotelev1">> Please speak up if you have any thoughts about this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 10:32:55 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu Apr 19 11:00:24 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 19 Apr 2007 16:00:24 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <46278408.9060401@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 16:00:24 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> model.divWrapper is in the content model of almost all the same </em><br /> <em class="quotelev1">> things (but not <divGen> nor <castList>), but only at the bottom. </em><br /> I think you mean model.divWrapper.bottom here. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --------- proposed arrangement --------- </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divTop = head opener salute epigraph </em><br /> <em class="quotelev1">> model.divBottom = closed signed trailer ps </em><br /> <em class="quotelev1">> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In general, model.divWrapper & model.divTop will be used near the </em><br /> <em class="quotelev1">> tops of things; and correspondingly, model.divWrapper and </em><br /> <em class="quotelev1">> model.divBottom would be used near the bottom. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> --------- </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This becomes a bit of a problem for <divGen>, which I just realized </em><br /> <em class="quotelev1">> is permitted to have content. (It is required to be empty in P3 & P4, </em><br /> <em class="quotelev1">> and was in P5 until we changed how the <index> element worked in </em><br /> <em class="quotelev1">> summer 2005. I'm at a bit of a loss at the moment -- can someone </em><br /> <em class="quotelev1">> explain to me why we did this? Why would <divGen> need content?) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Please speak up if you have any thoughts about this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 11:00:21 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 19 11:27:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 11:27:38 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <462779A3.3040105@oucs.ox.ac.uk> Message-ID: <17959.35434.210454.689469@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 11:27:38 -0400</span><br /> </address> <em class="quotelev1">> Can you summarize how <div> is broken at present? </em><br /> The main issue is that <head> & <opener> are premitted near the end <br /> of a division. <br /> <p><em class="quotelev1">> Limited phrase - no. I was vaguely trusting the test suite. </em><br /> I haven't looked to see if any of the test suite stresses this yet, <br /> although some of it probably does. The fact that nothing new seems to <br /> break in there is good sign, and I hope to check that there are a few <br /> tests in there or explicitly add them soon, but nonetheless I'd like <br /> someone to say "I tried it against my P5 docs, and ..." <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 11:27:41 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 19 15:09:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 15:09:23 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46277D05.8090604@oucs.ox.ac.uk> Message-ID: <17959.48739.941886.134351@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 15:09:23 -0400</span><br /> </address> <em class="quotelev1">> Eh? Hang on! where did this postscript element come from? is there </em><br /> <em class="quotelev1">> a sffr or trac item about it? </em><br /> IIRC, you were the one who said that while we can publish P5 1.0 <br /> without a letters & memos module, not having a method for encoding <br /> postscripts would be an embarrassment. <br /> <p><em class="quotelev1">> why do you think the content model of div is broken? </em><br /> Because <head> and <opener> are allowed at the bottom where they <br /> shouldn't be. <br /> <p><em class="quotelev2">> > model.divTop = head opener salute epigraph </em><br /> <em class="quotelev2">> > model.divBottom = closed signed trailer ps </em><br /> <em class="quotelev2">> > model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> this is not far from what we used to have, before (in Oxford) we </em><br /> <em class="quotelev1">> decided to make divWrapper.bottom a subclass of divWrapper, and </em><br /> <em class="quotelev1">> make divWrapper a combination of the old divTop and divBottom </em><br /> <em class="quotelev1">> Why are you revisiting this issue? </em><br /> You are correct, it is quite similar. I'm revisiting it because as <br /> implemented bottom-in-Wrapper turns out not to work.[1] I wonder if <br /> it wouldn't be better to use different names, though. <br /> model.div.start, model.div.end? <br /> BTW, the proposal I sketched out was to keep the three models <br /> separate, but it might be cleaner to have only 2 classes that get <br /> referenced from content models. I.e., instead of what I sketched out, <br /> have <br /> model.divTop = model.divWrapper head opener salute epigraph <br /> model.divBottom = model.divWrapper closed signed trailer ps <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> So rather than having thinks like <br /> ( model.divTop | model.divWrapper )* <br /> in content models, you'd have only <br /> model.divTop* <br /> Since I can't see any reason to want to refer to the top-only things <br /> by themselves from within content, this may make more sense. <br /> <p><em class="quotelev1">> divGen is supposed to behave just like a div, except that its </em><br /> <em class="quotelev1">> content can be generated. If it's a div it has to be able to have </em><br /> <em class="quotelev1">> divWrapper elements inside it. It's a convenience for the encoder </em><br /> <em class="quotelev1">> if the divWrapper elements can be explicitly attached to the divGen </em><br /> <em class="quotelev1">> rather than generated along with the content. I don't think it's </em><br /> <em class="quotelev1">> anything to do with <index> particularly. </em><br /> Hmmm ... I suppose I can see how it might be more convenient to have <br /> some of the stuff surrounding the generated content in the source <br /> XML. <br /> <divGen type="stats"> <br /> <head>Statistics</head> <br /> </divGen> <br /> Although it's a little harder to see the case for <argument>, <br /> <epigraph>, or <salute>, let's presume there is a case. But if so, <br /> why not <closed>, <signed>, or <trailer>? <br /> [Lots of train-of-thought that is unnecessary but some may find mildly <br /> interesting moved from here to appendix.] <br /> What is the difference, in P4, between <div> and <divGen>? Simple: <br /> the former is *required* to have content, the latter is *required* to <br /> be empty. (Oh, yeah, and they have different names :-) In the current <br /> instantiation of P5, though, <div> is not required to have content <br /> and <divGen> is permitted to have some (but not all). Why not just <br /> ditch <divGen> entirely, and advise people to use <br /> <div type="generatedIndex"/> <br /> or whatever? Or perhaps we can add <div> to att.typed (taking type= <br /> out of att.divLike), so that there's a subtype=: <br /> <div type="generated" subtype="index"/> <br /> The semantics of the suggested value "generated" could be applied to <br /> other elements as well. <ab> jumps to mind, but I chuckle when I <br /> think what it means to see <lg type="generated" subtype="sonnet"> :-) <br /> (I guess I could quite easily be convinced that type= is not the <br /> right attribute here, but that there should be generated= of <br /> data.truthValue.) <br /> Note <br /> ---- [1] The system we currently have doesn't match what we decided in Oxford, I don't think; but it's not completely clear to me, and not important at this point. Appendix -------- There might well be other content that I'd prefer not to bother auto-generating, too. E.g. <divGen type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> </divGen> But if we allow either the above *or* having both div-top-stuff and then div-bottom-stuff, we need some mechanism for saying "put the generated content here". E.g. <divGen type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> <put-it-here/> <p>Any discrepancies in the table above ...</p> </divGen> or <divGen type="FuncInd"> <head>index of functions</head> <put-it-here/> <trailer>only functions written in ...</trailer> </divGen> If we're going to have some mechanism for "put the generated content here", why not call it <divGen>? E.g.: <div type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> <divGen type="genStats"/> <p>Any discrepancies in the table above ...</p> </div> or <div type="functionIndex"> <head>index of functions</head> <divGen type="funcs"/> <trailer>only functions written in ...</trailer> </divGen> The answer is, of course, because the statics example above is neither valid nor in harmony with the semantics of divisions. So perhaps there should be an <abGen>? _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 15:09:27 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 17:49:38 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 19 Apr 2007 22:49:38 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.48739.941886.134351@emt.wwp.brown.edu> Message-ID: <4627E3F2.3010307@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 22:49:38 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> Eh? Hang on! where did this postscript element come from? is there </em><br /> <em class="quotelev2">>> a sffr or trac item about it? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> IIRC, you were the one who said that while we can publish P5 1.0 </em><br /> <em class="quotelev1">> without a letters & memos module, not having a method for encoding </em><br /> <em class="quotelev1">> postscripts would be an embarrassment. </em><br /> <em class="quotelev1">> </em><br /> Did I really. But that doesn't actually answer my question, does it? <br /> <p><em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> why do you think the content model of div is broken? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Because <head> and <opener> are allowed at the bottom where they </em><br /> <em class="quotelev1">> shouldn't be. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> It depends what you mean by "bottom". If you have a div that has only a <br /> head in it, that's OK in my book, even tho the head is at the bottom. I <br /> assume that what you're objecting to is <div><p/><head/></div> which i <br /> agree looks decidedly broken. If you have a proposed revision of the <br /> divWrapper bit of the class system which provides a solution to this <br /> then so much the better: let's see it properly worked out and tested. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev3">>>> model.divTop = head opener salute epigraph </em><br /> <em class="quotelev3">>>> model.divBottom = closed signed trailer ps </em><br /> <em class="quotelev3">>>> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> this is not far from what we used to have, before (in Oxford) we </em><br /> <em class="quotelev2">>> decided to make divWrapper.bottom a subclass of divWrapper, and </em><br /> <em class="quotelev2">>> make divWrapper a combination of the old divTop and divBottom </em><br /> <em class="quotelev2">>> Why are you revisiting this issue? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> You are correct, it is quite similar. I'm revisiting it because as </em><br /> <em class="quotelev1">> implemented bottom-in-Wrapper turns out not to work.[1] I wonder if </em><br /> <em class="quotelev1">> it wouldn't be better to use different names, though. </em><br /> <em class="quotelev1">> model.div.start, model.div.end? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> let's stick with top and bottom for the moment -- we might want start <br /> and end for horseification purposes one day. <br /> <em class="quotelev1">> BTW, the proposal I sketched out was to keep the three models </em><br /> <em class="quotelev1">> separate, but it might be cleaner to have only 2 classes that get </em><br /> <em class="quotelev1">> referenced from content models. I.e., instead of what I sketched out, </em><br /> <em class="quotelev1">> have </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divTop = model.divWrapper head opener salute epigraph </em><br /> <em class="quotelev1">> model.divBottom = model.divWrapper closed signed trailer ps </em><br /> <em class="quotelev1">> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> I dont understand this: once a class is defined it can be used anywhere. <br /> Or are you proposing macros here? <br /> <p><em class="quotelev2">>> divGen is supposed to behave just like a div, except that its </em><br /> <em class="quotelev2">>> content can be generated. If it's a div it has to be able to have </em><br /> <em class="quotelev2">>> divWrapper elements inside it. It's a convenience for the encoder </em><br /> <em class="quotelev2">>> if the divWrapper elements can be explicitly attached to the divGen </em><br /> <em class="quotelev2">>> rather than generated along with the content. I don't think it's </em><br /> <em class="quotelev2">>> anything to do with <index> particularly. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Hmmm ... I suppose I can see how it might be more convenient to have </em><br /> <em class="quotelev1">> some of the stuff surrounding the generated content in the source </em><br /> <em class="quotelev1">> XML. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <divGen type="stats"> </em><br /> <em class="quotelev1">> <head>Statistics</head> </em><br /> <em class="quotelev1">> </divGen> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Although it's a little harder to see the case for <argument>, </em><br /> <em class="quotelev1">> <epigraph>, or <salute>, let's presume there is a case. But if so, </em><br /> <em class="quotelev1">> why not <closed>, <signed>, or <trailer>? </em><br /> <em class="quotelev1">> </em><br /> you mean, why does divGen contain divWrapper but not divWrapper.bottom? <br /> fair question, and the answer is probably just an oversight. when you've <br /> sorted the classes out.... <br /> <em class="quotelev1">> Why not just </em><br /> <em class="quotelev1">> ditch <divGen> entirely, and advise people to use </em><br /> <em class="quotelev1">> <div type="generatedIndex"/> </em><br /> <em class="quotelev1">> or whatever? Or perhaps we can add <div> to att.typed (taking type= </em><br /> <em class="quotelev1">> out of att.divLike), so that there's a subtype=: </em><br /> <em class="quotelev1">> <div type="generated" subtype="index"/> </em><br /> <em class="quotelev1">> </em><br /> Plausible. But I still think a <divGen> really is quite a different <br /> sort of beast from a <div> all the same. <br /> <p><em class="quotelev1">> The semantics of the suggested value "generated" could be applied to </em><br /> <em class="quotelev1">> other elements as well. <ab> jumps to mind, but I chuckle when I </em><br /> <em class="quotelev1">> think what it means to see <lg type="generated" subtype="sonnet"> :-) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> That way madness lies. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 17:49:42 EDT</span> </div> From Syd_Bauman at Brown.edu Thu Apr 19 18:38:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 18:38:02 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <4627E3F2.3010307@computing-services.oxford.ac.uk> Message-ID: <17959.61258.201695.143086@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 19 Apr 2007 18:38:02 -0400</span><br /> </address> <em class="quotelev1">> Did I really. But that doesn't actually answer my question, does </em><br /> <em class="quotelev1">> it? </em><br /> No, I don't think there is a specific SFFR or Trac ticket for <br /> postscript. There probably should be. Sebastian probably even asked <br /> me to make one. I will shortly. <br /> <p><em class="quotelev1">> I assume that what you're objecting to is <div><p/><head/></div> </em><br /> <em class="quotelev1">> which i agree looks decidedly broken. </em><br /> Exactly. <br /> <p><em class="quotelev1">> If you have a proposed revision of the divWrapper bit of the class </em><br /> <em class="quotelev1">> system which provides a solution to this then so much the better: </em><br /> I do and I posted it. <br /> <p><em class="quotelev1">> let's see it properly worked out and tested. </em><br /> I was just making sure there were no objections before I implemented <br /> it. However, now that I've thought about it, I would like opinions on <br /> which is better, three separate classes: <br /> <br /> model.divTop = head opener salute epigraph <br /> model.divBottom = closed signed trailer ps <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> In which case use things like "(model.divWrapper|model.divTop)*"; OR <br /> making model.divWrapper a member of model.divTop and model.divBottom: <br /> model.divTop = model.divWrapper head opener salute epigraph <br /> model.divBottom = model.divWrapper closed signed trailer ps <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> In which case use things like "model.divTop*". <br /> <p><em class="quotelev1">> let's stick with top and bottom for the moment -- we might want </em><br /> <em class="quotelev1">> start and end for horseification purposes one day. </em><br /> Fine w/ me. <br /> <p><em class="quotelev1">> I dont understand this: once a class is defined it can be used </em><br /> <em class="quotelev1">> anywhere. Or are you proposing macros here? </em><br /> No, I'm proposing classes. But if model.divWrapper is a member of <br /> model.divTop (2nd, above), then there is no way in a content model to <br /> access only <head>, <opener>, etc., without also getting <argument>, <br /> <byline>, etc. I'm just trying to figure out if this is a problem or <br /> not. (One solution, of course is to invent two new classes: <br /> model.divWrapper = argument byline dateline docAuthor docDate <br /> model.openerLike = head opener salute epigraph <br /> model.closerLike = closer signed trailer ps <br /> model.divTop = model.divWrapper model.openerLike <br /> model.divBottom = model.divWrapper model.closerLike <br /> but that may be overkill.) <br /> <p><em class="quotelev1">> you mean, why does divGen contain divWrapper but not </em><br /> <em class="quotelev1">> divWrapper.bottom? fair question, and the answer is probably just </em><br /> <em class="quotelev1">> an oversight. when you've sorted the classes out.... </em><br /> Check. <br /> <p><em class="quotelev1">> Plausible. But I still think a <divGen> really is quite a different </em><br /> <em class="quotelev1">> sort of beast from a <div> all the same. </em><br /> Indeed it is semantically, but syntactically the line is getting <br /> quite fuzzy nowadays. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 18:38:07 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 19:01:31 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2007 00:01:31 +0100 Subject: [tei-council] New draft on Modification and Conformance Message-ID: <4627F4CB.4030500@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 00:01:31 +0100</span><br /> </address> Council members will recall that there was quite a flurry of debate on <br /> the topic of conformance following James's work on producing a "straw <br /> person" set of recommendations on the topic. <br /> In consultation with James, Sebastian, Veronika, and just about anyone <br /> else within earshot over the last couple of weeks, I have now finalized <br /> a new draft, which I would very much like Council to read over before <br /> Berlin. The draft is quite short, but the topic is important. <br /> The draft is at http://www.tei-c.org/Drafts/USE.html -- it consists of <br /> the first two subsections of a new chapter of the Guidelines, one on <br /> "Modification", and one on "Conformance". <br /> As some of you will know, the Board is anxious that the Council should <br /> be in a position to define what is meant by "TEI Conformance" sooner <br /> rather than later. I apologize therefore for having taken longer than <br /> intended to get this set of proposals into a shape where they can be <br /> discussed sensibly. Although the exact text of these chapters is <br /> obviously not going to be settled any time soon, and although P5 1.0 <br /> could go ahead without an exact definition of conformance, I would <br /> really like us to go away from Berlin with a clear consensus as to <br /> whether this draft is at least in the right general area, addressing the <br /> right topics, and reaching plausible conclusions we can all live with, <br /> and (indeed) enthusiastically support! <br /> Lou <br /> <p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu Apr 19 2007 - 19:01:34 EDT</span> </div> From cwittern at gmail.com Fri Apr 20 02:38:27 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 20 Apr 2007 08:38:27 +0200 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.48739.941886.134351@emt.wwp.brown.edu> Message-ID: <46285FE3.4050302@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 08:38:27 +0200</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> model.divTop = model.divWrapper head opener salute epigraph </em><br /> <em class="quotelev1">> model.divBottom = model.divWrapper closed signed trailer ps </em><br /> <em class="quotelev1">> model.divWrapper = argument byline dateline docAuthor docDate </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> This looks good to me so far. <br /> But here you lost me: <br /> <em class="quotelev1">> Appendix </em><br /> <em class="quotelev1">> -------- </em><br /> <em class="quotelev1">> There might well be other content that I'd prefer not to bother </em><br /> <em class="quotelev1">> auto-generating, too. E.g. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <divGen type="stats"> </em><br /> <em class="quotelev1">> <head>Statistics</head> </em><br /> <em class="quotelev1">> <p>The following table summarizes ...</p> </em><br /> <em class="quotelev1">> </divGen> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If we're going to have some mechanism for "put the generated content </em><br /> <em class="quotelev1">> here", why not call it <divGen>? E.g.: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <div type="stats"> </em><br /> <em class="quotelev1">> <head>Statistics</head> </em><br /> <em class="quotelev1">> <p>The following table summarizes ...</p> </em><br /> <em class="quotelev1">> <divGen type="genStats"/> </em><br /> <em class="quotelev1">> <p>Any discrepancies in the table above ...</p> </em><br /> <em class="quotelev1">> </div> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The answer is, of course, because the statics example above is </em><br /> <em class="quotelev1">> neither valid nor in harmony with the semantics of divisions. </em><br /> <em class="quotelev1">> </em><br /> Why not? You will only have to properly wrap the part after <divGen>: <br /> <br /> <div type="stats"> <br /> <head>Statistics</head> <br /> <p>The following table summarizes ...</p> <br /> <divGen type="genStats"/> <br /> <div> <br /> <p>Any discrepancies in the table above ...</p> <br /> </div> <br /> </div> <br /> and the whole bunch should be fine. But I do not really see how this <br /> relates to your argument about abolishing divGen, since this seems to be <br /> exactly the semantics as we have it now? Or is it that divGen can't be <br /> nested into other divs? <br /> Christian <br /> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 02:38:34 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 20 06:24:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 06:24:04 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46285FE3.4050302@gmail.com> Message-ID: <17960.38084.861225.128471@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 06:24:04 -0400</span><br /> </address> <em class="quotelev1">> This looks good to me so far. </em><br /> Check, thanks. I appreciate some input. <br /> <p><em class="quotelev1">> But here you lost me: </em><br /> Probably should defer serious discussions about this until someone <br /> chimes in (I should say if & when someone chimes in) and says it <br /> might be a good idea to either: <br /> * revert <divGen> to being an empty element, or <br /> * get rid of <divGen> <br /> <p><em class="quotelev1">> Why not? You will only have to properly wrap the part after </em><br /> <em class="quotelev1">> <divGen>: </em><br /> True. But if the thing-to-be-generated is only a <table> ... <br /> <p><em class="quotelev1">> But I do not really see how this relates to your argument about </em><br /> <em class="quotelev1">> abolishing divGen, since this seems to be exactly the semantics as </em><br /> <em class="quotelev1">> we have it now? </em><br /> It wasn't part of the argument for abolishing <divGen>, it was just <br /> part of the train of thought that got me there. It was part of my <br /> asking myself the question "is it helpful to permit content in <br /> <divGen>". <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 06:24:09 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Fri Apr 20 06:37:46 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 20 Apr 2007 11:37:46 +0100 Subject: [tei-council] Draft Agenda for Berlin meeting (Conformance) In-Reply-To: <46258955.4010705@gmail.com> Message-ID: <462897FA.7070605@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 11:37:46 +0100</span><br /> </address> Wittern Christian wrote: <br /> <em class="quotelev1">> DRAFT Agenda for the TEI Council meeting in Berlin, April 26 to 27 </em><br /> <snip/> <br /> <em class="quotelev1">> 4) Conformance Draft (JC) </em><br /> To save time at the meeting itself I will make a report here. As tasked by <br /> the last (tele) meeting of the council I produced a strawPerson draft of <br /> the CF chapter (now CF section in the USE chapter). This was then debated <br /> in some detail on the council list. I revised the chapter in accordance <br /> with what I viewed as the consensus on many of the aspects. At that point <br /> I handed it over to an editor (Lou) for reshaping and rewriting as the <br /> entire reason for me writing this was to get a draft for council to argue <br /> about and it had. Lou rewrote the draft changing things in a number of <br /> significant ways, and I provided some additional tidying up/proofreading. <br /> In a meeting with a number of interested parties (inc. Lou, Sebastian, <br /> Veronika, and I), we attempted to flesh out the criteria for Conformance in <br /> more depth and create a matrix of example types of conformance. Lou <br /> revised the draft further as a result, and he has both checked this into <br /> Sourceforge and made a nice HTML version for Council to read.[1] <br /> I'm just clarifying in the Council's mind that it is this latest draft by <br /> Lou which we will be debating in Berlin, not any of the earlier drafts for <br /> which I can really take credit. I would strongly reiterate Lou's <br /> message[2] that the Council needs to agree a clear consensus on whether <br /> this draft is basically right or not by Berlin. As such, I would suggest <br /> that everyone read it as soon as possible. <br /> -James <br /> [1] http://www.tei-c.org/Drafts/USE.html <br /> [2] http://lists.village.virginia.edu/pipermail/tei-council/2007/002821.html <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 06:37:50 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 20 06:56:20 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Apr 2007 11:56:20 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.38084.861225.128471@emt.wwp.brown.edu> Message-ID: <46289C54.7010400@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 11:56:20 +0100</span><br /> </address> Syd Bauman wrote: <br /> omeone chimes in) and says it <br /> <em class="quotelev1">> might be a good idea to either: </em><br /> <em class="quotelev1">> * revert <divGen> to being an empty element, or </em><br /> <em class="quotelev1">> * get rid of <divGen> </em><br /> In general, I am in favour to keep it as an empty element. Indeed, if <br /> it's purpose is to be used to mark some automatically generated text <br /> division (and this is the way we use it here), I don't see why it should <br /> contain anything else (besides model.divWrapper) that could go within <br /> more appropriate elements. <br /> However, I can see your point for having something automatically <br /> generated at a level that is different than the divisional one. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Why not? You will only have to properly wrap the part after </em><br /> <em class="quotelev2">>> <divGen>: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> True. But if the thing-to-be-generated is only a <table> ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> But I do not really see how this relates to your argument about </em><br /> <em class="quotelev2">>> abolishing divGen, since this seems to be exactly the semantics as </em><br /> <em class="quotelev2">>> we have it now? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> It wasn't part of the argument for abolishing <divGen>, it was just </em><br /> <em class="quotelev1">> part of the train of thought that got me there. It was part of my </em><br /> <em class="quotelev1">> asking myself the question "is it helpful to permit content in </em><br /> <em class="quotelev1">> <divGen>". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 06:57:18 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 20 07:04:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2007 12:04:11 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46289C54.7010400@kcl.ac.uk> Message-ID: <46289E2B.8060503@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 12:04:11 +0100</span><br /> </address> I have already expressed my view on this, but let me reiterate two <br /> things here: <br /> a. allowing divGen to contain (optionally) model.divWrapper content is a <br /> simple, useful, and in my view therefore should not change; <br /> b. expanding the semantic of divGen to mean "some other kind of virtual <br /> or generated element" is in my view neither simple nor necessary, and <br /> would be an undesirable change. <br /> We should resist the temptation to introduce change just because it <br /> looks like it might be fun. <br /> <p><p><p><p><p>Arianna Ciula wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Syd Bauman wrote: </em><br /> <em class="quotelev1">> omeone chimes in) and says it </em><br /> <em class="quotelev2">>> might be a good idea to either: </em><br /> <em class="quotelev2">>> * revert <divGen> to being an empty element, or </em><br /> <em class="quotelev2">>> * get rid of <divGen> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In general, I am in favour to keep it as an empty element. Indeed, if </em><br /> <em class="quotelev1">> it's purpose is to be used to mark some automatically generated text </em><br /> <em class="quotelev1">> division (and this is the way we use it here), I don't see why it should </em><br /> <em class="quotelev1">> contain anything else (besides model.divWrapper) that could go within </em><br /> <em class="quotelev1">> more appropriate elements. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> However, I can see your point for having something automatically </em><br /> <em class="quotelev1">> generated at a level that is different than the divisional one. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Arianna </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> Why not? You will only have to properly wrap the part after </em><br /> <em class="quotelev3">>>> <divGen>: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> True. But if the thing-to-be-generated is only a <table> ... </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> But I do not really see how this relates to your argument about </em><br /> <em class="quotelev3">>>> abolishing divGen, since this seems to be exactly the semantics as </em><br /> <em class="quotelev3">>>> we have it now? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> It wasn't part of the argument for abolishing <divGen>, it was just </em><br /> <em class="quotelev2">>> part of the train of thought that got me there. It was part of my </em><br /> <em class="quotelev2">>> asking myself the question "is it helpful to permit content in </em><br /> <em class="quotelev2">>> <divGen>". </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 07:06:43 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 20 07:07:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 07:07:35 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46289C54.7010400@kcl.ac.uk> Message-ID: <17960.40695.680006.273808@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 07:07:35 -0400</span><br /> </address> <em class="quotelev1">> In general, I am in favour to keep it as an empty element. ... I </em><br /> <em class="quotelev1">> don't see why it should contain anything else (besides </em><br /> <em class="quotelev1">> model.divWrapper) ... </em><br /> These seem contradictory. By "empty" I mean not allowed to have any <br /> content at all. (No text, Not even model.divWrapper or model.global; <br /> attributes are OK, of course.) <br /> <p><em class="quotelev1">> However, I can see your point for having something automatically </em><br /> <em class="quotelev1">> generated at a level that is different than the divisional one. </em><br /> I think it is a good idea to consider carefully. I.e., something to <br /> be put on the docket for 1.1 or later. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 07:07:40 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri Apr 20 07:51:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Apr 2007 12:51:06 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.40695.680006.273808@emt.wwp.brown.edu> Message-ID: <4628A92A.8080000@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 12:51:06 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> In general, I am in favour to keep it as an empty element. ... I </em><br /> <em class="quotelev2">>> don't see why it should contain anything else (besides </em><br /> <em class="quotelev2">>> model.divWrapper) ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> These seem contradictory. By "empty" I mean not allowed to have any </em><br /> <em class="quotelev1">> content at all. (No text, Not even model.divWrapper or model.global; </em><br /> <em class="quotelev1">> attributes are OK, of course.) </em><br /> Yes, sorry. I should have said: it's fine as an empty element for the <br /> way we use it, but the addition of model.divWrapper within it doesn't <br /> compromise this use and actually may be useful. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> However, I can see your point for having something automatically </em><br /> <em class="quotelev2">>> generated at a level that is different than the divisional one. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think it is a good idea to consider carefully. I.e., something to </em><br /> <em class="quotelev1">> be put on the docket for 1.1 or later. </em><br /> Yep. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 07:51:07 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Fri Apr 20 08:58:13 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 20 Apr 2007 13:58:13 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.40695.680006.273808@emt.wwp.brown.edu> Message-ID: <4628B8E5.8000506@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 13:58:13 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> In general, I am in favour to keep it as an empty element. ... I </em><br /> <em class="quotelev2">>> don't see why it should contain anything else (besides </em><br /> <em class="quotelev2">>> model.divWrapper) ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> These seem contradictory. By "empty" I mean not allowed to have any </em><br /> <em class="quotelev1">> content at all. (No text, Not even model.divWrapper or model.global; </em><br /> <em class="quotelev1">> attributes are OK, of course.) </em><br /> For the record I would probably always use divGen as empty, but could <br /> understand why someone might want a heading associated with it, so having <br /> divWrapper or divTop doesn't seem too problematic to me. It would seem <br /> better to have this only be head or a headLike class rather than divWrapper <br /> though. I can't think of a reasonable argument which would need the other <br /> members. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 08:58:17 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 20 14:06:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 14:06:14 -0400 Subject: [tei-council] Tegal -> Angleterre? Message-ID: <17961.278.544357.998640@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 14:06:14 -0400</span><br /> </address> I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre <br /> Hotel. Any one else arriving at Tegal at a similar time? Anyone know <br /> what the best ground transport option is? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 14:06:18 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 20 13:13:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2007 18:13:10 +0100 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <17961.278.544357.998640@emt.wwp.brown.edu> Message-ID: <4628F4A6.7010403@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 18:13:10 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre </em><br /> <em class="quotelev1">> Hotel. Any one else arriving at Tegal at a similar time? Anyone know </em><br /> <em class="quotelev1">> what the best ground transport option is? </em><br /> <em class="quotelev1">> </em><br /> "Tegel", actually <br /> From memory, there is a bus to the centre of town <br /> and then another bus. But that was a few years ago. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 14:13:13 EDT</span> </div> From dporter at uky.edu Fri Apr 20 14:26:50 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 20 Apr 2007 14:26:50 -0400 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <4628F4A6.7010403@oucs.ox.ac.uk> Message-ID: <96f3df640704201126tbfa5b4dxbd09afe9ab8e8327@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 14:26:50 -0400</span><br /> </address> This site will search public transport for you: <br /> http://www.vbb-fahrinfo.de/hafas/query.exe/en?L=vs_intermodal& <br /> It looks like there are various bus routs for getting from "Flughafen <br /> Tegel (Berlin)" to "U Kochstr./Checkpoint Charlie" (the stop up the <br /> street from the hotel), depending on the arrival/departure times and <br /> how quickly you want to transfer between legs. <br /> I'm arriving at 11:25 am on 4/24 and was thinking about taking a taxi, <br /> just to make things easier on myself. It's about 10km from the airport <br /> to the Angleterre. <br /> Dot <br /> On 4/20/07, Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> wrote: <br /> <em class="quotelev1">> Syd Bauman wrote: </em><br /> <em class="quotelev2">> > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre </em><br /> <em class="quotelev2">> > Hotel. Any one else arriving at Tegal at a similar time? Anyone know </em><br /> <em class="quotelev2">> > what the best ground transport option is? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> "Tegel", actually </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> From memory, there is a bus to the centre of town </em><br /> <em class="quotelev1">> and then another bus. But that was a few years ago. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> Sebastian Rahtz </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Information Manager, Oxford University Computing Services </em><br /> <em class="quotelev1">> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 14:26:54 EDT</span> </div> From daniel.odonnell at uleth.ca Fri Apr 20 15:06:57 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Apr 2007 13:06:57 -0600 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <4628F4A6.7010403@oucs.ox.ac.uk> Message-ID: <1177096017.32506.3.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 13:06:57 -0600</span><br /> </address> It'll come as no surprise to those who know me that my travel agent and <br /> I--with a good dose of me--have managed to screw up my hotel <br /> reservation. Does anybody have a street address/building name for where <br /> we'll be? Being used to me, she'll find me accommodation that way. <br /> -dan <br /> On Fri, 2007-04-20 at 18:13 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Syd Bauman wrote: </em><br /> <em class="quotelev2">> > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre </em><br /> <em class="quotelev2">> > Hotel. Any one else arriving at Tegal at a similar time? Anyone know </em><br /> <em class="quotelev2">> > what the best ground transport option is? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> "Tegel", actually </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> From memory, there is a bus to the centre of town </em><br /> <em class="quotelev1">> and then another bus. But that was a few years ago. </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 15:07:02 EDT</span> </div> From daniel.odonnell at uleth.ca Fri Apr 20 15:21:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Apr 2007 13:21:07 -0600 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <1177096017.32506.3.camel@caedmon> Message-ID: <1177096867.32506.11.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 13:21:07 -0600</span><br /> </address> Dot has rescued me. <br /> On Fri, 2007-04-20 at 13:06 -0600, Daniel O'Donnell wrote: <br /> <em class="quotelev1">> It'll come as no surprise to those who know me that my travel agent and </em><br /> <em class="quotelev1">> I--with a good dose of me--have managed to screw up my hotel </em><br /> <em class="quotelev1">> reservation. Does anybody have a street address/building name for where </em><br /> <em class="quotelev1">> we'll be? Being used to me, she'll find me accommodation that way. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -dan </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On Fri, 2007-04-20 at 18:13 +0100, Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">> > Syd Bauman wrote: </em><br /> <em class="quotelev3">> > > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre </em><br /> <em class="quotelev3">> > > Hotel. Any one else arriving at Tegal at a similar time? Anyone know </em><br /> <em class="quotelev3">> > > what the best ground transport option is? </em><br /> <em class="quotelev3">> > > </em><br /> <em class="quotelev2">> > "Tegel", actually </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > From memory, there is a bus to the centre of town </em><br /> <em class="quotelev2">> > and then another bus. But that was a few years ago. </em><br /> <em class="quotelev2">> > </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 15:21:11 EDT</span> </div> From Syd_Bauman at Brown.edu Fri Apr 20 15:45:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 15:45:46 -0400 Subject: [tei-council] updated Guidelines Message-ID: <17961.6250.83020.506471@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 15:45:46 -0400</span><br /> </address> BTW, just so everyone knows, I've been repeatedly updating my website <br /> with the current version of the Guidelines as we work away on it <br /> feverishly. (Except for when we had those power failures...)-: <br /> I expect to continue to do so until roughly Mon 04-23 15:00 UTC. <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ <br /> http://bauman.zapto.org/~syd/temp/Guidelines-web/fr/html/ <br /> There is also http://bauman.zapto.org/~syd/temp/Guidelines/, but that <br /> is the entirety of P5 in one big HTML file, and thus takes a long <br /> time to load, even from the basement to my desk! <br /> Currently up to version 2340. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 15:45:51 EDT</span> </div> From dporter at uky.edu Fri Apr 20 16:25:42 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 20 Apr 2007 16:25:42 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <96f3df640704201325k48236507r7e7f4983d4569ada@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 20 Apr 2007 16:25:42 -0400</span><br /> </address> Laurent, I'm happy to comment on session 2, or to chair any other session. <br /> Dot <br /> On 4/17/07, Laurent Romary <laurent.romary_at_loria.<!--nospam-->fr> wrote: <br /> <em class="quotelev1">> Dear all, </em><br /> <em class="quotelev1">> Here's some update information about the TEI related events in Berlin </em><br /> <em class="quotelev1">> next week. You will see below the outline of 3 events (you're not </em><br /> <em class="quotelev1">> involved in the first one, but it's just to keep you informed), and I </em><br /> <em class="quotelev1">> would like to ask at this stage for some volunteer to chair and ask </em><br /> <em class="quotelev1">> as commentators for the workshop some of you have agreed to </em><br /> <em class="quotelev1">> participate to (see program). </em><br /> <em class="quotelev1">> Viele Gr??e, </em><br /> <em class="quotelev1">> Laurent </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Summary of the TEI week in Berlin: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> "eSciDoc-Textgrid TEI expert workshop" [you are not concerned by this </em><br /> <em class="quotelev1">> - it's a joint tutorial between the two projects </em><br /> <em class="quotelev1">> date: 24.04.07 </em><br /> <em class="quotelev1">> place: </em><br /> <em class="quotelev1">> Tagungsst?tte Harnack-Haus </em><br /> <em class="quotelev1">> Ihnestra?e 16-20 </em><br /> <em class="quotelev1">> 14195 Berlin </em><br /> <em class="quotelev1">> http://www.harnackhaus-berlin.mpg.de </em><br /> <em class="quotelev1">> timeframe: 13-17:30h </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> "Putting the TEI to the test" [see program below - I need two </em><br /> <em class="quotelev1">> volunteers per session: one to chair and one to comment on the fly </em><br /> <em class="quotelev1">> after the talks] </em><br /> <em class="quotelev1">> date: 25.04.07 </em><br /> <em class="quotelev1">> place: </em><br /> <em class="quotelev1">> Tagungsst?tte Harnack-Haus </em><br /> <em class="quotelev1">> Ihnestra?e 16-20 </em><br /> <em class="quotelev1">> 14195 Berlin </em><br /> <em class="quotelev1">> http://www.harnackhaus-berlin.mpg.de </em><br /> <em class="quotelev1">> timeframe: 10:30 - 17:20h </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> "TEI Council Meeting" [well you know about it, don't you?] </em><br /> <em class="quotelev1">> date: 26.04.-27.04.07 </em><br /> <em class="quotelev1">> place: </em><br /> <em class="quotelev1">> Berlin-Brandenburgische Akademie der Wissenschaften </em><br /> <em class="quotelev1">> Jaegerstr. 22/23 </em><br /> <em class="quotelev1">> 10117 Berlin </em><br /> <em class="quotelev1">> timeframe: 9-18h </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> ---------------------------------------------------- </em><br /> <em class="quotelev1">> Program TEI workshop Putting the TEI to the test, 25.04.07 </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 10:30 ? 11:00 </em><br /> <em class="quotelev1">> Introductory Talk </em><br /> <em class="quotelev1">> 10:30 ? 10:45 Christian Wittern: </em><br /> <em class="quotelev1">> P5: current state and prospects </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 10:45 ? 11:00 Lou Burnard: </em><br /> <em class="quotelev1">> P5: technical overview </em><br /> <em class="quotelev1">> -------- </em><br /> <em class="quotelev1">> 11:00 ? 13:10 </em><br /> <em class="quotelev1">> 1. Session: Text-based projects </em><br /> <em class="quotelev1">> Chair: N.N. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 11:00 ? 11:15 Fotis Jannidis: </em><br /> <em class="quotelev1">> Searching TEI texts in TextGrid using basic encodings </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 11:15 ? 11:30 Torsten Scha?an: </em><br /> <em class="quotelev1">> Aspects of the integration of TEI in the workflows of the </em><br /> <em class="quotelev1">> Wolfenbuettel digital library (WDB) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 11:30 ? 12:00 </em><br /> <em class="quotelev1">> joint discussion </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 12:00 ? 12:15 Christian Mahnke: </em><br /> <em class="quotelev1">> Fulltext processing at the GDZ </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 12:15 ? 12:25 Bernhard Assmann: </em><br /> <em class="quotelev1">> The application of TEI in the digitalization project of the work of </em><br /> <em class="quotelev1">> Frederick the Great </em><br /> <em class="quotelev1">> (status report, presentation in German) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 12:25 ? 12:35 Thomas Burch: </em><br /> <em class="quotelev1">> The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus </em><br /> <em class="quotelev1">> (status report) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 12:35 ? 13:10 </em><br /> <em class="quotelev1">> joint discussion </em><br /> <em class="quotelev1">> ----------- </em><br /> <em class="quotelev1">> 13:10 - 14:00 </em><br /> <em class="quotelev1">> lunch break </em><br /> <em class="quotelev1">> --------- </em><br /> <em class="quotelev1">> 14:00 ? 15:00 </em><br /> <em class="quotelev1">> 2. Session: Charter </em><br /> <em class="quotelev1">> Chair: N.N. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 14:00 ? 14:30 Georg Vogeler: </em><br /> <em class="quotelev1">> How to standardize XML-encoding of medieval and early modern charters </em><br /> <em class="quotelev1">> and </em><br /> <em class="quotelev1">> instruments </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 14:30 ? 15:00 </em><br /> <em class="quotelev1">> discussion </em><br /> <em class="quotelev1">> -------- </em><br /> <em class="quotelev1">> 15:00 ? 16:00 </em><br /> <em class="quotelev1">> 3. Session: Dictionaries </em><br /> <em class="quotelev1">> Chair: N.N. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 15:00 ? 15:15 Alexander Geyken: </em><br /> <em class="quotelev1">> Representation of the German "Woerterbuch der Gegenwartssprache" in TEI: </em><br /> <em class="quotelev1">> encoding strategies and limitations </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 15:15 ? 15:30 Werner Wegstein: </em><br /> <em class="quotelev1">> The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 15:30 ? 16:00 </em><br /> <em class="quotelev1">> joint discussion </em><br /> <em class="quotelev1">> --------- </em><br /> <em class="quotelev1">> 16:00 ? 16:20 </em><br /> <em class="quotelev1">> coffee break </em><br /> <em class="quotelev1">> ------- </em><br /> <em class="quotelev1">> 16:20 ? 17:20 </em><br /> <em class="quotelev1">> 4. Session: Linguistic Annotations </em><br /> <em class="quotelev1">> Chair: N.N. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 16:20 ? 16:35 Susanne Alt: </em><br /> <em class="quotelev1">> TEI encoding of parallel texts: issues and proposals </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 16:35 ? 16:50 Andreas Witt: </em><br /> <em class="quotelev1">> The Role of TEI-Annotations for the Sustainable Representation of </em><br /> <em class="quotelev1">> Linguistic </em><br /> <em class="quotelev1">> Resources </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> 16:50 ? 17:20 </em><br /> <em class="quotelev1">> joint discussion </em><br /> <em class="quotelev1">> -------- </em><br /> <em class="quotelev1">> 17:20 </em><br /> <em class="quotelev1">> end of workshop </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri Apr 20 2007 - 16:25:46 EDT</span> </div> From Syd_Bauman at Brown.edu Sat Apr 21 13:34:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 21 Apr 2007 13:34:42 -0400 Subject: [tei-council] updated Guidelines In-Reply-To: <17961.6250.83020.506471@emt.wwp.brown.edu> Message-ID: <17962.19250.64119.309292@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 13:34:42 -0400</span><br /> </address> David just gently reminded me that it is not always convenient to <br /> access the Guidelines on the web. If you want the whole HTML kit 'n <br /> kaboodle on your laptop, grab it all once: <br /> http://bauman.zapto.org/~syd/temp/GLs.tgz <br /> That tarball contains two directories; you'll find the useful bits <br /> are in: <br /> Guidelines/ <br /> Guidelines-web/en/html/ <br /> Guidelines-web/fr/html/ <br /> Again, I'll try to be updating that very freuqently until Monday <br /> (next in < 1/2 hr I suspect) ... after that depends on internet <br /> connectivity in Berlin :-) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 13:34:45 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 15:51:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 20:51:45 +0100 Subject: [tei-council] up to date Guidelines Message-ID: <462A6B51.4070907@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 20:51:45 +0100</span><br /> </address> I have set up http://tei.oucs.ox.ac.uk/Guidelines/index.xml (and points <br /> south) to dynamically render <br /> the Guidelines to HTML, using Cocoon. It is reading a checkout from <br /> Subversion, <br /> updated every 5 minutes. <br /> Some flaws (ie all the notes appearing on the index page) which I <br /> will endeavour to correct, but I believe it is perfectly useable. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 15:51:49 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 15:57:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 20:57:56 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A6B51.4070907@oucs.ox.ac.uk> Message-ID: <462A6CC4.5070906@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 20:57:56 +0100</span><br /> </address> If its not obvious, the HTML is cached. So each time the source changes, <br /> it'll take a few tens of seconds for the first person to visit a given <br /> chapter. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 15:58:00 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Sat Apr 21 18:00:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 21 Apr 2007 23:00:51 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A6B51.4070907@oucs.ox.ac.uk> Message-ID: <462A8993.70209@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 23:00:51 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> I have set up http://tei.oucs.ox.ac.uk/Guidelines/index.xml (and points </em><br /> <em class="quotelev1">> south) to dynamically render </em><br /> <em class="quotelev1">> the Guidelines to HTML, using Cocoon. It is reading a checkout from </em><br /> <em class="quotelev1">> Subversion, updated every 5 minutes. </em><br /> Great idea, thanks Sebastian. <br /> <em class="quotelev1">> Some flaws (ie all the notes appearing on the index page) which I </em><br /> <em class="quotelev1">> will endeavour to correct, but I believe it is perfectly useable. </em><br /> How is this different from the situation at the following? <br /> http://www.tei-c.org/release/doc/tei-p5-doc/html/ <br /> (All the notes appear on the index page there). It was one of the <br /> things on a short list I've been compiling of "stuff in the presentation <br /> of the Guidelines that maybe should change", as a prelude to the task <br /> Dot and I have volunteered for (but which has been taking a back seat to <br /> chapters etc. <br /> -James <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 17:53:29 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 18:06:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 23:06:35 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A8993.70209@oucs.ox.ac.uk> Message-ID: <462A8AEB.2020903@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 23:06:35 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> How is this different from the situation at the following? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> http://www.tei-c.org/release/doc/tei-p5-doc/html/ </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> (All the notes appear on the index page there). </em><br /> yes, its wrong there too. <br /> <em class="quotelev1">> It was one of the things on a short list I've been compiling of "stuff </em><br /> <em class="quotelev1">> in the presentation of the Guidelines that maybe should change", as a </em><br /> <em class="quotelev1">> prelude to the task Dot and I have volunteered for (but which has been </em><br /> <em class="quotelev1">> taking a back seat to chapters etc. </em><br /> <em class="quotelev1">> </em><br /> for some reason, I have always found handling <note> immensely hard to <br /> get right. <br /> Its a generic error in my XSL, not special for the Guidelines, I think. <br /> I have pro tem turned off caching on this thing, by the way, as <br /> it as noting taking account of changes in the chapter files <br /> as I had expected. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 18:06:39 EDT</span> </div> From Syd_Bauman at Brown.edu Sat Apr 21 20:47:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 21 Apr 2007 20:47:29 -0400 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A8AEB.2020903@oucs.ox.ac.uk> Message-ID: <17962.45217.544772.641719@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 21 Apr 2007 20:47:29 -0400</span><br /> </address> Cool, Sebastian. Does this mean I can quit updating my <br /> server-in-the-basement? (Its name is "garak", BTW -- 2 points to <br /> anyone who recognizes the reference *without* looking using Google, <br /> Wikipedia, etc.) <br /> I'm inclined to say not, because the tarball is probably a very <br /> useful thing. <br /> Anyway ... <br /> <em class="quotelev1">> dynamically render the Guidelines to HTML, using Cocoon. It is </em><br /> <em class="quotelev1">> reading a checkout from Subversion, updated every 5 minutes. </em><br /> <em class="quotelev1">> I have pro tem turned off caching on this thing, </em><br /> Dynamically rendering seems like it might be a serious waste of <br /> computational resources and perhaps even a mild delay for the users. <br /> Why not transform them statically? <br /> In any case, thanks. <br /> P.S. Version on garak is current as of now, version 2354. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sat Apr 21 2007 - 20:47:34 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 22 06:21:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 22 Apr 2007 11:21:57 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <17962.45217.544772.641719@emt.wwp.brown.edu> Message-ID: <462B3745.4080202@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 11:21:57 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> Cool, Sebastian. Does this mean I can quit updating my </em><br /> <em class="quotelev1">> server-in-the-basement? </em><br /> if you trust my server any better.... <br /> <em class="quotelev1">> Dynamically rendering seems like it might be a serious waste of </em><br /> <em class="quotelev1">> computational resources and perhaps even a mild delay for the users. </em><br /> <em class="quotelev1">> </em><br /> indeed. if Cocoon was not so dumb about cacheing, <br /> it would be fine. But it does not realize that changing <br /> one *Spec.xml file means the document as a whole <br /> now needs regenerating <br /> <em class="quotelev1">> Why not transform them statically? </em><br /> <em class="quotelev1">> </em><br /> because then I would have to set up a Subversion <br /> trigger to make a rebuild when you submitted something. <br /> and because it was interesting to see whether <br /> I _could_ make this work! <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 06:22:01 EDT</span> </div> From Syd_Bauman at Brown.edu Sun Apr 22 08:37:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 22 Apr 2007 08:37:11 -0400 Subject: [tei-council] up to date Guidelines In-Reply-To: <462B3745.4080202@oucs.ox.ac.uk> Message-ID: <17963.22263.529033.957508@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 08:37:11 -0400</span><br /> </address> <em class="quotelev1">> if you trust my server any better.... </em><br /> A little better. But I still think the tarball is useful to people, <br /> so version 2360 (downloaded merely a few minutes before Sourceforge <br /> went down) is now available on my site. E.g., <br /> http://bauman.zapto.org/~syd/temp/GLs.tgz <br /> <p><em class="quotelev2">> > Why not transform them statically? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> because then I would have to set up a Subversion trigger to make a </em><br /> <em class="quotelev1">> rebuild when you submitted something. </em><br /> Oh. I was thinking along the lines of regenerating the HTML <br /> immediately after one of the every-5-minute Subversion checks <br /> (preferably iff something actually changed). <br /> <br /> <em class="quotelev1">> and because it was interesting to see whether I _could_ make this </em><br /> <em class="quotelev1">> work! </em><br /> Indeed! Darn good reason. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 08:37:14 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 22 08:49:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 22 Apr 2007 13:49:59 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <17963.22263.529033.957508@emt.wwp.brown.edu> Message-ID: <462B59F7.6040102@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 13:49:59 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev1">> Oh. I was thinking along the lines of regenerating the HTML </em><br /> <em class="quotelev1">> immediately after one of the every-5-minute Subversion checks </em><br /> <em class="quotelev1">> (preferably iff something actually changed). </em><br /> <em class="quotelev1">> </em><br /> yes, could do, if this proves unworkable. though <br /> boring to check whether things have changed. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 08:50:02 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 10:23:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 15:23:05 +0100 Subject: [tei-council] New draft on facsimile Message-ID: <462B6FC9.80000@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 15:23:05 +0100</span><br /> </address> I've taken the liberty of combining the two documents about use of TEI <br /> to mark up "digital facsimile" editions which Dot and Conal were working <br /> on into a single ODD file, making a few minor syntactic corrections, and <br /> producing an HTML version of it as well as a sample schema. You can see <br /> the HTML draft at http://www.tei-c.org/Drafts/testfacs.doc.html and the <br /> ODD source is in the P5/Test library in subversion. I did this because I <br /> think Dot and Conal have done some excellent work here and it would be a <br /> shame if we can't go the extra 500 metres to get it into 1.0. <br /> The main thing we're missing here is a samples document, which Conal was <br /> (I believe) working on and some (much) more explanatory prose. However I <br /> think we have enough here to start discussing the topic next week, if <br /> only to ask stupid questions! <br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 10:23:18 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 11:23:04 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 16:23:04 +0100 Subject: [tei-council] stoa comments on place proposals Message-ID: <462B7DD8.40002@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 16:23:04 +0100</span><br /> </address> Tom Elliott, of the Stoa project, has done us the honour of a careful <br /> read and makes several interesting comments on the current draft for <br /> encoding of placenames on the following web page: <br /> http://icon.stoa.org/trac/pleiades/wiki/TEIPlaceDraft <br /> (which is now linked to from the relevant trac item in our tracker) <br /> We should look at these comments together with those from Arianna last <br /> week when deciding what the next step should be for these proposals. <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 11:23:16 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 11:59:34 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 16:59:34 +0100 Subject: [tei-council] Comments on Place proposals from TEI Message-ID: <462B8666.9070209@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sun, 22 Apr 2007 16:59:34 +0100</span><br /> </address> Dear Tom <br /> Many thanks for your timely comments. I've alerted the Council to your <br /> wiki page and also I think we have a link to it from the relevant trac <br /> item for our own agenda. <br /> Here are my personal reactions to your comments, not to pre-empt the <br /> further discussion I expect to take place next week : <br /> 1. If accepted, the testplace proposals will probably be integrated <br /> into the existing chapter on Names of Places and Persons which has also <br /> undergone quite a lot of revision as you note. You might like therefore <br /> to point to the current state of that chapter which is (as of this <br /> morning) at <br /> http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=ND <br /> rather than the unrevised last stable version -- this is dynamically <br /> generated from the svn repository in which changes are being made at a <br /> great rate of knots <br /> 2. Thank you for the nice remarks about what distinguishes the TEI from <br /> the rest. You're right that we need to be clear about why the TEI goes <br /> down this particular muddy well trodden track at all, and certainly to <br /> alert readers of the Guidelines to other possibilities where they exist. <br /> 3. Named time periods. The treatment of dates and times has just <br /> undergone major surgery in order to support various kinds of automatic <br /> processing and validation, mappings to both ISO and W3C date formats <br /> etc. When the patient is mobile again, I agree that we need to start <br /> thinking about "named" dates. It should not be too difficult. <br /> 4. Linking assertions with responsibility statements is a recurrent <br /> thread. We have discussed a generic <assert> element, to combine an <br /> assertion with an indication of responsibility and certainty, but backed <br /> away from it as being too complex, and not adding much beyond what the <br /> existing @resp and @cert attributes provide; also there is an existing <br /> method for marking certainty <br /> (http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=CE) <br /> which should be taken into consideration. <br /> 5. Adding GeoRSS is definitely an option. We only specified GML because <br /> that was the one we found on the web... no intention of being exclusive. <br /> 6. <relation> vs containment. It always makes me uneasy to have too many <br /> ways of doing exactly the same thing, but it's hard to see what <br /> containment could mean for <place>s within <place>s other than what is <br /> proposed, nor to argue against allowing for relationships other than <br /> containment, so we wound up with both. Contrast this with the discussion <br /> of what <nym> within <nym> means -- something quite different. <br /> 7. <locale> was a pre-existing TEI element which we pressganged into <br /> service here. It does seem a bit problematic as to name, and its overlap <br /> with other ways of characterizing a place. <br /> 8. Ethnica sounds interesting. But I think it's a kind of placeName <br /> still, not a new kind of name, even though its location may be hard to <br /> pin down. After all whether we think of Bristol as "the place with a <br /> bridge" or "the place where the Bristolians hang out", it's still a place. <br /> 9. Absolutely no intention or need for TEI to re-invent detailed <br /> geographic metadata already done better by GML and similar. We could do <br /> with some real examples though, as you note. <br /> 10. SpatialML is an interesting one which I have glanced at but not <br /> studied in detail: it comes from the very different world of "named <br /> entity recognition" . Certainly we ought to review it and the others <br /> you mention, before rushing ahead, if only as a fruitful source of examples. <br /> best wishes <br /> Lou <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 11:59:48 EDT</span> </div> From Conal.Tuohy at vuw.ac.nz Sun Apr 22 22:28:18 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 23 Apr 2007 14:28:18 +1200 Subject: [tei-council] see you in Berlin Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Conal Tuohy <Conal.Tuohy_at_vuw.ac.nz> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 23 Apr 2007 14:28:18 +1200</span><br /> </address> I'm packed, and I'm off to catch my plane. See you all in Berlin! <br /> If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. <br /> Tschuss! <br /> Con <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Sun Apr 22 2007 - 22:32:26 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 23 09:29:27 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 23 Apr 2007 09:29:27 -0400 Subject: [tei-council] updated; mode= of <alt> Message-ID: <17964.46263.51819.216278@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 23 Apr 2007 09:29:27 -0400</span><br /> </address> Version on my website is up to r2379. <br /> I'm wondering if the mode= attribute of <alt> and <altGrp>, which <br /> take only the two values "inclusive" and "exclusive" should instead <br /> be the exclusive= attribute which has values "true" and "false". <br /> This change would make better use of datatypes, and would mean one <br /> fewer attribute with the same name and different semantics. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 23 2007 - 09:29:31 EDT</span> </div> From dporter at uky.edu Mon Apr 23 09:30:24 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 23 Apr 2007 09:30:24 -0400 Subject: [tei-council] updated; mode= of <alt> In-Reply-To: <17964.46263.51819.216278@emt.wwp.brown.edu> Message-ID: <96f3df640704230630t723afabdu5435cda5201ffdf9@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 23 Apr 2007 09:30:24 -0400</span><br /> </address> This change sounds good to me. <br /> Dot <br /> On 4/23/07, Syd Bauman <Syd_Bauman_at_brown.<!--nospam-->edu> wrote: <br /> <em class="quotelev1">> Version on my website is up to r2379. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm wondering if the mode= attribute of <alt> and <altGrp>, which </em><br /> <em class="quotelev1">> take only the two values "inclusive" and "exclusive" should instead </em><br /> <em class="quotelev1">> be the exclusive= attribute which has values "true" and "false". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This change would make better use of datatypes, and would mean one </em><br /> <em class="quotelev1">> fewer attribute with the same name and different semantics. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon Apr 23 2007 - 09:30:29 EDT</span> </div> From laurent.romary at loria.fr Mon Apr 23 09:32:13 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 23 Apr 2007 15:32:13 +0200 Subject: [tei-council] updated; mode= of <alt> In-Reply-To: <17964.46263.51819.216278@emt.wwp.brown.edu> Message-ID: <0CE0E07F-98FF-4D55-BD74-EC58EB107A49@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 23 Apr 2007 15:32:13 +0200</span><br /> </address> I would keep things as they are. Just looking at the description I <br /> can think of fancy combination modes which one would want to have there. <br /> Despite my intrinsic bend on simpifying things... <br /> Laurent <br /> <p>Le 23 avr. 07 ? 15:29, Syd Bauman a ?crit : <br /> <em class="quotelev1">> Version on my website is up to r2379. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm wondering if the mode= attribute of <alt> and <altGrp>, which </em><br /> <em class="quotelev1">> take only the two values "inclusive" and "exclusive" should instead </em><br /> <em class="quotelev1">> be the exclusive= attribute which has values "true" and "false". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This change would make better use of datatypes, and would mean one </em><br /> <em class="quotelev1">> fewer attribute with the same name and different semantics. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 23 2007 - 09:33:37 EDT</span> </div> From Syd_Bauman at Brown.edu Mon Apr 23 09:45:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 23 Apr 2007 09:45:04 -0400 Subject: [tei-council] xtext vs xText Message-ID: <17964.47200.674090.115006@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 23 Apr 2007 09:45:04 -0400</span><br /> </address> An example in TD referred to rng:text, where it is probably better to <br /> refer to a TEI structure. But as I changed it, I wondered ... <br /> shouldn't "macro.xtext" really be "macro.xText"? <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon Apr 23 2007 - 09:45:08 EDT</span> </div> From Conal.Tuohy at vuw.ac.nz Tue Apr 24 08:57:01 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 25 Apr 2007 00:57:01 +1200 Subject: [tei-council] see you in Berlin In-Reply-To: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Conal Tuohy <Conal.Tuohy_at_vuw.ac.nz> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 25 Apr 2007 00:57:01 +1200</span><br /> </address> I have arrived in Berlin and checked into my hotel, which is a few hundred m from the Angleterre where I believe several of you are staying. <br /> http://tinyurl.com/2fel5j <br /> Anyone else about, yet? Does anyone have any plans for dinner? Unfortunately my phone is not roaming in Germany, so I'm only contactable via email (I'm glad I brought a power cable for my computer this time!) or I guess by phone at the hotel. My room number is 306. <br /> Cheers! <br /> Con <br /> <p>-----Original Message----- <br /> From: tei-council-bounces_at_lists.<!--nospam-->village.Virginia.EDU on behalf of Conal Tuohy <br /> Sent: Mon 23/04/07 14:28 <br /> To: TEI Council <br /> Subject: [tei-council] see you in Berlin <br /> <br /> I'm packed, and I'm off to catch my plane. See you all in Berlin! <br /> If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. <br /> Tschuss! <br /> Con <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 24 2007 - 08:57:18 EDT</span> </div> From daniel.odonnell at uleth.ca Tue Apr 24 09:07:00 2007 From: daniel.odonnell at uleth.ca (Daniel Paul O'Donnell) Date: Tue, 24 Apr 2007 15:07:00 +0200 Subject: [tei-council] see you in Berlin In-Reply-To: <[tei-council] see you in Berlin> Message-ID: <20070424130706.TQJJ29757.to5email1.gprs.rogers.com@COM> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel Paul O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 24 Apr 2007 15:07:00 +0200</span><br /> </address> I'm on the bus still. Near Gedenkenst?tte Pl?tzenzee and stuck in traffic :-( <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 24 2007 - 09:07:47 EDT</span> </div> From arianna.ciula at kcl.ac.uk Tue Apr 24 09:14:46 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 24 Apr 2007 14:14:46 +0100 Subject: [tei-council] see you in Berlin In-Reply-To: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <462E02C6.4020509@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 24 Apr 2007 14:14:46 +0100</span><br /> </address> I will arrive tonight, but I guess too late to join you for <br /> dinner...I'll see you tomorrow. <br /> Arianna <br /> Conal Tuohy wrote: <br /> <em class="quotelev1">> I have arrived in Berlin and checked into my hotel, which is a few hundred m from the Angleterre where I believe several of you are staying. </em><br /> <em class="quotelev1">> http://tinyurl.com/2fel5j </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Anyone else about, yet? Does anyone have any plans for dinner? Unfortunately my phone is not roaming in Germany, so I'm only contactable via email (I'm glad I brought a power cable for my computer this time!) or I guess by phone at the hotel. My room number is 306. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Cheers! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Con </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -----Original Message----- </em><br /> <em class="quotelev1">> From: tei-council-bounces_at_lists.<!--nospam-->village.Virginia.EDU on behalf of Conal Tuohy </em><br /> <em class="quotelev1">> Sent: Mon 23/04/07 14:28 </em><br /> <em class="quotelev1">> To: TEI Council </em><br /> <em class="quotelev1">> Subject: [tei-council] see you in Berlin </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm packed, and I'm off to catch my plane. See you all in Berlin! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Tschuss! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Con </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue Apr 24 2007 - 09:15:11 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Tue Apr 24 09:29:24 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 24 Apr 2007 14:29:24 +0100 Subject: [tei-council] cu in berlin Message-ID: <462E0634.60806@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 24 Apr 2007 14:29:24 +0100</span><br /> </address> Sebastian and I will be arriving at 0800 tomorrow morning, and will go <br /> straight to the Harnackhaus. We look forward to your reports on suitable <br /> dining places near the hotel! <br /> a bientot... <br /> Lou <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 24 2007 - 09:32:05 EDT</span> </div> From Syd_Bauman at Brown.edu Tue Apr 24 11:44:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 24 Apr 2007 11:44:35 -0400 Subject: [tei-council] see you in Berlin In-Reply-To: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <17966.9699.475023.430728@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 24 Apr 2007 11:44:35 -0400</span><br /> </address> <em class="quotelev1">> Anyone else about, yet? Does anyone have any plans for dinner? </em><br /> David, John, Dot, and perhaps I will meet in the lobby of the <br /> Angleterre at 18:30 (i.e., in 45 mins). John & David have picked out <br /> an Autrian resteraount that is a bit of a hike away. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue Apr 24 2007 - 11:44:39 EDT</span> </div> From cwittern at gmail.com Wed Apr 25 10:51:02 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 25 Apr 2007 16:51:02 +0200 Subject: [tei-council] updated agenda for berlin meeting Message-ID: <462F6AD6.3050901@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 25 Apr 2007 16:51:02 +0200</span><br /> </address> Dear Council members, <br /> here is the updated agenda. The most important changes have been the <br /> addition of time & place of the meeting. <br /> <p>Agenda for the TEI Council meeting in Berlin, April 26 to 27 <br /> Place: Berlin-Brandenburgische Akademie der Wissenschaften, <br /> Gendarmenmarkt, Berlin <br /> (http://veranstaltungszentrum.bbaw.de/anfahrt/) <br /> Time: 9:00 to 17:00(?) <br /> Expected to participate: <br /> Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna <br /> Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, <br /> Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian <br /> Wittern <br /> PART I <br /> 1) Adotion of Agenda <br /> 2) Minutes, work items, progress since last meeting: <br /> http://www.tei-c.org.uk/Council/tcm29.xml?style=printable <br /> Please look at the action items and report progress here before the <br /> meeting! <br /> <p>3) Reports on Chapter reviews <br /> Council members are expected to report on the outcome of the chapter <br /> review they have undertaken in the last weeks. It would be helpful, <br /> if you could provide a short summary of your findings, including the <br /> outstanding issues that have to be adressed. We will collect these <br /> issues during this phase and resolve them later. <br /> 4) Conformance Draft (JC) <br /> 5) Formatting of Guidelines (JC & DP) <br /> PART II <br /> 6) Resolution of outstanding issues: <br /> - proposal to add a metadata element to record application information <br /> (SR) <br /> - nyms (LB) <br /> - proposal for places & placenames (MD) <br /> - fascsimile markup (TC) <br /> - (other essential items collected in Part I) <br /> <p>7) Adoption of Resolutions <br /> <p><p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 25 2007 - 10:51:13 EDT</span> </div> From Syd_Bauman at Brown.edu Wed Apr 25 11:27:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Apr 2007 11:27:55 -0400 Subject: [tei-council] Re: [Fwd: the easter egg has hatched] In-Reply-To: <2431.141.14.243.47.1177514233.squirrel@webmail.pitt.edu> Message-ID: <17967.29563.608685.211756@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 25 Apr 2007 11:27:55 -0400</span><br /> </address> Dear Syd, <br /> Thank you for forwarding this to the Council list. <br /> Cheers, <br /> David <br /> ---------------------------- Original Message ---------------------------- <br /> Subject: the easter egg has hatched <br /> From: djbpitt_at_pitt.<!--nospam-->edu <br /> Date: Wed, April 25, 2007 11:11 am <br /> To: "TEI Council" <tei-council_at_lists.<!--nospam-->village.virginia.edu> <br /> -------------------------------------------------------------------------- <br /> Dear Council, <br /> How does one find a trac ticket anyway? In any case, comments on my <br /> assigned chapters and a few others are below. <br /> Best, <br /> David <br /> ________ <br /> passim: Can we add links for references to classes, e.g.: <br /> measure.attributes = <br /> att.measurement.attributes, <br /> attribute type { data.enumerated }? <br /> Here data.enumerated is a link but att.measurement.attributes isn't, <br /> although it might be useful if it were. Note also that references to model <br /> groups are links, but references to attribute groups are not; why should <br /> these be rendered differently? <br /> Need examples for all ref-*.html pages (some have them, e.g., <equiv>, and <br /> some don't, e.g., <altIdent>) <br /> Am I the last person on earth who cares about the distinguishing <br /> restrictive and non-restrictive clauses? <br /> guidelines.css: add "white-space: pre;" for all .pre elements <br /> fix line spacing to avoid extra space above lines with footnote reference <br /> numbers (ask me how if necessary) <br /> bulleted list in fn 52 in CO is rendered with bullets and text overlapping <br /> (indentation set incorrectly?) <br /> AB (Preamble/preface): Pervasive references to SGML, DTDs, WSDs, etc. Also <br /> references to transition from P3; should these be to P4? <br /> SG (Gentle introduction): Needs a thorough rewrite; a discussion of <br /> content models in RelaxNG compact syntax is needed because this syntax is <br /> used in the documentation in the Guidelines, but DTD syntax doesn't fit. <br /> typo: documwents <br /> in "has the value draft", "draft" isn't typographicaly distinct (unlike <br /> the attribute value "P1" in the same line); this problem recurs frequently <br /> in other sections, including Documentation; is this a markup problem or a <br /> problem with the stylesheet? <br /> says that XML predefines & and <, but there are three others (>, <br /> ', and ")? <br /> fix alignment in declaration of parameter entity a.global <br /> there are lots of references, especially toward the end (entities, marked <br /> sections), to "the TEI DTD"; since this suggests that TEI structure is <br /> modeled directly with DTDs, should it be updated to refer instead to ODDs? <br /> example of marked section for <eg> should be wrapped; otherwise pre <br /> rendering extends beyond right margin <br /> example including/ignoring stanzas/couplets is garbled <br /> how comfortably do namespaces coexist with DTDs? <br /> tei2.dtd? Did we change the filename, or just the name of the root element? <br /> CH (Character Sets): "modeling the value of @xml:lang parallels the <br /> modeling of the value of @xml:lang"?? <br /> do we want French "coeur" to match only the four-character string, and not <br /> the five-? This isn't a TEI problem, but the guidelines seem to assert <br /> that a user would not want to search for the five-character string I got <br /> spanked (rhymes with but differs from "thanked" :-( ) for <br /> proofreading last time there was a call for *only* content-related <br /> feedback, but "are encoded in ISO-8859-n as a singlebyte with the same <br /> value as the code-point" needs a space between "single" and "byte". If <br /> this non-content-related observation is unwelcome, just ignore it, and I <br /> apologize for wasting your time. :-( <br /> ST (Infrastructure): missing word in "may be combined more less freely" <br /> (see snarky note above about proofreading) <br /> identifies three ways to specify (ODD, RelaxNG, DTD), but shouldn't we <br /> specify only ODD (not only recommended, but we mention no other; the <br /> others are possible, but neither recommended nor supported)? <br /> should "for a text to combine different kinds of object" read "objects"? <br /> two missing spaces in fn 34 <br /> Remove the sentence that reads "The values of xml:id attributes must be <br /> legal names with respect to the SGML declaration in force." and adjust the <br /> following one. That is, XML isn't an implementation of SGML as far as the <br /> TEI is concerned, and as far as TEI users are concerned (although they <br /> don't need to know that), there is only one SGML declaration in the world, <br /> and that's the XML one. <br /> what's the meaning of the SGML reference in "Declare TEI.XML marked <br /> section to permit SGML support"? <br /> The description of the order for DTD components lists user-defined element <br /> declarations at the end, but don't they need to come early for DTD <br /> purposes, since early definitions take precedence over later ones? do we <br /> need separate data.TruthValue and data.xTruthValue classes? Isn't this <br /> like specifying language where it has to be European, i.e., a formal <br /> restriction where user error is unlikely? <br /> Should att.declaring be broader? Why can't a <p> (for example) be <br /> associated with a declaration in the header (especially because <u> can)? <br /> line break missing in example of n.X notation <br /> references to use "in SGML mode" at the end <br /> CO (core): <br /> where does apostrophe mark a plural in English? <br /> "Parentheses and other marks of suspension" should omit "other" <br /> Lose the last comma in "light, buttery, pastry" <br /> "Element foreign" has some "include" notes <br /> The example that purports to illustrate a <bo> element doesn't seem to do <br /> so; no reference to <bo> and no uri, although the description above <br /> promises one <br /> "All members of this class carry the following optional attributes:" is <br /> not followed by a list of attributes (grabbed the description instead of <br /> the attributes/values?) <br /> "reg" erroneously tagged as attribute instead of element in the source <br /> underlying "This use should be distinguished from the use of a nested @reg <br /> (regularization) element ..." <br /> Stray leading backslash in "\list = element list { list.content, <br /> list.attributes }" <br /> In the discussion of indexing, the <index> element is inserted after the <br /> string being indexed, and does not contain it. Is this post-posed <br /> milestone strategy the best approach? Note that the use of <anchor> to <br /> mark the endpoint of a large target range becomes peculiar because the <br /> start point (the location of the <index> element begins only *after* the <br /> beginning of the logical target. <br /> The indexing term always comes from the <term> child, which is often <br /> necessary, but excludes the potential economy of using real text from the <br /> body when <term> is not specified. <br /> Reference to SGML in 4.10.3 (also just above and in 4.13) <br /> In structured bibliographies, are multiple authors/editors entered <br /> together in a single <author>/<editor> element or separately? There are <br /> examples of both, but no explicit statement about best practice (or about <br /> the conditions under which one or the other might be preferred). <br /> "include" notes at the end <br /> TD (Documentation Elements): Garbling in "In the remainder of this chapter <br /> we refer to software which provides such as a processing environment as an <br /> ODD processor" <br /> comma after "i.e." in "i.e. a named" <br /> reference to "SGML dtds" (aside from the problem of the reference to <br /> "SGML," should "dtds" be capitalized?) <br /> The text says "<egXML> contains a single well-formed XML example <br /> demonstrating the use of some XML element or attribute," but the first <br /> example (and others?) has no root element, and therefore is not well <br /> formed. If it is intended that <egXML> is itself the root, then it doesn't <br /> *contain* well-formed XML. <br /> The immediately following example with escaped XML has non-bold <term> <br /> tags, but does not clearly illustrate how the markup differs (that is, <br /> they are character-for-character identical). <br /> erroneous angle brackets (instead of leading "@") in: either a @bar <br /> attribute or a <baz> attribute <br /> missing space in "value ofsequenceRepeatable" <br /> some values in this section are not typographically distinct, while some <br /> earlier are. Is there missing markup in the source? Also in other <br /> chapters. <br /> the class name in "the class model.hiLike" is bold, but other class names <br /> are not typographically distinct. Missing markup in the source? <br /> is the plural of "child element" "children elements" (as here), or "child <br /> elements" (sounds better?) <br /> if you specify "delete" mode and no declaration exists, how can you remove <br /> the existing declaration (which doesn't exist), as the chart states? <br /> "include" notes at end <br /> <p><p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed Apr 25 2007 - 11:27:59 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Wed Apr 25 18:10:14 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 26 Apr 2007 00:10:14 +0200 Subject: [tei-council] Re: [Fwd: the easter egg has hatched] In-Reply-To: <17967.29563.608685.211756@emt.wwp.brown.edu> Message-ID: <462FD1C6.2040603@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 26 Apr 2007 00:10:14 +0200</span><br /> </address> <em class="quotelev1">> passim: Can we add links for references to classes, e.g.: </em><br /> <em class="quotelev1">> measure.attributes = </em><br /> <em class="quotelev1">> att.measurement.attributes, </em><br /> <em class="quotelev1">> attribute type { data.enumerated }? </em><br /> <em class="quotelev1">> Here data.enumerated is a link but att.measurement.attributes isn't, </em><br /> <em class="quotelev1">> although it might be useful if it were. Note also that references to model </em><br /> <em class="quotelev1">> groups are links, but references to attribute groups are not; why should </em><br /> <em class="quotelev1">> these be rendered differently? </em><br /> <p>I think this belongs in formatting desiderata, so I have added it to the list <br /> that Dot and I are compiling. <br /> <p><em class="quotelev1">> guidelines.css: add "white-space: pre;" for all .pre elements </em><br /> <em class="quotelev1">> fix line spacing to avoid extra space above lines with footnote reference </em><br /> <em class="quotelev1">> numbers (ask me how if necessary) </em><br /> <em class="quotelev1">> bulleted list in fn 52 in CO is rendered with bullets and text overlapping </em><br /> <em class="quotelev1">> (indentation set incorrectly?) </em><br /> Both now added to list to check when looking at the CSS. <br /> <em class="quotelev1">> in "has the value draft", "draft" isn't typographicaly distinct (unlike </em><br /> <em class="quotelev1">> the attribute value "P1" in the same line); this problem recurs frequently </em><br /> <em class="quotelev1">> in other sections, including Documentation; is this a markup problem or a </em><br /> <em class="quotelev1">> problem with the stylesheet? </em><br /> What element is the word wrapped in in the source? <br /> <em class="quotelev1"> > I got </em><br /> <em class="quotelev1">> spanked (rhymes with but differs from "thanked" :-( ) for </em><br /> <em class="quotelev1">> proofreading last time there was a call for *only* content-related </em><br /> <em class="quotelev1">> feedback, </em><br /> I thought I indeed thanked you... but simply wanted to point out that the <br /> grammar was lax because it was a strawman draft so I hadn't improved it even to <br /> my usual barely-literate standards. It has now almost entirely been rewritten. <br /> (Good thing I didn't sort out all the restrictive clauses, Lou deleted almost <br /> everything I wrote anyways.) <br /> <em class="quotelev1">> the class name in "the class model.hiLike" is bold, but other class names </em><br /> <em class="quotelev1">> are not typographically distinct. Missing markup in the source? </em><br /> Added to the list of formatting concerns to double-check. <br /> -James <br /> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed Apr 25 2007 - 18:10:18 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 08:21:33 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 08:21:33 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting Message-ID: <17976.33357.397972.941785@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 08:21:33 -0400</span><br /> </address> The first draft of the minutes from our meeting our now available at <br /> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although <br /> some of you may prefer to download <br /> http://www.tei-c.org/Council/tcm30.xml?style=raw.) <br /> A lot was covered at this meeting, and though the notes are <br /> extensive, I missed a lot, too. At some point before the next <br /> conference call, each of us should read the entire document pretty <br /> carefully. But *right now* you should quickly scan it, looking for <br /> your initials and passages flagged with "[?", and send in <br /> corrections ASAP, before (even more) details fade from memory, and so <br /> that we get the record straight as soon as we can. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 08:21:36 EDT</span> </div> From James.Cummings at computing-services.oxford.ac.uk Wed May 2 09:07:37 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 02 May 2007 14:07:37 +0100 Subject: [tei-council] Berlin Message-ID: <46388D19.3060102@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 02 May 2007 14:07:37 +0100</span><br /> </address> Just to say that I had a good time in Berlin and think that we got some <br /> useful work done. Also, while I was there I promised to send some URLs to <br /> various people on various topics (both TEI and non-TEI related) that we <br /> were discussing. I have now, of course, completely forgotten who had asked <br /> for what. So if that jogs your memory, please do email me and tell me what <br /> it was I was referring you to. :-) <br /> Sorry for the dull wits, <br /> -James <br /> --- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 09:07:42 EDT</span> </div> From laurent.romary at loria.fr Wed May 2 09:08:39 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 2 May 2007 15:08:39 +0200 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <90D03973-1561-4FB8-A484-7F2A085C8B67@loria.fr> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Laurent Romary <laurent.romary_at_loria.fr> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 15:08:39 +0200</span><br /> </address> Thanks for the notes. Two qiuck updates: <br /> - the name of the person is Eva Radermacher <br /> - Yes we decided on the change of names <br /> Lou: can you make the connexion with your technical student at Oxford? <br /> Best, <br /> Laurent <br /> Le 2 mai 07 ? 14:21, Syd Bauman a ?crit : <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 09:11:06 EDT</span> </div> From dporter at uky.edu Wed May 2 09:14:03 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 2 May 2007 09:14:03 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <96f3df640705020614u419abadamedeeca9bb8e2e8db@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 09:14:03 -0400</span><br /> </address> 1.2 all: Attempt to encode a place ? <br /> Should be: DO, *AC*, JC report they've done this <br /> Though I'm always flattered to be confused with Arianna :-) <br /> Dot <br /> On 5/2/07, Syd Bauman <Syd_Bauman_at_brown.<!--nospam-->edu> wrote: <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 09:14:07 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 09:52:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 09:52:59 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <90D03973-1561-4FB8-A484-7F2A085C8B67@loria.fr> Message-ID: <17976.38843.206272.321563@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 09:52:59 -0400</span><br /> </address> [DB sent some errors in directly to me -- fixed.] <br /> <p>Thanks, Laurent! (Or should I say "LR" :-) <br /> <em class="quotelev1">> - the name of the person is Eva Radermacher </em><br /> Check, entered. <br /> <em class="quotelev1">> - Yes we decided on the change of names </em><br /> Check, fixed. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 09:53:03 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 09:55:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 09:55:41 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <96f3df640705020614u419abadamedeeca9bb8e2e8db@mail.gmail.com> Message-ID: <17976.39005.634365.89542@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 09:55:41 -0400</span><br /> </address> DP> Should be: DO, *AC*, JC report they've done this <br /> DP> Though I'm always flattered to be confused with Arianna :-) <br /> A forgivalbe error, then? Whew! <br /> Of course, if you hurry, you too could attempt to encode a placename <br /> with the new proposed encoding, and I wouldn't have to change the <br /> minutes! <br /> Oh well, too late. Fixed. <br /> Thanks, Dot! <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 09:55:45 EDT</span> </div> From tone.bruvik at aksis.uib.no Wed May 2 10:02:27 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Wed, 2 May 2007 16:02:27 +0200 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <B7A28D22-31CF-444D-94B7-F82265B10595@aksis.uib.no> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Tone Merete Bruvik <tone.bruvik_at_aksis.uib.no> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 16:02:27 +0200</span><br /> </address> Some comments from me: <br /> 1. My name is abrivitated in to two different ways, TMB and TB. I <br /> prefer the first one. <br /> 2. By the way, who or what is MM in "MM says it's a good opportunity <br /> to work further on proposals" Messieurs?? <br /> 3. "DB suggests changing the name of this chapter to ?Dictionaries?. <br /> [? was this decided? ?]" Yes, I think so. <br /> 4. And I believe that I and Syd volunteered in 11.3.29. NH- <br /> MultipleHierarchies.xml to rewrite the chapter. <br /> Tone Merete <br /> <p>Den 2. mai. 2007 kl. 14.21 skrev Syd Bauman: <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 10:02:38 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 10:13:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 10:13:44 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <B7A28D22-31CF-444D-94B7-F82265B10595@aksis.uib.no> Message-ID: <17976.40088.68637.86930@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 10:13:44 -0400</span><br /> </address> <em class="quotelev1">> 1. My name is abrivitated in to two different ways, TMB and TB. I </em><br /> <em class="quotelev1">> prefer the first one. </em><br /> Fixed. <br /> <p><em class="quotelev1">> 2. By the way, who or what is MM in "MM says it's a good opportunity </em><br /> <em class="quotelev1">> to work further on proposals" Messieurs?? </em><br /> Oooh, good point. MM is Murray McGillivray, chair of the Physical <br /> Bibliography working group. I'll put his whole name in. <br /> <p><em class="quotelev1">> 3. "DB suggests changing the name of this chapter to ?Dictionaries?. </em><br /> <em class="quotelev1">> [? was this decided? ?]" Yes, I think so. </em><br /> LR agrees; fixed. <br /> <p><em class="quotelev1">> 4. And I believe that I and Syd volunteered in 11.3.29. NH- </em><br /> <em class="quotelev1">> MultipleHierarchies.xml to rewrite the chapter. </em><br /> Right. Already says that, I think. <br /> <p><p>Thanks, TMB! <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 10:13:47 EDT</span> </div> From arianna.ciula at kcl.ac.uk Wed May 2 12:23:59 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 02 May 2007 17:23:59 +0100 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <4638BB1F.9050303@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 02 May 2007 17:23:59 +0100</span><br /> </address> Thank-you Syd. <br /> Here my notes: <br /> 1.3.20. ND-NamesDates.xml --> I believe there was another action on you <br /> to add explanation on the difference w3c/iso in the prose (it's already <br /> in the specs). <br /> MD and AC are hoping to put together a meeting soon (in London?) of MD, <br /> Oxfordians, Londoners, and Alex Czmiel to work further on the proposal <br /> once participants have put it to the test of encoding real data. --> <br /> Yes, In London <br /> Get information from [? Alex Czmiel ?] --> yes Alex Czmiel <br /> 0. LB <br /> work out what GP? really wants. --> Gautier Poupeau, I believe <br /> 1.3.8. DS-DefaultTextStructure.xml <br /> [? whose chapter was this? ?] --> mine <br /> Arianna <br /> Syd Bauman wrote: <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 12:23:49 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 12:36:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 12:36:38 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <4638BB1F.9050303@kcl.ac.uk> Message-ID: <17976.48662.322933.32110@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 12:36:38 -0400</span><br /> </address> <em class="quotelev1">> 1.3.20. ND-NamesDates.xml --> I believe there was another action on </em><br /> <em class="quotelev1">> you to add explanation on the difference w3c/iso in the prose (it's </em><br /> <em class="quotelev1">> already in the specs). </em><br /> Yes, that's already on my list of things to do, as it were, but no <br /> harm in adding another action item as an additional reminder. Thanks, <br /> done. <br /> <p><em class="quotelev1">> MD and AC are hoping to put together a meeting soon (in London?) of MD, </em><br /> <em class="quotelev1">> Yes, In London </em><br /> Check, thanks. Fixed. <br /> <p><em class="quotelev1">> Get information from [? Alex Czmiel ?] --> yes Alex Czmiel </em><br /> Check, thanks. Fixed. <br /> <p><em class="quotelev1">> work out what GP? really wants. --> Gautier Poupeau, I believe </em><br /> Right. Thanks. Done. <br /> <p><em class="quotelev1">> 1.3.8. DS-DefaultTextStructure.xml </em><br /> <em class="quotelev1">> [? whose chapter was this? ?] --> mine </em><br /> Sorry. Is it safe to say "AC found no occurences of DTDs, P4, or <br /> SGML" or some such? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 12:36:41 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed May 2 12:56:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 02 May 2007 17:56:05 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] Message-ID: <4638C2A5.2080309@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 02 May 2007 17:56:05 +0100</span><br /> </address> This is really a datatype problem. Is there any desire on Council to <br /> review the datatype of the @lem attribute so as to address the issue? <br /> Making it xsd:token rather than data.word would help with the specific <br /> case Elena raises, at the expense of making this attribute inconsistent <br /> with all the other cases of "texty" attributes. <br /> <p>-------- Original Message -------- <br /> Subject: Re: recording multiword expression in lemma attribute <br /> Date: Wed, 02 May 2007 17:03:41 +0100 <br /> From: Elena Pierazzo <elena.pierazzo_at_kcl.<!--nospam-->ac.uk> <br /> To: Lou Burnard <lou.burnard_at_COMPUTING-SERVICES.<!--nospam-->OXFORD.AC.UK> <br /> CC: TEI-L_at_listserv.<!--nospam-->brown.edu <br /> References: <20070502152350.59BF2EB04D_at_webmail221.<!--nospam-->herald.ox.ac.uk> <br /> <p><p>Dear Lou, <br /> thanks for your example: I'll think about it. <br /> I just argue that from a linguistic point of view a lemma is not <br /> necessarily a single word (in case of Romance languages for sure). <br /> As it is, it seems that any project that is trying to lemmatize a text <br /> in a language that has multiword expressions cannot use the <w> element <br /> as it is and need to customize it either modifying the class or creating <br /> new elements. <br /> Furthermore, if the attribute approach is suitable for simple cases, why <br /> TEI should not support complex cases? In many other modules we have the <br /> opportunity to choose which granularity to adopt in the encoding, while <br /> for this it seems that complex cases and projects that will adopt a <br /> complex linguistic approach has to decide on their own how to customize. <br /> Cheers, <br /> Elena <br /> Lou Burnard ha scritto: <br /> <em class="quotelev1">> In my opinion, you would do better to put the lemma value into an element of its </em><br /> <em class="quotelev1">> own. The attribute value approach is really only suitable for simple cases. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So if it was me, I would define new elements <form> and <lem> as specialised </em><br /> <em class="quotelev1">> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and </em><br /> <em class="quotelev1">> then mark it up thusly: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <w> </em><br /> <em class="quotelev1">> <lem>in primis</lem> </em><br /> <em class="quotelev1">> <form>in prrrrrimmmmissss</form> </em><br /> <em class="quotelev1">> </w> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> This means you can put markup into the <lem> as well as spaces </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Alternatively, you could adopt a simple convention like this: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> <w lem="in_primis">....</w> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Redefining the datatype of the @lem attribute to accept spaces as you propose </em><br /> <em class="quotelev1">> would be a bit problematic since that changes the definition. Of course, you </em><br /> <em class="quotelev1">> could also argue that it *shouldn't* be defined as data.word... but it currently is! </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> message <200705021450.l42CiBmN008989_at_listserv.<!--nospam-->brown.edu> Elena Pierazzo </em><br /> <em class="quotelev1">> <elena.pierazzo_at_KCL.<!--nospam-->AC.UK> writes: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> This is a multi-part message in MIME format. </em><br /> <em class="quotelev2">>> --------------010005090407060100080705 </em><br /> <em class="quotelev2">>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed </em><br /> <em class="quotelev2">>> Content-Transfer-Encoding: 7bit </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Dear all, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev2">>> are lemmatizing all the words. For this purpose we are using: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <w lemma="">word</w> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev2">>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev2">>> (separating the expression in "in" and "primis" is simply nonsensical). </em><br /> <em class="quotelev2">>> The problem is that </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <w lemma="in primis">in primis</w> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> is not valid as the lemma definition is </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <attList> </em><br /> <em class="quotelev2">>> <attDef ident="lemma" mode="change"> </em><br /> <em class="quotelev2">>> <desc>identifies the word's lemma (dictionary entry form).</desc> </em><br /> <em class="quotelev2">>> <datatype minOccurs="1" maxOccurs="1"> </em><br /> <em class="quotelev2">>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev2">>> name="data.word"/> </em><br /> <em class="quotelev2">>> </datatype> </em><br /> <em class="quotelev2">>> ... </em><br /> <em class="quotelev2">>> </attDef> </em><br /> <em class="quotelev2">>> </attList> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev2">>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev2">>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev2">>> everybody. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Bests </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Elena </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> -- </em><br /> <em class="quotelev2">>> Elena Pierazzo </em><br /> <em class="quotelev2">>> Associate Researcher </em><br /> <em class="quotelev2">>> Centre for Computing in the Humanities </em><br /> <em class="quotelev2">>> King's College London </em><br /> <em class="quotelev2">>> Kay House 7 Arundel St </em><br /> <em class="quotelev2">>> London WC2R 3DX </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Phone: 0207-848-1949 </em><br /> <em class="quotelev2">>> Fax: 0207-848-2980 </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> --------------010005090407060100080705 </em><br /> <em class="quotelev2">>> Content-Type: text/html; charset=ISO-8859-15 </em><br /> <em class="quotelev2">>> Content-Transfer-Encoding: 8bit </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> </em><br /> <em class="quotelev2">>> <html> </em><br /> <em class="quotelev2">>> <head> </em><br /> <em class="quotelev2">>> <meta content="text/html;charset=ISO-8859-15" </em><br /> <em class="quotelev2">>> http-equiv="Content-Type"> </em><br /> <em class="quotelev2">>> </head> </em><br /> <em class="quotelev2">>> <body bgcolor="#ffffff" text="#000000"> </em><br /> <em class="quotelev2">>> <font size="-1"><font face="Verdana">Dear all,<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev2">>> are lemmatizing all the words. For this purpose we are using:<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <w lemma="">word</w><br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> but we are in trouble with multiword expressions (e.g. "in primis"). <br> </em><br /> <em class="quotelev2">>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev2">>> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev2">>> nonsensical). The problem is that <br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <w lemma="in primis">in primis</w><br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> is not valid as the lemma definition is<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <attList><br> </em><br /> <em class="quotelev2">>> <attDef ident="lemma" mode="change"><br> </em><br /> <em class="quotelev2">>> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev2">>> form).</desc><br> </em><br /> <em class="quotelev2">>> <datatype minOccurs="1" maxOccurs="1"><br> </em><br /> <em class="quotelev2">>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> name="data.word"/><br> </em><br /> <em class="quotelev2">>> </datatype><br> </em><br /> <em class="quotelev2">>> ...<br> </em><br /> <em class="quotelev2">>> </attDef><br> </em><br /> <em class="quotelev2">>> </attList><br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev2">>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev2">>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev2">>> everybody.<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Bests<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Elena<br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> </font></font><span class="moz-txt-tag">-- <br> </em><br /> <em class="quotelev2">>> </span>Elena Pierazzo </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Associate Researcher </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Centre for Computing in the Humanities </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> King's College London </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Kay House 7 Arundel St </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> London WC2R 3DX </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Phone: 0207-848-1949 </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> Fax: 0207-848-2980 </em><br /> <em class="quotelev2">>> <br> </em><br /> <em class="quotelev2">>> </body> </em><br /> <em class="quotelev2">>> </html> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> --------------010005090407060100080705-- </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 02 2007 - 12:59:11 EDT</span> </div> From Syd_Bauman at Brown.edu Thu May 3 07:13:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 3 May 2007 07:13:36 -0400 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <17977.50144.504417.384115@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 3 May 2007 07:13:36 -0400</span><br /> </address> <em class="quotelev1">> Making it xsd:token rather than data.word would help with the </em><br /> <em class="quotelev1">> specific case Elena raises, at the expense of making this attribute </em><br /> <em class="quotelev1">> inconsistent with all the other cases of "texty" attributes. </em><br /> But I would shy away from using xsd:token (which itself imposes no <br /> syntactic constraints at all -- any sequence of Unicode characters is <br /> permitted except for those XML itself does not allow) in any case. <br /> The more appropriate datatype would probably be one or more <br /> occurrences of data.word, which already appears 30 times in the <br /> Guidelines. <br /> Personally, I think I'm in favor, but I don't consider myself an <br /> expert in this arena whatsoever. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 13:23:00 EDT</span> </div> From Syd_Bauman at brown.edu Thu May 3 06:20:12 2007 From: Syd_Bauman at brown.edu (Syd Bauman) Date: Thu, 3 May 2007 06:20:12 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <4639A517.1000600@kcl.ac.uk> Message-ID: <17977.46940.890485.297311@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 3 May 2007 06:20:12 -0400</span><br /> </address> <em class="quotelev1">> All reported on Trac and already fixed by Lou. </em><br /> Check, thanks. Done. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 13:25:13 EDT</span> </div> From cwittern at gmail.com Wed May 2 19:30:52 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 03 May 2007 08:30:52 +0900 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <46391F2C.4050107@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 03 May 2007 08:30:52 +0900</span><br /> </address> Council members, <br /> Thanks to all of you again for contributing to the intense discussions <br /> which turned the two days in Berlin into a very successful meeting. <br /> Syd Bauman wrote: <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> Thanks for getting this up. I think you did a fair job at recording <br /> the deliberations. <br /> As far as I am concerned, here is a correction: <br /> <quote> <br /> <p> 1.3.25. FD-FeatureSystemDeclaration.xml <br /> CW reports that he found some references to DTDs in this chapter. <br /> *Action CW by *: <br /> fix or post references to DTDs in FS <br /> </quote> <br /> As I said during the meeting, these references have already been fixed <br /> and a revised chapter was send to Lou and subsequently checked into svn. <br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> The planning committee discussed the issues immediately after the <br /> meeting. The result is a list of items for which Sebastian will create <br /> trac tickets. Not all the actions are covered, some are so trivial that <br /> it did not really make sense to put them into trac. Please dispose with <br /> them immediately. <br /> Christian <br /> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 13:28:17 EDT</span> </div> From Syd_Bauman at Brown.edu Wed May 2 19:47:28 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 19:47:28 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <46391F2C.4050107@gmail.com> Message-ID: <17977.8976.299707.139222@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 2 May 2007 19:47:28 -0400</span><br /> </address> <em class="quotelev1">> As I said during the meeting, these references have already been </em><br /> <em class="quotelev1">> fixed and a revised chapter was send to Lou and subsequently </em><br /> <em class="quotelev1">> checked into svn. </em><br /> Ooops. Sorry. Corrected. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 13:33:05 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu May 3 05:02:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 03 May 2007 10:02:15 +0100 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.48662.322933.32110@emt.wwp.brown.edu> Message-ID: <4639A517.1000600@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 03 May 2007 10:02:15 +0100</span><br /> </address> Syd Bauman wrote: <br /> <em class="quotelev2">>> 1.3.8. DS-DefaultTextStructure.xml </em><br /> <em class="quotelev2">>> [? whose chapter was this? ?] --> mine </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Sorry. Is it safe to say "AC found no occurences of DTDs, P4, or </em><br /> <em class="quotelev1">> SGML" or some such? </em><br /> All reported on Trac and already fixed by Lou. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 14:08:07 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu May 3 05:08:59 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 03 May 2007 10:08:59 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <4639A6AB.8010707@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 03 May 2007 10:08:59 +0100</span><br /> </address> As I said to Elena face to face, I think her point is quite right and I <br /> would vote for changing the datatype of the @lemma attribute to xsd:token.<!--nospam--> <br /> Arianna <br /> Lou Burnard wrote: <br /> <em class="quotelev1">> This is really a datatype problem. Is there any desire on Council to </em><br /> <em class="quotelev1">> review the datatype of the @lem attribute so as to address the issue? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Making it xsd:token rather than data.word would help with the specific </em><br /> <em class="quotelev1">> case Elena raises, at the expense of making this attribute inconsistent </em><br /> <em class="quotelev1">> with all the other cases of "texty" attributes. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -------- Original Message -------- </em><br /> <em class="quotelev1">> Subject: Re: recording multiword expression in lemma attribute </em><br /> <em class="quotelev1">> Date: Wed, 02 May 2007 17:03:41 +0100 </em><br /> <em class="quotelev1">> From: Elena Pierazzo <elena.pierazzo_at_kcl.<!--nospam-->ac.uk> </em><br /> <em class="quotelev1">> To: Lou Burnard <lou.burnard_at_COMPUTING-SERVICES.<!--nospam-->OXFORD.AC.UK> </em><br /> <em class="quotelev1">> CC: TEI-L_at_listserv.<!--nospam-->brown.edu </em><br /> <em class="quotelev1">> References: <20070502152350.59BF2EB04D_at_webmail221.<!--nospam-->herald.ox.ac.uk> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Dear Lou, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> thanks for your example: I'll think about it. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I just argue that from a linguistic point of view a lemma is not </em><br /> <em class="quotelev1">> necessarily a single word (in case of Romance languages for sure). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As it is, it seems that any project that is trying to lemmatize a text </em><br /> <em class="quotelev1">> in a language that has multiword expressions cannot use the <w> element </em><br /> <em class="quotelev1">> as it is and need to customize it either modifying the class or creating </em><br /> <em class="quotelev1">> new elements. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Furthermore, if the attribute approach is suitable for simple cases, why </em><br /> <em class="quotelev1">> TEI should not support complex cases? In many other modules we have the </em><br /> <em class="quotelev1">> opportunity to choose which granularity to adopt in the encoding, while </em><br /> <em class="quotelev1">> for this it seems that complex cases and projects that will adopt a </em><br /> <em class="quotelev1">> complex linguistic approach has to decide on their own how to customize. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Cheers, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Elena </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Lou Burnard ha scritto: </em><br /> <em class="quotelev2">>> In my opinion, you would do better to put the lemma value into an </em><br /> <em class="quotelev2">>> element of its </em><br /> <em class="quotelev2">>> own. The attribute value approach is really only suitable for simple </em><br /> <em class="quotelev2">>> cases. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> So if it was me, I would define new elements <form> and <lem> as </em><br /> <em class="quotelev2">>> specialised </em><br /> <em class="quotelev2">>> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg </em><br /> <em class="quotelev2">>> type="lem">) and </em><br /> <em class="quotelev2">>> then mark it up thusly: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <w> </em><br /> <em class="quotelev2">>> <lem>in primis</lem> </em><br /> <em class="quotelev2">>> <form>in prrrrrimmmmissss</form> </em><br /> <em class="quotelev2">>> </w> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> This means you can put markup into the <lem> as well as spaces </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Alternatively, you could adopt a simple convention like this: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> <w lem="in_primis">....</w> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Redefining the datatype of the @lem attribute to accept spaces as you </em><br /> <em class="quotelev2">>> propose </em><br /> <em class="quotelev2">>> would be a bit problematic since that changes the definition. Of </em><br /> <em class="quotelev2">>> course, you </em><br /> <em class="quotelev2">>> could also argue that it *shouldn't* be defined as data.word... but it </em><br /> <em class="quotelev2">>> currently is! </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> message <200705021450.l42CiBmN008989_at_listserv.<!--nospam-->brown.edu> Elena Pierazzo </em><br /> <em class="quotelev2">>> <elena.pierazzo_at_KCL.<!--nospam-->AC.UK> writes: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> This is a multi-part message in MIME format. </em><br /> <em class="quotelev3">>>> --------------010005090407060100080705 </em><br /> <em class="quotelev3">>>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed </em><br /> <em class="quotelev3">>>> Content-Transfer-Encoding: 7bit </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Dear all, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I'm working in a project with a strong lexicographical component so </em><br /> <em class="quotelev3">>>> we are lemmatizing all the words. For this purpose we are using: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <w lemma="">word</w> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev3">>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev3">>>> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev3">>>> nonsensical). The problem is that </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <w lemma="in primis">in primis</w> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> is not valid as the lemma definition is </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <attList> </em><br /> <em class="quotelev3">>>> <attDef ident="lemma" mode="change"> </em><br /> <em class="quotelev3">>>> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev3">>>> form).</desc> </em><br /> <em class="quotelev3">>>> <datatype minOccurs="1" maxOccurs="1"> </em><br /> <em class="quotelev3">>>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev3">>>> name="data.word"/> </em><br /> <em class="quotelev3">>>> </datatype> </em><br /> <em class="quotelev3">>>> ... </em><br /> <em class="quotelev3">>>> </attDef> </em><br /> <em class="quotelev3">>>> </attList> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I can modify the definition, but I was thinking that my problem can </em><br /> <em class="quotelev3">>>> be rather common (for instance, Italian language contains thousands </em><br /> <em class="quotelev3">>>> of multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev3">>>> everybody. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Bests </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Elena </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> -- </em><br /> <em class="quotelev3">>>> Elena Pierazzo </em><br /> <em class="quotelev3">>>> Associate Researcher </em><br /> <em class="quotelev3">>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev3">>>> King's College London </em><br /> <em class="quotelev3">>>> Kay House 7 Arundel St </em><br /> <em class="quotelev3">>>> London WC2R 3DX </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev3">>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> --------------010005090407060100080705 </em><br /> <em class="quotelev3">>>> Content-Type: text/html; charset=ISO-8859-15 </em><br /> <em class="quotelev3">>>> Content-Transfer-Encoding: 8bit </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> </em><br /> <em class="quotelev3">>>> <html> </em><br /> <em class="quotelev3">>>> <head> </em><br /> <em class="quotelev3">>>> <meta content="text/html;charset=ISO-8859-15" </em><br /> <em class="quotelev3">>>> http-equiv="Content-Type"> </em><br /> <em class="quotelev3">>>> </head> </em><br /> <em class="quotelev3">>>> <body bgcolor="#ffffff" text="#000000"> </em><br /> <em class="quotelev3">>>> <font size="-1"><font face="Verdana">Dear all,<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev3">>>> are lemmatizing all the words. For this purpose we are using:<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <w lemma="">word</w><br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev3">>>> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev3">>>> nonsensical). The problem is that <br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <w lemma="in primis">in primis</w><br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> is not valid as the lemma definition is<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <attList><br> </em><br /> <em class="quotelev3">>>> <attDef ident="lemma" mode="change"><br> </em><br /> <em class="quotelev3">>>> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev3">>>> form).</desc><br> </em><br /> <em class="quotelev3">>>> <datatype minOccurs="1" maxOccurs="1"><br> </em><br /> <em class="quotelev3">>>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> name="data.word"/><br> </em><br /> <em class="quotelev3">>>> </datatype><br> </em><br /> <em class="quotelev3">>>> ...<br> </em><br /> <em class="quotelev3">>>> </attDef><br> </em><br /> <em class="quotelev3">>>> </attList><br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev3">>>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev3">>>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev3">>>> everybody.<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Bests<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Elena<br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> </font></font><span class="moz-txt-tag">-- <br> </em><br /> <em class="quotelev3">>>> </span>Elena Pierazzo </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Associate Researcher </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> King's College London </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Kay House 7 Arundel St </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> London WC2R 3DX </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev3">>>> <br> </em><br /> <em class="quotelev3">>>> </body> </em><br /> <em class="quotelev3">>>> </html> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> --------------010005090407060100080705-- </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 14:10:13 EDT</span> </div> From daniel.odonnell at uleth.ca Wed May 2 23:47:15 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 02 May 2007 21:47:15 -0600 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <1178164035.9068.15.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 02 May 2007 21:47:15 -0600</span><br /> </address> Before we tamper with something like this, I'd like to see some real <br /> examples of multiword lemmas... and, how does that affect w? Isn't it <br /> lemma that's affected? <br /> On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: <br /> <em class="quotelev1">> This is really a datatype problem. Is there any desire on Council to </em><br /> <em class="quotelev1">> review the datatype of the @lem attribute so as to address the issue? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Making it xsd:token rather than data.word would help with the specific </em><br /> <em class="quotelev1">> case Elena raises, at the expense of making this attribute inconsistent </em><br /> <em class="quotelev1">> with all the other cases of "texty" attributes. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -------- Original Message -------- </em><br /> <em class="quotelev1">> Subject: Re: recording multiword expression in lemma attribute </em><br /> <em class="quotelev1">> Date: Wed, 02 May 2007 17:03:41 +0100 </em><br /> <em class="quotelev1">> From: Elena Pierazzo <elena.pierazzo_at_kcl.<!--nospam-->ac.uk> </em><br /> <em class="quotelev1">> To: Lou Burnard <lou.burnard_at_COMPUTING-SERVICES.<!--nospam-->OXFORD.AC.UK> </em><br /> <em class="quotelev1">> CC: TEI-L_at_listserv.<!--nospam-->brown.edu </em><br /> <em class="quotelev1">> References: <20070502152350.59BF2EB04D_at_webmail221.<!--nospam-->herald.ox.ac.uk> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Dear Lou, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> thanks for your example: I'll think about it. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I just argue that from a linguistic point of view a lemma is not </em><br /> <em class="quotelev1">> necessarily a single word (in case of Romance languages for sure). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As it is, it seems that any project that is trying to lemmatize a text </em><br /> <em class="quotelev1">> in a language that has multiword expressions cannot use the <w> element </em><br /> <em class="quotelev1">> as it is and need to customize it either modifying the class or creating </em><br /> <em class="quotelev1">> new elements. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Furthermore, if the attribute approach is suitable for simple cases, why </em><br /> <em class="quotelev1">> TEI should not support complex cases? In many other modules we have the </em><br /> <em class="quotelev1">> opportunity to choose which granularity to adopt in the encoding, while </em><br /> <em class="quotelev1">> for this it seems that complex cases and projects that will adopt a </em><br /> <em class="quotelev1">> complex linguistic approach has to decide on their own how to customize. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Cheers, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Elena </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Lou Burnard ha scritto: </em><br /> <em class="quotelev2">> > In my opinion, you would do better to put the lemma value into an element of its </em><br /> <em class="quotelev2">> > own. The attribute value approach is really only suitable for simple cases. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > So if it was me, I would define new elements <form> and <lem> as specialised </em><br /> <em class="quotelev2">> > kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and </em><br /> <em class="quotelev2">> > then mark it up thusly: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > <w> </em><br /> <em class="quotelev2">> > <lem>in primis</lem> </em><br /> <em class="quotelev2">> > <form>in prrrrrimmmmissss</form> </em><br /> <em class="quotelev2">> > </w> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > This means you can put markup into the <lem> as well as spaces </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Alternatively, you could adopt a simple convention like this: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > <w lem="in_primis">....</w> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Redefining the datatype of the @lem attribute to accept spaces as you propose </em><br /> <em class="quotelev2">> > would be a bit problematic since that changes the definition. Of course, you </em><br /> <em class="quotelev2">> > could also argue that it *shouldn't* be defined as data.word... but it currently is! </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > message <200705021450.l42CiBmN008989_at_listserv.<!--nospam-->brown.edu> Elena Pierazzo </em><br /> <em class="quotelev2">> > <elena.pierazzo_at_KCL.<!--nospam-->AC.UK> writes: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> This is a multi-part message in MIME format. </em><br /> <em class="quotelev3">> >> --------------010005090407060100080705 </em><br /> <em class="quotelev3">> >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed </em><br /> <em class="quotelev3">> >> Content-Transfer-Encoding: 7bit </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Dear all, </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev3">> >> are lemmatizing all the words. For this purpose we are using: </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> <w lemma="">word</w> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev3">> >> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev3">> >> (separating the expression in "in" and "primis" is simply nonsensical). </em><br /> <em class="quotelev3">> >> The problem is that </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> <w lemma="in primis">in primis</w> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> is not valid as the lemma definition is </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> <attList> </em><br /> <em class="quotelev3">> >> <attDef ident="lemma" mode="change"> </em><br /> <em class="quotelev3">> >> <desc>identifies the word's lemma (dictionary entry form).</desc> </em><br /> <em class="quotelev3">> >> <datatype minOccurs="1" maxOccurs="1"> </em><br /> <em class="quotelev3">> >> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev3">> >> name="data.word"/> </em><br /> <em class="quotelev3">> >> </datatype> </em><br /> <em class="quotelev3">> >> ... </em><br /> <em class="quotelev3">> >> </attDef> </em><br /> <em class="quotelev3">> >> </attList> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev3">> >> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev3">> >> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev3">> >> everybody. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Bests </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Elena </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> -- </em><br /> <em class="quotelev3">> >> Elena Pierazzo </em><br /> <em class="quotelev3">> >> Associate Researcher </em><br /> <em class="quotelev3">> >> Centre for Computing in the Humanities </em><br /> <em class="quotelev3">> >> King's College London </em><br /> <em class="quotelev3">> >> Kay House 7 Arundel St </em><br /> <em class="quotelev3">> >> London WC2R 3DX </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Phone: 0207-848-1949 </em><br /> <em class="quotelev3">> >> Fax: 0207-848-2980 </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> --------------010005090407060100080705 </em><br /> <em class="quotelev3">> >> Content-Type: text/html; charset=ISO-8859-15 </em><br /> <em class="quotelev3">> >> Content-Transfer-Encoding: 8bit </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> </em><br /> <em class="quotelev3">> >> <html> </em><br /> <em class="quotelev3">> >> <head> </em><br /> <em class="quotelev3">> >> <meta content="text/html;charset=ISO-8859-15" </em><br /> <em class="quotelev3">> >> http-equiv="Content-Type"> </em><br /> <em class="quotelev3">> >> </head> </em><br /> <em class="quotelev3">> >> <body bgcolor="#ffffff" text="#000000"> </em><br /> <em class="quotelev3">> >> <font size="-1"><font face="Verdana">Dear all,<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev3">> >> are lemmatizing all the words. For this purpose we are using:<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <w lemma="">word</w><br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> but we are in trouble with multiword expressions (e.g. "in primis"). <br> </em><br /> <em class="quotelev3">> >> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev3">> >> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev3">> >> nonsensical). The problem is that <br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <w lemma="in primis">in primis</w><br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> is not valid as the lemma definition is<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <attList><br> </em><br /> <em class="quotelev3">> >> <attDef ident="lemma" mode="change"><br> </em><br /> <em class="quotelev3">> >> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev3">> >> form).</desc><br> </em><br /> <em class="quotelev3">> >> <datatype minOccurs="1" maxOccurs="1"><br> </em><br /> <em class="quotelev3">> >> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev2">> > href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> name="data.word"/><br> </em><br /> <em class="quotelev3">> >> </datatype><br> </em><br /> <em class="quotelev3">> >> ...<br> </em><br /> <em class="quotelev3">> >> </attDef><br> </em><br /> <em class="quotelev3">> >> </attList><br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev3">> >> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev3">> >> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev3">> >> everybody.<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Bests<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Elena<br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> </font></font><span class="moz-txt-tag">-- <br> </em><br /> <em class="quotelev3">> >> </span>Elena Pierazzo </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Associate Researcher </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Centre for Computing in the Humanities </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> King's College London </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Kay House 7 Arundel St </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> London WC2R 3DX </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Phone: 0207-848-1949 </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> Fax: 0207-848-2980 </em><br /> <em class="quotelev3">> >> <br> </em><br /> <em class="quotelev3">> >> </body> </em><br /> <em class="quotelev3">> >> </html> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> --------------010005090407060100080705-- </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 14:53:25 EDT</span> </div> From daniel.odonnell at uleth.ca Wed May 2 23:55:49 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 02 May 2007 21:55:49 -0600 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <1178164549.9068.20.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 02 May 2007 21:55:49 -0600</span><br /> </address> I don't want to speak for Christian while he sleeps, but I'd like to add <br /> that the planning committee met right after the meeting and did some <br /> triage on the action items, as discussed at the end of the council. <br /> We'll need to integrate these in the minutes. They're on Christian's <br /> computer. <br /> I agree the meeting went very well. <br /> -dan <br /> On Wed, 2007-05-02 at 08:21 -0400, Syd Bauman wrote: <br /> <em class="quotelev1">> The first draft of the minutes from our meeting our now available at </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although </em><br /> <em class="quotelev1">> some of you may prefer to download </em><br /> <em class="quotelev1">> http://www.tei-c.org/Council/tcm30.xml?style=raw.) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A lot was covered at this meeting, and though the notes are </em><br /> <em class="quotelev1">> extensive, I missed a lot, too. At some point before the next </em><br /> <em class="quotelev1">> conference call, each of us should read the entire document pretty </em><br /> <em class="quotelev1">> carefully. But *right now* you should quickly scan it, looking for </em><br /> <em class="quotelev1">> your initials and passages flagged with "[?", and send in </em><br /> <em class="quotelev1">> corrections ASAP, before (even more) details fade from memory, and so </em><br /> <em class="quotelev1">> that we get the record straight as soon as we can. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 14:53:26 EDT</span> </div> From cwittern at gmail.com Wed May 2 19:38:44 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 03 May 2007 08:38:44 +0900 Subject: [tei-council] Next telco Message-ID: <46392104.8040507@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 03 May 2007 08:38:44 +0900</span><br /> </address> Council members, <br /> I would like to schedule the next teleconference for the second week of <br /> June, that is between June 11 and 15. The time has to be UTC 1200 as <br /> usual. Please indicate which of these dates are suitable to you by <br /> visiting http://www.meetomatic.com/respond.php?id=LNCCG5 in the next few <br /> days. <br /> All the best, <br /> Christian <br /> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 14:56:06 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu May 3 04:39:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 03 May 2007 09:39:43 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <1178164035.9068.15.camel@localhost> Message-ID: <46399FCF.4080507@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 03 May 2007 09:39:43 +0100</span><br /> </address> There is one example in Elena's mail. As she points out there are plenty <br /> of times when it is convenient to regard as a single "word" something <br /> which is conventionally written as several orthographically distinct <br /> strings. Examples include "of course" "n'est-ce pas" "che bella" "et <br /> caetera" etc. Now, whether or not you regard the use of <w> to tag <br /> such things as legitimate you have the problem that at present we <br /> recommend using an attribute @lemma to carry the lemmatized version of <br /> the whatever it is (it somehow survived the war on attributes). And the <br /> lemma corresponding with a multiword may very well be a multiword itself <br /> (for example you might decide to mark phrasal verbs in this way and want <br /> to show that "putting up with" should have the lemma "put up with"). <br /> So yes, @lemma is the issue.<!--nospam--> Should it be abolished or should it have <br /> its datatype changed? <br /> <p>Daniel O'Donnell wrote: <br /> <em class="quotelev1">> Before we tamper with something like this, I'd like to see some real </em><br /> <em class="quotelev1">> examples of multiword lemmas... and, how does that affect w? Isn't it </em><br /> <em class="quotelev1">> lemma that's affected? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> This is really a datatype problem. Is there any desire on Council to </em><br /> <em class="quotelev2">>> review the datatype of the @lem attribute so as to address the issue? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Making it xsd:token rather than data.word would help with the specific </em><br /> <em class="quotelev2">>> case Elena raises, at the expense of making this attribute inconsistent </em><br /> <em class="quotelev2">>> with all the other cases of "texty" attributes. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> -------- Original Message -------- </em><br /> <em class="quotelev2">>> Subject: Re: recording multiword expression in lemma attribute </em><br /> <em class="quotelev2">>> Date: Wed, 02 May 2007 17:03:41 +0100 </em><br /> <em class="quotelev2">>> From: Elena Pierazzo <elena.pierazzo_at_kcl.<!--nospam-->ac.uk> </em><br /> <em class="quotelev2">>> To: Lou Burnard <lou.burnard_at_COMPUTING-SERVICES.<!--nospam-->OXFORD.AC.UK> </em><br /> <em class="quotelev2">>> CC: TEI-L_at_listserv.<!--nospam-->brown.edu </em><br /> <em class="quotelev2">>> References: <20070502152350.59BF2EB04D_at_webmail221.<!--nospam-->herald.ox.ac.uk> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Dear Lou, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> thanks for your example: I'll think about it. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I just argue that from a linguistic point of view a lemma is not </em><br /> <em class="quotelev2">>> necessarily a single word (in case of Romance languages for sure). </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> As it is, it seems that any project that is trying to lemmatize a text </em><br /> <em class="quotelev2">>> in a language that has multiword expressions cannot use the <w> element </em><br /> <em class="quotelev2">>> as it is and need to customize it either modifying the class or creating </em><br /> <em class="quotelev2">>> new elements. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Furthermore, if the attribute approach is suitable for simple cases, why </em><br /> <em class="quotelev2">>> TEI should not support complex cases? In many other modules we have the </em><br /> <em class="quotelev2">>> opportunity to choose which granularity to adopt in the encoding, while </em><br /> <em class="quotelev2">>> for this it seems that complex cases and projects that will adopt a </em><br /> <em class="quotelev2">>> complex linguistic approach has to decide on their own how to customize. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Cheers, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Elena </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Lou Burnard ha scritto: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> In my opinion, you would do better to put the lemma value into an element of its </em><br /> <em class="quotelev3">>>> own. The attribute value approach is really only suitable for simple cases. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> So if it was me, I would define new elements <form> and <lem> as specialised </em><br /> <em class="quotelev3">>>> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and </em><br /> <em class="quotelev3">>>> then mark it up thusly: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <w> </em><br /> <em class="quotelev3">>>> <lem>in primis</lem> </em><br /> <em class="quotelev3">>>> <form>in prrrrrimmmmissss</form> </em><br /> <em class="quotelev3">>>> </w> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> This means you can put markup into the <lem> as well as spaces </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Alternatively, you could adopt a simple convention like this: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> <w lem="in_primis">....</w> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Redefining the datatype of the @lem attribute to accept spaces as you propose </em><br /> <em class="quotelev3">>>> would be a bit problematic since that changes the definition. Of course, you </em><br /> <em class="quotelev3">>>> could also argue that it *shouldn't* be defined as data.word... but it currently is! </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> message <200705021450.l42CiBmN008989_at_listserv.<!--nospam-->brown.edu> Elena Pierazzo </em><br /> <em class="quotelev3">>>> <elena.pierazzo_at_KCL.<!--nospam-->AC.UK> writes: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> This is a multi-part message in MIME format. </em><br /> <em class="quotelev4">>>>> --------------010005090407060100080705 </em><br /> <em class="quotelev4">>>>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed </em><br /> <em class="quotelev4">>>>> Content-Transfer-Encoding: 7bit </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Dear all, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev4">>>>> are lemmatizing all the words. For this purpose we are using: </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> <w lemma="">word</w> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev4">>>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev4">>>>> (separating the expression in "in" and "primis" is simply nonsensical). </em><br /> <em class="quotelev4">>>>> The problem is that </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> <w lemma="in primis">in primis</w> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> is not valid as the lemma definition is </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> <attList> </em><br /> <em class="quotelev4">>>>> <attDef ident="lemma" mode="change"> </em><br /> <em class="quotelev4">>>>> <desc>identifies the word's lemma (dictionary entry form).</desc> </em><br /> <em class="quotelev4">>>>> <datatype minOccurs="1" maxOccurs="1"> </em><br /> <em class="quotelev4">>>>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev4">>>>> name="data.word"/> </em><br /> <em class="quotelev4">>>>> </datatype> </em><br /> <em class="quotelev4">>>>> ... </em><br /> <em class="quotelev4">>>>> </attDef> </em><br /> <em class="quotelev4">>>>> </attList> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev4">>>>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev4">>>>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev4">>>>> everybody. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Bests </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Elena </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> -- </em><br /> <em class="quotelev4">>>>> Elena Pierazzo </em><br /> <em class="quotelev4">>>>> Associate Researcher </em><br /> <em class="quotelev4">>>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev4">>>>> King's College London </em><br /> <em class="quotelev4">>>>> Kay House 7 Arundel St </em><br /> <em class="quotelev4">>>>> London WC2R 3DX </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev4">>>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> --------------010005090407060100080705 </em><br /> <em class="quotelev4">>>>> Content-Type: text/html; charset=ISO-8859-15 </em><br /> <em class="quotelev4">>>>> Content-Transfer-Encoding: 8bit </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> </em><br /> <em class="quotelev4">>>>> <html> </em><br /> <em class="quotelev4">>>>> <head> </em><br /> <em class="quotelev4">>>>> <meta content="text/html;charset=ISO-8859-15" </em><br /> <em class="quotelev4">>>>> http-equiv="Content-Type"> </em><br /> <em class="quotelev4">>>>> </head> </em><br /> <em class="quotelev4">>>>> <body bgcolor="#ffffff" text="#000000"> </em><br /> <em class="quotelev4">>>>> <font size="-1"><font face="Verdana">Dear all,<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev4">>>>> are lemmatizing all the words. For this purpose we are using:<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <w lemma="">word</w><br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> but we are in trouble with multiword expressions (e.g. "in primis"). <br> </em><br /> <em class="quotelev4">>>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev4">>>>> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev4">>>>> nonsensical). The problem is that <br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <w lemma="in primis">in primis</w><br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> is not valid as the lemma definition is<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <attList><br> </em><br /> <em class="quotelev4">>>>> <attDef ident="lemma" mode="change"><br> </em><br /> <em class="quotelev4">>>>> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev4">>>>> form).</desc><br> </em><br /> <em class="quotelev4">>>>> <datatype minOccurs="1" maxOccurs="1"><br> </em><br /> <em class="quotelev4">>>>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> name="data.word"/><br> </em><br /> <em class="quotelev4">>>>> </datatype><br> </em><br /> <em class="quotelev4">>>>> ...<br> </em><br /> <em class="quotelev4">>>>> </attDef><br> </em><br /> <em class="quotelev4">>>>> </attList><br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev4">>>>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev4">>>>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev4">>>>> everybody.<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Bests<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Elena<br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> </font></font><span class="moz-txt-tag">-- <br> </em><br /> <em class="quotelev4">>>>> </span>Elena Pierazzo </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Associate Researcher </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> King's College London </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Kay House 7 Arundel St </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> London WC2R 3DX </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev4">>>>> <br> </em><br /> <em class="quotelev4">>>>> </body> </em><br /> <em class="quotelev4">>>>> </html> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> --------------010005090407060100080705-- </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 15:53:45 EDT</span> </div> From dporter at uky.edu Thu May 3 15:57:27 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 3 May 2007 15:57:27 -0400 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <46399FCF.4080507@computing-services.oxford.ac.uk> Message-ID: <96f3df640705031257y5cd5b468h78210fc751ce67ae@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 3 May 2007 15:57:27 -0400</span><br /> </address> On 5/3/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> wrote: <br /> <em class="quotelev1">> So yes, @lemma is the issue.<!--nospam--> Should it be abolished or should it have </em><br /> <em class="quotelev1">> its datatype changed? </em><br /> <em class="quotelev1">> </em><br /> My first choice is to have the datatype changed to a pointer, with my <br /> second preference being @lemma becoming <lemma> <br /> Dot <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Daniel O'Donnell wrote: </em><br /> <em class="quotelev2">> > Before we tamper with something like this, I'd like to see some real </em><br /> <em class="quotelev2">> > examples of multiword lemmas... and, how does that affect w? Isn't it </em><br /> <em class="quotelev2">> > lemma that's affected? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> This is really a datatype problem. Is there any desire on Council to </em><br /> <em class="quotelev3">> >> review the datatype of the @lem attribute so as to address the issue? </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Making it xsd:token rather than data.word would help with the specific </em><br /> <em class="quotelev3">> >> case Elena raises, at the expense of making this attribute inconsistent </em><br /> <em class="quotelev3">> >> with all the other cases of "texty" attributes. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> -------- Original Message -------- </em><br /> <em class="quotelev3">> >> Subject: Re: recording multiword expression in lemma attribute </em><br /> <em class="quotelev3">> >> Date: Wed, 02 May 2007 17:03:41 +0100 </em><br /> <em class="quotelev3">> >> From: Elena Pierazzo <elena.pierazzo_at_kcl.<!--nospam-->ac.uk> </em><br /> <em class="quotelev3">> >> To: Lou Burnard <lou.burnard_at_COMPUTING-SERVICES.<!--nospam-->OXFORD.AC.UK> </em><br /> <em class="quotelev3">> >> CC: TEI-L_at_listserv.<!--nospam-->brown.edu </em><br /> <em class="quotelev3">> >> References: <20070502152350.59BF2EB04D_at_webmail221.<!--nospam-->herald.ox.ac.uk> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Dear Lou, </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> thanks for your example: I'll think about it. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> I just argue that from a linguistic point of view a lemma is not </em><br /> <em class="quotelev3">> >> necessarily a single word (in case of Romance languages for sure). </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> As it is, it seems that any project that is trying to lemmatize a text </em><br /> <em class="quotelev3">> >> in a language that has multiword expressions cannot use the <w> element </em><br /> <em class="quotelev3">> >> as it is and need to customize it either modifying the class or creating </em><br /> <em class="quotelev3">> >> new elements. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Furthermore, if the attribute approach is suitable for simple cases, why </em><br /> <em class="quotelev3">> >> TEI should not support complex cases? In many other modules we have the </em><br /> <em class="quotelev3">> >> opportunity to choose which granularity to adopt in the encoding, while </em><br /> <em class="quotelev3">> >> for this it seems that complex cases and projects that will adopt a </em><br /> <em class="quotelev3">> >> complex linguistic approach has to decide on their own how to customize. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Cheers, </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Elena </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev3">> >> Lou Burnard ha scritto: </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev4">> >>> In my opinion, you would do better to put the lemma value into an element of its </em><br /> <em class="quotelev4">> >>> own. The attribute value approach is really only suitable for simple cases. </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> So if it was me, I would define new elements <form> and <lem> as specialised </em><br /> <em class="quotelev4">> >>> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and </em><br /> <em class="quotelev4">> >>> then mark it up thusly: </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> <w> </em><br /> <em class="quotelev4">> >>> <lem>in primis</lem> </em><br /> <em class="quotelev4">> >>> <form>in prrrrrimmmmissss</form> </em><br /> <em class="quotelev4">> >>> </w> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> This means you can put markup into the <lem> as well as spaces </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> Alternatively, you could adopt a simple convention like this: </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> <w lem="in_primis">....</w> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> Redefining the datatype of the @lem attribute to accept spaces as you propose </em><br /> <em class="quotelev4">> >>> would be a bit problematic since that changes the definition. Of course, you </em><br /> <em class="quotelev4">> >>> could also argue that it *shouldn't* be defined as data.word... but it currently is! </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> message <200705021450.l42CiBmN008989_at_listserv.<!--nospam-->brown.edu> Elena Pierazzo </em><br /> <em class="quotelev4">> >>> <elena.pierazzo_at_KCL.<!--nospam-->AC.UK> writes: </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev1">> >>>> This is a multi-part message in MIME format. </em><br /> <em class="quotelev1">> >>>> --------------010005090407060100080705 </em><br /> <em class="quotelev1">> >>>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed </em><br /> <em class="quotelev1">> >>>> Content-Transfer-Encoding: 7bit </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> Dear all, </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev1">> >>>> are lemmatizing all the words. For this purpose we are using: </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> <w lemma="">word</w> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> but we are in trouble with multiword expressions (e.g. "in primis"). </em><br /> <em class="quotelev1">> >>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev1">> >>>> (separating the expression in "in" and "primis" is simply nonsensical). </em><br /> <em class="quotelev1">> >>>> The problem is that </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> <w lemma="in primis">in primis</w> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> is not valid as the lemma definition is </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> <attList> </em><br /> <em class="quotelev1">> >>>> <attDef ident="lemma" mode="change"> </em><br /> <em class="quotelev1">> >>>> <desc>identifies the word's lemma (dictionary entry form).</desc> </em><br /> <em class="quotelev1">> >>>> <datatype minOccurs="1" maxOccurs="1"> </em><br /> <em class="quotelev1">> >>>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev1">> >>>> name="data.word"/> </em><br /> <em class="quotelev1">> >>>> </datatype> </em><br /> <em class="quotelev1">> >>>> ... </em><br /> <em class="quotelev1">> >>>> </attDef> </em><br /> <em class="quotelev1">> >>>> </attList> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev1">> >>>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev1">> >>>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev1">> >>>> everybody. </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> Bests </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> Elena </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> -- </em><br /> <em class="quotelev1">> >>>> Elena Pierazzo </em><br /> <em class="quotelev1">> >>>> Associate Researcher </em><br /> <em class="quotelev1">> >>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev1">> >>>> King's College London </em><br /> <em class="quotelev1">> >>>> Kay House 7 Arundel St </em><br /> <em class="quotelev1">> >>>> London WC2R 3DX </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev1">> >>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> --------------010005090407060100080705 </em><br /> <em class="quotelev1">> >>>> Content-Type: text/html; charset=ISO-8859-15 </em><br /> <em class="quotelev1">> >>>> Content-Transfer-Encoding: 8bit </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> </em><br /> <em class="quotelev1">> >>>> <html> </em><br /> <em class="quotelev1">> >>>> <head> </em><br /> <em class="quotelev1">> >>>> <meta content="text/html;charset=ISO-8859-15" </em><br /> <em class="quotelev1">> >>>> http-equiv="Content-Type"> </em><br /> <em class="quotelev1">> >>>> </head> </em><br /> <em class="quotelev1">> >>>> <body bgcolor="#ffffff" text="#000000"> </em><br /> <em class="quotelev1">> >>>> <font size="-1"><font face="Verdana">Dear all,<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> I'm working in a project with a strong lexicographical component so we </em><br /> <em class="quotelev1">> >>>> are lemmatizing all the words. For this purpose we are using:<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <w lemma="">word</w><br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> but we are in trouble with multiword expressions (e.g. "in primis"). <br> </em><br /> <em class="quotelev1">> >>>> From a lexicographical point of view it is matter of a single entry </em><br /> <em class="quotelev1">> >>>> (separating the expression in "in" and "primis" is simply </em><br /> <em class="quotelev1">> >>>> nonsensical). The problem is that <br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <w lemma="in primis">in primis</w><br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> is not valid as the lemma definition is<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <attList><br> </em><br /> <em class="quotelev1">> >>>> <attDef ident="lemma" mode="change"><br> </em><br /> <em class="quotelev1">> >>>> <desc>identifies the word's lemma (dictionary entry </em><br /> <em class="quotelev1">> >>>> form).</desc><br> </em><br /> <em class="quotelev1">> >>>> <datatype minOccurs="1" maxOccurs="1"><br> </em><br /> <em class="quotelev1">> >>>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev4">> >>> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev4">> >>> </em><br /> <em class="quotelev1">> >>>> name="data.word"/><br> </em><br /> <em class="quotelev1">> >>>> </datatype><br> </em><br /> <em class="quotelev1">> >>>> ...<br> </em><br /> <em class="quotelev1">> >>>> </attDef><br> </em><br /> <em class="quotelev1">> >>>> </attList><br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> I can modify the definition, but I was thinking that my problem can be </em><br /> <em class="quotelev1">> >>>> rather common (for instance, Italian language contains thousands of </em><br /> <em class="quotelev1">> >>>> multiword expressions...) and would like to submit the question to </em><br /> <em class="quotelev1">> >>>> everybody.<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Bests<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Elena<br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> </font></font><span class="moz-txt-tag">-- <br> </em><br /> <em class="quotelev1">> >>>> </span>Elena Pierazzo </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Associate Researcher </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Centre for Computing in the Humanities </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> King's College London </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Kay House 7 Arundel St </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> London WC2R 3DX </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Phone: 0207-848-1949 </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> Fax: 0207-848-2980 </em><br /> <em class="quotelev1">> >>>> <br> </em><br /> <em class="quotelev1">> >>>> </body> </em><br /> <em class="quotelev1">> >>>> </html> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> --------------010005090407060100080705-- </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev1">> >>>> </em><br /> <em class="quotelev3">> >> _______________________________________________ </em><br /> <em class="quotelev3">> >> tei-council mailing list </em><br /> <em class="quotelev3">> >> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">> >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 03 2007 - 15:57:32 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Fri May 4 10:51:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 04 May 2007 15:51:57 +0100 Subject: [tei-council] tcm30 Message-ID: <463B488D.3000709@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 04 May 2007 15:51:57 +0100</span><br /> </address> One suggestion and some amplifications: <br /> 1. If you tag the actions as <note type="action"><label>...</label>plain <br /> text </note> (as usual), rather than as <note <br /> type="action"><label>...</label><p>plain text</p> </note>, then the <br /> resulting formatted text will be easier to read on screen, and waste <br /> fewer trees when printed out <br /> 2. the reference to 4/5 character issue in CH is the point raised in <br /> David's email <br /> http://lists.village.virginia.edu/pipermail/tei-council/2007/002860.html <br /> about whether the French word "coeur" for example has five characters or <br /> four. <br /> 3. Under ST, my notes read "amplify discussion of classes; module names <br /> need review" -- we should find some more consistent and sensible way of <br /> naming modules (once we've decided that we want to keep them, of course) <br /> 4. Under HD, <br /> - the action on Dot was also specifically to recommend whether or not <br /> the phrase "a machine readable version" vel sim shd be retained in a <br /> TEI title. <br /> - in the discussion of rendition, it was suggested that a global @style <br /> attribute might be useful, distinct from @rend <br /> - I have added the mimetype attribute to the <rendition> element but it <br /> needs more documentation <br /> - MJD supplied a list of typos in HD; I have corrected these <br /> The place where @xml:id was used instead of @ident was on <language> and <br /> I fixed it during the meeting. <br /> 5. VE -- I think I fixed the typos noted by JW in the meeting too, but <br /> I'll check <br /> 6. TS : my notes suggest that Dot's corrections are in TRAC 89 and that <br /> she agreed to update them <br /> 7. DI: my notes specify that there are too many examples of numbered <br /> divs in this chapter <br /> 8. TC/PH: I don't remember the point about re-ordering them being quite <br /> so clearcut; and I am quite sure that we didn't make any particular <br /> decision about <app> vs <choice>. The Beowulf example (Klaeber's use of <br /> parentheses) has been clarified in the source already. <br /> GD: The rather cryptic note "stemma modeling" means that DB and MD <br /> agreed to experiment with using the tagset in GD for representing a ms <br /> stemma, a point repeated in the minutes further on <br /> FT : Conal also pointed out that we should give more info on how to use <br /> e.g. SVG in a TEI document here, or at least reference MD <br /> .... oops must dash to a meeting, more later <br /> Lou <br /> <p><p><p><p><p><p><p><p><p><p><p><p><p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri May 04 2007 - 10:55:09 EDT</span> </div> From Syd_Bauman at Brown.edu Fri May 4 20:48:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 4 May 2007 20:48:04 -0400 (EDT) Subject: [tei-council] tcm30 In-Reply-To: <463B488D.3000709@oucs.ox.ac.uk> Message-ID: <200705050048.l450m486017209@perseus.services.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 4 May 2007 20:48:04 -0400 (EDT)</span><br /> </address> <em class="quotelev1">> 1. If you tag the actions as <note </em><br /> <em class="quotelev1">> type="action"><label>...</label>plain text </note> (as usual), </em><br /> <em class="quotelev1">> rather than as <note type="action"><label>...</label><p>plain </em><br /> <em class="quotelev1">> text</p> </note>, then the resulting formatted text will be easier </em><br /> <em class="quotelev1">> to read on screen, and waste fewer trees when printed out </em><br /> Uh ... yes, that is true. Of course, it would be better to fix the <br /> stylesheet IMHO. <br /> <p><em class="quotelev1">> 2. the reference to 4/5 character issue in CH is the point raised </em><br /> <em class="quotelev1">> in David's email </em><br /> <em class="quotelev1">> http://lists.village.virginia.edu/pipermail/tei-council/2007/002860.html </em><br /> <em class="quotelev1">> about whether the French word "coeur" for example has five </em><br /> <em class="quotelev1">> characters or four. </em><br /> Ah! Thank you. Fixed. <br /> <p><em class="quotelev1">> 3. Under ST, my notes read "amplify discussion of classes; module names </em><br /> <em class="quotelev1">> need review" -- we should find some more consistent and sensible </em><br /> <em class="quotelev1">> way of naming modules (once we've decided that we want to keep </em><br /> <em class="quotelev1">> them, of course) </em><br /> I'm not sure if you're suggesting this should replace the last <br /> sentence and action item or augment them. <br /> <p><em class="quotelev1">> 4. Under HD, - the action on Dot was also specifically to recommend </em><br /> <em class="quotelev1">> whether or not the phrase "a machine readable version" vel sim shd </em><br /> <em class="quotelev1">> be retained in a TEI title. </em><br /> Check, added. <br /> <p><em class="quotelev1">> - in the discussion of rendition, it was suggested that a global </em><br /> <em class="quotelev1">> @style attribute might be useful, distinct from @rend </em><br /> Right. JW is supposedly writing up this portion of the minutes. <br /> <p><em class="quotelev1">> - I have added the mimetype attribute to the <rendition> element </em><br /> <em class="quotelev1">> but it needs more documentation </em><br /> Check, noted. <br /> <p><em class="quotelev1">> - MJD supplied a list of typos in HD; I have corrected these </em><br /> Check, noted. <br /> <p><em class="quotelev1">> The place where @xml:id was used instead of @ident was on </em><br /> <em class="quotelev1">> <language> and I fixed it during the meeting. </em><br /> Check, thanks. Noted. <br /> <p><em class="quotelev1">> 5. VE -- I think I fixed the typos noted by JW in the meeting too, </em><br /> <em class="quotelev1">> but I'll check </em><br /> Standing by ... <br /> <p><em class="quotelev1">> 6. TS : my notes suggest that Dot's corrections are in TRAC 89 and that </em><br /> <em class="quotelev1">> she agreed to update them </em><br /> There is nothing in ticket #89. <br /> <p><em class="quotelev1">> 7. DI: my notes specify that there are too many examples of numbered </em><br /> <em class="quotelev1">> divs in this chapter </em><br /> I don't remember that being said, but I agree wholeheartedly! <br /> <p><em class="quotelev1">> 8. TC/PH: I don't remember the point about re-ordering them being </em><br /> <em class="quotelev1">> quite so clearcut; </em><br /> I remember it as being very clear-cut, primarily because I didn't <br /> understand it. Seemed to me you'd want to know how to encode a normal <br /> book before trying to work on an aparatus, but I was told there are a <br /> lot of references from PH to TC. <br /> Any one else have recollections of this? Opinions? <br /> <p><em class="quotelev1">> ... and I am quite sure that we didn't make any particular decision </em><br /> <em class="quotelev1">> about <app> vs <choice>. </em><br /> Check, so noted. <br /> <p><em class="quotelev1">> The Beowulf example (Klaeber's use of parentheses) has been </em><br /> <em class="quotelev1">> clarified in the source already. </em><br /> Check, which is why the action item says "done" for the date. <br /> <p><em class="quotelev1">> GD: The rather cryptic note "stemma modeling" means that DB and MD </em><br /> <em class="quotelev1">> agreed to experiment with using the tagset in GD for representing a </em><br /> <em class="quotelev1">> ms stemma, a point repeated in the minutes further on </em><br /> Check, thanks; so noted. <br /> <p><em class="quotelev1">> FT : Conal also pointed out that we should give more info on how to </em><br /> <em class="quotelev1">> use e.g. SVG in a TEI document here, or at least reference MD </em><br /> Check. So noted. <br /> <p><em class="quotelev1">> .... oops must dash to a meeting, more later </em><br /> Thanks for all these, and sorry I didn't get to them earlier today, <br /> but I had a bunch of meetings, too. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Fri May 04 2007 - 20:48:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat May 5 17:44:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 05 May 2007 22:44:22 +0100 Subject: [tei-council] actions from last week Message-ID: <463CFAB6.7060804@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 05 May 2007 22:44:22 +0100</span><br /> </address> I have been through the minutes of Berlin, <br /> and put in links to a set of tickets in trac which <br /> formalize the set of activites for coming 6 weeks. <br /> This is hopefully as per a planning <br /> meeting between self, Dan and Christian in Berlin. <br /> Please look at <br /> http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=Actions+from+chapter+review <br /> and make sure you know what is on your plate. <br /> Also read the minutes carefully. Any actions in there <br /> which no link to a trac ticket should be either <br /> so trivial that you have done them already, or <br /> so vague that I could not make a worthwhile ticket. <br /> If you are doing anything substantial this month <br /> for P5 which does not correspond to a trac item, <br /> please tell me so that I can record it. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat May 05 2007 - 17:44:27 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Sat May 5 18:24:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 05 May 2007 23:24:34 +0100 Subject: [tei-council] Tite for real Message-ID: <463D0422.8060301@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 05 May 2007 23:24:34 +0100</span><br /> </address> have a look at <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite.odd <br /> and consider <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite1.xml?style=xml <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite2.xml?style=xml <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite3.xml?style=xml <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite4.xml?style=xml <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite5.xml?style=xml <br /> http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite5.xml?style=xml <br /> these are all representations of a test Tite document, <br /> showing how the different namespace needed for the <br /> syntactic sugar elements in Tite can be handled. They <br /> all validate against a RELAXNG or XSD schema, but not <br /> all against the a DTD. testtite4.xml shows what a <br /> DTD-friendly version looks like - the DTD provides <br /> all the xmlns declarations. <br /> I'll have more to say on this, but I wanted to show <br /> concrete examples of what genuine Tite documents <br /> might look like, if we follow the proposal. <br /> For the cognoscenti, in Guidelines/Exemplars you <br /> can find make-acdc.xsl, which is an XSLT script <br /> to generate an XSLT transform from the <equiv> <br /> elements in testtite.odd, which makes a genuinely conformant <br /> TEI document from a TEI Tite one. <br /> I'm now off to bed and then away on holiday for a day, <br /> so don't expect me to answer questions on this until <br /> late Monday :-} <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat May 05 2007 - 18:24:38 EDT</span> </div> From cwittern at gmail.com Mon May 7 01:11:45 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:11:45 +0900 Subject: [tei-council] Berlin extra tour Message-ID: <463EB511.1000108@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 07 May 2007 14:11:45 +0900</span><br /> </address> Dear Council members, <br /> For those who went with me on our little impromptu Berlin excursion, I <br /> have now put up a GPS log of my steps of that evening at <br /> http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tmp/berlin-walk.zip <br /> You will find three files in there: <br /> berlin-walk.html will display a google map with the walk overlaid, you <br /> can use the play button to replay <br /> W*.log two files, one for the way to the restaurant, the <br /> other for the way back, for those who want to georeference the pictures <br /> taken during the excursion. <br /> All the best, <br /> Christian <br /> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon May 07 2007 - 01:11:54 EDT</span> </div> From cwittern at gmail.com Mon May 7 01:19:28 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:19:28 +0900 Subject: [tei-council] next telco date: June 12, 2007 Message-ID: <463EB6E0.8040308@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 07 May 2007 14:19:28 +0900</span><br /> </address> Dear Council members, <br /> Meetomatic has sent me the following recommendation: <br /> <p>So far, 11 responses have been received, and Meet-O-Matic is currently <br /> recommending the following date for the meeting: <br /> Tuesday 12th June 2007 <br /> On closer inspection, David Birnbaum is the only one who will not be <br /> available on this date out of those who responded. Another contender <br /> for the meeting date would be Friday, 15th, were we would have to do <br /> without Tone Merete. However, for the moment I would like to set the <br /> meeting to Tuesday 12th June 2007 , 12:00 GMT <br /> We expect a report on all action items from the Berlin meeting there at <br /> the latest, but please feel free to report at your earliest convenience:-) <br /> <p>All the best, <br /> Christian <br /> <p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon May 07 2007 - 01:19:37 EDT</span> </div> From cwittern at gmail.com Mon May 7 01:21:50 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:21:50 +0900 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <96f3df640705031257y5cd5b468h78210fc751ce67ae@mail.gmail.com> Message-ID: <463EB76E.4090802@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 07 May 2007 14:21:50 +0900</span><br /> </address> Dot Porter wrote: <br /> <em class="quotelev1">> On 5/3/07, Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> </em><br /> <em class="quotelev1">> wrote: </em><br /> <em class="quotelev2">>> So yes, @lemma is the issue.<!--nospam--> Should it be abolished or should it have </em><br /> <em class="quotelev2">>> its datatype changed? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> My first choice is to have the datatype changed to a pointer, with my </em><br /> <em class="quotelev1">> second preference being @lemma becoming <lemma> </em><br /> <em class="quotelev1">> </em><br /> This seems preferable to me as well. We will need examples to illustrate the usage then as well. <br /> Christian <br /> <p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Mon May 07 2007 - 01:21:58 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Mon May 7 05:49:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 07 May 2007 10:49:28 +0100 Subject: [tei-council] Berlin extra tour In-Reply-To: <463EB511.1000108@gmail.com> Message-ID: <463EF628.9050404@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 07 May 2007 10:49:28 +0100</span><br /> </address> Now that's what I call cool. If only I'd known I was participating in a <br /> scientific experiment! <br /> Wittern Christian wrote: <br /> <em class="quotelev1">> Dear Council members, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> For those who went with me on our little impromptu Berlin excursion, I </em><br /> <em class="quotelev1">> have now put up a GPS log of my steps of that evening at </em><br /> <em class="quotelev1">> http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tmp/berlin-walk.zip </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> You will find three files in there: </em><br /> <em class="quotelev1">> berlin-walk.html will display a google map with the walk overlaid, you </em><br /> <em class="quotelev1">> can use the play button to replay </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> W*.log two files, one for the way to the restaurant, the </em><br /> <em class="quotelev1">> other for the way back, for those who want to georeference the pictures </em><br /> <em class="quotelev1">> taken during the excursion. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> All the best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Christian </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon May 07 2007 - 05:50:16 EDT</span> </div> From Syd_Bauman at Brown.edu Mon May 7 22:54:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 7 May 2007 22:54:29 -0400 Subject: [tei-council] Berlin extra tour In-Reply-To: <463EB511.1000108@gmail.com> Message-ID: <17983.58981.476158.887427@emt.wwp.brown.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Syd Bauman <Syd_Bauman_at_Brown.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Mon, 7 May 2007 22:54:29 -0400</span><br /> </address> Oh that's cool. I can just hear Joan Jett or Pat Benetar now: <br /> I saw directions there on the computer screen <br /> I knew it was a place I had never been <br /> Me walkin' in my thongs, <br /> Singin' spoof X-M-L songs, <br /> An' I could tell it's gonna be long, <br /> Till we get to eat, yeah eat, singin' <br /> <br /> I love Google Earth, <br /> Please take me for a walk around Berlin, Christian; <br /> I love Google Earth, <br /> So come an' take your time an' walk with me. <br /> (For original lyrics see, e.g., <br /> http://www.lyred.com/lyrics/Joan+Jett+And+The+Blackhearts/I+Love+Rock+&+Roll/I+Love+Rock+N%27+Roll/) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Mon May 07 2007 - 22:54:33 EDT</span> </div> From cwittern at gmail.com Tue May 8 16:19:35 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 09 May 2007 05:19:35 +0900 Subject: [tei-council] facsimile markup Message-ID: <4640DB57.1060609@gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Wittern Christian <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 05:19:35 +0900</span><br /> </address> Dear Conal and Dot, <br /> Looking at the Berlin minutes again, I now see that there is no action <br /> item to follow up on the facsimile markup. While it might not be <br /> necessary for 1.0, I think now that the work has progressed so far it <br /> would be a pity not to include it, especially given the frequent <br /> requests for this. <br /> So I wonder if you could adress the concerns mentioned and revise your <br /> propsosal in a way that could go into the Guidelines. Maybe you could <br /> as a starter post the things we looked at during the meeting somewhere <br /> (at the Wiki?) so that we can have a closer look. <br /> All the best, <br /> Christian <br /> <p> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue May 08 2007 - 16:19:54 EDT</span> </div> From conal.tuohy at vuw.ac.nz Tue May 8 22:00:46 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 09 May 2007 14:00:46 +1200 Subject: [tei-council] facsimile markup In-Reply-To: <4640DB57.1060609@gmail.com> Message-ID: <1178676046.3107.128.camel@localhost> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Conal Tuohy <conal.tuohy_at_vuw.ac.nz> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 14:00:46 +1200</span><br /> </address> I finished my holiday in the UK and I'm now at work and catching up on a <br /> backlog of email. <br /> On Wed, 2007-05-09 at 05:19 +0900, Wittern Christian wrote: <br /> <em class="quotelev1">> Dear Conal and Dot, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Looking at the Berlin minutes again, I now see that there is no action </em><br /> <em class="quotelev1">> item to follow up on the facsimile markup. While it might not be </em><br /> <em class="quotelev1">> necessary for 1.0, I think now that the work has progressed so far it </em><br /> <em class="quotelev1">> would be a pity not to include it, especially given the frequent </em><br /> <em class="quotelev1">> requests for this. </em><br /> My memory was that I had an action item to compile a "full" set of <br /> examples, including the Comenius example, marked up according to that <br /> draft, and also to write it up as a chapter (or section of a chapter). <br /> <em class="quotelev1">> So I wonder if you could adress the concerns mentioned and revise your </em><br /> <em class="quotelev1">> propsosal in a way that could go into the Guidelines. Maybe you could </em><br /> <em class="quotelev1">> as a starter post the things we looked at during the meeting somewhere </em><br /> <em class="quotelev1">> (at the Wiki?) so that we can have a closer look. </em><br /> Will do <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> All the best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Christian </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Tue May 08 2007 - 22:07:44 EDT</span> </div> From dporter at uky.edu Tue May 8 22:14:27 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 9 May 2007 04:14:27 +0200 Subject: [tei-council] facsimile markup In-Reply-To: <1178676046.3107.128.camel@localhost> Message-ID: <96f3df640705081914m71af0ddi4ee9c751b7a1adc9@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 04:14:27 +0200</span><br /> </address> Lou was keen on having us look at the proposal next to what already <br /> appears in the Linking chapter. This wasn't assigned to me at the time <br /> but I am happy to take it on. <br /> Dot <br /> On 5/9/07, Conal Tuohy <conal.tuohy_at_vuw.<!--nospam-->ac.nz> wrote: <br /> <em class="quotelev1">> I finished my holiday in the UK and I'm now at work and catching up on a </em><br /> <em class="quotelev1">> backlog of email. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On Wed, 2007-05-09 at 05:19 +0900, Wittern Christian wrote: </em><br /> <em class="quotelev2">> > Dear Conal and Dot, </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Looking at the Berlin minutes again, I now see that there is no action </em><br /> <em class="quotelev2">> > item to follow up on the facsimile markup. While it might not be </em><br /> <em class="quotelev2">> > necessary for 1.0, I think now that the work has progressed so far it </em><br /> <em class="quotelev2">> > would be a pity not to include it, especially given the frequent </em><br /> <em class="quotelev2">> > requests for this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> My memory was that I had an action item to compile a "full" set of </em><br /> <em class="quotelev1">> examples, including the Comenius example, marked up according to that </em><br /> <em class="quotelev1">> draft, and also to write it up as a chapter (or section of a chapter). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > So I wonder if you could adress the concerns mentioned and revise your </em><br /> <em class="quotelev2">> > propsosal in a way that could go into the Guidelines. Maybe you could </em><br /> <em class="quotelev2">> > as a starter post the things we looked at during the meeting somewhere </em><br /> <em class="quotelev2">> > (at the Wiki?) so that we can have a closer look. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Will do </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > All the best, </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Christian </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue May 08 2007 - 22:14:31 EDT</span> </div> From jawalsh at indiana.edu Wed May 9 00:39:27 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 00:39:27 -0400 Subject: [tei-council] rendition, rend, and style Message-ID: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 00:39:27 -0400</span><br /> </address> Hi all, <br /> I'm supposed to write up my thoughts on proposed changes to <br /> <rendition> and @rend, including the possible addition of an @style <br /> attribute. <br /> The current P5 guidelines state that @rend "indicates how the element <br /> in question was rendered or presented in the source text." But my <br /> sense is that in practice @rend is used both to indicate how an <br /> element was rendered in the source text and/or how it should be <br /> rendered in a display environment such as a Web browser or printed <br /> output. <br /> The addition of @style could be used to distinguish between rendering <br /> in the source text (@rend) and rendering in an output format <br /> (@style).<!--nospam--> *OR* the addition of @style could be used to provided the <br /> @class/@style functionality of HTML.<!--nospam--> @rend (like @class) could refer <br /> to predefined style classes, which could be defined in the <br /> <rendition> element of the TEI Header. @style could be used to embed <br /> style information directly in an element. <br /> If we simply want to distinguish between source rendering and output <br /> rendering with the addition of an @style attribute, then my task is <br /> easy. <br /> If on the other hand we want to provide the @class/@style <br /> functionality of HTML, the task is more difficult and would involve <br /> prescribing or recommending practice that is not common at the <br /> moment, and would also likely involve changes to the <rendition> <br /> element and perhaps a new element in <encodingDesc> where folks could <br /> explain their implementation. For instance, users may define their <br /> styles using CSS, XSL-FO, rendition ladders, or some other mechanism, <br /> and this will need to be explained in <encodingDesc>. <br /> I believe we touched on all these various distinctions in Berlin, so <br /> I would like members of the council to weigh in on which way to go <br /> with this. Please select A. or B. (or a new letter and proposal of <br /> your own invention): <br /> A. @rend/@style should distinguish between source rendering and <br /> output rendering. <br /> B. @rend/@style should distinguish between HTML-like @class <br /> functionality and HTML-like @style functionality.<!--nospam--> <br /> Incidentally, if we go with B. and style classes are defined in <br /> <rendition> elements of the TEI Header, then we could add an <br /> attribute to <rendition> that indicates whether the "target" of this <br /> rendition "class" is the source text or the output format. The <br /> @style attribute would remain ambiguous in terms of source/output, <br /> but this ambiguity could be addressed and clarified in the <br /> <encodingDesc>. <br /> Once I hear back from others on the Council, I'll proceed with a more <br /> formal document on this topic. <br /> John <br /> -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 00:39:39 EDT</span> </div> From daniel.odonnell at uleth.ca Wed May 9 00:53:43 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 08 May 2007 22:53:43 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <1178686423.26240.2.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 08 May 2007 22:53:43 -0600</span><br /> </address> I like option a) @rend=input document, @style=output document with no <br /> guideline constraints on language used to describe them. <br /> However, I can easily see that somebody might want to use CSS as a style <br /> shorthand for @style and maybe even @rend, and that in such cases this <br /> should be machine checkable. Perhaps an optional reference in the header <br /> to the language used on the attributes if applicable? I.e. something <br /> that would have text/css and maybe xslt-fo as a valid attribute. <br /> -dan <br /> On Wed, 2007-05-09 at 00:39 -0400, John A. Walsh wrote: <br /> <em class="quotelev1">> Hi all, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev1">> <rendition> and @rend, including the possible addition of an @style </em><br /> <em class="quotelev1">> attribute. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The current P5 guidelines state that @rend "indicates how the element </em><br /> <em class="quotelev1">> in question was rendered or presented in the source text." But my </em><br /> <em class="quotelev1">> sense is that in practice @rend is used both to indicate how an </em><br /> <em class="quotelev1">> element was rendered in the source text and/or how it should be </em><br /> <em class="quotelev1">> rendered in a display environment such as a Web browser or printed </em><br /> <em class="quotelev1">> output. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The addition of @style could be used to distinguish between rendering </em><br /> <em class="quotelev1">> in the source text (@rend) and rendering in an output format </em><br /> <em class="quotelev1">> (@style).<!--nospam--> *OR* the addition of @style could be used to provided the </em><br /> <em class="quotelev1">> @class/@style functionality of HTML.<!--nospam--> @rend (like @class) could refer </em><br /> <em class="quotelev1">> to predefined style classes, which could be defined in the </em><br /> <em class="quotelev1">> <rendition> element of the TEI Header. @style could be used to embed </em><br /> <em class="quotelev1">> style information directly in an element. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If we simply want to distinguish between source rendering and output </em><br /> <em class="quotelev1">> rendering with the addition of an @style attribute, then my task is </em><br /> <em class="quotelev1">> easy. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev1">> functionality of HTML, the task is more difficult and would involve </em><br /> <em class="quotelev1">> prescribing or recommending practice that is not common at the </em><br /> <em class="quotelev1">> moment, and would also likely involve changes to the <rendition> </em><br /> <em class="quotelev1">> element and perhaps a new element in <encodingDesc> where folks could </em><br /> <em class="quotelev1">> explain their implementation. For instance, users may define their </em><br /> <em class="quotelev1">> styles using CSS, XSL-FO, rendition ladders, or some other mechanism, </em><br /> <em class="quotelev1">> and this will need to be explained in <encodingDesc>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I believe we touched on all these various distinctions in Berlin, so </em><br /> <em class="quotelev1">> I would like members of the council to weigh in on which way to go </em><br /> <em class="quotelev1">> with this. Please select A. or B. (or a new letter and proposal of </em><br /> <em class="quotelev1">> your own invention): </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev1">> output rendering. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev1">> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev1">> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev1">> attribute to <rendition> that indicates whether the "target" of this </em><br /> <em class="quotelev1">> rendition "class" is the source text or the output format. The </em><br /> <em class="quotelev1">> @style attribute would remain ambiguous in terms of source/output, </em><br /> <em class="quotelev1">> but this ambiguity could be addressed and clarified in the </em><br /> <em class="quotelev1">> <encodingDesc>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Once I hear back from others on the Council, I'll proceed with a more </em><br /> <em class="quotelev1">> formal document on this topic. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> | John A. Walsh </em><br /> <em class="quotelev1">> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 00:53:50 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed May 9 04:08:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 09 May 2007 09:08:11 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <4641816B.2010208@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 09:08:11 +0100</span><br /> </address> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev1">> <rendition> elements of the TEI Header, then we could add an attribute </em><br /> <em class="quotelev1">> to <rendition> that indicates whether the "target" of this rendition </em><br /> <em class="quotelev1">> "class" is the source text or the output format. The @style attribute </em><br /> <em class="quotelev1">> would remain ambiguous in terms of source/output, but this ambiguity </em><br /> <em class="quotelev1">> could be addressed and clarified in the <encodingDesc>. </em><br /> Why would you want to use e.g. CSS to describe the *original* rendition? <br /> surely it lacks many features you'd need (nothing about page layout, for <br /> example) and has too many irrelevant ones (because it assumes you are <br /> going to render it on a screen)? <br /> To my mind it makes sense to keep @rend with the proviso that it's for <br /> describing the original. If we add @style (and I'm not yet convinced <br /> it's a good idea) it should refer only to desired output. <br /> Mixing input/output definitions within <rendition> doesn't bother me <br /> particularly, though. <br /> <p><p><p><em class="quotelev1">> </em><br /> <em class="quotelev1">> Once I hear back from others on the Council, I'll proceed with a more </em><br /> <em class="quotelev1">> formal document on this topic. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> | John A. Walsh </em><br /> <em class="quotelev1">> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 04:09:10 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 04:13:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 09:13:10 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <46418296.1060708@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 09:13:10 +0100</span><br /> </address> we could just recommend using "html:class" and "html:style" attributes <br /> ebastian <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 04:13:14 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Wed May 9 04:20:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 09 May 2007 09:20:51 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> Message-ID: <46418463.80007@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 09:20:51 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> we could just recommend using "html:class" and "html:style" attributes </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> sebastian </em><br /> <em class="quotelev1">> </em><br /> duh! of course! <br /> These namespace things really are tricksy little fellows eh? <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 04:21:50 EDT</span> </div> From arianna.ciula at kcl.ac.uk Wed May 9 06:44:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 09 May 2007 11:44:32 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> Message-ID: <4641A610.4020507@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 11:44:32 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> we could just recommend using "html:class" and "html:style" attributes </em><br /> Yes, I think namespaces offer a good service here. <br /> So I agree the definition for @rend should still refer to the <br /> representation of the source (even if this may correspond to what we <br /> want the output to look like, but that's another matter). <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> sebastian </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 06:45:01 EDT</span> </div> From jawalsh at indiana.edu Wed May 9 07:58:40 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 07:58:40 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <565EEECA-CC88-455F-9E3E-E7E9D01F9755@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 07:58:40 -0400</span><br /> </address> On May 9, 2007, at 4:08 AM, Lou Burnard wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev2">>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev2">>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev2">>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev2">>> The @style attribute would remain ambiguous in terms of source/ </em><br /> <em class="quotelev2">>> output, but this ambiguity could be addressed and clarified in the </em><br /> <em class="quotelev2">>> <encodingDesc>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Why would you want to use e.g. CSS to describe the *original* </em><br /> <em class="quotelev1">> rendition? surely it lacks many features you'd need (nothing about </em><br /> <em class="quotelev1">> page layout, for example) and has too many irrelevant ones (because </em><br /> <em class="quotelev1">> it assumes you are going to render it on a screen)? </em><br /> <em class="quotelev1">> </em><br /> I'm imagining people might use a mix of CSS and XSL-FO and their own <br /> custom definitions to describe things. I believe CSS covers most of <br /> what people use rend for (font styles, indentation, superscript, <br /> subscript, alignment, margins, color, line spacing, etc.) <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 07:59:08 EDT</span> </div> From jawalsh at indiana.edu Wed May 9 08:02:03 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 08:02:03 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> Message-ID: <E163C1F2-BA22-48E3-99C1-56626C69A132@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 08:02:03 -0400</span><br /> </address> On May 9, 2007, at 4:13 AM, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> we could just recommend using "html:class" and "html:style" </em><br /> <em class="quotelev1">> attributes </em><br /> <em class="quotelev1">> </em><br /> True, although I like the idea of formalizing a relationship between <br /> <rendition> and @rend, and using the header to be more explicit about <br /> what exactly is going on with rendering issues in a document. <br /> Nothing prevents people from doing so now, but there is not much <br /> guidance in the guidelines on this particular issue. Although, <br /> perhaps practice and preferences vary so much that we want to leave <br /> it open and flexible. <br /> John <br /> <p><em class="quotelev1">> sebastian </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 08:02:44 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 09:11:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 14:11:41 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <4641C88D.6030304@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 14:11:41 +0100</span><br /> </address> I think that anyone who wants the equivalent of HTML's @style should <br /> literally <br /> use html:style, and it would only be used on born-digital stuff. So lets <br /> consider <br /> just HTML's class vs rend. <br /> If rend is to be used for what we _see_, we'll <br /> also very often use it for how we render. So <hi rend="italic"> <br /> will want to rendered as <span class="italic">, usually. We <br /> don't want to force people to say <hi rend="italic" style="italic">, <br /> so it makes sense for "italic" be a link to a place in <rendition> <br /> where it is mapped to a) an expansion of what we say (did <br /> we differentiate italic from slanted?), and b) a rendition class <br /> (HTML, FO, whatever). <br /> So I am wondering whether we should not just keep the single <br /> rend, but change its datatype to be a pointer to a composite <br /> source/ rendering pair? <br /> If forced to go A or B, I incline to] <br /> A. @rend/@style should distinguish between source rendering and output <br /> rendering. <br /> in which @rend is a token which is expected to be explained <br /> in <rendition>, and @style is system dependent, but normally <br /> equivalent to HTML @class <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 09:11:44 EDT</span> </div> From jawalsh at indiana.edu Wed May 9 12:14:52 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 12:14:52 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641C88D.6030304@oucs.ox.ac.uk> Message-ID: <3D946E83-DB54-416E-BA19-B8467FBFCFD5@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 12:14:52 -0400</span><br /> </address> On May 9, 2007, at 9:11 AM, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> I think that anyone who wants the equivalent of HTML's @style </em><br /> <em class="quotelev1">> should literally </em><br /> <em class="quotelev1">> use html:style, and it would only be used on born-digital stuff. So </em><br /> <em class="quotelev1">> lets consider </em><br /> <em class="quotelev1">> just HTML's class vs rend. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If rend is to be used for what we _see_, we'll </em><br /> <em class="quotelev1">> also very often use it for how we render. So <hi rend="italic"> </em><br /> <em class="quotelev1">> will want to rendered as <span class="italic">, usually. We </em><br /> <em class="quotelev1">> don't want to force people to say <hi rend="italic" style="italic">, </em><br /> <em class="quotelev1">> so it makes sense for "italic" be a link to a place in <rendition> </em><br /> <em class="quotelev1">> where it is mapped to a) an expansion of what we say (did </em><br /> <em class="quotelev1">> we differentiate italic from slanted?), and b) a rendition class </em><br /> <em class="quotelev1">> (HTML, FO, whatever). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So I am wondering whether we should not just keep the single </em><br /> <em class="quotelev1">> rend, but change its datatype to be a pointer to a composite </em><br /> <em class="quotelev1">> source/ rendering pair? </em><br /> <em class="quotelev1">> </em><br /> Sebastian, <br /> There seems to be wise agreement not to duplicate @html:style with a <br /> new @tei:style.<!--nospam--> For @rend, what you describe above--_at_rend as a <br /> pointer to <rendition>--is what I was planning to document if there <br /> is agreement to move @rend more in the direction of @html:class.<!--nospam--> <br /> @rend would be different from @html:class because of its (potential) <br /> linkage with <rendition>. I think this proposed change to @rend is <br /> a good idea (and something I've used for years in my P4 extension <br /> files and P5 ODD files). It helps prevent sloppy use of @rend (e.<!--nospam-->g., <br /> @rend="i", @rend="italic", @rend="italics", @rend="italicize", etc.<!--nospam-->-- <br /> all in the same document). It potentially allows easy automatic <br /> generation of CSS (or XSL-FO) styles from information documented in <br /> the <rendition> elements of the TEI Header. But changing the datatype <br /> of @rend would break lots of stuff, e.<!--nospam-->g., rendition ladders. It's a <br /> fairly radical change to a widely used global element. <br /> Is such a change worth pursuing as part of the Guidelines, or is an <br /> ODD and documentation about how to use @rend in this manner something <br /> for a separate paper? <br /> John <br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 12:15:07 EDT</span> </div> From jawalsh at indiana.edu Wed May 9 12:29:51 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 12:29:51 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641B808.5000600@pitt.edu> Message-ID: <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 9 May 2007 12:29:51 -0400</span><br /> </address> David, <br /> I agree about the descriptive vs. presentational issue...but the <br /> stylesheets you mention often need triggers in the TEI source, and <br /> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since we <br /> have an @rend attribute, it would seem useful to provide a standard <br /> mechanism for documenting how that attribute is used and defining the <br /> meaning of its content. @rend="big" could mean lots of things, but if <br /> it points to <rendition xml:id="big">font-family: Granjon; font-size: <br /> 16pt; font-weight: bold</rendition>, then one has a clear idea of <br /> what @rend="big" means, and this rendition definition may well refer <br /> to the source text, not any output format. A stylesheet can still <br /> take the "big" trigger and do something else with it. The Guidelines <br /> do already state that the content of rendition may be "expressed in <br /> running prose, or in some more formal language such as CSS." <br /> John <br /> -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: > Dear John, > > Option C, please. XML isn't Microsoft Word and TEI markup should be > descriptive, rather than presentational. The ability to specify > output rendering is often very important to projects, but the place > to declare it is the stylesheet, not the document instance. > > Best, > > David > > John A. Walsh wrote: >> Hi all, >> >> I'm supposed to write up my thoughts on proposed changes to >> <rendition> and @rend, including the possible addition of an >> @style attribute.<!--nospam--> >> >> The current P5 guidelines state that @rend "indicates how the >> element in question was rendered or presented in the source >> text." But my sense is that in practice @rend is used both to >> indicate how an element was rendered in the source text and/or how >> it should be rendered in a display environment such as a Web >> browser or printed output. >> >> The addition of @style could be used to distinguish between >> rendering in the source text (@rend) and rendering in an output >> format (@style).<!--nospam--> *OR* the addition of @style could be used to >> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like >> @class) could refer to predefined style classes, which could be >> defined in the <rendition> element of the TEI Header. @style >> could be used to embed style information directly in an element. >> >> If we simply want to distinguish between source rendering and >> output rendering with the addition of an @style attribute, then my >> task is easy. >> >> If on the other hand we want to provide the @class/@style >> functionality of HTML, the task is more difficult and would >> involve prescribing or recommending practice that is not common at >> the moment, and would also likely involve changes to the >> <rendition> element and perhaps a new element in <encodingDesc> >> where folks could explain their implementation. For instance, >> users may define their styles using CSS, XSL-FO, rendition >> ladders, or some other mechanism, and this will need to be >> explained in <encodingDesc>. >> >> I believe we touched on all these various distinctions in Berlin, >> so I would like members of the council to weigh in on which way to >> go with this. Please select A. or B. (or a new letter and >> proposal of your own invention): >> >> A. @rend/@style should distinguish between source rendering and >> output rendering. >> >> B. @rend/@style should distinguish between HTML-like @class >> functionality and HTML-like @style functionality.<!--nospam--> >> >> Incidentally, if we go with B. and style classes are defined in >> <rendition> elements of the TEI Header, then we could add an >> attribute to <rendition> that indicates whether the "target" of >> this rendition "class" is the source text or the output format. >> The @style attribute would remain ambiguous in terms of source/ >> output, but this ambiguity could be addressed and clarified in the >> <encodingDesc>. >> >> Once I hear back from others on the Council, I'll proceed with a >> more formal document on this topic. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council_at_lists.<!--nospam-->village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 12:30:29 EDT</span> </div> From daniel.odonnell at uleth.ca Wed May 9 13:35:20 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 09 May 2007 11:35:20 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <1178732120.27069.49.camel@odonned-eng06> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dan O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 11:35:20 -0600</span><br /> </address> Thinking about the option presented so far, I have a modified option. I <br /> still prefer option A. But I like the idea of html:style for real CSS. <br /> I think there is a fair bit of anecdotal evidence that people would like <br /> the idea of being able to describe the output rendition. But I suppose <br /> it does raise the question of whether that is a structural issue or not <br /> something better handled by stylesheets. <br /> -dan <br /> <p>On Wed, 2007-09-05 at 09:08 +0100, Lou Burnard wrote: <br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev2">> > <rendition> elements of the TEI Header, then we could add an attribute </em><br /> <em class="quotelev2">> > to <rendition> that indicates whether the "target" of this rendition </em><br /> <em class="quotelev2">> > "class" is the source text or the output format. The @style attribute </em><br /> <em class="quotelev2">> > would remain ambiguous in terms of source/output, but this ambiguity </em><br /> <em class="quotelev2">> > could be addressed and clarified in the <encodingDesc>. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Why would you want to use e.g. CSS to describe the *original* rendition? </em><br /> <em class="quotelev1">> surely it lacks many features you'd need (nothing about page layout, for </em><br /> <em class="quotelev1">> example) and has too many irrelevant ones (because it assumes you are </em><br /> <em class="quotelev1">> going to render it on a screen)? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> To my mind it makes sense to keep @rend with the proviso that it's for </em><br /> <em class="quotelev1">> describing the original. If we add @style (and I'm not yet convinced </em><br /> <em class="quotelev1">> it's a good idea) it should refer only to desired output. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Mixing input/output definitions within <rendition> doesn't bother me </em><br /> <em class="quotelev1">> particularly, though. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Once I hear back from others on the Council, I'll proceed with a more </em><br /> <em class="quotelev2">> > formal document on this topic. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > John </em><br /> <em class="quotelev2">> > -- </em><br /> <em class="quotelev2">> > | John A. Walsh </em><br /> <em class="quotelev2">> > | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev2">> > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev2">> > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev2">> > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > _______________________________________________ </em><br /> <em class="quotelev2">> > tei-council mailing list </em><br /> <em class="quotelev2">> > tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 13:28:38 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 17:44:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 22:44:57 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3D946E83-DB54-416E-BA19-B8467FBFCFD5@indiana.edu> Message-ID: <464240D9.1060405@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 22:44:57 +0100</span><br /> </address> John A. Walsh wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> There seems to be wise agreement not to duplicate @html:style with a </em><br /> <em class="quotelev1">> new @tei:style.<!--nospam--> For @rend, what you describe above--_at_rend as a </em><br /> <em class="quotelev1">> pointer to <rendition>--is what I was planning to document if there is </em><br /> <em class="quotelev1">> agreement to move @rend more in the direction of @html:class.<!--nospam--> @rend </em><br /> <em class="quotelev1">> would be different from @html:class because of its (potential) linkage </em><br /> <em class="quotelev1">> with <rendition>. I think this proposed change to @rend is a good </em><br /> <em class="quotelev1">> idea (and something I've used for years in my P4 extension files and </em><br /> <em class="quotelev1">> P5 ODD files). It helps prevent sloppy use of @rend (e.<!--nospam-->g., @rend="i", </em><br /> <em class="quotelev1">> @rend="italic", @rend="italics", @rend="italicize", etc.<!--nospam-->--all in the </em><br /> <em class="quotelev1">> same document). It potentially allows easy automatic generation of </em><br /> <em class="quotelev1">> CSS (or XSL-FO) styles from information documented in the <rendition> </em><br /> <em class="quotelev1">> elements of the TEI Header. But changing the datatype of @rend would </em><br /> <em class="quotelev1">> break lots of stuff, e.g., rendition ladders. It's a fairly radical </em><br /> <em class="quotelev1">> change to a widely used global element. </em><br /> Having @rend as a pointer would be nice, but I can see it would be <br /> horrid disruptive. <br /> Lets suppose @rend='foo' gets you to a part of <rendition>.<!--nospam--> are you <br /> proposing a notation <br /> there to distinguish input from output? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 17:45:00 EDT</span> </div> From djbpitt+tei at pitt.edu Wed May 9 18:51:28 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 09 May 2007 18:51:28 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> Message-ID: <46425070.3070004@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 09 May 2007 18:51:28 -0400</span><br /> </address> Dear John (cc Council), <br /> In David's Magical World of Descriptive Markup, markup is never <br /> procedural/presentational and output rendering is governed by mapping <br /> descriptive markup to rendering details in a stylesheet. If I want my <br /> code snippets output in a monospaced font, I tag them as <code> (or <br /> something similar) and in my stylesheet (not my document instance) I map <br /> the content of <code> elements to a CSS instruction to use that font (or <br /> FO or some other stylesheet-level specification). I never specify <br /> "monospaced font" as part of my markup of my born-electric source. <br /> Similarly, I can't imagine specifying in my descriptive markup that an <br /> element should be rendered as "big" in my output document. I might <br /> specify that it was big in my source document (not the same thing, as <br /> we've noted), or I might specify that it is important or that it is a <br /> section heading, but if I want any of these three features to produce <br /> rendering as big (however I interpret that) in the output, it would be <br /> because "big in the source document" or "important" or "section heading" <br /> was mapped to "render this in big type" in the stylesheet. <br /> I have no problem with mapping of @rend="big" to a font specification in <br /> a <rendition> element when this is part of a description of the source <br /> document. My only objection is to specifying output rendering in the <br /> document instance. <br /> For what it's worth ... <br /> Best, <br /> David <br /> John A. Walsh wrote: <br /> <em class="quotelev1">> David, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev1">> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev1">> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since we </em><br /> <em class="quotelev1">> have an @rend attribute, it would seem useful to provide a standard </em><br /> <em class="quotelev1">> mechanism for documenting how that attribute is used and defining the </em><br /> <em class="quotelev1">> meaning of its content. @rend="big" could mean lots of things, but if </em><br /> <em class="quotelev1">> it points to <rendition xml:id="big">font-family: Granjon; font-size: </em><br /> <em class="quotelev1">> 16pt; font-weight: bold</rendition>, then one has a clear idea of what </em><br /> <em class="quotelev1">> @rend="big" means, and this rendition definition may well refer to the </em><br /> <em class="quotelev1">> source text, not any output format. A stylesheet can still take the </em><br /> <em class="quotelev1">> "big" trigger and do something else with it. The Guidelines do </em><br /> <em class="quotelev1">> already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev1">> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> | John A. Walsh </em><br /> <em class="quotelev1">> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Dear John, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Option C, please. XML isn't Microsoft Word and TEI markup should be </em><br /> <em class="quotelev2">>> descriptive, rather than presentational. The ability to specify </em><br /> <em class="quotelev2">>> output rendering is often very important to projects, but the place </em><br /> <em class="quotelev2">>> to declare it is the stylesheet, not the document instance. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Best, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> David </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John A. Walsh wrote: </em><br /> <em class="quotelev3">>>> Hi all, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev3">>>> <rendition> and @rend, including the possible addition of an @style </em><br /> <em class="quotelev3">>>> attribute. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev3">>>> element in question was rendered or presented in the source text." </em><br /> <em class="quotelev3">>>> But my sense is that in practice @rend is used both to indicate how </em><br /> <em class="quotelev3">>>> an element was rendered in the source text and/or how it should be </em><br /> <em class="quotelev3">>>> rendered in a display environment such as a Web browser or printed </em><br /> <em class="quotelev3">>>> output. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev3">>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev3">>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev3">>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev3">>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev3">>>> defined in the <rendition> element of the TEI Header. @style could </em><br /> <em class="quotelev3">>>> be used to embed style information directly in an element. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> If we simply want to distinguish between source rendering and output </em><br /> <em class="quotelev3">>>> rendering with the addition of an @style attribute, then my task is </em><br /> <em class="quotelev3">>>> easy. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev3">>>> functionality of HTML, the task is more difficult and would involve </em><br /> <em class="quotelev3">>>> prescribing or recommending practice that is not common at the </em><br /> <em class="quotelev3">>>> moment, and would also likely involve changes to the <rendition> </em><br /> <em class="quotelev3">>>> element and perhaps a new element in <encodingDesc> where folks </em><br /> <em class="quotelev3">>>> could explain their implementation. For instance, users may define </em><br /> <em class="quotelev3">>>> their styles using CSS, XSL-FO, rendition ladders, or some other </em><br /> <em class="quotelev3">>>> mechanism, and this will need to be explained in <encodingDesc>. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I believe we touched on all these various distinctions in Berlin, so </em><br /> <em class="quotelev3">>>> I would like members of the council to weigh in on which way to go </em><br /> <em class="quotelev3">>>> with this. Please select A. or B. (or a new letter and proposal of </em><br /> <em class="quotelev3">>>> your own invention): </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev3">>>> output rendering. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev3">>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev3">>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev3">>>> attribute to <rendition> that indicates whether the "target" of this </em><br /> <em class="quotelev3">>>> rendition "class" is the source text or the output format. The </em><br /> <em class="quotelev3">>>> @style attribute would remain ambiguous in terms of source/output, </em><br /> <em class="quotelev3">>>> but this ambiguity could be addressed and clarified in the </em><br /> <em class="quotelev3">>>> <encodingDesc>. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev3">>>> more formal document on this topic. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> John </em><br /> <em class="quotelev3">>>> --| John A. Walsh </em><br /> <em class="quotelev3">>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev3">>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev3">>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev3">>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> _______________________________________________ </em><br /> <em class="quotelev3">>>> tei-council mailing list </em><br /> <em class="quotelev3">>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 09 2007 - 18:51:32 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 04:36:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 09:36:32 +0100 Subject: [tei-council] cleanup release of P5 Message-ID: <4642D990.6040700@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 09:36:32 +0100</span><br /> </address> I propose to make a 0.7 release of P5 in a few days, <br /> to get a level playing field with a new release of <br /> Roma and stylesheets for ODD processing. <br /> Any objections? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 04:36:36 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 04:37:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 09:37:58 +0100 Subject: [tei-council] release Message-ID: <4642D9E6.9000806@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 09:37:58 +0100</span><br /> </address> in fact, I would propose to say now that we <br /> make a 0.8 release on 1st July and a 0.9 <br /> release on 1st September, to firm up <br /> the schedule even more. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 04:38:01 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu May 10 09:41:20 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 10 May 2007 14:41:20 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46425070.3070004@pitt.edu> Message-ID: <46432100.2060404@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou's Laptop <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 14:41:20 +0100</span><br /> </address> This is both defensible and coherent as TEI policy. What changes are <br /> needed (if any) in P5 to reinforce that position? <br /> <p>David J Birnbaum wrote: <br /> <em class="quotelev1">> Dear John (cc Council), </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev1">> procedural/presentational and output rendering is governed by mapping </em><br /> <em class="quotelev1">> descriptive markup to rendering details in a stylesheet. If I want my </em><br /> <em class="quotelev1">> code snippets output in a monospaced font, I tag them as <code> (or </em><br /> <em class="quotelev1">> something similar) and in my stylesheet (not my document instance) I </em><br /> <em class="quotelev1">> map the content of <code> elements to a CSS instruction to use that </em><br /> <em class="quotelev1">> font (or FO or some other stylesheet-level specification). I never </em><br /> <em class="quotelev1">> specify "monospaced font" as part of my markup of my born-electric </em><br /> <em class="quotelev1">> source. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Similarly, I can't imagine specifying in my descriptive markup that an </em><br /> <em class="quotelev1">> element should be rendered as "big" in my output document. I might </em><br /> <em class="quotelev1">> specify that it was big in my source document (not the same thing, as </em><br /> <em class="quotelev1">> we've noted), or I might specify that it is important or that it is a </em><br /> <em class="quotelev1">> section heading, but if I want any of these three features to produce </em><br /> <em class="quotelev1">> rendering as big (however I interpret that) in the output, it would be </em><br /> <em class="quotelev1">> because "big in the source document" or "important" or "section </em><br /> <em class="quotelev1">> heading" was mapped to "render this in big type" in the stylesheet. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I have no problem with mapping of @rend="big" to a font specification </em><br /> <em class="quotelev1">> in a <rendition> element when this is part of a description of the </em><br /> <em class="quotelev1">> source document. My only objection is to specifying output rendering </em><br /> <em class="quotelev1">> in the document instance. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> For what it's worth ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> David </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John A. Walsh wrote: </em><br /> <em class="quotelev2">>> David, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev2">>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev2">>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since we </em><br /> <em class="quotelev2">>> have an @rend attribute, it would seem useful to provide a standard </em><br /> <em class="quotelev2">>> mechanism for documenting how that attribute is used and defining the </em><br /> <em class="quotelev2">>> meaning of its content. @rend="big" could mean lots of things, but if </em><br /> <em class="quotelev2">>> it points to <rendition xml:id="big">font-family: Granjon; font-size: </em><br /> <em class="quotelev2">>> 16pt; font-weight: bold</rendition>, then one has a clear idea of </em><br /> <em class="quotelev2">>> what @rend="big" means, and this rendition definition may well refer </em><br /> <em class="quotelev2">>> to the source text, not any output format. A stylesheet can still </em><br /> <em class="quotelev2">>> take the "big" trigger and do something else with it. The Guidelines </em><br /> <em class="quotelev2">>> do already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev2">>> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John </em><br /> <em class="quotelev2">>> -- </em><br /> <em class="quotelev2">>> | John A. Walsh </em><br /> <em class="quotelev2">>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev2">>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev2">>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev2">>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> Dear John, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Option C, please. XML isn't Microsoft Word and TEI markup should be </em><br /> <em class="quotelev3">>>> descriptive, rather than presentational. The ability to specify </em><br /> <em class="quotelev3">>>> output rendering is often very important to projects, but the place </em><br /> <em class="quotelev3">>>> to declare it is the stylesheet, not the document instance. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Best, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> David </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> John A. Walsh wrote: </em><br /> <em class="quotelev4">>>>> Hi all, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev4">>>>> <rendition> and @rend, including the possible addition of an @style </em><br /> <em class="quotelev4">>>>> attribute. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev4">>>>> element in question was rendered or presented in the source text." </em><br /> <em class="quotelev4">>>>> But my sense is that in practice @rend is used both to indicate how </em><br /> <em class="quotelev4">>>>> an element was rendered in the source text and/or how it should be </em><br /> <em class="quotelev4">>>>> rendered in a display environment such as a Web browser or printed </em><br /> <em class="quotelev4">>>>> output. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev4">>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev4">>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev4">>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev4">>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev4">>>>> defined in the <rendition> element of the TEI Header. @style could </em><br /> <em class="quotelev4">>>>> be used to embed style information directly in an element. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev4">>>>> output rendering with the addition of an @style attribute, then my </em><br /> <em class="quotelev4">>>>> task is easy. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev4">>>>> functionality of HTML, the task is more difficult and would involve </em><br /> <em class="quotelev4">>>>> prescribing or recommending practice that is not common at the </em><br /> <em class="quotelev4">>>>> moment, and would also likely involve changes to the <rendition> </em><br /> <em class="quotelev4">>>>> element and perhaps a new element in <encodingDesc> where folks </em><br /> <em class="quotelev4">>>>> could explain their implementation. For instance, users may define </em><br /> <em class="quotelev4">>>>> their styles using CSS, XSL-FO, rendition ladders, or some other </em><br /> <em class="quotelev4">>>>> mechanism, and this will need to be explained in <encodingDesc>. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I believe we touched on all these various distinctions in Berlin, </em><br /> <em class="quotelev4">>>>> so I would like members of the council to weigh in on which way to </em><br /> <em class="quotelev4">>>>> go with this. Please select A. or B. (or a new letter and proposal </em><br /> <em class="quotelev4">>>>> of your own invention): </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev4">>>>> output rendering. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev4">>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev4">>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev4">>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev4">>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev4">>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev4">>>>> source/output, but this ambiguity could be addressed and clarified </em><br /> <em class="quotelev4">>>>> in the <encodingDesc>. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev4">>>>> more formal document on this topic. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> John </em><br /> <em class="quotelev4">>>>> --| John A. Walsh </em><br /> <em class="quotelev4">>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev4">>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev4">>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev4">>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> _______________________________________________ </em><br /> <em class="quotelev4">>>>> tei-council mailing list </em><br /> <em class="quotelev4">>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev4">>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 09:41:52 EDT</span> </div> From djbpitt+tei at pitt.edu Thu May 10 10:12:50 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 10:12:50 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432100.2060404@computing-services.oxford.ac.uk> Message-ID: <46432862.9010907@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 10:12:50 -0400</span><br /> </address> Dear Lou (cc John, Council), <br /> We might want to review the description of @rend in the guidelines to <br /> ensure that the TEI recommends that it be used to indicate rendering in <br /> the source document, but not to specify output rendering. Since new <br /> users will then ask "so how do I specify output rendering?", we might <br /> also add a note that output rendering is governed by associations in <br /> stylesheets between the descriptive TEI markup and the desired output <br /> final form, and that output rendering is not specified in the document <br /> instance. If we are feeling ambitious, we can point them to a discussion <br /> in the Gentle Introduction of the difference between descriptive and <br /> procedural/presentational markup as away of explaining why specifying <br /> output rendering in the document instance is a Bad Idea (that is, why <br /> the TEI isn't supposed to be a typesetting spec). <br /> If we need an example, John and I discussed a specific issue from his <br /> projects in private email yesterday, and he's welcome to introduce that <br /> into the discussion if he thinks it would be constructive. <br /> In other words, I think the current TEI syntax is probably fine, and we <br /> just need to make sure that we provide clear advice about the semantics. <br /> We may already do that. <br /> Best, <br /> David <br /> Lou's Laptop wrote: <br /> <em class="quotelev1">> This is both defensible and coherent as TEI policy. What changes are </em><br /> <em class="quotelev1">> needed (if any) in P5 to reinforce that position? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> David J Birnbaum wrote: </em><br /> <em class="quotelev2">>> Dear John (cc Council), </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev2">>> procedural/presentational and output rendering is governed by mapping </em><br /> <em class="quotelev2">>> descriptive markup to rendering details in a stylesheet. If I want my </em><br /> <em class="quotelev2">>> code snippets output in a monospaced font, I tag them as <code> (or </em><br /> <em class="quotelev2">>> something similar) and in my stylesheet (not my document instance) I </em><br /> <em class="quotelev2">>> map the content of <code> elements to a CSS instruction to use that </em><br /> <em class="quotelev2">>> font (or FO or some other stylesheet-level specification). I never </em><br /> <em class="quotelev2">>> specify "monospaced font" as part of my markup of my born-electric </em><br /> <em class="quotelev2">>> source. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Similarly, I can't imagine specifying in my descriptive markup that </em><br /> <em class="quotelev2">>> an element should be rendered as "big" in my output document. I might </em><br /> <em class="quotelev2">>> specify that it was big in my source document (not the same thing, as </em><br /> <em class="quotelev2">>> we've noted), or I might specify that it is important or that it is a </em><br /> <em class="quotelev2">>> section heading, but if I want any of these three features to produce </em><br /> <em class="quotelev2">>> rendering as big (however I interpret that) in the output, it would </em><br /> <em class="quotelev2">>> be because "big in the source document" or "important" or "section </em><br /> <em class="quotelev2">>> heading" was mapped to "render this in big type" in the stylesheet. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> I have no problem with mapping of @rend="big" to a font specification </em><br /> <em class="quotelev2">>> in a <rendition> element when this is part of a description of the </em><br /> <em class="quotelev2">>> source document. My only objection is to specifying output rendering </em><br /> <em class="quotelev2">>> in the document instance. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> For what it's worth ... </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Best, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> David </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John A. Walsh wrote: </em><br /> <em class="quotelev3">>>> David, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev3">>>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev3">>>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since we </em><br /> <em class="quotelev3">>>> have an @rend attribute, it would seem useful to provide a standard </em><br /> <em class="quotelev3">>>> mechanism for documenting how that attribute is used and defining </em><br /> <em class="quotelev3">>>> the meaning of its content. @rend="big" could mean lots of things, </em><br /> <em class="quotelev3">>>> but if it points to <rendition xml:id="big">font-family: Granjon; </em><br /> <em class="quotelev3">>>> font-size: 16pt; font-weight: bold</rendition>, then one has a clear </em><br /> <em class="quotelev3">>>> idea of what @rend="big" means, and this rendition definition may </em><br /> <em class="quotelev3">>>> well refer to the source text, not any output format. A stylesheet </em><br /> <em class="quotelev3">>>> can still take the "big" trigger and do something else with it. The </em><br /> <em class="quotelev3">>>> Guidelines do already state that the content of rendition may be </em><br /> <em class="quotelev3">>>> "expressed in running prose, or in some more formal language such as </em><br /> <em class="quotelev3">>>> CSS." </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> John </em><br /> <em class="quotelev3">>>> -- </em><br /> <em class="quotelev3">>>> | John A. Walsh </em><br /> <em class="quotelev3">>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev3">>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev3">>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev3">>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> Dear John, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Option C, please. XML isn't Microsoft Word and TEI markup should be </em><br /> <em class="quotelev4">>>>> descriptive, rather than presentational. The ability to specify </em><br /> <em class="quotelev4">>>>> output rendering is often very important to projects, but the place </em><br /> <em class="quotelev4">>>>> to declare it is the stylesheet, not the document instance. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Best, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> David </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> John A. Walsh wrote: </em><br /> <em class="quotelev1">>>>>> Hi all, </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev1">>>>>> <rendition> and @rend, including the possible addition of an </em><br /> <em class="quotelev1">>>>>> @style attribute.<!--nospam--> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev1">>>>>> element in question was rendered or presented in the source </em><br /> <em class="quotelev1">>>>>> text." But my sense is that in practice @rend is used both to </em><br /> <em class="quotelev1">>>>>> indicate how an element was rendered in the source text and/or how </em><br /> <em class="quotelev1">>>>>> it should be rendered in a display environment such as a Web </em><br /> <em class="quotelev1">>>>>> browser or printed output. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev1">>>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev1">>>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev1">>>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev1">>>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev1">>>>>> defined in the <rendition> element of the TEI Header. @style </em><br /> <em class="quotelev1">>>>>> could be used to embed style information directly in an element. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev1">>>>>> output rendering with the addition of an @style attribute, then my </em><br /> <em class="quotelev1">>>>>> task is easy. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev1">>>>>> functionality of HTML, the task is more difficult and would </em><br /> <em class="quotelev1">>>>>> involve prescribing or recommending practice that is not common at </em><br /> <em class="quotelev1">>>>>> the moment, and would also likely involve changes to the </em><br /> <em class="quotelev1">>>>>> <rendition> element and perhaps a new element in <encodingDesc> </em><br /> <em class="quotelev1">>>>>> where folks could explain their implementation. For instance, </em><br /> <em class="quotelev1">>>>>> users may define their styles using CSS, XSL-FO, rendition </em><br /> <em class="quotelev1">>>>>> ladders, or some other mechanism, and this will need to be </em><br /> <em class="quotelev1">>>>>> explained in <encodingDesc>. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> I believe we touched on all these various distinctions in Berlin, </em><br /> <em class="quotelev1">>>>>> so I would like members of the council to weigh in on which way to </em><br /> <em class="quotelev1">>>>>> go with this. Please select A. or B. (or a new letter and </em><br /> <em class="quotelev1">>>>>> proposal of your own invention): </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev1">>>>>> output rendering. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev1">>>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev1">>>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev1">>>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev1">>>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev1">>>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev1">>>>>> source/output, but this ambiguity could be addressed and clarified </em><br /> <em class="quotelev1">>>>>> in the <encodingDesc>. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev1">>>>>> more formal document on this topic. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> John </em><br /> <em class="quotelev1">>>>>> --| John A. Walsh </em><br /> <em class="quotelev1">>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> _______________________________________________ </em><br /> <em class="quotelev1">>>>>> tei-council mailing list </em><br /> <em class="quotelev1">>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> _______________________________________________ </em><br /> <em class="quotelev3">>>> tei-council mailing list </em><br /> <em class="quotelev3">>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 10:12:55 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:22:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:22:31 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432862.9010907@pitt.edu> Message-ID: <46432AA7.5000002@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 15:22:31 +0100</span><br /> </address> If @rend says it is for source description only, <br /> then my born-digital document <br /> can't use it. So how _do_ I indicate superscript? <br /> Currently I say '2<hi rend="sup">nd</hi>', and all is ok. <br /> In future, putting @rend in there is deprecated, but I <br /> need _some_ clue. <br /> Answers of <br /> - use an xml:id and trap it in CSS <br /> - define <oxford:sup> <br /> are unacceptable. So now I should <br /> say: <br /> <br /> <hi html:class="sup">nd</hi> <br /> ? but of course that has an impact <br /> on the complexity of my ODD, if I have to <br /> add html:class to att.global. Plus, I am <br /> not conformant? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 10:22:36 EDT</span> </div> From lou.burnard at computing-services.oxford.ac.uk Thu May 10 10:36:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 10 May 2007 15:36:56 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432AA7.5000002@oucs.ox.ac.uk> Message-ID: <46432E08.5040408@computing-services.oxford.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Lou's Laptop <lou.burnard_at_computing-services.oxford.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 15:36:56 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> If @rend says it is for source description only, </em><br /> <em class="quotelev1">> then my born-digital document </em><br /> <em class="quotelev1">> can't use it. </em><br /> Hmm, I may be logic chopping here, but I don't think I agree. If your <br /> doc is born digital, then you *are* describing the source when you say <br /> @rend=sup, surely? <br /> Maybe this is one of the points that needs more careful elaboration. Can <br /> we imagine a case where @rend in a born-digital document does not <br /> describe how it should be rendered? @rend="done in emacs without benefit <br /> of markup" doesnt seem very likely. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 10:37:25 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:40:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:40:15 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <46432ECF.50308@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 15:40:15 +0100</span><br /> </address> Lou's Laptop wrote: <br /> <em class="quotelev1">> Hmm, I may be logic chopping here, but I don't think I agree. If your </em><br /> <em class="quotelev1">> doc is born digital, then you *are* describing the source when you say </em><br /> <em class="quotelev1">> @rend=sup, surely? </em><br /> hmm. suppose so. maybe. <br /> the change then is the recommendation to use the value of @rend <br /> to look at a section of <rendition>, no more no less. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 10:40:19 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:52:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:52:51 +0100 Subject: [tei-council] the "key" attribute Message-ID: <464331C3.8040102@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 15:52:51 +0100</span><br /> </address> Useful little beast, but I don't think we are 100% clear on its use <br /> yet. <br /> Here is @key's ODD: <br /> <attDef ident="key" usage="opt"> <br /> <desc>provides a means of locating a full definition for the <br /> entity being named such as a database record key or a <br /> URI.</desc> <br /> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" <br /> name="data.key"/></datatype> <br /> </attDef> <br /> o if I say key="foo", is that a URI or a database record key? <br /> I simply can't tell from the context. <br /> look at some of our test files: <br /> <name type="person" key="ThorJon08">Þorgeir Jónsson</name> <br /> <country key="#FR"/> <br /> <placeName key="http://www.activitaly.it/monument/portspaolo.htm">Porta <br /> <persName key="#CESTIUS">Cestius</persName> <br /> <placeName key="http://en.wikipedia.org/wiki/Aurelian_walls"> Aurelian <br /> <placeName key="#DK">Denmark</placeName></p></placeState> <br /> <country key="#place2"></country> <br /> <settlement key="place3"></settlement> <br /> <addrLine><name key="ota" type="organisation">Oxford Text <br /> Archive</name></addrLine> <br /> we're not even internally consistent! <br /> So, to # or not to #? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 10:52:55 EDT</span> </div> From arianna.ciula at kcl.ac.uk Thu May 10 13:01:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 10 May 2007 18:01:43 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <46434FF7.4020107@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 18:01:43 +0100</span><br /> </address> I totally agree with what David says about the meaning of @rend for not <br /> born digital material. <br /> As far as born digital material regard though, I can imagine the <br /> situation where someone wants to differentiate the semantics (not big or <br /> small, but myIntrepret_category1 and myIntrepret_category2) of the <br /> information so that some style could be applied - possibly - later on. <br /> We should remember that in some cases the people who do the markup are <br /> not bothered (should they be?) about what style is going to be applied <br /> to their documents, but they do want to differentiate between different <br /> things that may need a different visualisation. So while I can see the <br /> advantages of a good practice in pointing @rend to <rendition> in the <br /> header for born digital material, I am still not sure this is the only <br /> use we should support for @rend in this case.<!--nospam--> <br /> Arianna <br /> Lou's Laptop wrote: <br /> <em class="quotelev1">> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">>> If @rend says it is for source description only, </em><br /> <em class="quotelev2">>> then my born-digital document </em><br /> <em class="quotelev2">>> can't use it. </em><br /> <em class="quotelev1">> Hmm, I may be logic chopping here, but I don't think I agree. If your </em><br /> <em class="quotelev1">> doc is born digital, then you *are* describing the source when you say </em><br /> <em class="quotelev1">> @rend=sup, surely? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Maybe this is one of the points that needs more careful elaboration. Can </em><br /> <em class="quotelev1">> we imagine a case where @rend in a born-digital document does not </em><br /> <em class="quotelev1">> describe how it should be rendered? @rend="done in emacs without benefit </em><br /> <em class="quotelev1">> of markup" doesnt seem very likely. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:03:09 EDT</span> </div> From daniel.odonnell at uleth.ca Thu May 10 13:22:32 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:22:32 -0600 Subject: [tei-council] the "key" attribute In-Reply-To: <464331C3.8040102@oucs.ox.ac.uk> Message-ID: <1178817752.19411.4.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 11:22:32 -0600</span><br /> </address> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So, to # or not to #? </em><br /> # always means equivalent to xml:id? <br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:22:37 EDT</span> </div> From daniel.odonnell at uleth.ca Thu May 10 13:23:04 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:23:04 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432ECF.50308@oucs.ox.ac.uk> Message-ID: <1178817784.19411.6.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 11:23:04 -0600</span><br /> </address> On Thu, 2007-05-10 at 15:40 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Lou's Laptop wrote: </em><br /> <em class="quotelev2">> > Hmm, I may be logic chopping here, but I don't think I agree. If your </em><br /> <em class="quotelev2">> > doc is born digital, then you *are* describing the source when you say </em><br /> <em class="quotelev2">> > @rend=sup, surely? </em><br /> <em class="quotelev1">> hmm. suppose so. maybe. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> the change then is the recommendation to use the value of @rend </em><br /> <em class="quotelev1">> to look at a section of <rendition>, no more no less. </em><br /> Offloading seems yet again a good solution. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:23:10 EDT</span> </div> From daniel.odonnell at uleth.ca Thu May 10 13:31:25 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:31:25 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <1178818285.19989.5.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 11:31:25 -0600</span><br /> </address> On Thu, 2007-05-10 at 15:36 +0100, Lou's Laptop wrote: <br /> <em class="quotelev1">> Sebastian Rahtz wrote: </em><br /> <em class="quotelev2">> > If @rend says it is for source description only, </em><br /> <em class="quotelev2">> > then my born-digital document </em><br /> <em class="quotelev2">> > can't use it. </em><br /> <em class="quotelev1">> Hmm, I may be logic chopping here, but I don't think I agree. If your </em><br /> <em class="quotelev1">> doc is born digital, then you *are* describing the source when you say </em><br /> <em class="quotelev1">> @rend=sup, surely? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Maybe this is one of the points that needs more careful elaboration. Can </em><br /> <em class="quotelev1">> we imagine a case where @rend in a born-digital document does not </em><br /> <em class="quotelev1">> describe how it should be rendered? </em><br /> Well following David's observation, I'd have thought the answer to this <br /> question is always: i.e. even @rend="font-decoration:underline;" is a <br /> description of rendition in the digitally born document, not "how it <br /> should be rendered." <br /> Speaking of digitally born documents and rendition: what do we do a) <br /> about including stylesheet information as rendition information in the <br /> tei-xml document, and b) about declaring the language used in rendition <br /> if the our Born Digital Document is styled using a recognisable <br /> language. <br /> In the case of a) I am not wondering about how to attach a CSS sheet or <br /> the like for output processing, but how to include it as a rendition <br /> description on input: if I have a CSS stylesheet that formats the front <br /> page of the NYTimes, for example, the style information seems to me to <br /> be as much a valid rendition description as "written in a big looping <br /> hand" is for a manuscript. <br /> <em class="quotelev1">> @rend="done in emacs without benefit </em><br /> <em class="quotelev1">> of markup" doesnt seem very likely. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:31:29 EDT</span> </div> From daniel.odonnell at uleth.ca Thu May 10 13:37:12 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:37:12 -0600 Subject: [tei-council] release In-Reply-To: <4642D9E6.9000806@oucs.ox.ac.uk> Message-ID: <1178818632.19989.11.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 11:37:12 -0600</span><br /> </address> Sounds fine to me. <br /> On Thu, 2007-05-10 at 09:37 +0100, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> in fact, I would propose to say now that we </em><br /> <em class="quotelev1">> make a 0.8 release on 1st July and a 0.9 </em><br /> <em class="quotelev1">> release on 1st September, to firm up </em><br /> <em class="quotelev1">> the schedule even more. </em><br /> <em class="quotelev1">> </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:37:14 EDT</span> </div> From djbpitt+tei at pitt.edu Thu May 10 13:39:54 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 13:39:54 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> Message-ID: <464358EA.2000100@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 13:39:54 -0400</span><br /> </address> Dear Arianna (cc Lou, Council), <br /> I agree completely that we may need to tag information according to <br /> interpretive categories, but since @rend is supposed to be about <br /> rendering and interpretive categories are not essentially about <br /> rendering (although we may, of course, ultimately render different <br /> interpretive categories differently in certain views of our data), I <br /> don't think @rend is the right attribute semantically.<!--nospam--> To press <br /> something intended to indicate rendering into service as an indicator of <br /> interpretive categories that are not essentially about rendering <br /> suggests tag abuse. If we don't already have a way to flag interpretive <br /> categories, I'd certainly support implementing one. It's a very <br /> important need; my only objection is that @rend is the wrong way to <br /> address it. <br /> Cheers, <br /> David <br /> Arianna Ciula wrote: <br /> <em class="quotelev1">> I totally agree with what David says about the meaning of @rend for </em><br /> <em class="quotelev1">> not born digital material. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As far as born digital material regard though, I can imagine the </em><br /> <em class="quotelev1">> situation where someone wants to differentiate the semantics (not big </em><br /> <em class="quotelev1">> or small, but myIntrepret_category1 and myIntrepret_category2) of the </em><br /> <em class="quotelev1">> information so that some style could be applied - possibly - later on. </em><br /> <em class="quotelev1">> We should remember that in some cases the people who do the markup are </em><br /> <em class="quotelev1">> not bothered (should they be?) about what style is going to be applied </em><br /> <em class="quotelev1">> to their documents, but they do want to differentiate between </em><br /> <em class="quotelev1">> different things that may need a different visualisation. So while I </em><br /> <em class="quotelev1">> can see the advantages of a good practice in pointing @rend to </em><br /> <em class="quotelev1">> <rendition> in the header for born digital material, I am still not </em><br /> <em class="quotelev1">> sure this is the only use we should support for @rend in this case.<!--nospam--> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Arianna </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Lou's Laptop wrote: </em><br /> <em class="quotelev2">>> Sebastian Rahtz wrote: </em><br /> <em class="quotelev3">>>> If @rend says it is for source description only, </em><br /> <em class="quotelev3">>>> then my born-digital document </em><br /> <em class="quotelev3">>>> can't use it. </em><br /> <em class="quotelev2">>> Hmm, I may be logic chopping here, but I don't think I agree. If your </em><br /> <em class="quotelev2">>> doc is born digital, then you *are* describing the source when you </em><br /> <em class="quotelev2">>> say @rend=sup, surely? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Maybe this is one of the points that needs more careful elaboration. </em><br /> <em class="quotelev2">>> Can we imagine a case where @rend in a born-digital document does not </em><br /> <em class="quotelev2">>> describe how it should be rendered? @rend="done in emacs without </em><br /> <em class="quotelev2">>> benefit of markup" doesnt seem very likely. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> _______________________________________________ </em><br /> <em class="quotelev2">>> tei-council mailing list </em><br /> <em class="quotelev2">>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:39:59 EDT</span> </div> From jawalsh at indiana.edu Thu May 10 13:52:55 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 13:52:55 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> Message-ID: <20070510135255.64gyni6d8gso4kkc@webmail.iu.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 13:52:55 -0400</span><br /> </address> <em class="quotelev1">> So </em><br /> <em class="quotelev1">> while I can see the advantages of a good practice in pointing @rend </em><br /> <em class="quotelev1">> to <rendition> in the header for born digital material, I am still </em><br /> <em class="quotelev1">> not sure this is the only use we should support for @rend in this </em><br /> <em class="quotelev1">> case. </em><br /> The practice of pointing @rend to <rendition> is not just for born <br /> digital material. I think CSS (or XSL-FO) properties such as <br /> font-family, font-size, font-weight, text-indent, etc. can be used to <br /> describe accurately and precisely the appearance of a source document, <br /> at least for printed source documents, though many properties can also <br /> be useful in the description of manuscript documents. <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 13:52:58 EDT</span> </div> From jawalsh at indiana.edu Thu May 10 14:00:13 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 14:00:13 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432862.9010907@pitt.edu> Message-ID: <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 14:00:13 -0400</span><br /> </address> I've been persuaded by David's position and his clear and strong <br /> distinction between descriptive and procedural/presentation. I'm also <br /> persuaded that @rend should only refer to description of the source <br /> material (which may be the TEI document itself in the case of born <br /> digital material). I still believe though in the benefits of changing <br /> @rend to be a pointer to one or more <rendition> elements which provide <br /> a fuller and more formal description of what exactly is being described <br /> in the source document. <br /> John <br /> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: <br /> <em class="quotelev1">> Dear Lou (cc John, Council), </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> We might want to review the description of @rend in the guidelines to </em><br /> <em class="quotelev1">> ensure that the TEI recommends that it be used to indicate rendering </em><br /> <em class="quotelev1">> in the source document, but not to specify output rendering. Since </em><br /> <em class="quotelev1">> new users will then ask "so how do I specify output rendering?", we </em><br /> <em class="quotelev1">> might also add a note that output rendering is governed by </em><br /> <em class="quotelev1">> associations in stylesheets between the descriptive TEI markup and </em><br /> <em class="quotelev1">> the desired output final form, and that output rendering is not </em><br /> <em class="quotelev1">> specified in the document instance. If we are feeling ambitious, we </em><br /> <em class="quotelev1">> can point them to a discussion in the Gentle Introduction of the </em><br /> <em class="quotelev1">> difference between descriptive and procedural/presentational markup </em><br /> <em class="quotelev1">> as away of explaining why specifying output rendering in the document </em><br /> <em class="quotelev1">> instance is a Bad Idea (that is, why the TEI isn't supposed to be a </em><br /> <em class="quotelev1">> typesetting spec). </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> If we need an example, John and I discussed a specific issue from his </em><br /> <em class="quotelev1">> projects in private email yesterday, and he's welcome to introduce </em><br /> <em class="quotelev1">> that into the discussion if he thinks it would be constructive. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In other words, I think the current TEI syntax is probably fine, and </em><br /> <em class="quotelev1">> we just need to make sure that we provide clear advice about the </em><br /> <em class="quotelev1">> semantics. We may already do that. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> David </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Lou's Laptop wrote: </em><br /> <em class="quotelev2">>> This is both defensible and coherent as TEI policy. What changes are </em><br /> <em class="quotelev2">>> needed (if any) in P5 to reinforce that position? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> David J Birnbaum wrote: </em><br /> <em class="quotelev3">>>> Dear John (cc Council), </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev3">>>> procedural/presentational and output rendering is governed by </em><br /> <em class="quotelev3">>>> mapping descriptive markup to rendering details in a stylesheet. If </em><br /> <em class="quotelev3">>>> I want my code snippets output in a monospaced font, I tag them as </em><br /> <em class="quotelev3">>>> <code> (or something similar) and in my stylesheet (not my document </em><br /> <em class="quotelev3">>>> instance) I map the content of <code> elements to a CSS instruction </em><br /> <em class="quotelev3">>>> to use that font (or FO or some other stylesheet-level </em><br /> <em class="quotelev3">>>> specification). I never specify "monospaced font" as part of my </em><br /> <em class="quotelev3">>>> markup of my born-electric source. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Similarly, I can't imagine specifying in my descriptive markup that </em><br /> <em class="quotelev3">>>> an element should be rendered as "big" in my output document. I </em><br /> <em class="quotelev3">>>> might specify that it was big in my source document (not the same </em><br /> <em class="quotelev3">>>> thing, as we've noted), or I might specify that it is important or </em><br /> <em class="quotelev3">>>> that it is a section heading, but if I want any of these three </em><br /> <em class="quotelev3">>>> features to produce rendering as big (however I interpret that) in </em><br /> <em class="quotelev3">>>> the output, it would be because "big in the source document" or </em><br /> <em class="quotelev3">>>> "important" or "section heading" was mapped to "render this in big </em><br /> <em class="quotelev3">>>> type" in the stylesheet. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> I have no problem with mapping of @rend="big" to a font </em><br /> <em class="quotelev3">>>> specification in a <rendition> element when this is part of a </em><br /> <em class="quotelev3">>>> description of the source document. My only objection is to </em><br /> <em class="quotelev3">>>> specifying output rendering in the document instance. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> For what it's worth ... </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Best, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> David </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> John A. Walsh wrote: </em><br /> <em class="quotelev4">>>>> David, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev4">>>>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev4">>>>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since </em><br /> <em class="quotelev4">>>>> we have an @rend attribute, it would seem useful to provide a </em><br /> <em class="quotelev4">>>>> standard mechanism for documenting how that attribute is used and </em><br /> <em class="quotelev4">>>>> defining the meaning of its content. @rend="big" could mean lots </em><br /> <em class="quotelev4">>>>> of things, but if it points to <rendition </em><br /> <em class="quotelev4">>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: </em><br /> <em class="quotelev4">>>>> bold</rendition>, then one has a clear idea of what @rend="big" </em><br /> <em class="quotelev4">>>>> means, and this rendition definition may well refer to the source </em><br /> <em class="quotelev4">>>>> text, not any output format. A stylesheet can still take the </em><br /> <em class="quotelev4">>>>> "big" trigger and do something else with it. The Guidelines do </em><br /> <em class="quotelev4">>>>> already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev4">>>>> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> John </em><br /> <em class="quotelev4">>>>> -- </em><br /> <em class="quotelev4">>>>> | John A. Walsh </em><br /> <em class="quotelev4">>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev4">>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev4">>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev4">>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev1">>>>>> Dear John, </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should </em><br /> <em class="quotelev1">>>>>> be descriptive, rather than presentational. The ability to </em><br /> <em class="quotelev1">>>>>> specify output rendering is often very important to projects, but </em><br /> <em class="quotelev1">>>>>> the place to declare it is the stylesheet, not the document </em><br /> <em class="quotelev1">>>>>> instance. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Best, </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> David </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev2">>>>>>> Hi all, </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev2">>>>>>> <rendition> and @rend, including the possible addition of an </em><br /> <em class="quotelev2">>>>>>> @style attribute.<!--nospam--> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev2">>>>>>> element in question was rendered or presented in the source </em><br /> <em class="quotelev2">>>>>>> text." But my sense is that in practice @rend is used both to </em><br /> <em class="quotelev2">>>>>>> indicate how an element was rendered in the source text and/or </em><br /> <em class="quotelev2">>>>>>> how it should be rendered in a display environment such as a Web </em><br /> <em class="quotelev2">>>>>>> browser or printed output. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev2">>>>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev2">>>>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev2">>>>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev2">>>>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev2">>>>>>> defined in the <rendition> element of the TEI Header. @style </em><br /> <em class="quotelev2">>>>>>> could be used to embed style information directly in an element. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev2">>>>>>> output rendering with the addition of an @style attribute, then </em><br /> <em class="quotelev2">>>>>>> my task is easy. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev2">>>>>>> functionality of HTML, the task is more difficult and would </em><br /> <em class="quotelev2">>>>>>> involve prescribing or recommending practice that is not common </em><br /> <em class="quotelev2">>>>>>> at the moment, and would also likely involve changes to the </em><br /> <em class="quotelev2">>>>>>> <rendition> element and perhaps a new element in <encodingDesc> </em><br /> <em class="quotelev2">>>>>>> where folks could explain their implementation. For instance, </em><br /> <em class="quotelev2">>>>>>> users may define their styles using CSS, XSL-FO, rendition </em><br /> <em class="quotelev2">>>>>>> ladders, or some other mechanism, and this will need to be </em><br /> <em class="quotelev2">>>>>>> explained in <encodingDesc>. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> I believe we touched on all these various distinctions in </em><br /> <em class="quotelev2">>>>>>> Berlin, so I would like members of the council to weigh in on </em><br /> <em class="quotelev2">>>>>>> which way to go with this. Please select A. or B. (or a new </em><br /> <em class="quotelev2">>>>>>> letter and proposal of your own invention): </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev2">>>>>>> output rendering. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev2">>>>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev2">>>>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev2">>>>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev2">>>>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev2">>>>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev2">>>>>>> source/output, but this ambiguity could be addressed and </em><br /> <em class="quotelev2">>>>>>> clarified in the <encodingDesc>. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev2">>>>>>> more formal document on this topic. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> John </em><br /> <em class="quotelev2">>>>>>> --| John A. Walsh </em><br /> <em class="quotelev2">>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev2">>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev2">>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev2">>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> _______________________________________________ </em><br /> <em class="quotelev2">>>>>>> tei-council mailing list </em><br /> <em class="quotelev2">>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> _______________________________________________ </em><br /> <em class="quotelev4">>>>> tei-council mailing list </em><br /> <em class="quotelev4">>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev4">>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> _______________________________________________ </em><br /> <em class="quotelev3">>>> tei-council mailing list </em><br /> <em class="quotelev3">>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 14:01:02 EDT</span> </div> From djbpitt+tei at pitt.edu Thu May 10 14:19:00 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 14:19:00 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> Message-ID: <46436214.8020907@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 14:19:00 -0400</span><br /> </address> Dear John (cc Lou, Council), <br /> Are you suggesting that @rend should always be a pointer to a <br /> <rendition> element, or that it should have the option of being either a <br /> pointer or an in-line specification? <br /> Best, <br /> David <br /> John A. Walsh wrote: <br /> <em class="quotelev1">> I've been persuaded by David's position and his clear and strong </em><br /> <em class="quotelev1">> distinction between descriptive and procedural/presentation. I'm also </em><br /> <em class="quotelev1">> persuaded that @rend should only refer to description of the source </em><br /> <em class="quotelev1">> material (which may be the TEI document itself in the case of born </em><br /> <em class="quotelev1">> digital material). I still believe though in the benefits of changing </em><br /> <em class="quotelev1">> @rend to be a pointer to one or more <rendition> elements which </em><br /> <em class="quotelev1">> provide a fuller and more formal description of what exactly is being </em><br /> <em class="quotelev1">> described in the source document. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Dear Lou (cc John, Council), </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> We might want to review the description of @rend in the guidelines to </em><br /> <em class="quotelev2">>> ensure that the TEI recommends that it be used to indicate rendering </em><br /> <em class="quotelev2">>> in the source document, but not to specify output rendering. Since </em><br /> <em class="quotelev2">>> new users will then ask "so how do I specify output rendering?", we </em><br /> <em class="quotelev2">>> might also add a note that output rendering is governed by </em><br /> <em class="quotelev2">>> associations in stylesheets between the descriptive TEI markup and </em><br /> <em class="quotelev2">>> the desired output final form, and that output rendering is not </em><br /> <em class="quotelev2">>> specified in the document instance. If we are feeling ambitious, we </em><br /> <em class="quotelev2">>> can point them to a discussion in the Gentle Introduction of the </em><br /> <em class="quotelev2">>> difference between descriptive and procedural/presentational markup </em><br /> <em class="quotelev2">>> as away of explaining why specifying output rendering in the document </em><br /> <em class="quotelev2">>> instance is a Bad Idea (that is, why the TEI isn't supposed to be a </em><br /> <em class="quotelev2">>> typesetting spec). </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> If we need an example, John and I discussed a specific issue from his </em><br /> <em class="quotelev2">>> projects in private email yesterday, and he's welcome to introduce </em><br /> <em class="quotelev2">>> that into the discussion if he thinks it would be constructive. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> In other words, I think the current TEI syntax is probably fine, and </em><br /> <em class="quotelev2">>> we just need to make sure that we provide clear advice about the </em><br /> <em class="quotelev2">>> semantics. We may already do that. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Best, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> David </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Lou's Laptop wrote: </em><br /> <em class="quotelev3">>>> This is both defensible and coherent as TEI policy. What changes are </em><br /> <em class="quotelev3">>>> needed (if any) in P5 to reinforce that position? </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> David J Birnbaum wrote: </em><br /> <em class="quotelev4">>>>> Dear John (cc Council), </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev4">>>>> procedural/presentational and output rendering is governed by </em><br /> <em class="quotelev4">>>>> mapping descriptive markup to rendering details in a stylesheet. If </em><br /> <em class="quotelev4">>>>> I want my code snippets output in a monospaced font, I tag them as </em><br /> <em class="quotelev4">>>>> <code> (or something similar) and in my stylesheet (not my document </em><br /> <em class="quotelev4">>>>> instance) I map the content of <code> elements to a CSS instruction </em><br /> <em class="quotelev4">>>>> to use that font (or FO or some other stylesheet-level </em><br /> <em class="quotelev4">>>>> specification). I never specify "monospaced font" as part of my </em><br /> <em class="quotelev4">>>>> markup of my born-electric source. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Similarly, I can't imagine specifying in my descriptive markup that </em><br /> <em class="quotelev4">>>>> an element should be rendered as "big" in my output document. I </em><br /> <em class="quotelev4">>>>> might specify that it was big in my source document (not the same </em><br /> <em class="quotelev4">>>>> thing, as we've noted), or I might specify that it is important or </em><br /> <em class="quotelev4">>>>> that it is a section heading, but if I want any of these three </em><br /> <em class="quotelev4">>>>> features to produce rendering as big (however I interpret that) in </em><br /> <em class="quotelev4">>>>> the output, it would be because "big in the source document" or </em><br /> <em class="quotelev4">>>>> "important" or "section heading" was mapped to "render this in big </em><br /> <em class="quotelev4">>>>> type" in the stylesheet. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> I have no problem with mapping of @rend="big" to a font </em><br /> <em class="quotelev4">>>>> specification in a <rendition> element when this is part of a </em><br /> <em class="quotelev4">>>>> description of the source document. My only objection is to </em><br /> <em class="quotelev4">>>>> specifying output rendering in the document instance. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> For what it's worth ... </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Best, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> David </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> John A. Walsh wrote: </em><br /> <em class="quotelev1">>>>>> David, </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev1">>>>>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev1">>>>>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since </em><br /> <em class="quotelev1">>>>>> we have an @rend attribute, it would seem useful to provide a </em><br /> <em class="quotelev1">>>>>> standard mechanism for documenting how that attribute is used and </em><br /> <em class="quotelev1">>>>>> defining the meaning of its content. @rend="big" could mean lots </em><br /> <em class="quotelev1">>>>>> of things, but if it points to <rendition </em><br /> <em class="quotelev1">>>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: </em><br /> <em class="quotelev1">>>>>> bold</rendition>, then one has a clear idea of what @rend="big" </em><br /> <em class="quotelev1">>>>>> means, and this rendition definition may well refer to the source </em><br /> <em class="quotelev1">>>>>> text, not any output format. A stylesheet can still take the </em><br /> <em class="quotelev1">>>>>> "big" trigger and do something else with it. The Guidelines do </em><br /> <em class="quotelev1">>>>>> already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev1">>>>>> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> John </em><br /> <em class="quotelev1">>>>>> -- </em><br /> <em class="quotelev1">>>>>> | John A. Walsh </em><br /> <em class="quotelev1">>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev2">>>>>>> Dear John, </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should </em><br /> <em class="quotelev2">>>>>>> be descriptive, rather than presentational. The ability to </em><br /> <em class="quotelev2">>>>>>> specify output rendering is often very important to projects, but </em><br /> <em class="quotelev2">>>>>>> the place to declare it is the stylesheet, not the document </em><br /> <em class="quotelev2">>>>>>> instance. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Best, </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> David </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev3">>>>>>>> Hi all, </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev3">>>>>>>> <rendition> and @rend, including the possible addition of an </em><br /> <em class="quotelev3">>>>>>>> @style attribute.<!--nospam--> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev3">>>>>>>> element in question was rendered or presented in the source </em><br /> <em class="quotelev3">>>>>>>> text." But my sense is that in practice @rend is used both to </em><br /> <em class="quotelev3">>>>>>>> indicate how an element was rendered in the source text and/or </em><br /> <em class="quotelev3">>>>>>>> how it should be rendered in a display environment such as a Web </em><br /> <em class="quotelev3">>>>>>>> browser or printed output. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev3">>>>>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev3">>>>>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev3">>>>>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev3">>>>>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev3">>>>>>>> defined in the <rendition> element of the TEI Header. @style </em><br /> <em class="quotelev3">>>>>>>> could be used to embed style information directly in an element. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev3">>>>>>>> output rendering with the addition of an @style attribute, then </em><br /> <em class="quotelev3">>>>>>>> my task is easy. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev3">>>>>>>> functionality of HTML, the task is more difficult and would </em><br /> <em class="quotelev3">>>>>>>> involve prescribing or recommending practice that is not common </em><br /> <em class="quotelev3">>>>>>>> at the moment, and would also likely involve changes to the </em><br /> <em class="quotelev3">>>>>>>> <rendition> element and perhaps a new element in <encodingDesc> </em><br /> <em class="quotelev3">>>>>>>> where folks could explain their implementation. For instance, </em><br /> <em class="quotelev3">>>>>>>> users may define their styles using CSS, XSL-FO, rendition </em><br /> <em class="quotelev3">>>>>>>> ladders, or some other mechanism, and this will need to be </em><br /> <em class="quotelev3">>>>>>>> explained in <encodingDesc>. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> I believe we touched on all these various distinctions in </em><br /> <em class="quotelev3">>>>>>>> Berlin, so I would like members of the council to weigh in on </em><br /> <em class="quotelev3">>>>>>>> which way to go with this. Please select A. or B. (or a new </em><br /> <em class="quotelev3">>>>>>>> letter and proposal of your own invention): </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev3">>>>>>>> output rendering. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev3">>>>>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev3">>>>>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev3">>>>>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev3">>>>>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev3">>>>>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev3">>>>>>>> source/output, but this ambiguity could be addressed and </em><br /> <em class="quotelev3">>>>>>>> clarified in the <encodingDesc>. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev3">>>>>>>> more formal document on this topic. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> John </em><br /> <em class="quotelev3">>>>>>>> --| John A. Walsh </em><br /> <em class="quotelev3">>>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev3">>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev3">>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev3">>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> _______________________________________________ </em><br /> <em class="quotelev3">>>>>>>> tei-council mailing list </em><br /> <em class="quotelev3">>>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> _______________________________________________ </em><br /> <em class="quotelev1">>>>>> tei-council mailing list </em><br /> <em class="quotelev1">>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> _______________________________________________ </em><br /> <em class="quotelev4">>>>> tei-council mailing list </em><br /> <em class="quotelev4">>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev4">>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 14:19:04 EDT</span> </div> From jawalsh at indiana.edu Thu May 10 14:31:35 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 14:31:35 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46436214.8020907@pitt.edu> Message-ID: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 14:31:35 -0400</span><br /> </address> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: <br /> <em class="quotelev1">> Dear John (cc Lou, Council), </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Are you suggesting that @rend should always be a pointer to a </em><br /> <em class="quotelev1">> <rendition> element, or that it should have the option of being </em><br /> <em class="quotelev1">> either a pointer or an in-line specification? </em><br /> I think this question is now the major issue we have left to tackle. I <br /> would argue that we need to decide one way or another, rather than <br /> providing an option. Of course, we need a datatype on @rend, and I <br /> don't think there is one that would accomodate both pointers and inline <br /> specs. I think people understand the advantages of the pointer system. <br /> We end up with a tightly coupled system of <rendtion> elements and <br /> @rend pointers, which provides, I think, more accuracy and clarity, but <br /> it's a bit more rigid and more complicated. It also breaks a lot of <br /> existing practice. <br /> With all this feedback, I believe I can write up some useful <br /> clarifications for @rend, but do we simply clarify existing usage or <br /> propose a more radical change? <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Best, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> David </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John A. Walsh wrote: </em><br /> <em class="quotelev2">>> I've been persuaded by David's position and his clear and strong </em><br /> <em class="quotelev2">>> distinction between descriptive and procedural/presentation. I'm </em><br /> <em class="quotelev2">>> also persuaded that @rend should only refer to description of the </em><br /> <em class="quotelev2">>> source material (which may be the TEI document itself in the case of </em><br /> <em class="quotelev2">>> born digital material). I still believe though in the benefits of </em><br /> <em class="quotelev2">>> changing @rend to be a pointer to one or more <rendition> elements </em><br /> <em class="quotelev2">>> which provide a fuller and more formal description of what exactly </em><br /> <em class="quotelev2">>> is being described in the source document. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev3">>>> Dear Lou (cc John, Council), </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> We might want to review the description of @rend in the guidelines to </em><br /> <em class="quotelev3">>>> ensure that the TEI recommends that it be used to indicate rendering </em><br /> <em class="quotelev3">>>> in the source document, but not to specify output rendering. Since </em><br /> <em class="quotelev3">>>> new users will then ask "so how do I specify output rendering?", we </em><br /> <em class="quotelev3">>>> might also add a note that output rendering is governed by </em><br /> <em class="quotelev3">>>> associations in stylesheets between the descriptive TEI markup and </em><br /> <em class="quotelev3">>>> the desired output final form, and that output rendering is not </em><br /> <em class="quotelev3">>>> specified in the document instance. If we are feeling ambitious, we </em><br /> <em class="quotelev3">>>> can point them to a discussion in the Gentle Introduction of the </em><br /> <em class="quotelev3">>>> difference between descriptive and procedural/presentational markup </em><br /> <em class="quotelev3">>>> as away of explaining why specifying output rendering in the document </em><br /> <em class="quotelev3">>>> instance is a Bad Idea (that is, why the TEI isn't supposed to be a </em><br /> <em class="quotelev3">>>> typesetting spec). </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> If we need an example, John and I discussed a specific issue from his </em><br /> <em class="quotelev3">>>> projects in private email yesterday, and he's welcome to introduce </em><br /> <em class="quotelev3">>>> that into the discussion if he thinks it would be constructive. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> In other words, I think the current TEI syntax is probably fine, and </em><br /> <em class="quotelev3">>>> we just need to make sure that we provide clear advice about the </em><br /> <em class="quotelev3">>>> semantics. We may already do that. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Best, </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> David </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Lou's Laptop wrote: </em><br /> <em class="quotelev4">>>>> This is both defensible and coherent as TEI policy. What changes are </em><br /> <em class="quotelev4">>>>> needed (if any) in P5 to reinforce that position? </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> David J Birnbaum wrote: </em><br /> <em class="quotelev1">>>>>> Dear John (cc Council), </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev1">>>>>> procedural/presentational and output rendering is governed by </em><br /> <em class="quotelev1">>>>>> mapping descriptive markup to rendering details in a stylesheet. If </em><br /> <em class="quotelev1">>>>>> I want my code snippets output in a monospaced font, I tag them as </em><br /> <em class="quotelev1">>>>>> <code> (or something similar) and in my stylesheet (not my document </em><br /> <em class="quotelev1">>>>>> instance) I map the content of <code> elements to a CSS instruction </em><br /> <em class="quotelev1">>>>>> to use that font (or FO or some other stylesheet-level </em><br /> <em class="quotelev1">>>>>> specification). I never specify "monospaced font" as part of my </em><br /> <em class="quotelev1">>>>>> markup of my born-electric source. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Similarly, I can't imagine specifying in my descriptive markup that </em><br /> <em class="quotelev1">>>>>> an element should be rendered as "big" in my output document. I </em><br /> <em class="quotelev1">>>>>> might specify that it was big in my source document (not the same </em><br /> <em class="quotelev1">>>>>> thing, as we've noted), or I might specify that it is important or </em><br /> <em class="quotelev1">>>>>> that it is a section heading, but if I want any of these three </em><br /> <em class="quotelev1">>>>>> features to produce rendering as big (however I interpret that) in </em><br /> <em class="quotelev1">>>>>> the output, it would be because "big in the source document" or </em><br /> <em class="quotelev1">>>>>> "important" or "section heading" was mapped to "render this in big </em><br /> <em class="quotelev1">>>>>> type" in the stylesheet. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> I have no problem with mapping of @rend="big" to a font </em><br /> <em class="quotelev1">>>>>> specification in a <rendition> element when this is part of a </em><br /> <em class="quotelev1">>>>>> description of the source document. My only objection is to </em><br /> <em class="quotelev1">>>>>> specifying output rendering in the document instance. </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> For what it's worth ... </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> Best, </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> David </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev2">>>>>>> David, </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev2">>>>>>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev2">>>>>>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since </em><br /> <em class="quotelev2">>>>>>> we have an @rend attribute, it would seem useful to provide a </em><br /> <em class="quotelev2">>>>>>> standard mechanism for documenting how that attribute is used and </em><br /> <em class="quotelev2">>>>>>> defining the meaning of its content. @rend="big" could mean lots </em><br /> <em class="quotelev2">>>>>>> of things, but if it points to <rendition </em><br /> <em class="quotelev2">>>>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: </em><br /> <em class="quotelev2">>>>>>> bold</rendition>, then one has a clear idea of what @rend="big" </em><br /> <em class="quotelev2">>>>>>> means, and this rendition definition may well refer to the source </em><br /> <em class="quotelev2">>>>>>> text, not any output format. A stylesheet can still take the </em><br /> <em class="quotelev2">>>>>>> "big" trigger and do something else with it. The Guidelines do </em><br /> <em class="quotelev2">>>>>>> already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev2">>>>>>> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> John </em><br /> <em class="quotelev2">>>>>>> -- </em><br /> <em class="quotelev2">>>>>>> | John A. Walsh </em><br /> <em class="quotelev2">>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev2">>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev2">>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev2">>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev3">>>>>>>> Dear John, </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should </em><br /> <em class="quotelev3">>>>>>>> be descriptive, rather than presentational. The ability to </em><br /> <em class="quotelev3">>>>>>>> specify output rendering is often very important to projects, but </em><br /> <em class="quotelev3">>>>>>>> the place to declare it is the stylesheet, not the document </em><br /> <em class="quotelev3">>>>>>>> instance. </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> Best, </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> David </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev4">>>>>>>>> Hi all, </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev4">>>>>>>>> <rendition> and @rend, including the possible addition of an </em><br /> <em class="quotelev4">>>>>>>>> @style attribute.<!--nospam--> </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev4">>>>>>>>> element in question was rendered or presented in the source </em><br /> <em class="quotelev4">>>>>>>>> text." But my sense is that in practice @rend is used both to </em><br /> <em class="quotelev4">>>>>>>>> indicate how an element was rendered in the source text and/or </em><br /> <em class="quotelev4">>>>>>>>> how it should be rendered in a display environment such as a Web </em><br /> <em class="quotelev4">>>>>>>>> browser or printed output. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev4">>>>>>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev4">>>>>>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev4">>>>>>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev4">>>>>>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev4">>>>>>>>> defined in the <rendition> element of the TEI Header. @style </em><br /> <em class="quotelev4">>>>>>>>> could be used to embed style information directly in an element. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev4">>>>>>>>> output rendering with the addition of an @style attribute, then </em><br /> <em class="quotelev4">>>>>>>>> my task is easy. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev4">>>>>>>>> functionality of HTML, the task is more difficult and would </em><br /> <em class="quotelev4">>>>>>>>> involve prescribing or recommending practice that is not common </em><br /> <em class="quotelev4">>>>>>>>> at the moment, and would also likely involve changes to the </em><br /> <em class="quotelev4">>>>>>>>> <rendition> element and perhaps a new element in <encodingDesc> </em><br /> <em class="quotelev4">>>>>>>>> where folks could explain their implementation. For instance, </em><br /> <em class="quotelev4">>>>>>>>> users may define their styles using CSS, XSL-FO, rendition </em><br /> <em class="quotelev4">>>>>>>>> ladders, or some other mechanism, and this will need to be </em><br /> <em class="quotelev4">>>>>>>>> explained in <encodingDesc>. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> I believe we touched on all these various distinctions in </em><br /> <em class="quotelev4">>>>>>>>> Berlin, so I would like members of the council to weigh in on </em><br /> <em class="quotelev4">>>>>>>>> which way to go with this. Please select A. or B. (or a new </em><br /> <em class="quotelev4">>>>>>>>> letter and proposal of your own invention): </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev4">>>>>>>>> output rendering. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev4">>>>>>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev4">>>>>>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev4">>>>>>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev4">>>>>>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev4">>>>>>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev4">>>>>>>>> source/output, but this ambiguity could be addressed and </em><br /> <em class="quotelev4">>>>>>>>> clarified in the <encodingDesc>. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev4">>>>>>>>> more formal document on this topic. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> John </em><br /> <em class="quotelev4">>>>>>>>> --| John A. Walsh </em><br /> <em class="quotelev4">>>>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev4">>>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev4">>>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev4">>>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> _______________________________________________ </em><br /> <em class="quotelev4">>>>>>>>> tei-council mailing list </em><br /> <em class="quotelev4">>>>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev4">>>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> _______________________________________________ </em><br /> <em class="quotelev2">>>>>>> tei-council mailing list </em><br /> <em class="quotelev2">>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> _______________________________________________ </em><br /> <em class="quotelev1">>>>>> tei-council mailing list </em><br /> <em class="quotelev1">>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <p><p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 14:31:39 EDT</span> </div> From djbpitt+tei at pitt.edu Thu May 10 14:36:45 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 14:36:45 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> Message-ID: <4643663D.1070509@pitt.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: David J Birnbaum <djbpitt+tei_at_pitt.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 14:36:45 -0400</span><br /> </address> Dear John (cc Council), <br /> For what it's worth, my instinct is to support only the pointer. As you <br /> note, it provides greater accuracy and clarity (much harder to have <br /> rendition values of "ital" and "i" with the same semantics in the same <br /> document if you've grouped <rendition> elements in one place), it can do <br /> everything that the inline spec can do and then some, giving a choice <br /> would just complicate processing and reduce interoperability, and if <br /> we're going to break existing practice, P5 is the time to do it. <br /> Best, <br /> David <br /> John A. Walsh wrote: <br /> <em class="quotelev1">> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Dear John (cc Lou, Council), </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Are you suggesting that @rend should always be a pointer to a </em><br /> <em class="quotelev2">>> <rendition> element, or that it should have the option of being </em><br /> <em class="quotelev2">>> either a pointer or an in-line specification? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I think this question is now the major issue we have left to tackle. </em><br /> <em class="quotelev1">> I would argue that we need to decide one way or another, rather than </em><br /> <em class="quotelev1">> providing an option. Of course, we need a datatype on @rend, and I </em><br /> <em class="quotelev1">> don't think there is one that would accomodate both pointers and </em><br /> <em class="quotelev1">> inline specs. I think people understand the advantages of the pointer </em><br /> <em class="quotelev1">> system. We end up with a tightly coupled system of <rendtion> </em><br /> <em class="quotelev1">> elements and @rend pointers, which provides, I think, more accuracy </em><br /> <em class="quotelev1">> and clarity, but it's a bit more rigid and more complicated. It also </em><br /> <em class="quotelev1">> breaks a lot of existing practice. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> With all this feedback, I believe I can write up some useful </em><br /> <em class="quotelev1">> clarifications for @rend, but do we simply clarify existing usage or </em><br /> <em class="quotelev1">> propose a more radical change? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Best, </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> David </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John A. Walsh wrote: </em><br /> <em class="quotelev3">>>> I've been persuaded by David's position and his clear and strong </em><br /> <em class="quotelev3">>>> distinction between descriptive and procedural/presentation. I'm </em><br /> <em class="quotelev3">>>> also persuaded that @rend should only refer to description of the </em><br /> <em class="quotelev3">>>> source material (which may be the TEI document itself in the case of </em><br /> <em class="quotelev3">>>> born digital material). I still believe though in the benefits of </em><br /> <em class="quotelev3">>>> changing @rend to be a pointer to one or more <rendition> elements </em><br /> <em class="quotelev3">>>> which provide a fuller and more formal description of what exactly </em><br /> <em class="quotelev3">>>> is being described in the source document. </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> John </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> Quoting David J Birnbaum <djbpitt+tei_at_pitt.<!--nospam-->edu>: </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev4">>>>> Dear Lou (cc John, Council), </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> We might want to review the description of @rend in the guidelines to </em><br /> <em class="quotelev4">>>>> ensure that the TEI recommends that it be used to indicate rendering </em><br /> <em class="quotelev4">>>>> in the source document, but not to specify output rendering. Since </em><br /> <em class="quotelev4">>>>> new users will then ask "so how do I specify output rendering?", we </em><br /> <em class="quotelev4">>>>> might also add a note that output rendering is governed by </em><br /> <em class="quotelev4">>>>> associations in stylesheets between the descriptive TEI markup and </em><br /> <em class="quotelev4">>>>> the desired output final form, and that output rendering is not </em><br /> <em class="quotelev4">>>>> specified in the document instance. If we are feeling ambitious, we </em><br /> <em class="quotelev4">>>>> can point them to a discussion in the Gentle Introduction of the </em><br /> <em class="quotelev4">>>>> difference between descriptive and procedural/presentational markup </em><br /> <em class="quotelev4">>>>> as away of explaining why specifying output rendering in the document </em><br /> <em class="quotelev4">>>>> instance is a Bad Idea (that is, why the TEI isn't supposed to be a </em><br /> <em class="quotelev4">>>>> typesetting spec). </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> If we need an example, John and I discussed a specific issue from his </em><br /> <em class="quotelev4">>>>> projects in private email yesterday, and he's welcome to introduce </em><br /> <em class="quotelev4">>>>> that into the discussion if he thinks it would be constructive. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> In other words, I think the current TEI syntax is probably fine, and </em><br /> <em class="quotelev4">>>>> we just need to make sure that we provide clear advice about the </em><br /> <em class="quotelev4">>>>> semantics. We may already do that. </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Best, </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> David </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> Lou's Laptop wrote: </em><br /> <em class="quotelev1">>>>>> This is both defensible and coherent as TEI policy. What changes are </em><br /> <em class="quotelev1">>>>>> needed (if any) in P5 to reinforce that position? </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev1">>>>>> David J Birnbaum wrote: </em><br /> <em class="quotelev2">>>>>>> Dear John (cc Council), </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> In David's Magical World of Descriptive Markup, markup is never </em><br /> <em class="quotelev2">>>>>>> procedural/presentational and output rendering is governed by </em><br /> <em class="quotelev2">>>>>>> mapping descriptive markup to rendering details in a stylesheet. If </em><br /> <em class="quotelev2">>>>>>> I want my code snippets output in a monospaced font, I tag them as </em><br /> <em class="quotelev2">>>>>>> <code> (or something similar) and in my stylesheet (not my document </em><br /> <em class="quotelev2">>>>>>> instance) I map the content of <code> elements to a CSS instruction </em><br /> <em class="quotelev2">>>>>>> to use that font (or FO or some other stylesheet-level </em><br /> <em class="quotelev2">>>>>>> specification). I never specify "monospaced font" as part of my </em><br /> <em class="quotelev2">>>>>>> markup of my born-electric source. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Similarly, I can't imagine specifying in my descriptive markup that </em><br /> <em class="quotelev2">>>>>>> an element should be rendered as "big" in my output document. I </em><br /> <em class="quotelev2">>>>>>> might specify that it was big in my source document (not the same </em><br /> <em class="quotelev2">>>>>>> thing, as we've noted), or I might specify that it is important or </em><br /> <em class="quotelev2">>>>>>> that it is a section heading, but if I want any of these three </em><br /> <em class="quotelev2">>>>>>> features to produce rendering as big (however I interpret that) in </em><br /> <em class="quotelev2">>>>>>> the output, it would be because "big in the source document" or </em><br /> <em class="quotelev2">>>>>>> "important" or "section heading" was mapped to "render this in big </em><br /> <em class="quotelev2">>>>>>> type" in the stylesheet. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> I have no problem with mapping of @rend="big" to a font </em><br /> <em class="quotelev2">>>>>>> specification in a <rendition> element when this is part of a </em><br /> <em class="quotelev2">>>>>>> description of the source document. My only objection is to </em><br /> <em class="quotelev2">>>>>>> specifying output rendering in the document instance. </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> For what it's worth ... </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> Best, </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> David </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev3">>>>>>>> David, </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> I agree about the descriptive vs. presentational issue...but the </em><br /> <em class="quotelev3">>>>>>>> stylesheets you mention often need triggers in the TEI source, and </em><br /> <em class="quotelev3">>>>>>>> they @rend attribute is often the trigger one uses.<!--nospam--> Also, since </em><br /> <em class="quotelev3">>>>>>>> we have an @rend attribute, it would seem useful to provide a </em><br /> <em class="quotelev3">>>>>>>> standard mechanism for documenting how that attribute is used and </em><br /> <em class="quotelev3">>>>>>>> defining the meaning of its content. @rend="big" could mean lots </em><br /> <em class="quotelev3">>>>>>>> of things, but if it points to <rendition </em><br /> <em class="quotelev3">>>>>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: </em><br /> <em class="quotelev3">>>>>>>> bold</rendition>, then one has a clear idea of what @rend="big" </em><br /> <em class="quotelev3">>>>>>>> means, and this rendition definition may well refer to the source </em><br /> <em class="quotelev3">>>>>>>> text, not any output format. A stylesheet can still take the </em><br /> <em class="quotelev3">>>>>>>> "big" trigger and do something else with it. The Guidelines do </em><br /> <em class="quotelev3">>>>>>>> already state that the content of rendition may be "expressed in </em><br /> <em class="quotelev3">>>>>>>> running prose, or in some more formal language such as CSS." </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> John </em><br /> <em class="quotelev3">>>>>>>> -- </em><br /> <em class="quotelev3">>>>>>>> | John A. Walsh </em><br /> <em class="quotelev3">>>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev3">>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev3">>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev3">>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> Dear John, </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should </em><br /> <em class="quotelev4">>>>>>>>> be descriptive, rather than presentational. The ability to </em><br /> <em class="quotelev4">>>>>>>>> specify output rendering is often very important to projects, but </em><br /> <em class="quotelev4">>>>>>>>> the place to declare it is the stylesheet, not the document </em><br /> <em class="quotelev4">>>>>>>>> instance. </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> Best, </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> David </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev4">>>>>>>>> John A. Walsh wrote: </em><br /> <em class="quotelev1">>>>>>>>>> Hi all, </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> I'm supposed to write up my thoughts on proposed changes to </em><br /> <em class="quotelev1">>>>>>>>>> <rendition> and @rend, including the possible addition of an </em><br /> <em class="quotelev1">>>>>>>>>> @style attribute.<!--nospam--> </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> The current P5 guidelines state that @rend "indicates how the </em><br /> <em class="quotelev1">>>>>>>>>> element in question was rendered or presented in the source </em><br /> <em class="quotelev1">>>>>>>>>> text." But my sense is that in practice @rend is used both to </em><br /> <em class="quotelev1">>>>>>>>>> indicate how an element was rendered in the source text and/or </em><br /> <em class="quotelev1">>>>>>>>>> how it should be rendered in a display environment such as a Web </em><br /> <em class="quotelev1">>>>>>>>>> browser or printed output. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> The addition of @style could be used to distinguish between </em><br /> <em class="quotelev1">>>>>>>>>> rendering in the source text (@rend) and rendering in an output </em><br /> <em class="quotelev1">>>>>>>>>> format (@style).<!--nospam--> *OR* the addition of @style could be used to </em><br /> <em class="quotelev1">>>>>>>>>> provided the @class/@style functionality of HTML.<!--nospam--> @rend (like </em><br /> <em class="quotelev1">>>>>>>>>> @class) could refer to predefined style classes, which could be </em><br /> <em class="quotelev1">>>>>>>>>> defined in the <rendition> element of the TEI Header. @style </em><br /> <em class="quotelev1">>>>>>>>>> could be used to embed style information directly in an element. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> If we simply want to distinguish between source rendering and </em><br /> <em class="quotelev1">>>>>>>>>> output rendering with the addition of an @style attribute, then </em><br /> <em class="quotelev1">>>>>>>>>> my task is easy. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> If on the other hand we want to provide the @class/@style </em><br /> <em class="quotelev1">>>>>>>>>> functionality of HTML, the task is more difficult and would </em><br /> <em class="quotelev1">>>>>>>>>> involve prescribing or recommending practice that is not common </em><br /> <em class="quotelev1">>>>>>>>>> at the moment, and would also likely involve changes to the </em><br /> <em class="quotelev1">>>>>>>>>> <rendition> element and perhaps a new element in <encodingDesc> </em><br /> <em class="quotelev1">>>>>>>>>> where folks could explain their implementation. For instance, </em><br /> <em class="quotelev1">>>>>>>>>> users may define their styles using CSS, XSL-FO, rendition </em><br /> <em class="quotelev1">>>>>>>>>> ladders, or some other mechanism, and this will need to be </em><br /> <em class="quotelev1">>>>>>>>>> explained in <encodingDesc>. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> I believe we touched on all these various distinctions in </em><br /> <em class="quotelev1">>>>>>>>>> Berlin, so I would like members of the council to weigh in on </em><br /> <em class="quotelev1">>>>>>>>>> which way to go with this. Please select A. or B. (or a new </em><br /> <em class="quotelev1">>>>>>>>>> letter and proposal of your own invention): </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> A. @rend/@style should distinguish between source rendering and </em><br /> <em class="quotelev1">>>>>>>>>> output rendering. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> B. @rend/@style should distinguish between HTML-like @class </em><br /> <em class="quotelev1">>>>>>>>>> functionality and HTML-like @style functionality.<!--nospam--> </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> Incidentally, if we go with B. and style classes are defined in </em><br /> <em class="quotelev1">>>>>>>>>> <rendition> elements of the TEI Header, then we could add an </em><br /> <em class="quotelev1">>>>>>>>>> attribute to <rendition> that indicates whether the "target" of </em><br /> <em class="quotelev1">>>>>>>>>> this rendition "class" is the source text or the output format. </em><br /> <em class="quotelev1">>>>>>>>>> The @style attribute would remain ambiguous in terms of </em><br /> <em class="quotelev1">>>>>>>>>> source/output, but this ambiguity could be addressed and </em><br /> <em class="quotelev1">>>>>>>>>> clarified in the <encodingDesc>. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> Once I hear back from others on the Council, I'll proceed with a </em><br /> <em class="quotelev1">>>>>>>>>> more formal document on this topic. </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> John </em><br /> <em class="quotelev1">>>>>>>>>> --| John A. Walsh </em><br /> <em class="quotelev1">>>>>>>>>> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">>>>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN </em><br /> <em class="quotelev1">>>>>>>>>> 47405 </em><br /> <em class="quotelev1">>>>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">>>>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 </em><br /> <em class="quotelev1">>>>>>>>>> <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> </em><br /> <em class="quotelev1">>>>>>>>>> _______________________________________________ </em><br /> <em class="quotelev1">>>>>>>>>> tei-council mailing list </em><br /> <em class="quotelev1">>>>>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">>>>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev4">>>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> </em><br /> <em class="quotelev3">>>>>>>> _______________________________________________ </em><br /> <em class="quotelev3">>>>>>>> tei-council mailing list </em><br /> <em class="quotelev3">>>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev3">>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev2">>>>>>> _______________________________________________ </em><br /> <em class="quotelev2">>>>>>> tei-council mailing list </em><br /> <em class="quotelev2">>>>>>> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev2">>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev2">>>>>>> </em><br /> <em class="quotelev1">>>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev4">>>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev3">>>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 14:36:50 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 14:59:02 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 19:59:02 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> Message-ID: <46436B76.1060901@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 19:59:02 +0100</span><br /> </address> Switching to rend="#italic" is quite attractive, especially <br /> as it can refer to a common set of <rendition> elements, <br /> eg rend="mymasterdocument.xml#italic". This matters, <br /> cos if I write 3000 small web pages in TEI XML, I don't <br /> want each one to have a <rendition> section. HOWEVER, <br /> the overhead of rend="document.xml#italic" over <br /> rend="italic" is pretty big, with lots of scope for error. <br /> Using pointers would break every processor of TEI documents, <br /> but in an understandable way; I could cope with that, <br /> after swallowing hard, but I fear the Goblin Rebellions <br /> might seem like a picnic when we announce this. <br /> John, maybe you could lead some discussion on TEI-L? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 14:59:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 15:01:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 20:01:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1178817752.19411.4.camel@caedmon> Message-ID: <46436BF0.1030304@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 20:01:04 +0100</span><br /> </address> Daniel O'Donnell wrote: <br /> <em class="quotelev2">>> So, to # or not to #? </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> # always means equivalent to xml:id? </em><br /> <em class="quotelev1">> </em><br /> if its #foo, it means that there is expected to be <br /> a corresponding object with an ID of "foo", yes. <br /> It could also be "http://www.example.com/tei.xml#foo", <br /> of course. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 15:01:08 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 15:07:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 20:07:45 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> Message-ID: <46436D81.4020102@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 20:07:45 +0100</span><br /> </address> Arianna Ciula wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> As far as born digital material regard though, I can imagine the </em><br /> <em class="quotelev1">> situation where someone wants to differentiate the semantics (not big </em><br /> <em class="quotelev1">> or small, but myIntrepret_category1 and myIntrepret_category2) of the </em><br /> <em class="quotelev1">> information so that some style could be applied - possibly - later on. </em><br /> surely they'll use other data containers for semantics? such as the <br /> "type" attribute? <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 15:07:50 EDT</span> </div> From jawalsh at indiana.edu Thu May 10 18:05:58 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 18:05:58 -0400 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> Message-ID: <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 18:05:58 -0400</span><br /> </address> On May 10, 2007, at 2:59 PM, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Switching to rend="#italic" is quite attractive, especially </em><br /> <em class="quotelev1">> as it can refer to a common set of <rendition> elements, </em><br /> <em class="quotelev1">> eg rend="mymasterdocument.xml#italic". This matters, </em><br /> <em class="quotelev1">> cos if I write 3000 small web pages in TEI XML, I don't </em><br /> <em class="quotelev1">> want each one to have a <rendition> section. HOWEVER, </em><br /> <em class="quotelev1">> the overhead of rend="document.xml#italic" over </em><br /> <em class="quotelev1">> rend="italic" is pretty big, with lots of scope for error. </em><br /> Sebastian, you raise a good point. My current solution to this <br /> problem is a common set of <rendition> elements that I include in all <br /> my documents using XInclude. <br /> Perhaps this is obvious, but I think that if we go this direction, <br /> rend should clearly provide pionters (plural) rather than a single <br /> pointer, thus allowing rend="#bold #italic" and avoiding inane things <br /> like rend="#bold_italic_underline". <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Using pointers would break every processor of TEI documents, </em><br /> <em class="quotelev1">> but in an understandable way; I could cope with that, </em><br /> <em class="quotelev1">> after swallowing hard, but I fear the Goblin Rebellions </em><br /> <em class="quotelev1">> might seem like a picnic when we announce this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John, maybe you could lead some discussion on TEI-L? </em><br /> TEI-L discussion is another good suggestion. I'll do this. <br /> John <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> Sebastian Rahtz </em><br /> <em class="quotelev1">> Information Manager, Oxford University Computing Services </em><br /> <em class="quotelev1">> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 </em><br /> <em class="quotelev1">> </em><br /> <p>_______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 18:06:20 EDT</span> </div> From daniel.odonnell at uleth.ca Thu May 10 18:27:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 16:27:33 -0600 Subject: [tei-council] Finishing off our easter eggs Message-ID: <1178836053.11190.14.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Thu, 10 May 2007 16:27:33 -0600</span><br /> </address> Hi all, <br /> I've just finished add my detailed notes--i.e. the ones that weren't <br /> raised in the meeting--to my easter eggs in trac. My question is what to <br /> do with them now. I reassigned them to "eds" as a temporary device to <br /> indicate that I'd finished with them, but I was wondering what I should <br /> do with them. <br /> Most of the notes are identification of loci and suggestions for <br /> editorial interventions rather than corrections. <br /> -dan <br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Thu May 10 2007 - 18:31:11 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri May 11 04:56:00 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 09:56:00 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46436D81.4020102@oucs.ox.ac.uk> Message-ID: <46442FA0.9010404@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 09:56:00 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Arianna Ciula wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> As far as born digital material regard though, I can imagine the </em><br /> <em class="quotelev2">>> situation where someone wants to differentiate the semantics (not big </em><br /> <em class="quotelev2">>> or small, but myIntrepret_category1 and myIntrepret_category2) of the </em><br /> <em class="quotelev2">>> information so that some style could be applied - possibly - later on. </em><br /> <em class="quotelev1">> surely they'll use other data containers for semantics? such as the </em><br /> <em class="quotelev1">> "type" attribute? </em><br /> Sure. What I meant was interpretative categories related to the <br /> rendition of the document but at the same time not as procedural as <br /> 'italic bold'. <br /> So for instance if I have two different tables and they both contain <br /> images of text, my @type could be used to specify the type of text they <br /> contain (e.g. images of different scribal abbreviations vs. images of <br /> different scribal headings), while my @rend could be used to say that <br /> both tables contain images of text and therefore have different <br /> rendition from those that contain other type of images. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 04:56:35 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Fri May 11 04:59:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 11 May 2007 09:59:31 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46442FA0.9010404@kcl.ac.uk> Message-ID: <46443073.70801@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 09:59:31 +0100</span><br /> </address> Arianna Ciula wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> So for instance if I have two different tables and they both contain </em><br /> <em class="quotelev1">> images of text, my @type could be used to specify the type of text </em><br /> <em class="quotelev1">> they contain (e.g. images of different scribal abbreviations vs. </em><br /> <em class="quotelev1">> images of different scribal headings), while my @rend could be used to </em><br /> <em class="quotelev1">> say that both tables contain images of text and therefore have </em><br /> <em class="quotelev1">> different rendition from those that contain other type of images. </em><br /> <em class="quotelev1">> </em><br /> multiple values for the @type attribute? <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 04:59:36 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri May 11 04:59:50 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 09:59:50 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510135255.64gyni6d8gso4kkc@webmail.iu.edu> Message-ID: <46443086.8090008@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 09:59:50 +0100</span><br /> </address> John A. Walsh wrote: <br /> <em class="quotelev1">> The practice of pointing @rend to <rendition> is not just for born </em><br /> <em class="quotelev1">> digital material. I think CSS (or XSL-FO) properties such as </em><br /> <em class="quotelev1">> font-family, font-size, font-weight, text-indent, etc. can be used to </em><br /> <em class="quotelev1">> describe accurately and precisely the appearance of a source document, </em><br /> <em class="quotelev1">> at least for printed source documents, though many properties can also </em><br /> <em class="quotelev1">> be useful in the description of manuscript documents. </em><br /> Good point. <br /> I don't want to seem against this. As I said, I think the precision of <br /> the encoding would only gain. The issue is, as always, the balance <br /> between the precision of a good practice and the flexible tolerance of <br /> the single user's practices. <br /> We will see what the TEI-L has to say. <br /> Arianna <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 05:00:29 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri May 11 05:05:33 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 10:05:33 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46443073.70801@oucs.ox.ac.uk> Message-ID: <464431DD.4030301@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 10:05:33 +0100</span><br /> </address> Sebastian Rahtz wrote: <br /> <em class="quotelev1">> Arianna Ciula wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> So for instance if I have two different tables and they both contain </em><br /> <em class="quotelev2">>> images of text, my @type could be used to specify the type of text </em><br /> <em class="quotelev2">>> they contain (e.g. images of different scribal abbreviations vs. </em><br /> <em class="quotelev2">>> images of different scribal headings), while my @rend could be used to </em><br /> <em class="quotelev2">>> say that both tables contain images of text and therefore have </em><br /> <em class="quotelev2">>> different rendition from those that contain other type of images. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> multiple values for the @type attribute? </em><br /> could do, but could also use @rend since its purpose it to represent the <br /> rendition of the source. <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 05:07:00 EDT</span> </div> From jawalsh at indiana.edu Fri May 11 07:01:05 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Fri, 11 May 2007 07:01:05 -0400 Subject: [tei-council] More on rend Message-ID: <30F3DAD4-067A-456E-A77E-029DB1101799@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 07:01:05 -0400</span><br /> </address> Hi all, <br /> Yesterday David mentioned a private exchange we had about a specific <br /> example of rend usage. The example is somewhat analogous to the <br /> interpretive categories issue we discussed yesterday and provides <br /> further amplification to David's thoughtful commentary on the issue <br /> of descriptive vs. presentation/procedural markup. The exchange is <br /> less relevant to the specific discussion of rend as pointer to <br /> <rendition>, so I don't want the message to confuse that issue, but <br /> here it is for your enjoyment: <br /> <em class="quotelev1">> From: djbpitt+tei_at_pitt.<!--nospam-->edu </em><br /> <em class="quotelev1">> Subject: Re: [tei-council] rendition, rend, and style </em><br /> <em class="quotelev1">> Date: May 9, 2007 10:31:45 PM EDT </em><br /> <em class="quotelev1">> To: jawalsh_at_indiana.<!--nospam-->edu </em><br /> <em class="quotelev1">> Reply-To: djbpitt+tei_at_pitt.<!--nospam-->edu </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Dear John, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> I'm wanting to succumb to the rigorous purity of your descriptive </em><br /> <em class="quotelev2">>> vs. presentational distinction, but find I've perhaps irrevocably </em><br /> <em class="quotelev2">>> polluted my own personal encoding practice. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The purity of which you speak is a hypothesis I am continually </em><br /> <em class="quotelev1">> testing, but so far I haven't run into trouble. When I really need </em><br /> <em class="quotelev1">> to focus on a specific output format, I use Word or PowerPoint or </em><br /> <em class="quotelev1">> presentationally-oriented HTML. When I want to focus on structure, </em><br /> <em class="quotelev1">> I use XML with descriptive markup and impose presentational </em><br /> <em class="quotelev1">> features during XSLT transformation. So far I've been able to </em><br /> <em class="quotelev1">> maintain my principles and get the results I need. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> [By the way, concerning purity and principles more generally, I may </em><br /> <em class="quotelev1">> have mentioned that one of the first papers I ever delivered at an </em><br /> <em class="quotelev1">> SGML conference was entitled "In Defense of Invalid SGML," where I </em><br /> <em class="quotelev1">> told several hundred people who write massive electronic </em><br /> <em class="quotelev1">> documentation files for government and industry why it might be </em><br /> <em class="quotelev1">> desirable to produce SGML that failed validation. I got a laugh </em><br /> <em class="quotelev1">> when I said "I'm an academic; I don't have to build working </em><br /> <em class="quotelev1">> systems," but the paper was serious, and I hope I dealt seriously </em><br /> <em class="quotelev1">> with the consequences. (If you're curious, the paper, with a less </em><br /> <em class="quotelev1">> polemical title, is at http://clover.slavic.pitt.edu/~djb/sgml/ </em><br /> <em class="quotelev1">> invalid.html .)] </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> In any case ... </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Here's an example. My documents are full of <persName> elements. </em><br /> <em class="quotelev2">>> In some cases, I want the <persName> element "rendered" as (or </em><br /> <em class="quotelev2">>> with) a mouseover gloss that describes a potentially unfamiliar </em><br /> <em class="quotelev2">>> person. So <persName key="bill">William Shakespeare</persName> </em><br /> <em class="quotelev2">>> may not need a gloss, but <persName key="villon">Fran?ois Villon</ </em><br /> <em class="quotelev2">>> persName> may indeed need a gloss. I've done something like this, </em><br /> <em class="quotelev2">>> <persName rend="gloss" key="villon">Fra?ois Villon</persName>. </em><br /> <em class="quotelev2">>> What other semantics (other than @rend) are available to me to </em><br /> <em class="quotelev2">>> make the distinction between names needing a gloss? Perhaps my </em><br /> <em class="quotelev2">>> person database could contain a field indicating whether the </em><br /> <em class="quotelev2">>> person requires a gloss. But I may be using the same database for </em><br /> <em class="quotelev2">>> multiple projects and multiple source documents, and the need for </em><br /> <em class="quotelev2">>> a gloss may not be consistent across all these projects/documents. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I like the syntax of your solution, but I would approach the </em><br /> <em class="quotelev1">> semantics differently. Instead of @rend="gloss" I would have </em><br /> <em class="quotelev1">> something like @unfamiliar="yes".<!--nospam--> The descriptive fact is that the </em><br /> <em class="quotelev1">> name is unfamiliar, and the way you deal with it in one view is to </em><br /> <em class="quotelev1">> provide a mouseover gloss. You might, in an alternative view, </em><br /> <em class="quotelev1">> render all of the unfamiliar names in a different color and ask </em><br /> <em class="quotelev1">> your students to identify them for a test, and in that view you </em><br /> <em class="quotelev1">> wouldn't be glossing them at all. Or you might collect a list of </em><br /> <em class="quotelev1">> unfamiliar names as an appendix for scholars or a study guide for </em><br /> <em class="quotelev1">> students, with or without glosses. In other words, the </em><br /> <em class="quotelev1">> unfamiliarity is the descriptive fact, and the glossing an artifact </em><br /> <em class="quotelev1">> of a particular view. Both of our approaches tag the unfamiliar </em><br /> <em class="quotelev1">> names, but mine separates the fact that they are unfamiliar (and </em><br /> <em class="quotelev1">> therefore might need special treatment, with the exact special </em><br /> <em class="quotelev1">> treatment subject to variation) from the way they are rendered in a </em><br /> <em class="quotelev1">> particular view / application / environment. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Another approach might be assemble the information about who gets </em><br /> <em class="quotelev1">> glossed for a particular project not in your general database of </em><br /> <em class="quotelev1">> persons (since the need for glossing may vary from project to </em><br /> <em class="quotelev1">> project) and not in the <persName> elements in the document </em><br /> <em class="quotelev1">> instance, but in a separate structure in the header in the document </em><br /> <em class="quotelev1">> instance, one that listed the names that should be considered </em><br /> <em class="quotelev1">> unfamiliar within the context of that instance. This has the added </em><br /> <em class="quotelev1">> advantage of letting you indicate once in the header that every </em><br /> <em class="quotelev1">> occurence of Fran??ois Villon should be considered unfamiliar in a </em><br /> <em class="quotelev1">> particular document without having to add the @rend element each </em><br /> <em class="quotelev1">> time the name occurs. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Without taking up too much more of your time, could you offer some </em><br /> <em class="quotelev2">>> advice on this particular case? It's something I've been </em><br /> <em class="quotelev2">>> wrestling with, and I would value your input. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I'm happy to spend time this way. And, unlike with my invalid SGML </em><br /> <em class="quotelev1">> presentation, I think the approaches described above should be able </em><br /> <em class="quotelev1">> to maintain markup that is rigorously descriptive while also </em><br /> <em class="quotelev1">> providing a working system that affords the functionality needed </em><br /> <em class="quotelev1">> for the projects you describe. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Does this help? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Cheers, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> David </em><br /> <p><p><p> -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 07:01:35 EDT</span> </div> From daniel.odonnell at uleth.ca Fri May 11 12:13:21 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 11 May 2007 10:13:21 -0600 Subject: [tei-council] Venues for distributing MM posters? Message-ID: <1178900001.31143.32.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 10:13:21 -0600</span><br /> </address> Hi all, <br /> I have a question for the whole band of plugged in people: Susan <br /> Schreibman, who is organising this fall's members meeting/markup <br /> conference, has a poster ready that she'd like to distribute at <br /> conferences of relevant organisations over the course of the summer. <br /> What conferences/meetings would you suggest? She is going to get them <br /> into DH and DRHA. Any other suggestions? <br /> -dan <br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 12:13:29 EDT</span> </div> From daniel.odonnell at uleth.ca Fri May 11 12:15:00 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 11 May 2007 10:15:00 -0600 Subject: [tei-council] More on rend In-Reply-To: <30F3DAD4-067A-456E-A77E-029DB1101799@indiana.edu> Message-ID: <1178900100.31143.34.camel@caedmon> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Daniel O'Donnell <daniel.odonnell_at_uleth.ca> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 10:15:00 -0600</span><br /> </address> I think if there has been a trend throughout our P5 council discussions <br /> it has been towards purity. So I'm happy with how things are going. <br /> On Fri, 2007-05-11 at 07:01 -0400, John A. Walsh wrote: <br /> <em class="quotelev1">> Hi all, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Yesterday David mentioned a private exchange we had about a specific </em><br /> <em class="quotelev1">> example of rend usage. The example is somewhat analogous to the </em><br /> <em class="quotelev1">> interpretive categories issue we discussed yesterday and provides </em><br /> <em class="quotelev1">> further amplification to David's thoughtful commentary on the issue </em><br /> <em class="quotelev1">> of descriptive vs. presentation/procedural markup. The exchange is </em><br /> <em class="quotelev1">> less relevant to the specific discussion of rend as pointer to </em><br /> <em class="quotelev1">> <rendition>, so I don't want the message to confuse that issue, but </em><br /> <em class="quotelev1">> here it is for your enjoyment: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">> > From: djbpitt+tei_at_pitt.<!--nospam-->edu </em><br /> <em class="quotelev2">> > Subject: Re: [tei-council] rendition, rend, and style </em><br /> <em class="quotelev2">> > Date: May 9, 2007 10:31:45 PM EDT </em><br /> <em class="quotelev2">> > To: jawalsh_at_indiana.<!--nospam-->edu </em><br /> <em class="quotelev2">> > Reply-To: djbpitt+tei_at_pitt.<!--nospam-->edu </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Dear John, </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> I'm wanting to succumb to the rigorous purity of your descriptive </em><br /> <em class="quotelev3">> >> vs. presentational distinction, but find I've perhaps irrevocably </em><br /> <em class="quotelev3">> >> polluted my own personal encoding practice. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > The purity of which you speak is a hypothesis I am continually </em><br /> <em class="quotelev2">> > testing, but so far I haven't run into trouble. When I really need </em><br /> <em class="quotelev2">> > to focus on a specific output format, I use Word or PowerPoint or </em><br /> <em class="quotelev2">> > presentationally-oriented HTML. When I want to focus on structure, </em><br /> <em class="quotelev2">> > I use XML with descriptive markup and impose presentational </em><br /> <em class="quotelev2">> > features during XSLT transformation. So far I've been able to </em><br /> <em class="quotelev2">> > maintain my principles and get the results I need. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > [By the way, concerning purity and principles more generally, I may </em><br /> <em class="quotelev2">> > have mentioned that one of the first papers I ever delivered at an </em><br /> <em class="quotelev2">> > SGML conference was entitled "In Defense of Invalid SGML," where I </em><br /> <em class="quotelev2">> > told several hundred people who write massive electronic </em><br /> <em class="quotelev2">> > documentation files for government and industry why it might be </em><br /> <em class="quotelev2">> > desirable to produce SGML that failed validation. I got a laugh </em><br /> <em class="quotelev2">> > when I said "I'm an academic; I don't have to build working </em><br /> <em class="quotelev2">> > systems," but the paper was serious, and I hope I dealt seriously </em><br /> <em class="quotelev2">> > with the consequences. (If you're curious, the paper, with a less </em><br /> <em class="quotelev2">> > polemical title, is at http://clover.slavic.pitt.edu/~djb/sgml/ </em><br /> <em class="quotelev2">> > invalid.html .)] </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > In any case ... </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> Here's an example. My documents are full of <persName> elements. </em><br /> <em class="quotelev3">> >> In some cases, I want the <persName> element "rendered" as (or </em><br /> <em class="quotelev3">> >> with) a mouseover gloss that describes a potentially unfamiliar </em><br /> <em class="quotelev3">> >> person. So <persName key="bill">William Shakespeare</persName> </em><br /> <em class="quotelev3">> >> may not need a gloss, but <persName key="villon">Fran??ois Villon</ </em><br /> <em class="quotelev3">> >> persName> may indeed need a gloss. I've done something like this, </em><br /> <em class="quotelev3">> >> <persName rend="gloss" key="villon">Fra??ois Villon</persName>. </em><br /> <em class="quotelev3">> >> What other semantics (other than @rend) are available to me to </em><br /> <em class="quotelev3">> >> make the distinction between names needing a gloss? Perhaps my </em><br /> <em class="quotelev3">> >> person database could contain a field indicating whether the </em><br /> <em class="quotelev3">> >> person requires a gloss. But I may be using the same database for </em><br /> <em class="quotelev3">> >> multiple projects and multiple source documents, and the need for </em><br /> <em class="quotelev3">> >> a gloss may not be consistent across all these projects/documents. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I like the syntax of your solution, but I would approach the </em><br /> <em class="quotelev2">> > semantics differently. Instead of @rend="gloss" I would have </em><br /> <em class="quotelev2">> > something like @unfamiliar="yes".<!--nospam--> The descriptive fact is that the </em><br /> <em class="quotelev2">> > name is unfamiliar, and the way you deal with it in one view is to </em><br /> <em class="quotelev2">> > provide a mouseover gloss. You might, in an alternative view, </em><br /> <em class="quotelev2">> > render all of the unfamiliar names in a different color and ask </em><br /> <em class="quotelev2">> > your students to identify them for a test, and in that view you </em><br /> <em class="quotelev2">> > wouldn't be glossing them at all. Or you might collect a list of </em><br /> <em class="quotelev2">> > unfamiliar names as an appendix for scholars or a study guide for </em><br /> <em class="quotelev2">> > students, with or without glosses. In other words, the </em><br /> <em class="quotelev2">> > unfamiliarity is the descriptive fact, and the glossing an artifact </em><br /> <em class="quotelev2">> > of a particular view. Both of our approaches tag the unfamiliar </em><br /> <em class="quotelev2">> > names, but mine separates the fact that they are unfamiliar (and </em><br /> <em class="quotelev2">> > therefore might need special treatment, with the exact special </em><br /> <em class="quotelev2">> > treatment subject to variation) from the way they are rendered in a </em><br /> <em class="quotelev2">> > particular view / application / environment. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Another approach might be assemble the information about who gets </em><br /> <em class="quotelev2">> > glossed for a particular project not in your general database of </em><br /> <em class="quotelev2">> > persons (since the need for glossing may vary from project to </em><br /> <em class="quotelev2">> > project) and not in the <persName> elements in the document </em><br /> <em class="quotelev2">> > instance, but in a separate structure in the header in the document </em><br /> <em class="quotelev2">> > instance, one that listed the names that should be considered </em><br /> <em class="quotelev2">> > unfamiliar within the context of that instance. This has the added </em><br /> <em class="quotelev2">> > advantage of letting you indicate once in the header that every </em><br /> <em class="quotelev2">> > occurence of Fran????ois Villon should be considered unfamiliar in a </em><br /> <em class="quotelev2">> > particular document without having to add the @rend element each </em><br /> <em class="quotelev2">> > time the name occurs. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev3">> >> Without taking up too much more of your time, could you offer some </em><br /> <em class="quotelev3">> >> advice on this particular case? It's something I've been </em><br /> <em class="quotelev3">> >> wrestling with, and I would value your input. </em><br /> <em class="quotelev3">> >> </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I'm happy to spend time this way. And, unlike with my invalid SGML </em><br /> <em class="quotelev2">> > presentation, I think the approaches described above should be able </em><br /> <em class="quotelev2">> > to maintain markup that is rigorously descriptive while also </em><br /> <em class="quotelev2">> > providing a working system that affords the functionality needed </em><br /> <em class="quotelev2">> > for the projects you describe. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Does this help? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > Cheers, </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > David </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> | John A. Walsh </em><br /> <em class="quotelev1">> | Assistant Professor, School of Library and Information Science </em><br /> <em class="quotelev1">> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 </em><br /> <em class="quotelev1">> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> </em><br /> <em class="quotelev1">> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.<!--nospam-->ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 12:15:08 EDT</span> </div> From arianna.ciula at kcl.ac.uk Fri May 11 12:45:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 17:45:32 +0100 Subject: [tei-council] Venues for distributing MM posters? In-Reply-To: <1178900001.31143.32.camel@caedmon> Message-ID: <46449DAC.60504@kcl.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Arianna Ciula <arianna.ciula_at_kcl.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Fri, 11 May 2007 17:45:32 +0100</span><br /> </address> May be: <br /> DIGIMED workshop Paris (June, Ecole des Chartes) <br /> DIGIMED Arezzo (September) <br /> IMC Kalamazoo (May) <br /> IMC Leeds (July) <br /> Arianna <br /> Daniel O'Donnell wrote: <br /> <em class="quotelev1">> Hi all, </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> I have a question for the whole band of plugged in people: Susan </em><br /> <em class="quotelev1">> Schreibman, who is organising this fall's members meeting/markup </em><br /> <em class="quotelev1">> conference, has a poster ready that she'd like to distribute at </em><br /> <em class="quotelev1">> conferences of relevant organisations over the course of the summer. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> What conferences/meetings would you suggest? She is going to get them </em><br /> <em class="quotelev1">> into DH and DRHA. Any other suggestions? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -dan </em><br /> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Fri May 11 2007 - 12:46:30 EDT</span> </div> From dporter at uky.edu Sat May 12 10:42:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sat, 12 May 2007 10:42:16 -0400 Subject: [tei-council] Venues for distributing MM posters? In-Reply-To: <46449DAC.60504@kcl.ac.uk> Message-ID: <96f3df640705120742y26fdb5b7qec555a74de32a16@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Dot Porter <dporter_at_uky.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Sat, 12 May 2007 10:42:16 -0400</span><br /> </address> Kalamazoo is happening right now, so too late for that, though I have <br /> been spreading the word to anyone I meet here who is in the eastern US <br /> (including folks from UVA and at the JHU Roman de la Rose project). <br /> James and I (at least - probably others too) will both be at Leeds so <br /> we can take posters there, if Susan could provide them for us. <br /> Thanks, Susan and Dan! <br /> Dot <br /> On 5/11/07, Arianna Ciula <arianna.ciula_at_kcl.<!--nospam-->ac.uk> wrote: <br /> <em class="quotelev1">> May be: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> DIGIMED workshop Paris (June, Ecole des Chartes) </em><br /> <em class="quotelev1">> DIGIMED Arezzo (September) </em><br /> <em class="quotelev1">> IMC Kalamazoo (May) </em><br /> <em class="quotelev1">> IMC Leeds (July) </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Arianna </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Daniel O'Donnell wrote: </em><br /> <em class="quotelev2">> > Hi all, </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > I have a question for the whole band of plugged in people: Susan </em><br /> <em class="quotelev2">> > Schreibman, who is organising this fall's members meeting/markup </em><br /> <em class="quotelev2">> > conference, has a poster ready that she'd like to distribute at </em><br /> <em class="quotelev2">> > conferences of relevant organisations over the course of the summer. </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > What conferences/meetings would you suggest? She is going to get them </em><br /> <em class="quotelev2">> > into DH and DRHA. Any other suggestions? </em><br /> <em class="quotelev2">> > </em><br /> <em class="quotelev2">> > -dan </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> -- </em><br /> <em class="quotelev1">> Dr Arianna Ciula </em><br /> <em class="quotelev1">> Research Associate </em><br /> <em class="quotelev1">> Centre for Computing in the Humanities </em><br /> <em class="quotelev1">> King's College London </em><br /> <em class="quotelev1">> Strand </em><br /> <em class="quotelev1">> London WC2R 2LS (UK) </em><br /> <em class="quotelev1">> Tel: +44 (0)20 78481945 </em><br /> <em class="quotelev1">> http://www.kcl.ac.uk/cch </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.<!--nospam-->edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.<!--nospam-->uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Sat May 12 2007 - 10:42:20 EDT</span> </div> From James.Cummings at oucs.ox.ac.uk Tue May 15 15:17:48 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 15 May 2007 15:17:48 -0400 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> Message-ID: <464A075C.2080707@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: James Cummings <James.Cummings_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Tue, 15 May 2007 15:17:48 -0400</span><br /> </address> Hi, <br /> I've been away (still am), and have just now been wading through the discussion <br /> on @rend.<!--nospam--> <br /> My thoughts so far are: <br /> - @rend should only refer to the rendition in the original source <br /> - @rend shouldn't be used to indicate output style (something else trapped in <br /> the xslt should, but I think I basically agree with David on purity of <br /> descriptive markup) <br /> - @rend should be a datatype of one or more data.<!--nospam-->pointer which the Guidelines <br /> prose states should ideally be pointing to one or more <rendition> elements in <br /> the header of this or another document. This should help create internal <br /> document consistency. <br /> - I'd be tempted to do @rend="#bigFunnyLooking5" and then have a <ptr/> inside <br /> <rendition xml:id="bigFunnyLooking5"> to point to an external source for <br /> rendition information kept elsewhere. (rather than have <br /> @rend="http://www.example.com/foo/renditions.xml#bigFunnyLooking5" on various <br /> <hi> elements. John's XIncluding is another solution. <br /> - Importing @html:style is a use of namespaces I've been fearing -- I know <br /> people are going to do it, but I personally prefer to have little or no output <br /> style information in my TEI documents if possible. But, since people are going <br /> to do it anyway, maybe the Guidelines should mention it. <br /> - Importing @html:class isn't as necessary I think.<!--nospam--> In most cases where I would <br /> want to do this the elements already have @tei:type which is more specific in <br /> terms of its semantics. (It applying to the type of that element, rather than a <br /> generalistic class regardless of element.) I'd catch @tei:type in my xslt and <br /> provide style information there (or load it in from elsewhere), or base it on <br /> structure. <br /> I'm sure I've missed or misunderstood some of the issues, but I've been <br /> ploughing through all the messages while on holiday ;-) <br /> -James <br /> John A. Walsh wrote: <br /> <em class="quotelev1">> On May 10, 2007, at 2:59 PM, Sebastian Rahtz wrote: </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> Switching to rend="#italic" is quite attractive, especially </em><br /> <em class="quotelev2">>> as it can refer to a common set of <rendition> elements, </em><br /> <em class="quotelev2">>> eg rend="mymasterdocument.xml#italic". This matters, </em><br /> <em class="quotelev2">>> cos if I write 3000 small web pages in TEI XML, I don't </em><br /> <em class="quotelev2">>> want each one to have a <rendition> section. HOWEVER, </em><br /> <em class="quotelev2">>> the overhead of rend="document.xml#italic" over </em><br /> <em class="quotelev2">>> rend="italic" is pretty big, with lots of scope for error. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> Sebastian, you raise a good point. My current solution to this problem </em><br /> <em class="quotelev1">> is a common set of <rendition> elements that I include in all my </em><br /> <em class="quotelev1">> documents using XInclude. </em><br /> <em class="quotelev1">> Perhaps this is obvious, but I think that if we go this direction, rend </em><br /> <em class="quotelev1">> should clearly provide pionters (plural) rather than a single pointer, </em><br /> <em class="quotelev1">> thus allowing rend="#bold #italic" and avoiding inane things like </em><br /> <em class="quotelev1">> rend="#bold_italic_underline". </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> Using pointers would break every processor of TEI documents, </em><br /> <em class="quotelev2">>> but in an understandable way; I could cope with that, </em><br /> <em class="quotelev2">>> after swallowing hard, but I fear the Goblin Rebellions </em><br /> <em class="quotelev2">>> might seem like a picnic when we announce this. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> John, maybe you could lead some discussion on TEI-L? </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> TEI-L discussion is another good suggestion. I'll do this. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> John </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> --Sebastian Rahtz </em><br /> <em class="quotelev2">>> Information Manager, Oxford University Computing Services </em><br /> <em class="quotelev2">>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> _______________________________________________ </em><br /> <em class="quotelev1">> tei-council mailing list </em><br /> <em class="quotelev1">> tei-council_at_lists.<!--nospam-->village.Virginia.EDU </em><br /> <em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council </em><br /> <em class="quotelev1">> </em><br /> <p> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Tue May 15 2007 - 15:17:56 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 05:37:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 10:37:19 +0100 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <464A075C.2080707@oucs.ox.ac.uk> Message-ID: <464AD0CF.5060901@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 10:37:19 +0100</span><br /> </address> James Cummings wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> - I'd be tempted to do @rend="#bigFunnyLooking5" and then have a </em><br /> <em class="quotelev1">> <ptr/> inside <rendition xml:id="bigFunnyLooking5"> to point to an </em><br /> <em class="quotelev1">> external source for rendition information kept elsewhere. (rather than </em><br /> <em class="quotelev1">> have </em><br /> <em class="quotelev1">> @rend="http://www.example.com/foo/renditions.xml#bigFunnyLooking5" on </em><br /> <em class="quotelev1">> various <hi> elements. John's XIncluding is another solution. </em><br /> You can make it a little easier by going via <rendition>, but it does <br /> not obviate the <br /> need to maintain a great gross wodge of identical material in the header <br /> of every document. <br /> Using XInclude works, of course, but it still seems to bloat things. <br /> Those XIncludes will <br /> keep on getting expanded. <br /> if you want consistency across docs, avoiding rend="italic vs <br /> rend="it", then <br /> put fixed value lists on the rend attribute in your schema. that answers <br /> most <br /> of the practical criticisms of @rend as it stands, surely? its actually <br /> _better_ <br /> that pointers, because it is validated, and prompts you during editing. <br /> Due to the wonders of ODD, you can provide different value lists for <br /> each element if you want. <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 05:37:22 EDT</span> </div> From cwittern at gmail.com Wed May 16 07:44:18 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 16 May 2007 20:44:18 +0900 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <464AD0CF.5060901@oucs.ox.ac.uk> Message-ID: <5268d87d0705160444r7e696ffey9770b1f01e9d0cfd@mail.gmail.com> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Christian Wittern <cwittern_at_gmail.com> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 20:44:18 +0900</span><br /> </address> On 16/05/07, Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> wrote: <br /> <em class="quotelev1">> James Cummings wrote: </em><br /> <em class="quotelev1">> if you want consistency across docs, avoiding rend="italic vs </em><br /> <em class="quotelev1">> rend="it", then </em><br /> <em class="quotelev1">> put fixed value lists on the rend attribute in your schema. that answers </em><br /> <em class="quotelev1">> most </em><br /> <em class="quotelev1">> of the practical criticisms of @rend as it stands, surely? its actually </em><br /> <em class="quotelev1">> _better_ </em><br /> <em class="quotelev1">> that pointers, because it is validated, and prompts you during editing. </em><br /> <em class="quotelev1">> Due to the wonders of ODD, you can provide different value lists for </em><br /> <em class="quotelev1">> each element if you want. </em><br /> But this will prevent you from getting the highest grades in <br /> Conformance-School, right? <br /> Christian <br /> -- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 07:44:22 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 07:53:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 12:53:43 +0100 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <5268d87d0705160444r7e696ffey9770b1f01e9d0cfd@mail.gmail.com> Message-ID: <464AF0C7.1070505@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 12:53:43 +0100</span><br /> </address> Christian Wittern wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> But this will prevent you from getting the highest grades in </em><br /> <em class="quotelev1">> Conformance-School, right? </em><br /> <em class="quotelev1">> </em><br /> not all. its a clean modification, subsetting the TEI. <br /> you get full marks. <br /> <p> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 07:53:47 EDT</span> </div> From jawalsh at indiana.edu Wed May 16 08:12:13 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 16 May 2007 08:12:13 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464AD0CF.5060901@oucs.ox.ac.uk> Message-ID: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 08:12:13 -0400</span><br /> </address> On May 16, 2007, at 5:37 AM, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> if you want consistency across docs, avoiding rend="italic vs </em><br /> <em class="quotelev1">> rend="it", then </em><br /> <em class="quotelev1">> put fixed value lists on the rend attribute in your schema. that </em><br /> <em class="quotelev1">> answers most </em><br /> <em class="quotelev1">> of the practical criticisms of @rend as it stands, surely? its </em><br /> <em class="quotelev1">> actually _better_ </em><br /> <em class="quotelev1">> that pointers, because it is validated, and prompts you during </em><br /> <em class="quotelev1">> editing. </em><br /> <em class="quotelev1">> Due to the wonders of ODD, you can provide different value lists for </em><br /> <em class="quotelev1">> each element if you want. </em><br /> The problem is with a fixed value list is that you can't combine <br /> rendition styles. With the pointers (note the plural) method, I can <br /> have <rendition> elements defining italic, bold, underline, and <br /> center styles. If my source includes an element that is all of <br /> these, I can do rend="#i #b #u #center". With the fixed value list, <br /> I'd have to have an unwieldy number of values to accommodate all the <br /> combinations. <br /> John <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 08:12:35 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 08:53:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 13:53:22 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> Message-ID: <464AFEC2.9040304@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 13:53:22 +0100</span><br /> </address> John A. Walsh wrote: <br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> The problem is with a fixed value list is that you can't combine </em><br /> <em class="quotelev1">> rendition styles. With the pointers (note the plural) method, I can </em><br /> <em class="quotelev1">> have <rendition> elements defining italic, bold, underline, and center </em><br /> <em class="quotelev1">> styles. If my source includes an element that is all of these, I can </em><br /> <em class="quotelev1">> do rend="#i #b #u #center". With the fixed value list, I'd have to </em><br /> <em class="quotelev1">> have an unwieldy number of values to accommodate all the combinations. </em><br /> <em class="quotelev1">> </em><br /> but the datatype of rend is "multiple tokens"[1], so you can say <br /> rend="a b c" and each of a, b and <br /> c will be checked against the list. honest. <br /> <p>[1] <datatype maxOccurs="unbounded"> <br /> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" <br /> name="data.word"/> <br /> </datatype> <br /> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.<!--nospam-->village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 08:53:26 EDT</span> </div> From jawalsh at indiana.edu Wed May 16 09:14:11 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 16 May 2007 09:14:11 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464AFEC2.9040304@oucs.ox.ac.uk> Message-ID: <A25EA971-3FC4-44D1-9B23-F2251EC40FC8@indiana.edu> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: John A. Walsh <jawalsh_at_indiana.edu> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 09:14:11 -0400</span><br /> </address> On May 16, 2007, at 8:53 AM, Sebastian Rahtz wrote: <br /> <em class="quotelev1">> John A. Walsh wrote: </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev2">>> The problem is with a fixed value list is that you can't combine </em><br /> <em class="quotelev2">>> rendition styles. With the pointers (note the plural) method, I </em><br /> <em class="quotelev2">>> can have <rendition> elements defining italic, bold, underline, </em><br /> <em class="quotelev2">>> and center styles. If my source includes an element that is all </em><br /> <em class="quotelev2">>> of these, I can do rend="#i #b #u #center". With the fixed value </em><br /> <em class="quotelev2">>> list, I'd have to have an unwieldy number of values to accommodate </em><br /> <em class="quotelev2">>> all the combinations. </em><br /> <em class="quotelev2">>> </em><br /> <em class="quotelev1">> but the datatype of rend is "multiple tokens"[1], so you can say </em><br /> <em class="quotelev1">> rend="a b c" and each of a, b and </em><br /> <em class="quotelev1">> c will be checked against the list. honest. </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> </em><br /> <em class="quotelev1">> [1] <datatype maxOccurs="unbounded"> </em><br /> <em class="quotelev1">> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" </em><br /> <em class="quotelev1">> name="data.word"/> </em><br /> <em class="quotelev1">> </datatype> </em><br /> <em class="quotelev1">> </em><br /> Thanks for the clarification, Sebastian. I guess I was still thinking <br /> in terms of the more limited enumerated lists in DTDs which only <br /> allow one value. The value list approach provides better validation <br /> but still does not provide the benefit of linking to explicit and <br /> formally defined styles in the <rendition> element in the header, but <br /> I'm probably beating a horse (whether it's a dead horse or not <br /> remains to be seen :-). <br /> John <br /> _______________________________________________ <br /> tei-council mailing list <br /> tei-council_at_lists.<!--nospam-->village.Virginia.EDU <br /> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council <br /> <span id="received"><dfn>Received on</dfn> Wed May 16 2007 - 09:15:04 EDT</span> </div> From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:07:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:07:49 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> Message-ID: <464B0225.4080901@oucs.ox.ac.uk> <div class="mail"> <address class="headers"> <span id="from"> <dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk> </span><br /> <span id="date"><dfn>Date</dfn>: Wed, 16 May 2007 14:07:49 +0100</span><br /> </address> ok, here is the demonstration. This is the input file, with different <br /> rend values <br /> for <p> and <hi>: <br /> <TEI xmlns="http://www.tei-c.org/ns/1.0"> <br /> <teiHeader> <br /> <fileDesc> <br /> <titleStmt> <br /> <title>The title











hello


hello

and here is the ODD from which you can generate a schema to validate
the above. Note that I have changed the global rend attribute
to a fixed list, then overridden that for

.
I claim this is *better* than pointers, cos it is validated,
and you can do all the documentation in the ODD file
at the project level rather than the file level. The CSS could
be included in the ODD file and generated from there.
If anyone believes this is not conformant, I'll see you
outside the school gates later for a fight.

xmlns:rng="http://relaxng.org/ns/structure/1.0"
n="testrend">



TEI with rend setup
Sebastian Rahtz





authored from scratch






My schema to check rend values

Here is the introduction to your document


Here is the schema:


















-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 16 2007 - 09:16:02 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:20:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:20:42 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: Message-ID: <464B052A.5080109@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 16 May 2007 14:20:42 +0100
John A. Walsh wrote:
> Thanks for the clarification, Sebastian. I guess I was still thinking
> in terms of the more limited enumerated lists in DTDs which only allow
> one value.
ah well, a DTD will simply not do any data checking at all in this
situation. but who uses DTDs any more?
> The value list approach provides better validation but still does not
> provide the benefit of linking to explicit and formally defined styles
> in the element in the header
no, but it does provide a formal link to an element in the ODD, and can
argue that
is even better.
> , but I'm probably beating a horse (whether it's a dead horse or not
> remains to be seen :-).
>
Your horse can get up and run, it's a good horse. But I think my ODD
horse may at least
make a race of it.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 16 2007 - 09:20:46 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:23:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:23:10 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: Message-ID: <464B05BE.20802@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 16 May 2007 14:23:10 +0100
John A. Walsh wrote:
>
> I can do rend="#i #b #u #center"
Note that the schema will not stop you writing "#it" or just "it" here
by mistake.
You have to write your own validator for that.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 16 2007 - 09:23:13 EDT

From James.Cummings at computing-services.oxford.ac.uk Wed May 16 17:22:12 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 16 May 2007 17:22:12 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: Message-ID: <464B7604.1030102@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 16 May 2007 17:22:12 -0400
John A. Walsh wrote:
> On May 16, 2007, at 8:53 AM, Sebastian Rahtz wrote:
>> John A. Walsh wrote:
>>> The problem is with a fixed value list is that you can't combine
>>> rendition styles.
>> but the datatype of rend is "multiple tokens"[1], so you can say
>> rend="a b c" and each of a, b and
>> c will be checked against the list. honest.
> Thanks for the clarification, Sebastian.
> The value list approach provides better validation but still
> does not provide the benefit of linking to explicit and formally defined
> styles in the element in the header, but I'm probably
> beating a horse (whether it's a dead horse or not remains to be seen :-).
I still agree that there is a benefit of being able to point back to a
in the header to document it more fully than one does with an
attribute value. Yes, I like the validation that a closed value list provides,
and I think I'd seriously recommend that approach for most uses, but being able
to point to a place in the header which has even a prose description is in many
ways much more powerful. Because doing rend="bigWobbly" where I define that by
a paragraph in my ODD necessitates the ODD to accompany the instance (not a bad
thing!), but point to a element in the header where I have a
paragraph describing it means my document instance stands on its own in terms of
documenting the meaning of the values it contains.
Is there an easy clear way to have something be multiple tokens and/or multiple
pointers? Or is that just getting icky?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 16 2007 - 17:22:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 17:28:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 22:28:29 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464B7604.1030102@computing-services.oxford.ac.uk> Message-ID: <464B777D.7000304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 16 May 2007 22:28:29 +0100
James Cummings wrote:
> Because doing rend="bigWobbly" where I define that by a paragraph in
> my ODD necessitates the ODD to accompany the instance (not a bad
> thing!), but point to a element in the header where I have
> a paragraph describing it means my document instance stands on its own
> in terms of documenting the meaning of the values it contains.
true. but why single out this one element for documentation of attribute
values in the header? you
could say the same about @type
>
> Is there an easy clear way to have something be multiple tokens and/or
> multiple pointers? Or is that just getting icky?
you cant distinguish. rend="big" could mean either.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 16 2007 - 17:28:34 EDT

From conal.tuohy at vuw.ac.nz Wed May 16 21:14:32 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 17 May 2007 13:14:32 +1200 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464B777D.7000304@oucs.ox.ac.uk> Message-ID: <1179364472.3735.7.camel@localhost>
From: Conal Tuohy
Date: Thu, 17 May 2007 13:14:32 +1200
On Wed, 2007-05-16 at 22:28 +0100, Sebastian Rahtz wrote:
> James Cummings wrote:
> > Because doing rend="bigWobbly" where I define that by a paragraph in
> > my ODD necessitates the ODD to accompany the instance (not a bad
> > thing!), but point to a element in the header where I have
> > a paragraph describing it means my document instance stands on its own
> > in terms of documenting the meaning of the values it contains.
> true. but why single out this one element for documentation of attribute
> values in the header? you
> could say the same about @type
I think the main advantage of this would be when using a common
rendition language (i.e. CSS), which opens up the prospect of automated
rendering of diverse instance docs, with rendition. Clearly, the same
doesn't apply to @type.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed May 16 2007 - 21:18:03 EDT
From lou.burnard at computing-services.oxford.ac.uk Sat May 19 14:09:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 19 May 2007 19:09:42 +0100 Subject: [tei-council] witList/Group query Message-ID: <464F3D66.10301@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 19 May 2007 19:09:42 +0100
TRAC ticket 332 states gnomically "change witList to witGroup, allow it
to self-nest, and drop @included."
I'm just about to make the recommended changes but would like to check
that Council's recommendation was made in full understanding of the
implication that a given witness can only appear in one witGroup (or
witList). Certainly makes things simpler and clearer, but does it
correspond with reality? Do textual critix never talk about overlapping
groups of witnesses, or witnesses which appear in more than one group?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat May 19 2007 - 14:11:21 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sat May 19 17:03:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 19 May 2007 22:03:21 +0100 Subject: [tei-council] cleaning up after your easter egg Message-ID: <464F6619.7080701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 19 May 2007 22:03:21 +0100
Could I beg you all to look again at the list at
http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=First+pass+technical+chapter+review
What I need for each ticket is one of the following:
* confirmation that what you wanted done has been implemented (you can
check at
http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml)
* a note that the necessary actions are visible in
http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=Actions+from+chapter+review
and thus the easter ticket can be closed
* a promise that the necessary changes have been fully reported to Lou
or Syd,
and that you are on the case of badgering to see that they get done
wouldn't it be great to get all these tickets closed in the next week?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat May 19 2007 - 17:03:25 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun May 20 16:00:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 20 May 2007 21:00:59 +0100 Subject: [tei-council] the "key" attribute Message-ID: <4650A8FB.3050301@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 20 May 2007 21:00:59 +0100
I have raised this before, but it did not not stimulate any response, so
I am bringing it up again, with the reiteration that it a _mess_.
The key attribute is used in two situations:
1. on elements moduleRef, memberOf and specDesc to point to objects in
the TEI universe
which are identifiable by having @ident. It's like the old ID/IDREF pairing.
2. on elements like persName (all the things to do with naming people
and places)
to point to the canonical object. Unfortunately, our examples use it in
two different
ways
2a. as a URI pointer eg
2b as a database lookup somewhere eg
o that's three distinct data types used on one attribute,
differering in our examples even on the same element!
What are the choices?
1. shrug our shoulders and say "bof, compared to the loss of Mourinho's
dog it ees a nothing".
2. regularize all uses of @key to be URIs (screws up royally)

3. regularize all uses of @key to be database pointers, undefined
(loses chance to use external URLs)
4. replace @key with @target in all the naming contexts
5a. allow both @key and @target on all naming objects (5b. making them
mutually exclusive)
I can live with 4, 5a or 5b. What say the rest of you?
I think it is very important that we decide this before the meeting at
month's
end to finish places, as it is intimately caught up with all that
persons/places stuff.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun May 20 2007 - 16:01:02 EDT
From lou.burnard at computing-services.oxford.ac.uk Sun May 20 16:07:04 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 20 May 2007 21:07:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650A8FB.3050301@oucs.ox.ac.uk> Message-ID: <4650AA68.1060000@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 20 May 2007 21:07:04 +0100
Sebastian Rahtz wrote:
> I have raised this before, but it did not not stimulate any response, so
> I am bringing it up again, with the reiteration that it a _mess_.
>
> The key attribute is used in two situations:
>
> 1. on elements moduleRef, memberOf and specDesc to point to objects
> in the TEI universe
> which are identifiable by having @ident. It's like the old ID/IDREF
> pairing.
>
> 2. on elements like persName (all the things to do with naming people
> and places)
> to point to the canonical object. Unfortunately, our examples use it
> in two different
> ways
> 2a. as a URI pointer eg
> 2b as a database lookup somewhere eg
> key="ThorJon08">
>
> so that's three distinct data types used on one attribute,
> differering in our examples even on the same element!
>
> What are the choices?
>
> 1. shrug our shoulders and say "bof, compared to the loss of
> Mourinho's dog it ees a nothing".
>
> 2. regularize all uses of @key to be URIs (screws up royally)
>
> 3. regularize all uses of @key to be database pointers, undefined
> (loses chance to use external URLs)
>
> 4. replace @key with @target in all the naming contexts
>
> 5a. allow both @key and @target on all naming objects (5b. making them
> mutually exclusive)
>
> I can live with 4, 5a or 5b. What say the rest of you?
>
> I think it is very important that we decide this before the meeting at
> month's
> end to finish places, as it is intimately caught up with all that
> persons/places stuff.
>
In order of decreasing preference:
4
5b
5a
I agree with Sebastian that we *must* do something about this. I think 4
would be the least painful option, but like him can live with either of
the 5s. Neither 1 nor 2 is acceptable. 3 would only be an option if we
were also willing to revise all the , like things to use
@ident rather than xml:id.


_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun May 20 2007 - 16:08:51 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun May 20 16:22:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 20 May 2007 21:22:46 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650AA68.1060000@computing-services.oxford.ac.uk> Message-ID: <4650AE16.7010602@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 20 May 2007 21:22:46 +0100
Lou Burnard wrote:
> e. 3 would only be an option if we were also willing to revise all the
> , like things to use @ident rather than xml:id.
Which would be OK, if we accepted the limitation that the records would
have to be in the
same XML document. For this sort of work, pointing to an external
document seems like
a good and powerful facility. But its a possibility.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun May 20 2007 - 16:22:50 EDT
From daniel.odonnell at uleth.ca Sun May 20 20:45:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 20 May 2007 18:45:33 -0600 Subject: [tei-council] witList/Group query In-Reply-To: <464F3D66.10301@computing-services.oxford.ac.uk> Message-ID: <1179708333.7616.5.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 20 May 2007 18:45:33 -0600
On Sat, 2007-05-19 at 19:09 +0100, Lou Burnard wrote:
> TRAC ticket 332 states gnomically "change witList to witGroup, allow it
> to self-nest, and drop @included."
>
> I'm just about to make the recommended changes but would like to check
> that Council's recommendation was made in full understanding of the
> implication that a given witness can only appear in one witGroup (or
> witList). Certainly makes things simpler and clearer, but does it
> correspond with reality? Do textual critix never talk about overlapping
> groups of witnesses, or witnesses which appear in more than one group?
Because witgroup overlaps, you can have subdivisions--I.e. I can be in a
group within a group. So a witness can still be in a larger group as
well as its own group.
The main thing here, as I remember, was to avoid the situation where you
end up with the following:
wit a
wit b
wit c
wit sigma (consensus of a,b,c)
this should now be:
witgroup/sigma|witgroup/wit a|wit b|wit c
You could get more complicated, of course and have things like
witgroup/sigma|witgroup/wit a|witgroup/wit b|wit c
-d
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun May 20 2007 - 20:46:42 EDT
From Syd_Bauman at Brown.edu Sun May 20 22:53:12 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 20 May 2007 22:53:12 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4650AE16.7010602@oucs.ox.ac.uk> Message-ID: <18001.2456.218488.358701@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 20 May 2007 22:53:12 -0400
The problem (ti seems to me) was caused when we overloaded the
semantics of the attribute name "key=" when son of ODD was born. I'm
inclined to say the best way to fix it is to fix the original error,
and rename the attribute used by et al.
That is, there are three kinds of semantics:
* I am a pointer, and point to a digital resource via a URI
* I am a pointer, and point to an element inside this current
document by matching the value of its (possibly non-unique) ident=
attribute
* I am a key into a database
In cases where there are no special semantics (like next= and prev=)
we use target= for the first, and key= for both the second and third.
I think we need separate names for the 2nd and 3rd. My conservative
instinct was to leave the P4 use for names as key= and change the
name used by ODD elements. But in fact, since we are permitted to
"break" existing documents, and it is just another template in the
transformation from P4 to P5, there really isn't any strong reason not
to use key= for the ODD elements and make up a new name for the
database looker-upper attribute for names.

While I'd be fine with adding a new attribute in the naming contexts
that is explicitly a URI reference to the regularization or
disambiguation information, I would be very hesitant to completely
remove key= and thus the capability to refer to databases that are
not addressable via URI. (As I said above, I have no problem renaming
it; nor do I currently have any opinion on whether if there are two
attributes, one for database record identification and one for a URI,
they should be mutually exclusive or not.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun May 20 2007 - 22:53:16 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon May 21 01:58:59 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 06:58:59 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650A8FB.3050301@oucs.ox.ac.uk> Message-ID: <46513523.8060007@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 21 May 2007 06:58:59 +0100
Sebastian Rahtz wrote:
> 5a. allow both @key and @target on all naming objects (5b. making them
> mutually exclusive)
I'd vote for 5a or if others feel strongly that they should be exclusive 5b. I
don't feel strongly about the need for mutual exclusivity and think that the two
attributes have (slightly) different meanings. I feel memberOf should be using
@target.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 01:59:06 EDT
From cwittern at gmail.com Mon May 21 03:02:13 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 21 May 2007 16:02:13 +0900 Subject: [tei-council] the "key" attribute In-Reply-To: <18001.2456.218488.358701@emt.wwp.brown.edu> Message-ID: <465143F5.5080100@gmail.com>
From: Wittern Christian
Date: Mon, 21 May 2007 16:02:13 +0900
Syd Bauman wrote:
> The problem (ti seems to me) was caused when we overloaded the
> semantics of the attribute name "key=" when son of ODD was born. I'm
> inclined to say the best way to fix it is to fix the original error,
> and rename the attribute used by et al.
>
>
Well, I am with Syd here, why don't we change @key on the
stuff (pointing to @ident) and leave key as it is, with its double face
as either URL or database key. For the name for the new attribute, I
have no preferences, but @target seems to suggest a @xml:id at the other
end in most cases, so I think we should rather use something else.
Christian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 21 2007 - 03:03:30 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 03:46:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 08:46:18 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18001.2456.218488.358701@emt.wwp.brown.edu> Message-ID: <46514E4A.1020605@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 08:46:18 +0100
Syd Bauman wrote:
> While I'd be fine with adding a new attribute in the naming contexts
> that is explicitly a URI reference to the regularization or
> disambiguation information, I would be very hesitant to completely
> remove key= and thus the capability to refer to databases that are
> not addressable via URI.
so this is possibly
6a. allow any (but only one) of @target, @key and @lookup on the
object elements
or, more likely,
6b. allow either (but only one) @target or @lookup on the
object elements
You may well be right, though, that we should take @key away from
specDesc, memberOf
and moduleRef and give them @teiKey instead. It would be a pain, because
people
_have_ been using Odds and have their customization files, and I'd have
an unpleasant
evening scouring ODD software for @key; but it is doable, and we could
justify it to the
world.
in which case, I'd be happy with
7. give the TEI ODD elements a new @teiKey, and allow the object elements
a choice of @key or @target. @key keeps its vague semantics of "a
database lookup
key"
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 03:46:21 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:25:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:25:58 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46513523.8060007@computing-services.oxford.ac.uk> Message-ID: <46515796.3030805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 09:25:58 +0100
James Cummings wrote:
> I feel memberOf should be using @target.
butthat's tricky. your ODD file says .
You can't change that to ,
as "att.naming" is not in the current document (and by the way does
not have an xml:id of "att.naming"...), but neither is it a web
resource. You'd
have to say
target="http://www.tei-c.org/release/xml/tei/odd/Source/Guidelines/en/guidelines-xml.xml#core"/>
which would
- be a mess
- preclude you working offline
- stop you transparently switching to French
- make a big hole in Roma (mendable, but big)
pecDesc more arguably could use target (though we'd have to change all
the IDs)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 04:26:01 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:27:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:27:20 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465143F5.5080100@gmail.com> Message-ID: <465157E8.2080009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 09:27:20 +0100
Wittern Christian wrote:
> leave key as it is, with its double face as either URL or database key.
urely this is evil. as a processor, if I meet , how
do I what to do with it?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 04:27:24 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:28:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:28:43 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515796.3030805@oucs.ox.ac.uk> Message-ID: <4651583B.3070208@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 09:28:43 +0100
Sebastian Rahtz wrote:
> You'd
> have to say
>
>
> target="http://www.tei-c.org/release/xml/tei/odd/Source/Guidelines/en/guidelines-xml.xml#core"/>
>
>
sorry, switched context half-way; for "-xml.xml#core" read ".xml#att.naming"
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 04:28:45 EDT
From James.Cummings at computing-services.oxford.ac.uk Mon May 21 04:57:17 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 09:57:17 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515796.3030805@oucs.ox.ac.uk> Message-ID: <46515EED.5060709@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 21 May 2007 09:57:17 +0100
Hrmmm, you are right, I hadn't thought through the implications. So the
attribute used on memberOf should be 'key' or something similar (though I
don't like 'teikey'). In most other cases does having a choice of target
or key make sense? What's the logic of making them mutually exclusive? My
original thought with regard to allowing @target on memberOf (and similar)
was that it might help with (possibly non-TEI) ODDs that incorporate bits
and pieces from other standards.
-James
Sebastian Rahtz wrote:
> James Cummings wrote:
>> I feel memberOf should be using @target.
> butthat's tricky. your ODD file says .
> You can't change that to ,
> as "att.naming" is not in the current document (and by the way does
> not have an xml:id of "att.naming"...), but neither is it a web
> resource. You'd
> have to say
>
>
> target="http://www.tei-c.org/release/xml/tei/odd/Source/Guidelines/en/guidelines-xml.xml#core"/>
>
>
> which would
>
> - be a mess
> - preclude you working offline
> - stop you transparently switching to French
> - make a big hole in Roma (mendable, but big)
>
> specDesc more arguably could use target (though we'd have to change all
> the IDs)
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 04:57:20 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 05:05:40 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 10:05:40 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515EED.5060709@computing-services.oxford.ac.uk> Message-ID: <465160E4.2040705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 10:05:40 +0100
James Cummings wrote:
> In most other cases does having a choice of target
> or key make sense? What's the logic of making them mutually exclusive?
to assist processors. If I see both, which do I operate on?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 05:05:45 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon May 21 05:36:15 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 10:36:15 +0100 Subject: [tei-council] witList/Group query In-Reply-To: <1179708333.7616.5.camel@localhost> Message-ID: <4651680F.9040301@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 21 May 2007 10:36:15 +0100
Thanks Daniel, but this does not address the question. By "overlapping"
I did not mean "containing". Let me rephrase the question: if to witness
A is allocated to witGroup sigma, does that always preclude it
simultaneously being allocated to witGroup delta? I have modified the
text on the assumption that it does, but would just like to check that
that is indeed the case. (The former state of affairs, using the
attribute @included, did not enforce such a rule, of course)
More significantly, looking at this again, I really want to know why we
need this element at all. Why isn't it a (possibly
abbreviated) ?

Daniel O'Donnell wrote:
> On Sat, 2007-05-19 at 19:09 +0100, Lou Burnard wrote:
>> TRAC ticket 332 states gnomically "change witList to witGroup, allow it
>> to self-nest, and drop @included."
>>
>> I'm just about to make the recommended changes but would like to check
>> that Council's recommendation was made in full understanding of the
>> implication that a given witness can only appear in one witGroup (or
>> witList). Certainly makes things simpler and clearer, but does it
>> correspond with reality? Do textual critix never talk about overlapping
>> groups of witnesses, or witnesses which appear in more than one group?
>
> Because witgroup overlaps, you can have subdivisions--I.e. I can be in a
> group within a group. So a witness can still be in a larger group as
> well as its own group.
>
> The main thing here, as I remember, was to avoid the situation where you
> end up with the following:
>
> wit a
> wit b
> wit c
> wit sigma (consensus of a,b,c)
>
> this should now be:
>
> witgroup/sigma|witgroup/wit a|wit b|wit c
>
> You could get more complicated, of course and have things like
>
> witgroup/sigma|witgroup/wit a|witgroup/wit b|wit c
>
> -d
>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 21 2007 - 05:40:18 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon May 21 06:47:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 11:47:21 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465160E4.2040705@oucs.ox.ac.uk> Message-ID: <465178B9.8030601@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 21 May 2007 11:47:21 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
>> In most other cases does having a choice of target
>> or key make sense? What's the logic of making them mutually exclusive?
> to assist processors. If I see both, which do I operate on?
Whichever you know how to handle? I view them sort of as different things.
To me @key gives a record that can (if understood) be used to provide more
information about the element content, whereas @target provides a reference
to something. i.e. the first is a key for metadata, while the second is
more a form of transclusion and/or citation. But, thinking about it, maybe
that isn't really much of a distinction.
Are you proposing that anywhere that @target exists, this could be replaced
by a mutually exclusive @key? i.e. ref ?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 06:47:26 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 06:52:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 11:52:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465178B9.8030601@computing-services.oxford.ac.uk> Message-ID: <465179D4.2030709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 11:52:04 +0100
James Cummings wrote:
> Whichever you know how to handle? I view them sort of as different things.
> To me @key gives a record that can (if understood) be used to provide more
> information about the element content, whereas @target provides a reference
> to something. i.e. the first is a key for metadata, while the second is
> more a form of transclusion and/or citation. But, thinking about it, maybe
> that isn't really much of a distinction.
>
I can see the argument for allowing both, yes. But on the whole
I think it gives an irritating possibility of confusion without buying
a huge amount. I'd put my money on "just switch object elements to use
@target" if I had to choose.
> Are you proposing that anywhere that @target exists, this could be replaced
> by a mutually exclusive @key? i.e. ref ?
>
No, I was not; but that would not be an impossible argument
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 06:52:06 EDT
From James.Cummings at computing-services.oxford.ac.uk Mon May 21 07:02:22 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 12:02:22 +0100 Subject: [tei-council] witList/Group query In-Reply-To: <4651680F.9040301@oucs.ox.ac.uk> Message-ID: <46517C3E.60703@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 21 May 2007 12:02:22 +0100
Lou Burnard wrote:
> Thanks Daniel, but this does not address the question. By "overlapping"
> I did not mean "containing". Let me rephrase the question: if to witness
> A is allocated to witGroup sigma, does that always preclude it
> simultaneously being allocated to witGroup delta? I have modified the
> text on the assumption that it does, but would just like to check that
> that is indeed the case. (The former state of affairs, using the
> attribute @included, did not enforce such a rule, of course)
I'm not sure, I suppose it makes sense that at any one time a witness is
part of a particular witGroup and that precludes it being part of any other
(non-ancestor) witGroup. But I'm not confident enough in that to say that
it always precludes it. I view these groupings as possibly very fluid and
dependent on future analysis of the apparatus in the document instance.
> More significantly, looking at this again, I really want to know why we
> need this element at all. Why isn't it a (possibly
> abbreviated) ?
That is the problem, I believe that Dot and I had with Gautier's proposed
revisions, most of what he wanted to do, I believe, could be done in an
msDesc. But, the short answer being, I suppose, that msDesc is for
manuscripts, and not all witnesses are manuscripts. Thus, some people
might feel it is semantically inaccurate to use msDesc for other
text-bearing objects which witness the same text as some manuscripts.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 07:02:26 EDT
From mjd at hum.ku.dk Mon May 21 10:21:47 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 21 May 2007 16:21:47 +0200 Subject: [tei-council] witList/Group query In-Reply-To: <[tei-council] witList/Group query> Message-ID: <5FA95E40EE2AD51190380090272724BB0F7F254A@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Mon, 21 May 2007 16:21:47 +0200
Dot and you and Matthew. We discussed this in Berlin, I remember, although I
can't now remember what we decided (apart from changing witList to
witGroup). It seems clear enough, though, that witness is essentially a
pared down msDesc, with only those subelements necessary for describing
manuscripts in a specific context or perhaps rather a specific role, as text
witnesses. My feeling is still that as such it's not necessary.
Whether msDesc can be used for TBOs other than manuscripts is obviously a
much larger issue.
But as regards your question, Lou, I think James's answer, that a witness is
only likely to be part of a single witGroup AT ANY ONE TIME is the right
one. Nesting should be able to take of any overlaps.
Matthew
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU
[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of James
Cummings
Sent: Monday, May 21, 2007 1:02 PM
To: Lou Burnard
Cc: TEI Council
Subject: Re: [tei-council] witList/Group query
Lou Burnard wrote:
> Thanks Daniel, but this does not address the question. By "overlapping"
> I did not mean "containing". Let me rephrase the question: if to witness
> A is allocated to witGroup sigma, does that always preclude it
> simultaneously being allocated to witGroup delta? I have modified the
> text on the assumption that it does, but would just like to check that
> that is indeed the case. (The former state of affairs, using the
> attribute @included, did not enforce such a rule, of course)
I'm not sure, I suppose it makes sense that at any one time a witness is
part of a particular witGroup and that precludes it being part of any other
(non-ancestor) witGroup. But I'm not confident enough in that to say that
it always precludes it. I view these groupings as possibly very fluid and
dependent on future analysis of the apparatus in the document instance.
> More significantly, looking at this again, I really want to know why we
> need this element at all. Why isn't it a (possibly
> abbreviated) ?
That is the problem, I believe that Dot and I had with Gautier's proposed
revisions, most of what he wanted to do, I believe, could be done in an
msDesc. But, the short answer being, I suppose, that msDesc is for
manuscripts, and not all witnesses are manuscripts. Thus, some people
might feel it is semantically inaccurate to use msDesc for other
text-bearing objects which witness the same text as some manuscripts.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 10:21:57 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon May 21 11:56:32 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 16:56:32 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465179D4.2030709@oucs.ox.ac.uk> Message-ID: <4651C130.6090509@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 21 May 2007 16:56:32 +0100
How do we feel about pos tagging? At present the Guiidelines say you
have to do things like
bum
and point off stage to some definition for noun (an or a
or something).
But why shouldn't I do
bum
meaning "Everyone knows what a NOUN is, but if you insist on finding out
use this magic string 'NOUN' and some mechanism external to this
document will enlighten you"

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 21 2007 - 12:00:34 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 16:58:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 21:58:10 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4651C130.6090509@oucs.ox.ac.uk> Message-ID: <465207E2.5010106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 21:58:10 +0100
Lou Burnard wrote:
> How do we feel about pos tagging? At present the Guiidelines say you
> have to do things like
> bum
>
> and point off stage to some definition for noun (an or a
> or something).
>
> But why shouldn't I do
>
> bum
>
> meaning "Everyone knows what a NOUN is, but if you insist on finding
> out use this magic string 'NOUN' and some mechanism external to this
> document will enlighten you"
If Boney is right, I assume your example
should be by
the same argument.
It is a slippery (and seductive) slope if we appear to let ID/IDREF back
in, which is what
will happen if we allow key="NOUN", cos people will use it to point to
that ,
instead of "the universe".
I am fairly sure we should switch all the @keys on objects to @target
forthwith,
and then consider separately whether to allow @key back in.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 16:58:13 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon May 21 17:35:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 22:35:06 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465207E2.5010106@oucs.ox.ac.uk> Message-ID: <4652108A.7040200@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 21 May 2007 22:35:06 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> How do we feel about pos tagging? At present the Guiidelines say you
>> have to do things like
>> bum
>>
>> and point off stage to some definition for noun (an or a
>> or something).
>>
>> But why shouldn't I do
>>
>> bum
>>
>> meaning "Everyone knows what a NOUN is, but if you insist on finding
>> out use this magic string 'NOUN' and some mechanism external to this
>> document will enlighten you"
> If Boney is right, I assume your
> example should be by
> the same argument.
Well, @ana is defined for this very purpose, so no, I wouldn't use @target.
>
> It is a slippery (and seductive) slope if we appear to let ID/IDREF
> back in, which is what
> will happen if we allow key="NOUN", cos people will use it to point to
> that ,
> instead of "the universe".
>
But that's Wrong. If you want to point to the you need a
pointer, not a key.
> I am fairly sure we should switch all the @keys on objects to @target
> forthwith,
> and then consider separately whether to allow @key back in.
>
I'm happy with turning all the @keys on ect
into @target s (or @ana, or @ref)
Actually @ref might be clearer. It's what we use for , which is very
similar.
I have no problem leaving @key in places where it's clear that a URI
won't fit, i.e. where you might need to do some more processing to turn
the @key value into what you want. But I don't see why
might not fall into that category.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 21 2007 - 17:37:05 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 17:46:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 22:46:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4652108A.7040200@computing-services.oxford.ac.uk> Message-ID: <4652131C.4010702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 21 May 2007 22:46:04 +0100
Lou Burnard wrote:
> I'm happy with turning all the @keys on ect
> into @target s (or @ana, or @ref)
> Actually @ref might be clearer. It's what we use for , which is
> very similar.
sure, no disagreement with @ref instead of @target.
>
> I have no problem leaving @key in places where it's clear that a URI
> won't fit, i.e. where you might need to do some more processing to
> turn the @key value into what you want.
like on memberOf, you mean?
hould @key stay on some object things? I find



lightly weird. I'd rather have that as



personally. its more like your POS stuff, no?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 21 2007 - 17:46:08 EDT
From Syd_Bauman at Brown.edu Mon May 21 22:52:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 21 May 2007 22:52:55 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4652131C.4010702@oucs.ox.ac.uk> Message-ID: <18002.23303.258022.297312@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 21 May 2007 22:52:55 -0400
I'm sorry, it is likely I have not been able to follow the
conversation well enough from here, but could you define what an
"object thing" is?
While I actually prefer to add a URI attribute that is probably
mutually exclusive with key= (whether renamed or not) to the naming
elements rather than overload key= with "either a URI or a database
thingy", I think Sebastian's argument does not hold much water ...
asking the qustion "If I'm trying to process this, and I come across
a key=, what should I do?" is a bit silly. If you haven't read the
local documentation on how key= is used, you have to ignore it
whether it's a URI or not. And every project is going to use the
non-URI keys differently. So this is not a place where
interoperability concerns come into play.
But again, I still think it's probably better to separate these
things.
I also still think key= of , , et al. should
remain a "match the ident=" attribute, but should undergo a name
change. I'm also still happy to consider leaving its name key=, and
coming up with a better name for the use for naming elements.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 21 2007 - 22:52:59 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 05:07:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 10:07:56 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18002.23303.258022.297312@emt.wwp.brown.edu> Message-ID: <4652B2EC.1070907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 22 May 2007 10:07:56 +0100
Syd Bauman wrote:
> I'm sorry, it is likely I have not been able to follow the
> conversation well enough from here, but could you define what an
> "object thing" is?
>
all the things which are members of att.naming
> And every project is going to use the
> non-URI keys differently. So this is not a place where
> interoperability concerns come into play.
>
ok, fair enough; we could allow both
> I also still think key= of , , et al. should
> remain a "match the ident=" attribute, but should undergo a name
> change. I'm also still happy to consider leaving its name key=, and
> coming up with a better name for the use for naming elements.
>
OK, how about we do this:
- leave @key on etc as is
- change att.naming to remove @key and put in @ref as pointer instead
- discuss at places meeting next week whether they need the @key
functionality back,
and if so ask them to choose a name
Matthew, are you awake? do you have a view on this, as a big proponent
of keys on naming objects?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue May 22 2007 - 05:07:59 EDT
From mjd at hum.ku.dk Tue May 22 07:50:02 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Tue, 22 May 2007 13:50:02 +0200 Subject: [tei-council] the "key" attribute In-Reply-To: <[tei-council] the "key" attribute> Message-ID: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Tue, 22 May 2007 13:50:02 +0200
Yes, quite awake, but up to my oxters in work (by which I mean what I'm
actually paid to do). Still, I've been following this debate very closely,
for the reason you indicate, viz. that this issue is of such importance to
all this name stuff. Unfortunately, but not for the first time, I'm not sure
I understand the technical issues sufficiently to try and voice an opinion.
It would be helpful if I had a clearer idea of the difference between key,
ana and target (and ref), all of which seem to do similar, but subtly
different, things. It's the "subtly different" bit that gets me.
key "provides a means of locating a full definition for the entity being
named such as a database record key or a URI"
ana "indicates one or more elements containing interpretations of the
element on which the ana attribute appears"
target "specifies the destination of the reference by supplying one or more
URI References"
ref "points to a description of the character or glyph intended"
The first of these is datatype data.key ("defines the range of attribute
values expressing a coded value by means of an arbitrary identifier,
typically taken from a set of externally-defined possibilities=), while the
last 3 are data.pointer ("defines the range of attribute values used to
provide a single pointer to any other resource, either within the current
document or elsewhere").
Anybody want to try to explain to me wherein the subtle difference lies?
Matthew

-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU
[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of
Sebastian Rahtz
Sent: Tuesday, May 22, 2007 11:08 AM
To: Syd_Bauman_at_Brown.edu
Cc: TEI Council
Subject: Re: [tei-council] the "key" attribute
Syd Bauman wrote:
> I'm sorry, it is likely I have not been able to follow the
> conversation well enough from here, but could you define what an
> "object thing" is?
>
all the things which are members of att.naming
> And every project is going to use the
> non-URI keys differently. So this is not a place where
> interoperability concerns come into play.
>
ok, fair enough; we could allow both
> I also still think key= of , , et al. should
> remain a "match the ident=" attribute, but should undergo a name
> change. I'm also still happy to consider leaving its name key=, and
> coming up with a better name for the use for naming elements.
>
OK, how about we do this:
- leave @key on etc as is
- change att.naming to remove @key and put in @ref as pointer instead
- discuss at places meeting next week whether they need the @key
functionality back,
and if so ask them to choose a name
Matthew, are you awake? do you have a view on this, as a big proponent
of keys on naming objects?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue May 22 2007 - 07:50:30 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 09:14:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 14:14:03 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> Message-ID: <4652EC9B.8030904@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 22 May 2007 14:14:03 +0100
Matthew James Driscoll wrote:
> It would be helpful if I had a clearer idea of the difference between key,
> ana and target (and ref), all of which seem to do similar, but subtly
> different, things. It's the "subtly different" bit that gets me.
>
> key "provides a means of locating a full definition for the entity being
> named such as a database record key or a URI" ]
>
no, scrub that "or a URI" bit. It can't work.
> ana "indicates one or more elements containing interpretations of the
> element on which the ana attribute appears"
>
> target "specifies the destination of the reference by supplying one or more
> URI References"
>
> ref "points to a description of the character or glyph intended"
>
these are three different semantics for the same action,
pointing at something by an explicit route
("http://www.example.com/person#OF08").Using the
data.key method points at things by an implicit route
("you know what I mean by HOF08")
> Anybody want to try to explain to me wherein the subtle difference lies?
>
whether you want explicit routing to the resource
by means of a URI, or just a system-specific token
which will help you find it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue May 22 2007 - 09:14:06 EDT
From conal.tuohy at vuw.ac.nz Tue May 22 17:34:38 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 23 May 2007 09:34:38 +1200 Subject: [tei-council] the "key" attribute In-Reply-To: <4652EC9B.8030904@oucs.ox.ac.uk> Message-ID: <1179869678.6486.18.camel@localhost>
From: Conal Tuohy
Date: Wed, 23 May 2007 09:34:38 +1200
On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote:
> Matthew James Driscoll wrote:
> > It would be helpful if I had a clearer idea of the difference between key,
> > ana and target (and ref), all of which seem to do similar, but subtly
> > different, things. It's the "subtly different" bit that gets me.
> >
> > key "provides a means of locating a full definition for the entity being
> > named such as a database record key or a URI" ]
> >
> no, scrub that "or a URI" bit. It can't work.
Can you explain why? Do you mean because of your earlier point that
there's no failsafe way to determine whether a @key is intended to
represent a db record key on the one hand, or a URI on the other?
I have to say I am very much a fan of @key as a URI (and of URIs as a
preferred reference mechanism is general).
If the problem with "or a URI" is as I supposed, another approach would
be to require that @key always contains a URI, and recommend to encoders
who wish to encode a locally-defined database record key that they
encode the record key, slightly more verbosely, in some kind of URI
syntax.

Conal
The @key above is actually a key in a database here at work. There are
several usable http URLs I could construct from it, e.g.:
key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal
Without using http or another resolution protocol, the key could still
be encoded in URI syntax using the "tag" URI scheme:

Conal

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue May 22 2007 - 17:38:47 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 17:55:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 22:55:53 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1179869678.6486.18.camel@localhost> Message-ID: <465366E9.4000508@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 22 May 2007 22:55:53 +0100
Conal Tuohy wrote:
> Can you explain why? Do you mean because of your earlier point that
> there's no failsafe way to determine whether a @key is intended to
> represent a db record key on the one hand, or a URI on the other?
>
yes. what does mean?
> If the problem with "or a URI" is as I supposed, another approach would
> be to require that @key always contains a URI
thats fine, but then we have two elements with the same "key" attribute,
but different datatypes. this just seems wrong.
> Without using http or another resolution protocol, the key could still
> be encoded in URI syntax using the "tag" URI scheme:
>
>
> Conal
>
>
thats an interesting idea. bit verbose, tho?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue May 22 2007 - 17:55:58 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue May 22 17:57:50 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 22 May 2007 22:57:50 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1179869678.6486.18.camel@localhost> Message-ID: <4653675E.6000305@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 22 May 2007 22:57:50 +0100
I wondered about this, even as I made the changes proposed. It's clear
that there is going to be some overlap: if for example my special
database actually provides a web front end, then I might be able to
access it either by means of the (magic) key "blort", or by means of a
URI such as "http://mySpecialDatabase/frontEnd?key=blort"
But I don't think this affects the issue. The idea is that there are two
ways of finding something:
(a) you point at it with a URI.
(b) you do it some other way
In the latter case, the value supplied in your document is a magic
token. We make no assumptions about how you will use that magic token to
find the thing you're looking for: that's up to you. You might look it
up in a database, you might stick some extra stuff on the front and turn
it into a URL, you might attach it to a carrier pigeon.
There are probably only a few cases where (b) is the best way of doing
things, but they do exist: the way we hook modules and elements into a
TEI schema spec is one -- we supply an identifier (the magic token) and
the Odd processor Does The Right Thing with it. Another case might be
where everybody *just knows* what you mean by a given code -- say, for
example, identifying the books of the Bible. You don't want to have to
spell out in every single Biblical commentary you encode that "Gen"
means "Genesis", etc. You just want to say "Gen". Yes, of course it's
better to spell things like that out. But there are limits to people's
willingness to be explicit!
The proposal (now implemented) is to reserve @key, with datatype
data.key, for that latter usage.
Case (a), using a URI, is of course far and away the better solution for
the vast majority of practical usages. The attribute name in this case
varies, depending on the semantics: so we have @ref, @target, @ana,
@corresp, inter alia.

Conal Tuohy wrote:
> On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote:
>
>> Matthew James Driscoll wrote:
>>
>>> It would be helpful if I had a clearer idea of the difference between key,
>>> ana and target (and ref), all of which seem to do similar, but subtly
>>> different, things. It's the "subtly different" bit that gets me.
>>>
>>> key "provides a means of locating a full definition for the entity being
>>> named such as a database record key or a URI" ]
>>>
>>>
>> no, scrub that "or a URI" bit. It can't work.
>>
>
> Can you explain why? Do you mean because of your earlier point that
> there's no failsafe way to determine whether a @key is intended to
> represent a db record key on the one hand, or a URI on the other?
>
> I have to say I am very much a fan of @key as a URI (and of URIs as a
> preferred reference mechanism is general).
>
> If the problem with "or a URI" is as I supposed, another approach would
> be to require that @key always contains a URI, and recommend to encoders
> who wish to encode a locally-defined database record key that they
> encode the record key, slightly more verbosely, in some kind of URI
> syntax.
>
>
> Conal
>
> The @key above is actually a key in a database here at work. There are
> several usable http URLs I could construct from it, e.g.:
>
>
> key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal
>
> Without using http or another resolution protocol, the key could still
> be encoded in URI syntax using the "tag" URI scheme:
>
>
> Conal
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue May 22 2007 - 17:59:58 EDT

From Syd_Bauman at Brown.edu Tue May 22 23:00:32 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 22 May 2007 23:00:32 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4653675E.6000305@computing-services.oxford.ac.uk> Message-ID: <18003.44624.650363.406838@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 22 May 2007 23:00:32 -0400
SR> all the things which are members of att.naming
Thank you.

SR> OK, how about we do this:
SR> - leave @key on etc as is
ure

SR> - change att.naming to remove @key and put in @ref as pointer
SR> instead
I am not in favor. I don't mind renaming @key, but I think its
functionality has to stay.[1] E.g., the US LOC may have changed
recently, but as of a few years ago you could not access an LOC name
authority record via a URI.

SR> - discuss at places meeting next week whether they need the @key
SR> functionality back, and if so ask them to choose a name
I don't think there is really any need for discussion -- it has to
stay.[1] (Its name, on the other hand ... :-)

LB> The idea is that there are two
LB> ways of finding something:
LB> (a) you point at it with a URI.
LB> (b) you do it some other way
LB> In the latter case, the value supplied in your document is a magic
LB> token. We make no assumptions about how you will use that magic token to
LB> find the thing you're looking for: that's up to you. You might look it
LB> up in a database, you might stick some extra stuff on the front and turn
LB> it into a URL,
In which case it really should be a cRef=. Which makes some sense.

LB> There are probably only a few cases where (b) is the best way of
LB> doing things, but they do exist: the way we hook modules and
LB> elements into a TEI schema spec is one -- we supply an identifier
LB> (the magic token) and the Odd processor Does The Right Thing with
LB> it.
I am unconvinced that this is a correct analysis. As I've said, I see
three categories:
1. point at it with a URI
1a. use the cRef= mechanism for shorthand of a URI
2. point at it by matching its ident= (remember this is used not only
be key= of et al., but also by xml:lang=)
3. a user-defined magic token
The usage is not a user-defined black box method of
finding something. This is clearly defined: the value has to match an
ident= in the same document, no?

LB> Another case might be where everybody *just knows* what you mean
LB> by a given code -- say, for example, identifying the books of the
LB> Bible. You don't want to have to spell out in every single
LB> Biblical commentary you encode that "Gen" means "Genesis", etc.
LB> You just want to say "Gen". Yes, of course it's better to spell
LB> things like that out. But there are limits to people's
LB> willingness to be explicit!
This is a really good example, and a potential reason why the tag:
URL scheme won't really solve the problem -- people who don't want to
bother being explicit are certainly not going to want to develop tag:
URLs.

LB> I wondered about this, even as I made the changes proposed. ...
LB> The proposal (now implemented) is to reserve @key, with datatype
LB> data.key, for that latter usage.
I'm sorry, what has now been implemented? What change (if any) has
been made?

Notes
-----
[1] However, Conal's suggestion of using the tag: URI scheme bears
further thought and discussion -- it may actually provide
sufficient functionality, but I'm not convinced yet. And I don't
really have the capability to read up on it right now from
dial-up land, but it's worth reading up on:
http://www.rfc-editor.org/rfc/rfc4151.txt
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue May 22 2007 - 23:00:37 EDT

From conal.tuohy at vuw.ac.nz Wed May 23 00:01:44 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 23 May 2007 16:01:44 +1200 Subject: [tei-council] the "key" attribute In-Reply-To: <18003.44624.650363.406838@emt.wwp.brown.edu> Message-ID: <1179892904.27602.14.camel@localhost>
From: Conal Tuohy
Date: Wed, 23 May 2007 16:01:44 +1200
On Tue, 2007-05-22 at 23:00 -0400, Syd Bauman wrote:
> SR> - change att.naming to remove @key and put in @ref as pointer
> SR> instead
>
> I am not in favor. I don't mind renaming @key, but I think its
> functionality has to stay.[1] E.g., the US LOC may have changed
> recently, but as of a few years ago you could not access an LOC name
> authority record via a URI.
I think it's still true that you can't "access" an LoC name record via a
URL, but it's certainly possible to encode a Library of Congress Control
Number (LCCN) in a URI, in a standard way:
e.g. "info:lccn/n2002153210" is the URI for a certain Syd Bauman.
Disappointingly, on the LoC web page for this record (I won't post a
more specific URL than http://authorities.loc.gov/ because their rubbish
URLs don't persist from one moment to the next) the LCCN is nowhere
presented in the form of an "info" URI. However, I believe that using
the "info" URI scheme is the recommended practice for URI-encoding of
LCCN identifiers.
This URI does not have a well-defined resolution mechanism, however, it
is still a valuable standard, and a useful key for Syd Bauman.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed May 23 2007 - 00:05:53 EDT
From daniel.odonnell at uleth.ca Wed May 23 00:08:51 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 22 May 2007 22:08:51 -0600 Subject: [tei-council] the "key" attribute In-Reply-To: <1179892904.27602.14.camel@localhost> Message-ID: <1179893331.12852.9.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 22 May 2007 22:08:51 -0600
Another group I'm working on is busy implementing a LOC URL scheme
called SRU: http://refdb.sourceforge.net/sru.html
-dan
On Wed, 2007-05-23 at 16:01 +1200, Conal Tuohy wrote:
> On Tue, 2007-05-22 at 23:00 -0400, Syd Bauman wrote:
> > SR> - change att.naming to remove @key and put in @ref as pointer
> > SR> instead
> >
> > I am not in favor. I don't mind renaming @key, but I think its
> > functionality has to stay.[1] E.g., the US LOC may have changed
> > recently, but as of a few years ago you could not access an LOC name
> > authority record via a URI.
>
> I think it's still true that you can't "access" an LoC name record via a
> URL, but it's certainly possible to encode a Library of Congress Control
> Number (LCCN) in a URI, in a standard way:
>
> e.g. "info:lccn/n2002153210" is the URI for a certain Syd Bauman.
>
> Disappointingly, on the LoC web page for this record (I won't post a
> more specific URL than http://authorities.loc.gov/ because their rubbish
> URLs don't persist from one moment to the next) the LCCN is nowhere
> presented in the form of an "info" URI. However, I believe that using
> the "info" URI scheme is the recommended practice for URI-encoding of
> LCCN identifiers.
>
> This URI does not have a well-defined resolution mechanism, however, it
> is still a valuable standard, and a useful key for Syd Bauman.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 00:10:11 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 04:03:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 09:03:38 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18003.44624.650363.406838@emt.wwp.brown.edu> Message-ID: <4653F55A.702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 23 May 2007 09:03:38 +0100
Syd Bauman wrote:
> functionality has to stay.[1] E.g., the US LOC may have changed
> recently, but as of a few years ago you could not access an LOC name
> authority record via a URI.
>
you could use Conal's trick
maybe we _should_ all use cRef for some of these
things; possibly that should be added to att.naming?
If, for example, Matthew has a canonical way of referring
to dead Icelanders, he should document it in
a and point using a cRef.
is cRef used in the wild?
> I'm sorry, what has now been implemented? What change (if any) has
> been made?
>
Lou has added @ref to att.naming
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 04:08:02 EDT
From James.Cummings at oucs.ox.ac.uk Wed May 23 09:19:55 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 23 May 2007 14:19:55 +0100 Subject: [tei-council] Berlin Photos Message-ID: <46543F7B.2000105@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 23 May 2007 14:19:55 +0100
By the way I finally got around to posting the numerous photos I took in
Berlin, in case anyone is interested. If anyone has any objections to the
public posting of photos they appear in, let me know which photos you
object to and I will remove them (or change their permissions).
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/
My favourites (for various reasons) include:
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_018.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_060.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_063.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_120.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_121.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_151.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_162.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_202.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_218.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_275.jpg.html
http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_296.jpg.html

-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 09:20:00 EDT

From arianna.ciula at kcl.ac.uk Wed May 23 09:58:23 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 23 May 2007 14:58:23 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4653675E.6000305@computing-services.oxford.ac.uk> Message-ID: <4654487F.4030602@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 23 May 2007 14:58:23 +0100
I think this is quite a complex issue to tackle since the use of
implicit @key to refer to something else implies some sort of
user-defined method to transform it into a real reference but at the
same time requires the guidelines to be more explicit in suggested
practices (e.g. use the TEI header, store your more explicit paths
somewhere, create a TEI authority list of people/places).
In general I think I agree with the proposal
Lou Burnard wrote:
> to reserve @key, with datatype
> data.key, for that latter usage.
i.e. for references that don't have necessarily the format of a
pointer....but more to be done on the names and dates chapter to show
how @key can be REALLY used.
Arianna
>
>
>
> Conal Tuohy wrote:
>> On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote:
>>
>>> Matthew James Driscoll wrote:
>>>
>>>> It would be helpful if I had a clearer idea of the difference
>>>> between key,
>>>> ana and target (and ref), all of which seem to do similar, but subtly
>>>> different, things. It's the "subtly different" bit that gets me.
>>>>
>>>> key "provides a means of locating a full definition for the entity
>>>> being
>>>> named such as a database record key or a URI" ]
>>>>
>>> no, scrub that "or a URI" bit. It can't work.
>>>
>>
>> Can you explain why? Do you mean because of your earlier point that
>> there's no failsafe way to determine whether a @key is intended to
>> represent a db record key on the one hand, or a URI on the other?
>>
>> I have to say I am very much a fan of @key as a URI (and of URIs as a
>> preferred reference mechanism is general).
>> If the problem with "or a URI" is as I supposed, another approach would
>> be to require that @key always contains a URI, and recommend to encoders
>> who wish to encode a locally-defined database record key that they
>> encode the record key, slightly more verbosely, in some kind of URI
>> syntax.
>>
>>
>> Conal
>>
>> The @key above is actually a key in a database here at work. There are
>> several usable http URLs I could construct from it, e.g.:
>>
>>
>> key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal
>>
>> Without using http or another resolution protocol, the key could still
>> be encoded in URI syntax using the "tag" URI scheme:
>>
>>
>> Conal
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 10:00:09 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 10:41:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 15:41:47 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4654487F.4030602@kcl.ac.uk> Message-ID: <465452AB.8060002@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 23 May 2007 15:41:47 +0100
Arianna Ciula wrote:
> I think this is quite a complex issue to tackle since the use of
> implicit @key to refer to something else implies some sort of
> user-defined method to transform it into a real reference but at the
> same time requires the guidelines to be more explicit in suggested
> practices (e.g. use the TEI header, store your more explicit paths
> somewhere, create a TEI authority list of people/places).
you mean that in general show people better how to use @ref instead of @key?
> i.e. for references that don't have necessarily the format of a
> pointer....but more to be done on the names and dates chapter to show
> how @key can be REALLY used.
can you expand? in general, we discourage use of @key, don't we?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 10:41:52 EDT
From arianna.ciula at kcl.ac.uk Wed May 23 13:30:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 23 May 2007 18:30:56 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465452AB.8060002@oucs.ox.ac.uk> Message-ID: <46547A50.1080308@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 23 May 2007 18:30:56 +0100
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> I think this is quite a complex issue to tackle since the use of
>> implicit @key to refer to something else implies some sort of
>> user-defined method to transform it into a real reference but at the
>> same time requires the guidelines to be more explicit in suggested
>> practices (e.g. use the TEI header, store your more explicit paths
>> somewhere, create a TEI authority list of people/places).
> you mean that in general show people better how to use @ref instead of
> @key?
I think the use of @key for persons/places is shown (inconsistently as
you have also pointed out) but without prose on concrete practices. If I
remember well the examples show the use of @key as a pointer to a person
element, for instance, in the header. Now, we know this is a practice
that work for relative small scenarios. Every project with a good amount
of data on persons need a different way (TEI authority file containing
only person elements for instance, prosopographical DB etc.) to store
this information and recall it (need a better word than 'recall' here)
from each single document through @keys.
>> i.e. for references that don't have necessarily the format of a
>> pointer....but more to be done on the names and dates chapter to show
>> how @key can be REALLY used.
> can you expand? in general, we discourage use of @key, don't we?
I am not sure we should discourage the use of an attribute that allows
people to integrate data coming from different resources (e.g. XML
source documents separate from DB material, ontology or whatever).
I am also a fan of @keys.
The XML source file cannot contain ALL the information about its context
(e.g. prosopographical context) and shouldn't (IMO).
However, I do agree that we could suggest better ways of doing things
such as what we are now doing by supporting the use of namespaces: for
instance, tell where you could store store the path to get to your DB
and transform those keys into actual references and so on.
Hope I wasn't too confusing...really busy week.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 13:33:16 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 14:43:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 19:43:30 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46547A50.1080308@kcl.ac.uk> Message-ID: <46548B52.7030902@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 23 May 2007 19:43:30 +0100
Arianna Ciula wrote:
> that work for relative small scenarios. Every project with a good
> amount of data on persons need a different way (TEI authority file
> containing only person elements for instance, prosopographical DB
> etc.) to store this information and recall it (need a better word than
> 'recall' here) from each single document through @keys.
by which I hope you mean not old @key, but new @ref.....
>
> I am not sure we should discourage the use of an attribute that allows
> people to integrate data coming from different resources (e.g. XML
> source documents separate from DB material, ontology or whatever).
I thought we encouraged integration by URLs, pure and simple, except in
special cases?
> The XML source file cannot contain ALL the information about its
> context (e.g. prosopographical context) and shouldn't (IMO).
no, which is why a URL which can go inside the file, or out of it, is a
good answer. Isn't this basic TEI P5, a move
towards Web-style hyperlinking as the primary method?
> However, I do agree that we could suggest better ways of doing things
> such as what we are now doing by supporting the use of namespaces: for
> instance, tell where you could store store the path to get to your DB
> and transform those keys into actual references and so on.
I don't think you mean namespaces here; you refer, I think, to creative
use of different URI protocols.
We must make sure we dont spend the whole day next week discussing this....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed May 23 2007 - 14:43:35 EDT
From arianna.ciula at kcl.ac.uk Thu May 24 05:09:52 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 24 May 2007 10:09:52 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46548B52.7030902@oucs.ox.ac.uk> Message-ID: <46555660.8040701@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 24 May 2007 10:09:52 +0100
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> that work for relative small scenarios. Every project with a good
>> amount of data on persons need a different way (TEI authority file
>> containing only person elements for instance, prosopographical DB
>> etc.) to store this information and recall it (need a better word than
>> 'recall' here) from each single document through @keys.
> by which I hope you mean not old @key, but new @ref.....
well, yes, new @ref when we can have explicit references.
>> The XML source file cannot contain ALL the information about its
>> context (e.g. prosopographical context) and shouldn't (IMO).
> no, which is why a URL which can go inside the file, or out of it, is a
> good answer. Isn't this basic TEI P5, a move
> towards Web-style hyperlinking as the primary method?
>> However, I do agree that we could suggest better ways of doing things
>> such as what we are now doing by supporting the use of namespaces: for
>> instance, tell where you could store store the path to get to your DB
>> and transform those keys into actual references and so on.
> I don't think you mean namespaces here; you refer, I think, to creative
> use of different URI protocols.
ure, namespaces meaning: clean declaration of where things come from
that is URI.
>
> We must make sure we dont spend the whole day next week discussing this....
I meant to agree on an agenda with Matthew but hadn't had time to draft
anything yet.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu May 24 2007 - 05:12:15 EDT
From arianna.ciula at kcl.ac.uk Mon May 28 07:49:29 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 28 May 2007 12:49:29 +0100 Subject: [tei-council] Re: TEI P5 release 0.7 In-Reply-To: <46585FCC.6040700@oucs.ox.ac.uk> Message-ID: <465AC1C9.3080302@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 28 May 2007 12:49:29 +0100
Hi,
I have noticed that nymKey has now correctly become
nymRef (therefore datat.pointer); however there is still one
reference to nymKey in the ND prose.
I suppose we could deal with this tomorrow, but since it's an easy fix
and the new chapter is already public, I thought useful to point it out.
Arianna

Sebastian Rahtz wrote:
> A new release of P5 has just slipped its mooring and glided away into
> the darkling night,
> accompanied by its Stylesheets and Roma consorts, intent on havoc across
> the text
> encoding oceans.
>
> This release is relatively minor, but is the start of what I hope will
> be 4 more releases
> before the final 1.0; so expect to see the predators emerging once a
> month or so from now on.
>
> The release includes many small fixes made at the TEI Council's spring
> meeting in Berlin, though there are a lot still to come from that. Among
> the
> (obscure) things you may notice:
>
> *) the hoary old entities/macros mix.drama, mix.verse etc are all gone.
> if conceivably you mourn their passing, let us know
>
> *) the macro.component object has also gone, replaced by simply
> a call to macro.common. You may have this in an existing ODD file
> - contact me if you cannot see how to fix.
>
> *) the att.naming class adds a new @ref attribute to things like .
> This removes a confusion whereby the @key attribute was said to allow
> either a token or a URL pointer. Now you have to make up your mind -
> use @ref if its a pointer, @key if its a private token.
>
> No, the @rend attribute has NOT changed its datatype
> or semantics in this release.
>
> As ever, the release is on Sourceforge, on the Debian package repository
> at http://tei.oucs.ox.ac.uk/teideb/, and on the TEI web site. A Live
> CD will be ready shortly, Dr Who permitting (UK readers
> will know whta I mean...)
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 28 2007 - 07:51:42 EDT

From Syd_Bauman at Brown.edu Mon May 28 08:33:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 28 May 2007 08:33:10 -0400 Subject: [tei-council] place meeting? Message-ID: <18010.52230.92805.529954@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 28 May 2007 08:33:10 -0400
I am gathering from oblique references in various posts that the
place-name meeting has not only been set up, but will be happening
tomorrow. Has the Council been kept abreast of its progress (as was
actioned in Berlin), and I missed it while away on my various
travels? Who is attending? What's the agenda? The expected
deliverable? Not that I think it matters much, but are *any* North
Americans invited? I've also forgotten what is left in the budget to
cover this meeting.
Good luck to those attending, I hope you have a very productive
meeting and a good time.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 28 2007 - 08:33:13 EDT
From arianna.ciula at kcl.ac.uk Mon May 28 08:51:01 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 28 May 2007 13:51:01 +0100 Subject: [tei-council] place meeting? In-Reply-To: <18010.52230.92805.529954@emt.wwp.brown.edu> Message-ID: <465AD035.1000805@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 28 May 2007 13:51:01 +0100
Syd Bauman wrote:
> I am gathering from oblique references in various posts that the
> place-name meeting has not only been set up, but will be happening
> tomorrow.
Yes, it will.
Has the Council been kept abreast of its progress (as was
> actioned in Berlin), and I missed it while away on my various
> travels?
No progress so far. The meeting is tomorrow and we will certainly report
on the discussion.
Who is attending?
Lou, Sebastian, James, Matthew, me, Gabriel Bodard, Tom Elliott (on
skype), Leif Isaksen (Oxford Archaeology) and Stuart Dunn (methods Network).
What's the agenda?
we don't have an official agenda ...sorry
The expected
> deliverable?
In general terms: some clear specifications on what to do as far as the
encoding of data about places regard (i.e. additions to the ND chapter).
I am sure others could give more specific indications.
Not that I think it matters much, but are *any* North
> Americans invited?
Tom Elliott.

>
> Good luck to those attending, I hope you have a very productive
> meeting and a good time.
Thank-you,
Arianna
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon May 28 2007 - 08:53:14 EDT

From Syd_Bauman at Brown.edu Mon May 28 09:00:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 28 May 2007 09:00:53 -0400 Subject: [tei-council] place meeting? In-Reply-To: <465AD035.1000805@kcl.ac.uk> Message-ID: <18010.53893.300768.718455@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 28 May 2007 09:00:53 -0400
Thank you, Arianna!

> > Has the Council been kept abreast of its progress (as was
> > actioned in Berlin), and I missed it while away on my various
> > travels?
>
> No progress so far. ...
I meant progress in planning, sorry.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 28 2007 - 09:00:57 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon May 28 11:37:33 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 28 May 2007 16:37:33 +0100 Subject: [tei-council] Re: TEI P5 release 0.7 In-Reply-To: <465AC1C9.3080302@kcl.ac.uk> Message-ID: <465AF73D.2060408@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 28 May 2007 16:37:33 +0100
Ooops. Thanks for spotting this. Removed.
L
Arianna Ciula wrote:
>
> Hi,
>
> I have noticed that nymKey has now correctly become
> nymRef (therefore datat.pointer); however there is still
> one reference to nymKey in the ND prose.
>
> I suppose we could deal with this tomorrow, but since it's an easy fix
> and the new chapter is already public, I thought useful to point it out.
>
> Arianna
>
>
> Sebastian Rahtz wrote:
>> A new release of P5 has just slipped its mooring and glided away into
>> the darkling night,
>> accompanied by its Stylesheets and Roma consorts, intent on havoc
>> across the text
>> encoding oceans.
>>
>> This release is relatively minor, but is the start of what I hope
>> will be 4 more releases
>> before the final 1.0; so expect to see the predators emerging once a
>> month or so from now on.
>>
>> The release includes many small fixes made at the TEI Council's spring
>> meeting in Berlin, though there are a lot still to come from that.
>> Among the
>> (obscure) things you may notice:
>>
>> *) the hoary old entities/macros mix.drama, mix.verse etc are all gone.
>> if conceivably you mourn their passing, let us know
>>
>> *) the macro.component object has also gone, replaced by simply
>> a call to macro.common. You may have this in an existing ODD file
>> - contact me if you cannot see how to fix.
>>
>> *) the att.naming class adds a new @ref attribute to things like .
>> This removes a confusion whereby the @key attribute was said to allow
>> either a token or a URL pointer. Now you have to make up your mind -
>> use @ref if its a pointer, @key if its a private token.
>>
>> No, the @rend attribute has NOT changed its datatype
>> or semantics in this release.
>>
>> As ever, the release is on Sourceforge, on the Debian package repository
>> at http://tei.oucs.ox.ac.uk/teideb/, and on the TEI web site. A Live
>> CD will be ready shortly, Dr Who permitting (UK readers
>> will know whta I mean...)
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon May 28 2007 - 11:39:45 EDT
From Syd_Bauman at Brown.edu Tue May 29 17:01:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 29 May 2007 17:01:10 -0400 Subject: [tei-council] place meeting? In-Reply-To: <18010.53893.300768.718455@emt.wwp.brown.edu> Message-ID: <18012.38038.754247.734771@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 29 May 2007 17:01:10 -0400
I'm sorry I wasn't able to post this before the place meeting occured
earlier today.
I never got the chance in Berlin to give my comments on the "Draft
proposals for representation of geographic information" document.
Most of the scribbles on my hard-copy are typos. But I went over it
again and found two substantive issues:
* In an example of , the element is used. Per
previous Council discussions, the element was removed. I
am not sure if this document is recommending that it be brought
back for this purpose or not. (Personally, I think will
do for this usage.)
* There are 3 examples of using latitude and longitude to indicate a
place's location (in #MYF, #IS, and #ESB), and they are all
different!
41.687142 -74.870109
65 00 N, 18 00 W

40.7484° N 73.9858° W

Use of latitude and longitude to locate a place is going to be
*extremely* common, and, IMHO, fits squarely into that category of
things where it is more important that we all do it the same than
that we have the capability to do it however we want. I.e., the TEI
Guidelines should recommend one and only one method for encoding
these.
Note, BTW, that is, as currently defined, not a
particularly good way to encode a latitude or longitude (nor a
latitude and longitude). This is because latitude and longitude
traditionally include a direction, for which does not
provide a place for normalization. However, it may be quite
reasonable to simply decide to use the common system of using
negative values for S and W:
40°44'54.21" N
70°59'06" W
28°00'22" S
153°25'46" E
Using negative values for S and W is what's done in digital mapping
applications, or so I've read. I think I like this the best. (That
second example is the location of Queensland Number One: "At 323 m
[it] is the world's tallest all-residential building, when measured
to the top of its spire.".)
The advantage of using , is that the normalized decimal
degrees using negatives for S and W can be stored in the attribute
values, and users can do whatever they want for the content.
BTW, decimal degrees should be used as the value of quantity=, not
degrees, minutes, seconds. (Obviously, because the unit= is
"degrees", not "DMS" -- but ISO 31 recommends that the degree be
subdivided decimally rather than using the minute and second.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue May 29 2007 - 17:01:14 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue May 29 18:45:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 29 May 2007 23:45:09 +0100 Subject: [tei-council] place meeting? In-Reply-To: <18012.38038.754247.734771@emt.wwp.brown.edu> Message-ID: <465CACF5.5010104@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 29 May 2007 23:45:09 +0100
I am glad to say that the issue of representing latitude/longitude got
a thorough and constructive airing at the meeting today; I am not
sure the scheme we ended up with is perfect yet, but it's
well on the way.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue May 29 2007 - 18:45:14 EDT
From cwittern at gmail.com Thu May 31 00:03:42 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 31 May 2007 13:03:42 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items Message-ID: <465E491E.4070009@gmail.com>
From: Wittern Christian
Date: Thu, 31 May 2007 13:03:42 +0900
Dear Council members,
Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like
to see the action/trac items resulting from the Berlin meeting cleared
out by that time. Please go once again to look at
http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example)
http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review
and make sure that the things on your table get done.
I would also like to ask those who are revising / composing working
documents, to get the documents ready by June 8, so that we have time to
review them before the call.
As always, please report work done here (and close/update the
corresponding trac ticket) so that we know whats going on.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu May 31 2007 - 00:03:50 EDT

From James.Cummings at oucs.ox.ac.uk Thu May 31 04:58:56 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 31 May 2007 09:58:56 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465E491E.4070009@gmail.com> Message-ID: <465E8E50.5070108@oucs.ox.ac.uk>
From: James Cummings
Date: Thu, 31 May 2007 09:58:56 +0100
Wittern Christian wrote:
> Dear Council members,
>
> Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like
> to see the action/trac items resulting from the Berlin meeting cleared
> out by that time. Please go once again to look at
> http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example)
> http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review
> and make sure that the things on your table get done.
Could I remind all the council that each one of you is meant to send Dot
and I (though send to my email address) a minimum of 5 ways you'd improve
the formatting of the HTML version of the Guidelines.
No deadline was set for that, but I'd like to now suggest that each of you
do this by the 5 June 2007..
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu May 31 2007 - 04:59:01 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu May 31 06:53:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 11:53:23 +0100 Subject: [tei-council] USE chapter Message-ID: <465EA923.20804@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 31 May 2007 11:53:23 +0100
Somewhat later than hoped, I've now done some revision of the CF chapter
in line with Council's desire that this should make clearer that there
are many paths to the city of righteousness. In the process I also put
in a place marker for a new section on ODD implementation and wrote an
introductory para for the USE chapter itself (this was a trac item
mysteriously associated with the AB chapter and previous assigned to
Syd, so he owes me one!)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu May 31 2007 - 06:55:43 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu May 31 07:02:38 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 12:02:38 +0100 Subject: [tei-council] Trac Message-ID: <465EAB4E.5080900@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 31 May 2007 12:02:38 +0100
If we are serious about using TRAC to get this job done, could the junta
responsible please tidy it up a bit? In particular : is "rahtz" the same
sentient being as "sebastian" and do we need both of them? The former
has dozens of tickets, most but not all of which I believe are now
superannuated; the latter has only three. Sorry if this was explained
earlier and I missed it in the welter of other buziness.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu May 31 2007 - 07:04:59 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu May 31 08:53:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 13:53:05 +0100 Subject: [tei-council] Place meeting at Kings Message-ID: <465EC531.2060500@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 31 May 2007 13:53:05 +0100
A brief report on issues discussed and proposals agreed at Tuesday's
meeting on Geographical data is now available at
http://www.tei-c.org/Activities/PERS/placeMtg.xml (couldnt think of
anywhere else to put it)
The meeting felt, in summary, that
- the places proposal developed in Vilnius should be included in P5,
modulo various clarifications and enhancements
- to facilitate this, two existing TEI elements would need to be
renamed: and
- the existing material on etc needed to be completely revised
with several elements disappearing
- some minor changes were proposed for the treatment of dates and times
Feedback from Council members on these specific issues would be much
appreciated.
Many thanks to Arianna and others at CCH for organizing and hosting the
meeting so efficiently!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu May 31 2007 - 08:55:26 EDT

From cwittern at gmail.com Thu May 31 21:31:47 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 01 Jun 2007 10:31:47 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465E8E50.5070108@oucs.ox.ac.uk> Message-ID: <465F7703.1060503@gmail.com>
From: Wittern Christian
Date: Fri, 01 Jun 2007 10:31:47 +0900
OK, here is my 5 cents:
1) get rid of the sidebar or make it configurable
2) have a "print view"
3) show possible parents of elements in the reference chapter
4) show possible children of elements in the reference chapter
5) Tidy up the display of rng fragments and make the display (and
print!) of these passages optional
All the best,
Christian

James Cummings wrote:
> Wittern Christian wrote:
>
>> Dear Council members,
>>
>> Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like
>> to see the action/trac items resulting from the Berlin meeting cleared
>> out by that time. Please go once again to look at
>> http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example)
>> http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review
>> and make sure that the things on your table get done.
>>
>
> Could I remind all the council that each one of you is meant to send Dot
> and I (though send to my email address) a minimum of 5 ways you'd improve
> the formatting of the HTML version of the Guidelines.
>
> No deadline was set for that, but I'd like to now suggest that each of you
> do this by the 5 June 2007..
>
> -James
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu May 31 2007 - 21:31:53 EDT

From cwittern at gmail.com Thu May 31 21:43:10 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 01 Jun 2007 10:43:10 +0900 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465EC531.2060500@computing-services.oxford.ac.uk> Message-ID: <465F79AE.2090201@gmail.com>
From: Wittern Christian
Date: Fri, 01 Jun 2007 10:43:10 +0900
Thanks for the report, which seems to indicate to me that the meeting
was very successful.
As to the proposals, they all seem plausible and have my support,
including the new element (I'd prefer this to .
According to the report, would also be among the candidates for
renaming.
All the best,
Christian
Lou Burnard wrote:
> A brief report on issues discussed and proposals agreed at Tuesday's
> meeting on Geographical data is now available at
> http://www.tei-c.org/Activities/PERS/placeMtg.xml (couldnt think of
> anywhere else to put it)
>
> The meeting felt, in summary, that
> - the places proposal developed in Vilnius should be included in P5,
> modulo various clarifications and enhancements
> - to facilitate this, two existing TEI elements would need to be
> renamed: and
> - the existing material on etc needed to be completely
> revised with several elements disappearing
> - some minor changes were proposed for the treatment of dates and times
>
> Feedback from Council members on these specific issues would be much
> appreciated.
>
> Many thanks to Arianna and others at CCH for organizing and hosting
> the meeting so efficiently!
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu May 31 2007 - 21:43:17 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 1 03:50:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 01 Jun 2007 08:50:16 +0100 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465F79AE.2090201@gmail.com> Message-ID: <465FCFB8.2030409@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 01 Jun 2007 08:50:16 +0100
Wittern Christian wrote:
>
> As to the proposals, they all seem plausible and have my support,
> including the new element (I'd prefer this to .
> According to the report, would also be among the candidates
> for renaming.
>
its an @period attribute to join all the other dating attributes, actually.
and is new, but replaces
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 01 2007 - 03:50:19 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 04:54:48 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 09:54:48 +0100 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465F79AE.2090201@gmail.com> Message-ID: <465FDED8.7080308@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 01 Jun 2007 09:54:48 +0100
Wittern Christian wrote:
> Thanks for the report, which seems to indicate to me that the meeting
> was very successful.
>
> As to the proposals, they all seem plausible and have my support,
> including the new element (I'd prefer this to .
It wasn't proposed as an element, but as an attribute.

> According to the report, would also be among the candidates
> for renaming.

eh?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 01 2007 - 04:57:12 EDT

From James.Cummings at oucs.ox.ac.uk Fri Jun 1 06:59:39 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 01 Jun 2007 11:59:39 +0100 Subject: [tei-council] @reg on country Message-ID: <465FFC1B.5020306@oucs.ox.ac.uk>
From: James Cummings
Date: Fri, 01 Jun 2007 11:59:39 +0100
Hi there,
Now I know this problem might be about to disappear as @reg attributes
vanish in a puff of rationalisation, however in answering an enquiry about
placenames I had reason to look up the country element. Currently the
country element has a @reg attribute whose data-type is {data.code}? where
data.code resolves to xsd:anyURI. See:
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-country.html
What bothered me was that @reg is defined as supplying "a regularized form
of the country name using a name or code from ISO 3166".
However, since the datatype of reg is a URI, what the example:
Denmark
means is that there is a file 'DK' that this element is point at.
So ok, it should be #DK and point to the places you've defined up in your
header or wherever. But the problem with that is it ignores that this is a
fixed value list of codes from ISO 3166 and instead makes it a URI. Just
seems wrong to me.
Roll on @ref (for those countries not defined by ISO3166) and cref (for
those which are, I'd say.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 01 2007 - 06:59:42 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 11:18:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 16:18:05 +0100 Subject: [tei-council] What did we decide? Message-ID: <466038AD.5060104@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 01 Jun 2007 16:18:05 +0100
I thought we had some discussion in Berlin about what the Guidelines
should say about the feasibility of constructing a TEI schema by non-ODD
methods, e.g. by lumping together references to TEI dtd fragments within
a doctype, or building a relaxng schema by referencing the TEI Relaxng
modules.
I cannot however find any reference to it in the minutes (instead they
seem to document all sorts of minor corrections which we not only
decided but dealt with in the meeting itself)
Before I go ahead and rewrite history, here's what I believe the party
line to be:
1. TEI Conformance (whether implicit or algorithmic) requires that
there be an ODD. Therefore if you don't have an ODD, you cannot be TEI
conformant.
2. Nevertheless, we do create TEI modules as distinct schema/DTD
fragments, with published names (someone was actioned to review the
names I think? sebastian?) and document said names and modules.
So, if you're smart, you can go ahead and build yourself a TEI aschema
without an ODD. But we don't promise it will always work -- at release
1.n we might (for example) move an element from one module to another.
Argal, the discussion in ST.xml#STIN should refer only to ODDs? (which
is where I came in)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 01 2007 - 11:22:41 EDT

From djbpitt+tei at pitt.edu Fri Jun 1 11:35:22 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 01 Jun 2007 11:35:22 -0400 Subject: [tei-council] What did we decide? In-Reply-To: <46603C95.4010006@pitt.edu> Message-ID: <46603CBA.1040609@pitt.edu>
From: David J Birnbaum
Date: Fri, 01 Jun 2007 11:35:22 -0400
Dear Lou (cc Council),
My memory about this is a bit foggy, but I thought someone suggested in
Berlin that since TEI conformance requires an ODD, the Guidelines should
say nothing about modifying the TEI otherwise than through the use of an
ODD. That is, although other types of modification can be implemented by
someone perverse enough to try, the Guidelines shouldn't get involved in
(or even acknowledge the existence of) such non-conformant endeavors.
I don't remember whether we agreed on this or whether it just floated
around the table, slipped out under the door, headed down in the pater
noster, and disappeared across the square, but whatever the disposition,
I think it would 1) make our lives easier and 2) make the lives of those
who wish to modify the TEI easier.
Best,
David
>
> Lou Burnard wrote:
>> I thought we had some discussion in Berlin about what the Guidelines
>> should say about the feasibility of constructing a TEI schema by
>> non-ODD methods, e.g. by lumping together references to TEI dtd
>> fragments within a doctype, or building a relaxng schema by
>> referencing the TEI Relaxng modules.
>>
>> I cannot however find any reference to it in the minutes (instead
>> they seem to document all sorts of minor corrections which we not
>> only decided but dealt with in the meeting itself)
>>
>> Before I go ahead and rewrite history, here's what I believe the
>> party line to be:
>>
>> 1. TEI Conformance (whether implicit or algorithmic) requires that
>> there be an ODD. Therefore if you don't have an ODD, you cannot be
>> TEI conformant.
>>
>> 2. Nevertheless, we do create TEI modules as distinct schema/DTD
>> fragments, with published names (someone was actioned to review the
>> names I think? sebastian?) and document said names and modules.
>>
>> So, if you're smart, you can go ahead and build yourself a TEI
>> aschema without an ODD. But we don't promise it will always work --
>> at release 1.n we might (for example) move an element from one module
>> to another.
>>
>> Argal, the discussion in ST.xml#STIN should refer only to ODDs?
>> (which is where I came in)
>>
>>
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 01 2007 - 11:35:26 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 13:33:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 18:33:52 +0100 Subject: [tei-council] What did we decide? In-Reply-To: <46603C95.4010006@pitt.edu> Message-ID: <46605880.7030106@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 01 Jun 2007 18:33:52 +0100
Thanks David.
If you check
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/33
and
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/54
you'll see that I've at last got round to your helpful comments on those
chapters at least.
L

David J Birnbaum wrote:
> Dear Lou (cc Council),
>
> My memory about this is a bit foggy, but I thought someone suggested in
> Berlin that since TEI conformance requires an ODD, the Guidelines should
> say nothing about modifying the TEI otherwise than through the use of an
> ODD. That is, although other types of modification can be implemented by
> someone perverse enough to try, the Guidelines shouldn't get involved in
> (or even acknowledge the existence of) such non-conformant endeavors.
>
> I don't remember whether we agreed on this or whether it just floated
> around the table, slipped out under the door, headed down in the pater
> noster, and disappeared across the square, but whatever the disposition,
> I think it would 1) make our lives easier and 2) make the lives of those
> who wish to modify the TEI easier.
>
> Best,
>
> David
>
> Lou Burnard wrote:
>> I thought we had some discussion in Berlin about what the Guidelines
>> should say about the feasibility of constructing a TEI schema by
>> non-ODD methods, e.g. by lumping together references to TEI dtd
>> fragments within a doctype, or building a relaxng schema by
>> referencing the TEI Relaxng modules.
>>
>> I cannot however find any reference to it in the minutes (instead they
>> seem to document all sorts of minor corrections which we not only
>> decided but dealt with in the meeting itself)
>>
>> Before I go ahead and rewrite history, here's what I believe the party
>> line to be:
>>
>> 1. TEI Conformance (whether implicit or algorithmic) requires that
>> there be an ODD. Therefore if you don't have an ODD, you cannot be TEI
>> conformant.
>>
>> 2. Nevertheless, we do create TEI modules as distinct schema/DTD
>> fragments, with published names (someone was actioned to review the
>> names I think? sebastian?) and document said names and modules.
>>
>> So, if you're smart, you can go ahead and build yourself a TEI aschema
>> without an ODD. But we don't promise it will always work -- at release
>> 1.n we might (for example) move an element from one module to another.
>>
>> Argal, the discussion in ST.xml#STIN should refer only to ODDs? (which
>> is where I came in)
>>
>>
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 01 2007 - 13:38:29 EDT

From djbpitt+tei at pitt.edu Fri Jun 1 14:18:30 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 01 Jun 2007 14:18:30 -0400 Subject: [tei-council] What did we decide? In-Reply-To: <46605880.7030106@computing-services.oxford.ac.uk> Message-ID: <466062F6.9090008@pitt.edu>
From: David J Birnbaum
Date: Fri, 01 Jun 2007 14:18:30 -0400
Dear Lou (cc Council),
Thanks!
> where does apostrophe mark a plural in English? /It disambiguates
phrases like "the dogs' paws" and "the dog's paws"
/Call me an orthographic or linguistic pedant, but the "s" marks the
plural in "the dogs' paws" and the apostrophe marks the possessive in
both "the dog's paws" and "the dogs' paws". That is, although the
relative place of the apostrophe and the "s" distinguishes the singular
from the plural, it is not the apostrophe, but the "s", that marks the
plural.
> "Parentheses and other marks of suspension" should omit "other" /Why?
"suspension" is being used in a linguistic sense here
/This isn't the meaning of suspension that occurred to me when I read
it, but I understand now.
> /"Element foreign" has some "include" notes /Sorry, I dont understand
this comment
There were places (here and elsewhere in my sections) where there were
notes that said something like "Include xxx" (with a title or number or
something in place of the xxx). That seems like a clumsy sort of link;
shouldn't we either actually include the text or word the links as
something like "more information about xxx is available at yyy"?
"Include xxx" sounds like an instruction in a processing environment,
not part of guidelines or documentation.
> Stray leading backslash in "\list = element list { list.content,
list.attributes }" /Not a stray: RELAXNC needs it
/
Oops. Sorry!
> do we need separate data.TruthValue?? and data.xTruthValue classes?
Isn't this like specifying language where it has to be European, i.e., a
formal restriction where user error is unlikely? /Not sure I understand
this analogy /
I think what I meant was that we might consider having a single class
that accepts booleans, "unknown", and "inapplicable", and that we don't
have to have a separate boolean-only class because users who want the
more restricted boolean-only option are likely to select "unknown" or
"inapplicable", and don't need to be protect from it by the schema. I
think the point of the analogy was that a project that requires us to
specify the language of some text doesn't usually provided a narrowly
constrained list of languages, and trusts instead that the user does not
need to be protected from picking an inappropriate one, and that one
might take the same attitude toward the two boolean-like classes. I
don't feel strongly about this, but it did seem as if we were using two
classes where one would probably meet our users' needs.
Best,
David
/
/Lou Burnard wrote:
> Thanks David.
>
> If you check
> http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/33
> and
> http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/54
> you'll see that I've at last got round to your helpful comments on
> those chapters at least.
>
> L
>
>
> David J Birnbaum wrote:
>> Dear Lou (cc Council),
>>
>> My memory about this is a bit foggy, but I thought someone suggested
>> in Berlin that since TEI conformance requires an ODD, the Guidelines
>> should say nothing about modifying the TEI otherwise than through the
>> use of an ODD. That is, although other types of modification can be
>> implemented by someone perverse enough to try, the Guidelines
>> shouldn't get involved in (or even acknowledge the existence of) such
>> non-conformant endeavors.
>>
>> I don't remember whether we agreed on this or whether it just floated
>> around the table, slipped out under the door, headed down in the
>> pater noster, and disappeared across the square, but whatever the
>> disposition, I think it would 1) make our lives easier and 2) make
>> the lives of those who wish to modify the TEI easier.
>>
>> Best,
>>
>> David
>>
>> Lou Burnard wrote:
>>> I thought we had some discussion in Berlin about what the Guidelines
>>> should say about the feasibility of constructing a TEI schema by
>>> non-ODD methods, e.g. by lumping together references to TEI dtd
>>> fragments within a doctype, or building a relaxng schema by
>>> referencing the TEI Relaxng modules.
>>>
>>> I cannot however find any reference to it in the minutes (instead
>>> they seem to document all sorts of minor corrections which we not
>>> only decided but dealt with in the meeting itself)
>>>
>>> Before I go ahead and rewrite history, here's what I believe the
>>> party line to be:
>>>
>>> 1. TEI Conformance (whether implicit or algorithmic) requires that
>>> there be an ODD. Therefore if you don't have an ODD, you cannot be
>>> TEI conformant.
>>>
>>> 2. Nevertheless, we do create TEI modules as distinct schema/DTD
>>> fragments, with published names (someone was actioned to review the
>>> names I think? sebastian?) and document said names and modules.
>>>
>>> So, if you're smart, you can go ahead and build yourself a TEI
>>> aschema without an ODD. But we don't promise it will always work --
>>> at release 1.n we might (for example) move an element from one
>>> module to another.
>>>
>>> Argal, the discussion in ST.xml#STIN should refer only to ODDs?
>>> (which is where I came in)
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 01 2007 - 14:18:35 EDT
From lou.burnard at computing-services.oxford.ac.uk Sun Jun 3 09:31:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 03 Jun 2007 14:31:01 +0100 Subject: [tei-council] intro to XML chapter Message-ID: <4662C295.1020704@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sun, 03 Jun 2007 14:31:01 +0100
I'm working on the overdue revision of this chapter and hope to have a
draft ready in a day or so. Meanwhile here's how YOU can help:
There's a blithe comment early on in this chapter about the dozens of
other places where you can learn about XML, to which is attached a
footnote saying "For example...."
If every member of the Council sent me their top 5 favourite
recommendations
for what should be on that list, what a happy bunny I would be. No you
may not cite either the chapter I am revising or the Annotated W3C
recommendations.
I promise to collate and circulate the results of this enquiry whatever
gets into the footnote!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 03 2007 - 09:31:05 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 3 10:04:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 03 Jun 2007 15:04:54 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465F7703.1060503@gmail.com> Message-ID: <4662CA86.8000208@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 03 Jun 2007 15:04:54 +0100
Wittern Christian wrote:
> 1) get rid of the sidebar or make it configurable
>
where would you put the table of contents?
> 5) Tidy up the display of rng fragments
can you elucidate? in what sense are they not
tidy?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 03 2007 - 10:05:03 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 3 18:02:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 03 Jun 2007 23:02:01 +0100 Subject: [tei-council] @reg on country In-Reply-To: <465FFC1B.5020306@oucs.ox.ac.uk> Message-ID: <46633A59.5000106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 03 Jun 2007 23:02:01 +0100
sounds like to me?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 03 2007 - 18:02:04 EDT
From cwittern at gmail.com Sun Jun 3 21:27:26 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 04 Jun 2007 10:27:26 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <4662CA86.8000208@oucs.ox.ac.uk> Message-ID: <46636A7E.8020609@gmail.com>
From: Wittern Christian
Date: Mon, 04 Jun 2007 10:27:26 +0900
Sebastian Rahtz wrote:
> Wittern Christian wrote:
>
>> 1) get rid of the sidebar or make it configurable
>>
>>
> where would you put the table of contents?
>
I would think you could use breadcrumbs for the uplink back to a full
toc and have only the toc for the chapter itself at the beginning of the
text.
>> 5) Tidy up the display of rng fragments
>>
> can you elucidate? in what sense are they not
> tidy?
>
When printing, they seem to run occasionally over the edge of the page.
Thinking of it, the same also happens to the examples here and there.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 03 2007 - 21:27:33 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 4 03:54:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 04 Jun 2007 08:54:41 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <46636A7E.8020609@gmail.com> Message-ID: <4663C541.2010609@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 04 Jun 2007 08:54:41 +0100
Wittern Christian wrote:
>
> I would think you could use breadcrumbs for the uplink back to a full
> toc and have only the toc for the chapter itself at the beginning of the
> text.
>
ok, I see. I'll leave that with James and Dot.
>
> When printing, they seem to run occasionally over the edge of the page.
> Thinking of it, the same also happens to the examples here and there.
>
oh dear, this is hard to deal with ...:-{
both the schema fragments and examples are pretty-printing.
and the algorithm obviously needs more tweaking. sigh.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 04 2007 - 03:54:45 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 4 06:28:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 04 Jun 2007 11:28:46 +0100 Subject: [tei-council] What did we decide? In-Reply-To: <466038AD.5060104@computing-services.oxford.ac.uk> Message-ID: <4663E95E.3060204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 04 Jun 2007 11:28:46 +0100
Lou Burnard wrote:
>
> 1. TEI Conformance (whether implicit or algorithmic) requires that
> there be an ODD. Therefore if you don't have an ODD, you cannot be TEI
> conformant.
with the caveat that your ODD can be tei_all
>
> 2. Nevertheless, we do create TEI modules as distinct schema/DTD
> fragments, with published names (someone was actioned to review the
> names I think? sebastian?) and document said names and modules.
the names are used in an ODD anyway with , so thats needed
regardless
>
> So, if you're smart, you can go ahead and build yourself a TEI aschema
> without an ODD. But we don't promise it will always work -- at release
> 1.n we might (for example) move an element from one module to another.
and then your ODD will break too.
You can't have it both ways. If we generate DTD and RELAXNG module fragments
and publish them, the punter has a reasonable expectation that a) we won't
willfully break them, and b) we will explain how to use them. Otherwise,
let's stop generating the wretched creatures!
I think you can simply not discuss it, and leave it to IM to document
what actually happens

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 04 2007 - 06:28:49 EDT

From laurent.romary at loria.fr Mon Jun 4 11:29:26 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 4 Jun 2007 17:29:26 +0200 Subject: [tei-council] Dictionary chapter update and proposal Message-ID: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr>
From: Laurent Romary
Date: Mon, 4 Jun 2007 17:29:26 +0200
Dear all,
Since our last meeting we been going through the PD chapter, trying
to see room for improvement. Element descriptions will thus be
completed by appropriate examples and tiny editorial improvements
made (before the more extensive linguistic editing that Lou would
like to do on the chapter).
I would like to address here a specific issue related to a change we
would like to operate on the technical content of the chapter: using
in replacement to and . This follows a
discussion I had with Lou (and technical fights with Roma), where we
tried to revisit the intrinsic complexity of various elements in the
disctionary chapter which seem more or less to express the same
structure as , namely and .
A replacement by would imply among other thing to introduce a
class (model.citDesc) in the content model of to which one
could attach whatever kind of descriptive elements (dictionnary
elements in the case of the dictionary module, but I could anticipate
useful applications in many domains). I think we do have here a very
nice simplification of quite a generic structure and would really
like to have it endorsed by the council.
I am thus asking you:
a) your opinion about the thing
b) your green light to put it on the P5 1.0 agenda
You will find below a set of dictionary examples together with the
ODD file.
Best wishes,
Laurent







My TEI Extension
generated by Roma 2.11


for use by whoever wants it




created on Wednesday 23rd May 2007 12:24:00 PM by
the form at
http://www.tei-c.org.uk/Roma/










type="model">
Class of descriptive elements for cit gi> constructs

type="model">















data.word
























r?moulade
Remulad


n
f


remoulade
r?moulade
dressing containing mustard and herbs





dresser



Theat

habilleur
m


-euse
f



Comm

window



?talagiste
mf



she's a stylish


elle s'habille avec chic


V. hair



tool

for wood

raboteuse
f



for stone

rabotin
m







OAS
illegal military organization supporting
French rule of Algeria



Judaism. the ceremony marking the end of the sabbath
or of a festival, including
the blessings over wine, candles and spices.
[literally: separation] [CED] -->


havdalah
havdoloh

Judaism
the ceremony marking the end of the sabbath or
of a festival, including the
blessings over wine, candles and spices.

literally
separation






and any mentioned> are used with
more


Give me more
s@'mO:(r)






to horrify


elle ?tait horrifi?e par la d?pense

she was horrified at the expense.






Vx.
Vaillance, bravoure (sp?cial., au combat) def>

La valeur n'attend pas le nombre des
ann?es

Corneille







Peinture
lit
fig

palette



Boucherie

shoulder




aube de roue

paddle



battoir ? linge

beetle



Manutention
Constr

pallet







reseating
rebottoming
with straw





ain't
eInt

Not standard

contraction of
am not
is not
are not
have not
has not


I ain't seen it.

Although the interrogative form
ain't I?
would be a natural contraction of am
I not?, it is
generally avoided in spoken English and never
used in formal English.




vag-
vago-

vagus nerve


al

tomy





Mr Burton took us for
French





was quite
n with him





it's easy to xml:id="ov1">mix her xml:id="ov2">up with her sister





Geog


Canary Isles
Canaries


?les
f
pl


Canaries
f
pl






_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jun 04 2007 - 11:30:59 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jun 5 05:51:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 05 Jun 2007 10:51:57 +0100 Subject: [tei-council] Dictionary chapter update and proposal In-Reply-To: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> Message-ID: <4665323D.3090508@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 05 Jun 2007 10:51:57 +0100
As Laurent and I have already discussed this on a couple of occasions, I
will try to repeat here my understanding of the proposed change to
(but please note I may have got it wrong!)
1. At present we use as a way of grouping a quote-like thing with
a bibl-like thing and/or a pointer-like thing, as a means of asserting
that this quote is associated with that source.
2. However, it is certainly the case in dictionaries and not implausibly
the case elsewhere, that there lurks in the vicinity of the cit a third
thing explaining exactly why or how this quote is being used (plus or
minus its attribution) in this context, which it would be more
convenient to regard as a child of the cit than as a sibling of it
3. I have suggested that model.noteLike would do for this purpose, but
Laurent feels that a more specific class is needed -- his proposed
model.citDesc
Laurent's note includes a long list of utterly splendid examples, which
I would like to read through and comment on at length, but just to
illustrate how the proposal works, consider the following one:




and
any are used with
more


Give me more
s@'mO:(r)



Under sense 4 of "some", there is a cit which wraps both a quote "Give
me _ more" (the is a reference to the element containing
"some", a specialized ptr if you like) and a note about how this
particular example should be pronounced. The doesn't belong to
the sense, and it doesn't belong, really, to the headword "some" --
just to this quotation.
I think we should try to get this change into P5 in some shape: it will
simplify the dictionary chapter and may be useful elsewhere. What do
others think?
Lou

Laurent Romary wrote:
> Dear all,
> Since our last meeting we been going through the PD chapter, trying to
> see room for improvement.
//
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 05 2007 - 05:54:37 EDT

From cwittern at gmail.com Thu Jun 7 03:52:12 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 07 Jun 2007 16:52:12 +0900 Subject: [tei-council] Dictionary chapter update and proposal In-Reply-To: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> Message-ID: <4667B92C.7020406@gmail.com>
From: Wittern Christian
Date: Thu, 07 Jun 2007 16:52:12 +0900
Laurent Romary wrote:
> Dear all,
> Since our last meeting we been going through the PD chapter, trying to
> see room for improvement. Element descriptions will thus be completed
> by appropriate examples and tiny editorial improvements made (before
> the more extensive linguistic editing that Lou would like to do on the
> chapter).
> I would like to address here a specific issue related to a change we
> would like to operate on the technical content of the chapter: using
> in replacement to and . This follows a
> discussion I had with Lou (and technical fights with Roma), where we
> tried to revisit the intrinsic complexity of various elements in the
> disctionary chapter which seem more or less to express the same
> structure as , namely and .
> A replacement by would imply among other thing to introduce a
> class (model.citDesc) in the content model of to which one could
> attach whatever kind of descriptive elements (dictionnary elements in
> the case of the dictionary module, but I could anticipate useful
> applications in many domains). I think we do have here a very nice
> simplification of quite a generic structure and would really like to
> have it endorsed by the council.
> I am thus asking you:
> a) your opinion about the thing
The scope and intent seems right on spot.
> b) your green light to put it on the P5 1.0 agenda
I would like to see this in P5 1.0. I think we already agreed in Berlin
that given the timescale no big changes can be made. However, the
things you propose look more like a cleanup than a major revision so I
think it is very much in the range of things that can be done.
(I will need to look at the examples in more detail later.)
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 07 2007 - 03:52:18 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jun 7 12:31:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 07 Jun 2007 17:31:17 +0100 Subject: [tei-council] Gentle intro updated Message-ID: <466832D5.6060508@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 07 Jun 2007 17:31:17 +0100
As promised earlier (in "a few days", hmm), I am pleased to announce
that I have now finished a major rewrite of the "Gentle Introduction to
XML" chapter of the Guidelines.
The draft is checked into SF at the usual place, and there is also a
printable PDF for your reading pleasure at
http://www.tei-c.org/Drafts/FASC-SG.pdf
This revision reflects primarily the action placed on me to get rid of
all the DTD specific material, but I've taken the opportunity to rework
a lot of the rest as well, bringing it a bit more up to date in line
with its primary function of giving the novice reader just enough
technical information to stand a chance of understanding the rest of the
Guidelines, but certainly no more.
I would much appreciate notification of any typos, blunders, materials
omitted or egregious nonsense Council members care to identify before
posting it more widely.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 07 2007 - 12:36:11 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Jun 7 14:30:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 07 Jun 2007 19:30:06 +0100 Subject: [tei-council] that footnote Message-ID: <46684EAE.8050002@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 07 Jun 2007 19:30:06 +0100
Just for the record, I promised to report the result of my request for
suggested reading on XML.

Sebastian suggested:
http://www.zvon.org/
http://www.w3schools.com/xml/default.asp
http://xml.coverpages.org/
James suggested:
1) W3Schools: http://www.w3schools.com/xml/
2) Zvon: http://www.zvon.org/xxl/XMLTutorial/General/book.html
3) Norm Walsh: http://www.zvon.org/xxl/XMLTutorial/General/book.html
(though now dated)
4) XML.org list of resources:
http://www.xml.org/xml/resources_focus_beginnerguide.shtml
5) Tizag XML tutorial: http://www.tizag.com/xmlTutorial/
Bonus) I hear that the IBM XML tutorial is good, but I've not tried it:
http://www.ibm.com/developerworks/edu/x-dw-xmlintro-i.html
Daniel suggested:
I don't have five: I came from SGML which I learned from the Gentle
introduction and the Spec.
But here's one I used to learn XSLT and figure out my transition from
SGML to XML:
http://www.amazon.com/exec/obidos/ASIN/0764548190/ref=nosim/cafeaulaitA/
Rusty Harold, XML Bible.
And the footnote,fwiw, now reads:
New
textbooks about XML appear at regular intervals and to select any one
of them would be invidious. A useful list of pointers to introductory
websites is available from target="http://www.xml.org/xml/resources_focus_beginnerguide.shtml"/>;
recommended online course include target="http://www.w3schools.com/xml/default.asp"/> and

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 07 2007 - 14:33:00 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 7 16:43:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 07 Jun 2007 21:43:55 +0100 Subject: [tei-council] Tite Message-ID: <46686E0B.9050004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 07 Jun 2007 21:43:55 +0100
I propose to declare Tite finished.
I have checked in
a revised version to the TEI Exemplars area, ready
for the next release. It has records for all
the added elements, and an associated XSL stylesheet
which does the transformation from algorithmically-conformant
to directly-conformant (hence tite-acdc.xsl....).
Four points to note:
a) is declared to be

xxx

.
does any disagree
b) this means adding a "place" attribute to
, which Lou is now
doing.
c) is declared to be
d) I told the prose to use @rend on ornament instead of @type
Speak now, or forever hold your peace on these matters.

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 07 2007 - 16:43:59 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 05:38:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 08 Jun 2007 10:38:57 +0100 Subject: [tei-council] Re: Suggestions for P5 + a Manuscripts query In-Reply-To: <46690A59.6020904@ed.ac.uk> Message-ID: <466923B1.6070502@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 08 Jun 2007 10:38:57 +0100
Dear Charlie
Thanks for your note which I'm copying with this response to the TEI
Council and to Murray McGilvray. The existing element isn't
really meant for this kind of detailed codicological description: as it
currently stands it's just a prose essay. Murray McGilvray's "physical
bibliography" activity (PB) produced some more detailed proposals which
certainly do address this need (see
http://www.tei-c.org/Activities/PB/draft-0714.html) but which were not
accepted by the TEI Council in their present form; the minutes (rather
flatteringly for me!) express a preference for the approach Richard
Gartner and I sketched out ages ago (see
http://users.ox.ac.uk/~lou/wip/MS/msodd.htm#MSCOLL); more recent work
in this area has also been carried out by Dot Porter at UKY (but I can't
for the moment find a reference to it). There was some active discussion
of the PB proposals on the PB mailing list last summer, but the TEI
Council's attention has been fairly solidly engaged elsewhere in P5
since then.
Sadly, I think it's now too late to get a properly worked out proposal
for markup of physical document structure into the 1.0 release. But I
certainly think it ought to be being planned and worked on now, and
doing it as a P5 extension will make the task of subsequently
integrating it that much easier. If you'd like to work on that, your
input would be most welcome.
It's not clear from your note what exactly you're currently doing
though: presumably the fragment in your note is validated by a schema of
some sort; is there an ODD describing that schema? if not, is there
other documentation for it?

best wishes
Lou

Charlie Mansfield wrote:
> Dear Lou & Co
> We're trying to bend the P5 to describe where miniatures sit within
> folded quires in 14th C French manuscripts. See picture in PowerPoint
> attached.
>
> I've dug through
> http://www.tei-c.org/P5/Guidelines/ref-foliation.html
> to give me the tags, but I need to stretch them further, I think.
>
> I'm not sure whether I', asking for advice or just wanting to tell
> someone all this, but here goes...
>
> Recording Codicological Position of Miniatures within the Make-Up of
> Quire Bundles (with Letter-names of Artists). Note: Some folios within
> quires do not follow-through but terminate in a 'talon' or heel.
>
>
>
>
>
> Orpheus playing lyre to fish and birds
>
>
>
>
>
>
> Ignore me if this all sounds too complicated but if someone is still
> looking at mansucsript description then I'd welcome their thoughts.
>
> Best Wishes
> Charlie
>
> Charlie Mansfield
> AHRC Middle French Project
> http://www.pizan.lib.ed.ac.uk/
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 08 2007 - 05:43:54 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 10:38:26 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 08 Jun 2007 15:38:26 +0100 Subject: [tei-council] Action list from TCM30 Message-ID: <466969E2.30701@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 08 Jun 2007 15:38:26 +0100
As the action list from our meeting in Berlin, as presented in TCM 30,
is infeasibly long and indigestible, Sebastian and I have now done some
work (in consultation with Christian) on refining and prioritizing the
items it contains which refer specifically to P5 matters.
The revised document is available from
http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
It combines in one handy list all the actions from the Berlin meeting
and also from outstanding TRAC tickets, divided into (a) items still to
be done, indicating the person/s allegedly responsible; (b) a few items
where the action to be taken is either not clear to us, or needs greater
discussion by the Council (c) a heartening number of items where the
action is already complete.
It would be very helpful if Council members could scan this list for
(a) things we have overlooked or misrepresented
(b) tasks allocated to them on which they can report
Our suggestion is that this document would be a very useful way of
organizing our next telecon. If there is a substantial amount of other
business we should maybe schedule another call for that?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 08 2007 - 10:43:22 EDT
From cwittern at gmail.com Fri Jun 8 18:47:53 2007 From: cwittern at gmail.com (Wittern Christian) Date: Sat, 09 Jun 2007 07:47:53 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC Message-ID: <4669DC99.2040703@gmail.com>
From: Wittern Christian
Date: Sat, 09 Jun 2007 07:47:53 +0900
Dear Council members,
As usual I would like to collect things you think that need our
attention and would like to see on the agenda. Please send them either
to me or to the Council list. I plan to send out the draft agenda next
Monday.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 08 2007 - 18:48:14 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 19:42:46 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 09 Jun 2007 00:42:46 +0100 Subject: [tei-council] state and event Message-ID: <4669E976.9050609@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sat, 09 Jun 2007 00:42:46 +0100
Amongst other things reported from the "geog" meeting at CCH a couple of
weeks back, it was suggested that we would like to use and
as generic states and events (rather than the current persState,
placeState, orgState, etc.
As these names unfortunately collide with the existing and
elements
(which got there first) I am now proposing to rename the existing
elements, unless anyone has very strong objections.
The existing element (used only in the rather obscure context of
the Header's ) is the easy one: I propose to change it to

The existing element (used in the only slightly less obscure
context of the chapter on spoken transcription) is trickier to find a
good replacement for. Sebastian suggests which is almost
right but a bit long winded.
Does anyone have better suggestions?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 08 2007 - 19:42:50 EDT
From daniel.odonnell at uleth.ca Fri Jun 8 23:48:00 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 08 Jun 2007 21:48:00 -0600 Subject: [tei-council] state and event In-Reply-To: <4669E976.9050609@computing-services.oxford.ac.uk> Message-ID: <1181360880.18928.0.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 08 Jun 2007 21:48:00 -0600
Very good solution. I like them. Another possibility might be occurrence
instead of incident. But I don't care.
I'm glad we are moving this way.
-dan
On Sat, 2007-06-09 at 00:42 +0100, Lou's Laptop wrote:
> Amongst other things reported from the "geog" meeting at CCH a couple of
> weeks back, it was suggested that we would like to use and
> as generic states and events (rather than the current persState,
> placeState, orgState, etc.
>
> As these names unfortunately collide with the existing and
> elements
> (which got there first) I am now proposing to rename the existing
> elements, unless anyone has very strong objections.
>
> The existing element (used only in the rather obscure context of
> the Header's ) is the easy one: I propose to change it to
>
>
> The existing element (used in the only slightly less obscure
> context of the chapter on spoken transcription) is trickier to find a
> good replacement for. Sebastian suggests which is almost
> right but a bit long winded.
>
> Does anyone have better suggestions?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 08 2007 - 23:49:46 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 9 04:40:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 09 Jun 2007 09:40:36 +0100 Subject: [tei-council] state and event In-Reply-To: <4669E976.9050609@computing-services.oxford.ac.uk> Message-ID: <466A6784.6090304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 09 Jun 2007 09:40:36 +0100
Lou's Laptop wrote:
>
> The existing element (used in the only slightly less obscure
> context of the chapter on spoken transcription) is trickier to find a
> good replacement for. Sebastian suggests which is almost
> right but a bit long winded.





sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 09 2007 - 04:40:40 EDT
From lou.burnard at computing-services.oxford.ac.uk Sun Jun 10 09:09:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 10 Jun 2007 14:09:41 +0100 Subject: [tei-council] @key and @ref: recap ok? Message-ID: <466BF815.1010803@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sun, 10 Jun 2007 14:09:41 +0100
About a month ago on this list we had some discussion about the
attributes used to associate a name with its referent, i.e. how do you
say that "Bill Sniggsw" in the text is actually the same person as "Wm
Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis
mutandis) how do you say that "Shipton" in your source is actually the
place located at lat/long 14.2 13.2 and formerly known as "Brycgstow".
As I work on integrating placeography outcomes into the chapter that
treats these matters, I have found it helpful to briefly summarize the
various linking attributes concerned once for all. This duplicates some
matter presented elsewhere in the Guidelines, but it seemed convenient
to recap it in this context.
I'd be very grateful if you could read it through (it's only a few
paras) and confirm (or deny) that it expresses the consensus we reached
earlier reasonably well.
-------------------------------------
Linking names and their referents

As members of the att.naming class,
many of the elements described in this chapter share the following
attributes:

These attributes are designed to support two different ways of
associating a name, of any kind, with its referent. The encoder may
use either, neither, or both in combination as appropriate. The
ref attribute should be used wherever it is possible to supply
a direct link such as a URI to indicate the location of canonical
information about the referent. For example:
That silly man
David Paul Brown has suffered
...
This encoding requires that there exist somewhere in the same document
a person element with the identifier DBP1, which
will contain canonical information about this particular person,
marked up using the elements discussed in
below. The same element might alternatively be provided by some other
document,
of course, which the same attribute could refer to by means of a URI,
as explained in :
That silly man
type="person">David Paul Brown has suffered
...


The key attribute is provided for cases where no such
direct link is required: for example because resolution of the reference is
carried out by some local convention, or because the encoder judges
that no such resolution is necessary. As an example of the first case,
a project might maintain its own local database system
containing canonical information about persons and places, each entry
in which is accessed by means of some system-specific identifier
constructed in a project-specific way from the value supplied for the
key attribute. In the module described by
chapter a similar method is used to link element
descriptions to the modules or classes to which they belong, for
example. As an example of the second case, consider the use of
well-established codifications such as country or airport codes, which
it is probably unnecessary for an encoder to expand further:

I never fly from Heathrow Airport
to France



_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 10 2007 - 09:10:04 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 12:46:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 17:46:38 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466C2AEE.6090403@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 10 Jun 2007 17:46:38 +0100
it's lovely, and I agree with it. but isn't a paragraph about @nymRef
missing at the
end?
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 10 2007 - 12:46:41 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 12:56:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 17:56:27 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466C2D3B.20108@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 10 Jun 2007 17:56:27 +0100
do you also want a sentence mentioning cRef?
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 10 2007 - 12:56:31 EDT
From daniel.odonnell at uleth.ca Sun Jun 10 17:50:52 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 15:50:52 -0600 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <1181512252.32504.0.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 10 Jun 2007 15:50:52 -0600
Seems fine to me, though I don't like unresolvable keys, even for
airports.
On Sun, 2007-06-10 at 14:09 +0100, Lou's Laptop wrote:
> About a month ago on this list we had some discussion about the
> attributes used to associate a name with its referent, i.e. how do you
> say that "Bill Sniggsw" in the text is actually the same person as "Wm
> Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis
> mutandis) how do you say that "Shipton" in your source is actually the
> place located at lat/long 14.2 13.2 and formerly known as "Brycgstow".
>
> As I work on integrating placeography outcomes into the chapter that
> treats these matters, I have found it helpful to briefly summarize the
> various linking attributes concerned once for all. This duplicates some
> matter presented elsewhere in the Guidelines, but it seemed convenient
> to recap it in this context.
>
> I'd be very grateful if you could read it through (it's only a few
> paras) and confirm (or deny) that it expresses the consensus we reached
> earlier reasonably well.
>
> -------------------------------------
>
>
Linking names and their referents
>
>

As members of the att.naming class,
> many of the elements described in this chapter share the following
> attributes:
>
> These attributes are designed to support two different ways of
> associating a name, of any kind, with its referent. The encoder may
> use either, neither, or both in combination as appropriate. The
> ref attribute should be used wherever it is possible to supply
> a direct link such as a URI to indicate the location of canonical
> information about the referent. For example:
> That silly man
> David Paul Brown has suffered
> ...
> This encoding requires that there exist somewhere in the same document
> a person element with the identifier DBP1, which
> will contain canonical information about this particular person,
> marked up using the elements discussed in
> below. The same element might alternatively be provided by some other
> document,
> of course, which the same attribute could refer to by means of a URI,
> as explained in :
> That silly man
>
> type="person">David Paul Brown has suffered
> ...


>

The key attribute is provided for cases where no such
> direct link is required: for example because resolution of the reference is
> carried out by some local convention, or because the encoder judges
> that no such resolution is necessary. As an example of the first case,
> a project might maintain its own local database system
> containing canonical information about persons and places, each entry
> in which is accessed by means of some system-specific identifier
> constructed in a project-specific way from the value supplied for the
> key attribute. In the module described by
> chapter a similar method is used to link element
> descriptions to the modules or classes to which they belong, for
> example. As an example of the second case, consider the use of
> well-established codifications such as country or airport codes, which
> it is probably unnecessary for an encoder to expand further:
>
> I never fly from Heathrow Airport
> to France
>


>

>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 10 2007 - 17:52:45 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 18:00:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 23:00:17 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <1181512252.32504.0.camel@localhost> Message-ID: <466C7471.2090003@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 10 Jun 2007 23:00:17 +0100
Daniel O'Donnell wrote:
> Seems fine to me, though I don't like unresolvable keys, even for
> airports.
>
they are not unresolvable; just that they dont
play in the world of URLs

consider

ich bin ein berliner

- the
token "de" there just the same as Lou's FR and LHR.
I think @key is following the same datatype.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 10 2007 - 18:00:20 EDT
From daniel.odonnell at uleth.ca Sun Jun 10 18:22:03 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 16:22:03 -0600 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466C7471.2090003@oucs.ox.ac.uk> Message-ID: <1181514123.32504.31.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 10 Jun 2007 16:22:03 -0600
Good 'nuff.
On Sun, 2007-06-10 at 23:00 +0100, Sebastian Rahtz wrote:
> Daniel O'Donnell wrote:
> > Seems fine to me, though I don't like unresolvable keys, even for
> > airports.
> >
> they are not unresolvable; just that they dont
> play in the world of URLs
>
>
> consider

ich bin ein berliner

- the
> token "de" there just the same as Lou's FR and LHR.
> I think @key is following the same datatype.
>
> Sebastian
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 10 2007 - 18:23:56 EDT
From daniel.odonnell at uleth.ca Sun Jun 10 18:24:23 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 16:24:23 -0600 Subject: [tei-council] state and event In-Reply-To: <466A6784.6090304@oucs.ox.ac.uk> Message-ID: <1181514263.32504.33.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 10 Jun 2007 16:24:23 -0600
Or, begging indulgence and forgiveness in advance:

(it also happens).
-dan
On Sat, 2007-06-09 at 09:40 +0100, Sebastian Rahtz wrote:
> Lou's Laptop wrote:
> >
> > The existing element (used in the only slightly less obscure
> > context of the chapter on spoken transcription) is trickier to find a
> > good replacement for. Sebastian suggests which is almost
> > right but a bit long winded.
>
>
>
>
>
>
>
>
>
> sebastian
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 10 2007 - 18:26:15 EDT
From cwittern at gmail.com Sun Jun 10 21:54:56 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 11 Jun 2007 10:54:56 +0900 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466CAB70.6020202@gmail.com>
From: Wittern Christian
Date: Mon, 11 Jun 2007 10:54:56 +0900
Seems fine to me as well, modulo the possible additions mentioned by SR.
All the best,
Christian
Lou's Laptop wrote:
> About a month ago on this list we had some discussion about the
> attributes used to associate a name with its referent, i.e. how do you
> say that "Bill Sniggsw" in the text is actually the same person as "Wm
> Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis
> mutandis) how do you say that "Shipton" in your source is actually the
> place located at lat/long 14.2 13.2 and formerly known as "Brycgstow".
>
> As I work on integrating placeography outcomes into the chapter that
> treats these matters, I have found it helpful to briefly summarize the
> various linking attributes concerned once for all. This duplicates
> some matter presented elsewhere in the Guidelines, but it seemed
> convenient to recap it in this context.
>
> I'd be very grateful if you could read it through (it's only a few
> paras) and confirm (or deny) that it expresses the consensus we
> reached earlier reasonably well.
>
> -------------------------------------
>
>
Linking names and their referents
>
>

As members of the att.naming class,
> many of the elements described in this chapter share the following
> attributes:
>
> These attributes are designed to support two different ways of
> associating a name, of any kind, with its referent. The encoder may
> use either, neither, or both in combination as appropriate. The
> ref attribute should be used wherever it is possible to supply
> a direct link such as a URI to indicate the location of canonical
> information about the referent. For example:
> That silly man
> David Paul Brown has suffered
> ...
> This encoding requires that there exist somewhere in the same document
> a person element with the identifier DBP1, which
> will contain canonical information about this particular person,
> marked up using the elements discussed in
> below. The same element might alternatively be provided by some other
> document,
> of course, which the same attribute could refer to by means of a URI,
> as explained in :
> That silly man
>
> type="person">David Paul Brown has suffered
> ...


>

The key attribute is provided for cases where no such
> direct link is required: for example because resolution of the
> reference is
> carried out by some local convention, or because the encoder judges
> that no such resolution is necessary. As an example of the first case,
> a project might maintain its own local database system
> containing canonical information about persons and places, each entry
> in which is accessed by means of some system-specific identifier
> constructed in a project-specific way from the value supplied for the
> key attribute. In the module described by
> chapter a similar method is used to link element
> descriptions to the modules or classes to which they belong, for
> example. As an example of the second case, consider the use of
> well-established codifications such as country or airport codes, which
> it is probably unnecessary for an encoder to expand further:
>
> I never fly from Heathrow Airport
> to France
>


>

>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 10 2007 - 21:55:03 EDT

From Syd_Bauman at Brown.edu Sun Jun 10 23:14:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 10 Jun 2007 23:14:05 -0400 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <4669DC99.2040703@gmail.com> Message-ID: <18028.48637.741251.58018@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 10 Jun 2007 23:14:05 -0400
First, I just want to verify that the upcoming conference call is
scheduled for this coming Friday 15 June at 12:00 UTC[1].

> As usual I would like to collect things you think that need our
> attention and would like to see on the agenda. Please send them
> either to me or to the Council list. I plan to send out the draft
> agenda next Monday.
I do have one item that, if we had time, I would have wanted to run
past Sebastian first for a feasibility check. However ...
Council has charged me with implementing Schematron rules in the
Guidelines for expressing a variety of constraints that are not
expressed in the RELAX NG schemas produced by the ODDs. A very large
percentage, probably even a large majority, of these rules are going
to be of the form "the X= attribute of should point to a ".
While at the DH conference at UIUC, I saw a very interesting poster
by Kevin Reiss of CUNY. His major point for our purposes was to
better describe the semantics of XML languages by some extensions to
ODD.
I quickly noticed three major useful suggestions in his poster. One
for describing the inheritance of attribute and one for describing
the semantics of child elements. I think both of these are good
ideas, but I think they require more fleshing out and more work on
the Guidelines than is feasible for inclusion in P5 1.0. However, his
third suggestion is directly apropos to the issue described above,
and I think may well be reasonable to include in P5 1.0.
I have revised his extension a little; here it is.
We add a references= attribute to which could be used only if
the datatype of the attribute being defined was data.pointer.[2] The
references= attribute itself has a datatype of data.name, and gives
the name of the element type to which the pointer attribute being
defined should point. The ODD processor would generate the Schematron
needed to validate that instances of the pointer attribute actually
pointed to elements of the type named on references=.[3]
Problem: what would the message in the generated content of the
or be? I haven't even thought about it yet,
but I doubt it's a show-stopper. This does, however, violate the "no
new additions post Berlin" idea.

Notes
-----
[1] 06:00 MDT in Calgary,
07:00 CDT in Chicago,
08:00 EDT in New York,
13:00 BST in London,
14:00 CEST in Paris,
21:00 JST in Kyoto, and
Sat 06-16 00:00 NZST in Wellington.
[2] I.e.,

The
@references attribute may only be used if the attribute being
defined is a pointer.

[3] I'm not 100% on what the Schematron for this would be, in part
because I haven't figured out if ISO Schematron is well enough
implemented we can and should use it (I suspect it is), or if the
document() function has been implemented properly ala the XSLT
2.0 specification or not. Shouldn't be too hard to test, just
haven't gotten to it yet.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jun 10 2007 - 23:14:10 EDT

From cwittern at gmail.com Mon Jun 11 03:16:21 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 11 Jun 2007 16:16:21 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466CF6C5.6050806@gmail.com>
From: Wittern Christian
Date: Mon, 11 Jun 2007 16:16:21 +0900
Syd Bauman wrote:
> First, I just want to verify that the upcoming conference call is
> scheduled for this coming Friday 15 June at 12:00 UTC[1].
>
Yes, that is correct.
> I have revised his extension a little; here it is.
>
> We add a references= attribute to which could be used only if
> the datatype of the attribute being defined was data.pointer.[2] The
> references= attribute itself has a datatype of data.name, and gives
> the name of the element type to which the pointer attribute being
> defined should point. The ODD processor would generate the Schematron
> needed to validate that instances of the pointer attribute actually
> pointed to elements of the type named on references=.[3]
>
So the question seems to be whether to add this @references and what
implications this might have. I think this is more suitable to
discussion here (with some examples and running code), rather than
spending time on this at the call.
> Problem: what would the message in the generated content of the
> or be? I haven't even thought about it yet,
> but I doubt it's a show-stopper. This does, however, violate the "no
> new additions post Berlin" idea.
>
This will not so much be a new item, but rather part of your dealing
with the existing action item, so I do not see how this is affected by
that rule.

Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 03:16:28 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 11 04:05:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 11 Jun 2007 09:05:26 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466D0246.8040709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 11 Jun 2007 09:05:26 +0100
Syd Bauman wrote:
> Council has charged me with implementing Schematron rules in the
> Guidelines for expressing a variety of constraints that are not
> expressed in the RELAX NG schemas produced by the ODDs. A very large
> percentage, probably even a large majority, of these rules are going
> to be of the form "the X= attribute of should point to a ".
>
it might help if you listed the outstanding rules
you have to implement using Schematron? I am bit
nonplussed by the assertion. Maybe I need a cup
of tea
> I quickly noticed three major useful suggestions in his poster. One
> for describing the inheritance of attribute and one for describing
> the semantics of child elements.
would be interesting to hear more about these
> We add a references= attribute to which could be used only if
> the datatype of the attribute being defined was data.pointer.[2] The
> references= attribute itself has a datatype of data.name, and gives
> the name of the element type to which the pointer attribute being
> defined should point.
so must point to a
somewhere, for example? but that's not true, is it?
If it pointed to www.example.com/person.php?ID=SYD,
did we ever say that must return a ?
are you sure that ISO Schematron supports using of
document() to access remote resources? what do you
do if the site is unreachable?
wearing my ODD programmer hat, implementing your
proposal would be pretty easy, I think. My concern
is simply whether there are enough cases to justify it.
examples, please......
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 04:05:30 EDT
From James.Cummings at oucs.ox.ac.uk Mon Jun 11 04:15:06 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 11 Jun 2007 09:15:06 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466CAB70.6020202@gmail.com> Message-ID: <466D048A.5050305@oucs.ox.ac.uk>
From: James Cummings
Date: Mon, 11 Jun 2007 09:15:06 +0100
Wittern Christian wrote:
> Seems fine to me as well, modulo the possible additions mentioned by SR.
Me too
(esp. a paragraph distinguishing nymKey from key).
-James
>
> All the best,
>
> Christian
>
> Lou's Laptop wrote:
>> About a month ago on this list we had some discussion about the
>> attributes used to associate a name with its referent, i.e. how do you
>> say that "Bill Sniggsw" in the text is actually the same person as "Wm
>> Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis
>> mutandis) how do you say that "Shipton" in your source is actually the
>> place located at lat/long 14.2 13.2 and formerly known as "Brycgstow".
>>
>> As I work on integrating placeography outcomes into the chapter that
>> treats these matters, I have found it helpful to briefly summarize the
>> various linking attributes concerned once for all. This duplicates
>> some matter presented elsewhere in the Guidelines, but it seemed
>> convenient to recap it in this context.
>>
>> I'd be very grateful if you could read it through (it's only a few
>> paras) and confirm (or deny) that it expresses the consensus we
>> reached earlier reasonably well.
>>
>> -------------------------------------
>>
>>
Linking names and their referents
>>
>>

As members of the att.naming class,
>> many of the elements described in this chapter share the following
>> attributes:
>>
>> These attributes are designed to support two different ways of
>> associating a name, of any kind, with its referent. The encoder may
>> use either, neither, or both in combination as appropriate. The
>> ref attribute should be used wherever it is possible to supply
>> a direct link such as a URI to indicate the location of canonical
>> information about the referent. For example:
>> That silly man
>> David Paul Brown has suffered
>> ...
>> This encoding requires that there exist somewhere in the same document
>> a person element with the identifier DBP1, which
>> will contain canonical information about this particular person,
>> marked up using the elements discussed in
>> below. The same element might alternatively be provided by some other
>> document,
>> of course, which the same attribute could refer to by means of a URI,
>> as explained in :
>> That silly man
>>
>> type="person">David Paul Brown has suffered
>> ...


>>

The key attribute is provided for cases where no such
>> direct link is required: for example because resolution of the
>> reference is
>> carried out by some local convention, or because the encoder judges
>> that no such resolution is necessary. As an example of the first case,
>> a project might maintain its own local database system
>> containing canonical information about persons and places, each entry
>> in which is accessed by means of some system-specific identifier
>> constructed in a project-specific way from the value supplied for the
>> key attribute. In the module described by
>> chapter a similar method is used to link element
>> descriptions to the modules or classes to which they belong, for
>> example. As an example of the second case, consider the use of
>> well-established codifications such as country or airport codes, which
>> it is probably unnecessary for an encoder to expand further:
>>
>> I never fly from Heathrow Airport
>> to France
>>


>>

>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 04:15:10 EDT

From arianna.ciula at kcl.ac.uk Mon Jun 11 06:10:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 11 Jun 2007 11:10:43 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466D1FA3.6000900@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 11 Jun 2007 11:10:43 +0100
I agree with this plus the additions mentioned by Sebastian. A small
observation:

Lou's Laptop wrote:
The
> ref attribute should be used wherever it is possible to supply
> a direct link such as a URI to indicate the location of canonical
> information about the referent. For example:
> That silly man
> David Paul Brown has suffered
> ...
> This encoding requires that there exist somewhere in the same document
> a person element with the identifier DBP1, which
> will contain canonical information about this particular person,
> marked up using the elements discussed in
> below. The same element might alternatively be provided by some other
> document,
> of course,...
May be I am reading too much here, but it seems that this second option
(i.e. having your list of persons/places, for instance, in another TEI
document) as it is written in this prose is less preferred, while I
think it will be the most used/useful especially for those projects that
have a gazetteer or a substantial set of persons.
Arianna
_______________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 06:12:44 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jun 11 06:10:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 11 Jun 2007 11:10:55 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466D1FA3.6000900@kcl.ac.uk> Message-ID: <466D1FAF.7010200@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 11 Jun 2007 11:10:55 +0100
Arianna Ciula wrote:
>
>
> Lou's Laptop wrote:
> The
>> ref attribute should be used wherever it is possible to supply
>> a direct link such as a URI to indicate the location of canonical
>> information about the referent. For example:
>> That silly man
>> David Paul Brown has suffered
>> ...
>> This encoding requires that there exist somewhere in the same document
>> a person element with the identifier DBP1, which
>> will contain canonical information about this particular person,
>> marked up using the elements discussed in
>> below. The same element might alternatively be provided by some other
>> document,
>> of course,...
>
> May be I am reading too much here, but it seems that this second option
> (i.e. having your list of persons/places, for instance, in another TEI
> document) as it is written in this prose is less preferred, while I
> think it will be the most used/useful especially for those projects that
> have a gazetteer or a substantial set of persons.

"alternatively" certainly isn't meant to imply "second best", as the "of
course" is meant to show. But if it doesn't work, I'll try to improve
the wording.

>
> Arianna
>
> _______________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jun 11 2007 - 06:16:00 EDT

From cwittern at gmail.com Mon Jun 11 21:04:20 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 12 Jun 2007 10:04:20 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466DF114.80703@gmail.com>
From: Wittern Christian
Date: Tue, 12 Jun 2007 10:04:20 +0900
Syd Bauman wrote:
> First, I just want to verify that the upcoming conference call is
> scheduled for this coming Friday 15 June at 12:00 UTC[1].
>
Now I see why you ask: I just realized that I originally announced the
meeting for *today*, Tue 12, 2007. Obviously this can not work anymore
and in terms of availability according to meet-o-matic, Friday is as
good, except that we have to do without Tone Merete:-(, but on the
positive side, we gain David Birnbaum:-).
My apologies for this confusion!
All the best,
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 21:04:43 EDT
From cwittern at gmail.com Mon Jun 11 21:14:48 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 12 Jun 2007 10:14:48 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC Message-ID: <466DF388.9090409@gmail.com>
From: Wittern Christian
Date: Tue, 12 Jun 2007 10:14:48 +0900
DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC
Expected to participate:
Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James
Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian
Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
excused: Tone Merete Bruvik
============================================================
How to connect:
We will use the highspeedconferencing.com service again.
Participants can use their skype account (www.skype.com) or regular
phones to call. When calling via skype, *please use a headset*. If
in doubt, it might be better to call via regular phone. Numbers as follow:
>From Skype call +99008278525675
In the US, call 1-712-432-4000
Calling from Europe, call
In Austria: 0820 400 01562
In Belgium: 0703 59 984
In France: 0826 100 266
In Germany 01805 00 7620
In UK: 0870 119 2350
other places: call to US:-(
Enter Conference Room Number : 5326922
(this is Sebastian's Conference room)
============================================================
Please read through the following (including the linked pages) before
the meeting.
============================================================
1) Open action items
There are a lot of open action items registered in TRAC. The planning-and-deadline
sub committee (DSC) has tried to organize them in a more coherent list also
ordered by importance and degree of difficulty, available at
http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
The DSC members have individually contacted the action holders and
inquired about progress. We will start with reports from the DSC.
* Consolidated reports on outstanding actions from Daniel, Sebastian and
Christian
[we will try to get these also in writing to the council list prior to
the meeting]
2) To discuss
Some of the items scheduled for action in Berlin look a bit unclear or
need further discussion. We should briefly try to clarify these
issues:
* (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge corpus
chapter into DS.
* (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think
ST and its position in the Guidelines soon
* (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re-work NH
3) Reports
* Places meeting at Kings. (Arianna / Lou)
* ISO FSD activity (LR)
4) Further planning
* The main question here is how much time we can allow for solving the
remaining technical issues and how to divide up the tasks.
Again, please have a careful look at
http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap
5) next meeting
Mid/end of July
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 11 2007 - 21:15:05 EDT
From laurent.romary at loria.fr Tue Jun 12 03:26:25 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 12 Jun 2007 09:26:25 +0200 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466DF114.80703@gmail.com> Message-ID: <10655074-5816-4C8A-A034-6529BBEF8D0E@loria.fr>
From: Laurent Romary
Date: Tue, 12 Jun 2007 09:26:25 +0200
I see too. I was about to ask the number to which I should connect
this afternoon... I have a meeting just before the newly planned call
on Friday and may arrive a little late.
Best,
Laurent
Le 12 juin 07 ? 03:04, Wittern Christian a ?crit :
> Syd Bauman wrote:
>> First, I just want to verify that the upcoming conference call is
>> scheduled for this coming Friday 15 June at 12:00 UTC[1].
>>
> Now I see why you ask: I just realized that I originally announced
> the meeting for *today*, Tue 12, 2007. Obviously this can not work
> anymore and in terms of availability according to meet-o-matic,
> Friday is as good, except that we have to do without Tone Merete:-
> (, but on the positive side, we gain David Birnbaum:-).
> My apologies for this confusion!
>
> All the best,
>
> --
>
> Christian Wittern Institute for Research in Humanities, Kyoto
> University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 03:28:03 EDT
From tone.bruvik at aksis.uib.no Tue Jun 12 06:06:28 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Tue, 12 Jun 2007 12:06:28 +0200 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <466DF388.9090409@gmail.com> Message-ID: <14F39CC5-64AC-413D-AC9E-966E13A10831@aksis.uib.no>
From: Tone Merete Bruvik
Date: Tue, 12 Jun 2007 12:06:28 +0200
As I will not be able to attend the teleconference, I think I should
say something on the re-work of NH - Multiple Hierarchies:
1. At the council meeting in Berlin we agreed upon that this chapter
has to be rewritten with particularly this in mind:
- NH should be make into a chapter again. We did not decide that,
but I think we pretty much agreed upon that. Where should it be
placed , at the end?
- The chapter has to be far clearer about which solutions are
available in P5, which are implementable in P5, and which are not.
(This is of course a major task.)
- I suggested that there should be pointers to template or exemplar
ODDs demonstrating how to implement those solutions that can be.
2. There are some minor errors that should be corrected, see Trac
Tickets #236, #237 and #238.
Syd and me have this job assigned to us, and I have to admit that I
have not work much on this lately. My plan was to work on this
chapter during the next 2 weeks, and then again in August. What I
will do first is to find some new samples (and I has thinking of
asking Claus Huitfeldt if he could give some of his samples to be
used here).
Syd, what are you view on this chapter and our work on it? I guess we
need to have a schedule to give to the council on what we should do
and when?

Tone Merete Bruvik
tone.bruvik_at_aksis.uib.no
---- The Research Group for Text Technology - Aksis (The Department of Culture, Language and Information Technology), Unifob AS All?gaten 27 - N-5020 Bergen, Norway Den 12. jun. 2007 kl. 03.14 skrev Wittern Christian: > > DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at > 1200 UTC > > Expected to participate: > > Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James > Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian > Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern > > excused: Tone Merete Bruvik > > ============================================================ > How to connect: > > We will use the highspeedconferencing.com service again. > > Participants can use their skype account (www.skype.com) or regular > phones to call. When calling via skype, *please use a headset*. If > in doubt, it might be better to call via regular phone. Numbers as > follow: > >> From Skype call +99008278525675 > In the US, call 1-712-432-4000 > Calling from Europe, call > In Austria: 0820 400 01562 > In Belgium: 0703 59 984 > In France: 0826 100 266 > In Germany 01805 00 7620 > In UK: 0870 119 2350 > other places: call to US:-( > Enter Conference Room Number : 5326922 > (this is Sebastian's Conference room) > ============================================================ > > Please read through the following (including the linked pages) before > the meeting. > > ============================================================ > > 1) Open action items > > There are a lot of open action items registered in TRAC. The > planning-and-deadline > sub committee (DSC) has tried to organize them in a more coherent > list also > ordered by importance and degree of difficulty, available at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > The DSC members have individually contacted the action holders and > inquired about progress. We will start with reports from the DSC. > > * Consolidated reports on outstanding actions from Daniel, > Sebastian and > Christian > [we will try to get these also in writing to the council list > prior to > the meeting] > > 2) To discuss > > Some of the items scheduled for action in Berlin look a bit unclear or > need further discussion. We should briefly try to clarify these > issues: > > * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge > corpus > chapter into DS. > * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think > ST and its position in the Guidelines soon > * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re- > work NH > > 3) Reports > > * Places meeting at Kings. (Arianna / Lou) > > * ISO FSD activity (LR) > > 4) Further planning > > * The main question here is how much time we can allow for solving the > remaining technical issues and how to divide up the tasks. > Again, please have a careful look at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap > > 5) next meeting > Mid/end of July > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 12 2007 - 06:06:34 EDT

From Syd_Bauman at Brown.edu Tue Jun 12 14:47:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 14:47:45 -0400 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466DF114.80703@gmail.com> Message-ID: <18030.59985.661920.836809@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 12 Jun 2007 14:47:45 -0400
> Now I see why you ask: I just realized that I originally announced
> the meeting for *today*, Tue 12, 2007.
Ah! And I thought I just put it on my calendar incorrectly. Thanks
for clarifying. Talk to you Fri!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 14:47:49 EDT
From daniel.odonnell at uleth.ca Tue Jun 12 15:09:53 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 12 Jun 2007 13:09:53 -0600 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18030.59985.661920.836809@emt.wwp.brown.edu> Message-ID: <1181675393.24880.0.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 12 Jun 2007 13:09:53 -0600
Me too! It was like a confederacy of dunces.
-dan
On Tue, 2007-06-12 at 14:47 -0400, Syd Bauman wrote:
> > Now I see why you ask: I just realized that I originally announced
> > the meeting for *today*, Tue 12, 2007.
>
> Ah! And I thought I just put it on my calendar incorrectly. Thanks
> for clarifying. Talk to you Fri!
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 12 2007 - 15:12:03 EDT
From dporter at uky.edu Tue Jun 12 16:25:37 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 12 Jun 2007 16:25:37 -0400 Subject: [tei-council] List of items from Berlin Message-ID: <96f3df640706121325h39bde542k5005ae89faeea548@mail.gmail.com>
From: Dot Porter
Date: Tue, 12 Jun 2007 16:25:37 -0400
Hello all,
Here is a complete list of errors from the three chapters I checked
for the Berlin meeting. Sorry to take so long to get them to the list,
but most of my original comments have already been dealt with by the
editors.
19: Language Corpora
all recommended changes made
7: Transcription of Speech
7.3: "To enable these modules, the appropriate parameter entities must
be declared in the document type declaration subset, as described in
section 1.2 Defining a TEI schema." Should there be here instead a
reference to specifying modules in the ODD, or just a more general
declaring modules in DTD or schema languages?
7.3.1: I believe that there is an incorrect usage of in the
second example. According to its definition in 3.4.3, "
(deletion) contains a letter, word or passage deleted, marked as
deleted, or otherwise indicated as superfluous or spurious in the copy
text by an author, scribe, annotator, or corrector." But its usage in
the example is described as "This example also uses the core elements
and to mark editorial decisions concerning matter
completely omitted from the transcript (because of inaudibility), and
words which have been transcribed but which the transcriber considers
may be deleted, respectively." Either the example needs to be changed
to reflect accepted practice or the description needs to be clarified
(what does it mean when a transcriber considers that something may be
deleted? I don't think that makes sense.)
7.3.4: This section includes an example of defining entities to
represent prosodic features. The entire discussion assumes that the
editor is using DTDs. If there is another method for doing the same
thing in ODD/RNG this section should be changed.
OTOH at the end of my notes I say "Chapter needs to be rewritten!" and
I believe we discussed this in Berlin.
10: Linking
10.4.3: Three-way alignment. This section needs to be reexamined in
light of the current work on facsimile/image markup, and I am working
on this currently.

These are all the comments I had left over from Berlin. Everything
else in my notes has been changed.
Thanks,
Dot

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 12 2007 - 16:25:43 EDT

From Syd_Bauman at Brown.edu Tue Jun 12 17:20:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 17:20:38 -0400 (EDT) Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466D0246.8040709@oucs.ox.ac.uk> Message-ID: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu>
From: Syd Bauman
Date: Tue, 12 Jun 2007 17:20:38 -0400 (EDT)
> it might help if you listed the outstanding rules you have to
> implement using Schematron? I am bit nonplussed by the assertion.
What assertion? Yes, it would help if I provided a list, but since
creating such a list is a large part of the project ...
In the meantime, here is a list of some that we considered candidates
back in summer 2005:
---------
active= should point to a or , pending work on prosopography
adj= should point to one or more s
adjFrom= should point to one or more s
adjTo= should point to one or more s
children= should point to one or more s or s
children= should point to one or more s or s
class= should point to a or child of a ? ask MS
class= should point to a or child of a ? ask MS
code= should point to a element
code= should point to a element
end= %tei.timed; should point to a
exclude= %tei.linking; should point to one or more members of the tei.declarable class
feats= should point to one or more s
follow= should point to an or
follow= should point to an or
from= should point to a
given= should point to a different or a

?
hand= %tei.readings; should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
hand= should point to a
location= %tei.dictionaries; should point to an
new= should point to a
next= %tei.linking; should point to an element of same type
old= should point to a
origin= should point to one of its own children
parent= should point to an , , or
parent= should point to an , , or
passive= should point to a or , pending work on prosopography
perf= should point to one or more s
perf= should point to one or more s
prev= %tei.linking; should point to an element of same type
ref= should point to a or a
render= should point to a element
resp= %tei.interpret; should point to a tei.naming or element
resp= %tei.readings; should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= should point to a tei.naming or element
resp= %tei.intervention; should point to a tei.naming or element
role= should point to a ??
role= should point to a ??
scheme= should point to a element
scheme= should point to a element
scheme= should point to a element
scheme= should point to a element
scheme= should point to a element
scribe= should point to a tei.naming or element?
script= should point to a , , , or (maybe) ?
select= %tei.linking; should point to one or more of its own descendants
since= should point to a sibling
source= should point to a tei.naming, , , , , or
start= %tei.timed; should point to a
target= %tei.formPointers; should point to an , , or


target= should point to elements
target= should point to a
target= should point to a
target= should point to a
to= should point to a
url= should point to a (file whose root is a) ?
who= %tei.ascribed; should point to a or , pending work on prosopography

> would be interesting to hear more about these
I don't think it's up on the web yet ...

> so must point to a
> somewhere, for example? but that's not true, is it?
> If it pointed to www.example.com/person.php?ID=SYD,
> did we ever say that must return a ?
I was not privy to the discussions about ref= of , so I can't
say. Perhaps it is a reasonable restriction that it point to a TEI
or element, though. If you want to refer to some
external database either
* you shouldn't use ref=, or
* you should point to it from the entry, no?

> are you sure that ISO Schematron supports using of document() to
> access remote resources?
Yes, I think it does. I even think that it is supposed to support use
of fragment identifiers. What I don't know is if any implementations
actually do this or not.

> what do you do if the site is unreachable?
I would say throw a warning that it can't be tested and go on, but I'm
not sure Schematron implementations let you do that or not.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 17:20:42 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jun 12 17:40:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 12 Jun 2007 22:40:49 +0100 Subject: [tei-council] List of items from Berlin In-Reply-To: <96f3df640706121325h39bde542k5005ae89faeea548@mail.gmail.com> Message-ID: <466F12E1.5090109@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 12 Jun 2007 22:40:49 +0100
Dot Porter wrote:
>
> Here is a complete list of errors from the three chapters I checked
> for the Berlin meeting. Sorry to take so long to get them to the list,
> but most of my original comments have already been dealt with by the
> editors.
Thanks Dot!
>
> 7: Transcription of Speech
> 7.3: "To enable these modules, the appropriate parameter entities must
> be declared in the document type declaration subset, as described in
> section 1.2 Defining a TEI schema." Should there be here instead a
> reference to specifying modules in the ODD, or just a more general
> declaring modules in DTD or schema languages?
All such references should refer to the same place and should be in
approximately the same form; the one in this chapter seems to have
escaped. But not for long!
> 7.3.1: I believe that there is an incorrect usage of in the
> second example.
This is a rather strange use of I agree, but not I think
completely wrong. The problem is that the transcriber (this is a real
example, by the way, not one I made up!) is interested in the kinds of
segment primarily, and wants to show that for the purpose of
segmentation the repeated words should be deleted. In the original
typescript they do this by transcribing it and then... deleting it (with
overstriking). So that's what I have encoded. I have tried to reword it
a bit to explain what's going on.

>
> 7.3.4: This section includes an example of defining entities to
> represent prosodic features. The entire discussion assumes that the
> editor is using DTDs. If there is another method for doing the same
> thing in ODD/RNG this section should be changed.
>
Indeed it should, and has been.
> OTOH at the end of my notes I say "Chapter needs to be rewritten!" and
> I believe we discussed this in Berlin.
>
Well, certainly the chapter is in need of a spring clean, but I can't
see that happening in the next month, so it's probably not going to get
done for P5.

> 10: Linking
> 10.4.3: Three-way alignment. This section needs to be reexamined in
> light of the current work on facsimile/image markup, and I am working
> on this currently.
>
I see Conal has just posted a whole mass of things. Hoorah!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 17:44:12 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 12 17:45:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 12 Jun 2007 22:45:14 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> Message-ID: <466F13EA.2020701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 12 Jun 2007 22:45:14 +0100
Syd Bauman wrote:
> In the meantime, here is a list of some that we considered candidates
> back in summer 2005:
>
your memory or records are better than mine!
ok, your list is quite convincing. if you write
the spec, I guess I'll try to implement it in due course.
HOWEVER, I would suggest that implementing
all this (both on your part and my part)
is very much a luxury. If all the other
work gets done, then it would be nice to
get it in place for 1.0. But I'd suggest that
most of the long list of other tasks to be done should take
precedence.
consider than we reshould really freeze the Specs on August 1st
for a November 1st release, and then consider that this
is about 7 weeks away...
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 17:45:35 EDT
From Syd_Bauman at Brown.edu Tue Jun 12 20:43:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 20:43:11 -0400 Subject: [tei-council] mimeType= Message-ID: <18031.15775.225195.541353@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 12 Jun 2007 20:43:11 -0400
We now have 4 elements which each individually declare a mimeType=
attribute.
attribute mimeType { data.word }?, mwa
The MIME type to be used for the object when it is decoded
attribute mimeType { data.word }?, opt
MIME type of external filter script
attribute mimeType { data.word }?, mwa
The MIME type
attribute mimeType { text }?, [defaults to opt]
supplies a MIME type for the content of this element.

Recommendation
--------------
New class, att.internetMedia (or whatever) that defines the mimeType=
attribute as 'mwa' with datatype data.word, and a description of
"specifies the applicable multimedia internet mail extension (MIME)
media type". These four elements become members of this class. The
remarks element for this class would include a reference to the MIME
type registry (http://www.iana.org/assignments/media-types/).
This means that the information about *what* the attribute is the
MIME type for, and (in the case of ) that the contents
need to be decoded before the MIME type applies, will need to be
noted in the remarks section of the tagdoc for the element.
It's also a real change in the case of , from optional to
mandatory when applicable.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 12 2007 - 20:43:15 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Jun 13 03:37:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 13 Jun 2007 08:37:59 +0100 Subject: [tei-council] mimeType= In-Reply-To: <18031.15775.225195.541353@emt.wwp.brown.edu> Message-ID: <466F9ED7.8010001@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 13 Jun 2007 08:37:59 +0100
Sounds like an open and shut case to me : plz do it forthwith
Syd Bauman wrote:
> We now have 4 elements which each individually declare a mimeType=
> attribute.
>
> attribute mimeType { data.word }?, mwa
> The MIME type to be used for the object when it is decoded
>
> attribute mimeType { data.word }?, opt
> MIME type of external filter script
>
> attribute mimeType { data.word }?, mwa
> The MIME type
>
> attribute mimeType { text }?, [defaults to opt]
> supplies a MIME type for the content of this element.
>
>
> Recommendation
> --------------
> New class, att.internetMedia (or whatever) that defines the mimeType=
> attribute as 'mwa' with datatype data.word, and a description of
> "specifies the applicable multimedia internet mail extension (MIME)
> media type". These four elements become members of this class. The
> remarks element for this class would include a reference to the MIME
> type registry (http://www.iana.org/assignments/media-types/).
>
> This means that the information about *what* the attribute is the
> MIME type for, and (in the case of ) that the contents
> need to be decoded before the MIME type applies, will need to be
> noted in the remarks section of the tagdoc for the element.
>
> It's also a real change in the case of , from optional to
> mandatory when applicable.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jun 13 2007 - 03:41:22 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 03:43:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 08:43:18 +0100 Subject: [tei-council] mimeType= In-Reply-To: <18031.15775.225195.541353@emt.wwp.brown.edu> Message-ID: <466FA016.2020707@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 13 Jun 2007 08:43:18 +0100
I agree, seems entirely reasonable
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 03:43:23 EDT
From arianna.ciula at kcl.ac.uk Wed Jun 13 05:28:11 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 13 Jun 2007 10:28:11 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> Message-ID: <466FB8AB.4090606@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 13 Jun 2007 10:28:11 +0100
Syd Bauman wrote:
> ---------
> active= should point to a or , pending work on prosopography
I think this will need to be updated: it can also point to a or
may be also and possibly in the near future.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 05:28:58 EDT
From laurent.romary at loria.fr Wed Jun 13 11:55:06 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 13 Jun 2007 17:55:06 +0200 Subject: [tei-council] Dictionary update Message-ID: <9D8830D1-056A-4F56-A0D9-3AB01C2BA82B@loria.fr>
From: Laurent Romary
Date: Wed, 13 Jun 2007 17:55:06 +0200
In complement to my previous message related to ? here's the
current state of progress with regards the dictionary chapter. I take
this opportunity to send my apologies to Seb for the extra work that
our activities have put on him (Roma still seems to be laying in bed
with fever, it seems...).
Laurent

Report - dictionary chapter (date: 13. 06. 07)
Done
* Examples added to the following element descriptions:
, , , , , ,
, , , , , , , ,

* In order to allow within : Made model.gramPart
member of model.formPart (instead of model.morphLike being member of
model.formPart)
> to be tested!

To Do
* complete missing examples in element descriptions
(working on examples from Campe: , , , )

- modify/discard the examples for , , , ,
, and depending on the decision concerning

* text guidelines:
- Changing the passages concerning , , depending
on the decision.
- Maybe adding examples for the following elements: , ,
, , ,
- Maybe adding some examples illustrating the use of some attributes?
e.g. sortKey

Problems
* Until now no (good) examples available for the following elements:
, ,
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jun 13 2007 - 11:56:38 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 12:03:00 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 17:03:00 +0100 Subject: [tei-council] Dictionary update In-Reply-To: <9D8830D1-056A-4F56-A0D9-3AB01C2BA82B@loria.fr> Message-ID: <46701534.9000302@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 13 Jun 2007 17:03:00 +0100
Laurent Romary wrote:
> I take this opportunity to send my apologies to Seb for the extra work
> that our activities have put on him (Roma still seems to be laying in
> bed with fever, it seems...).
I am glad to say that I have finally identified the problem with
term/@target which has
been plaguing us; I don't have a solution yet, but I know where to look.
If I can't solve this tonight, I shall probably scream so loudly
you'll hear me in Berlin; on the other hand, after almost
eveyrthing you can imagine going wrong in the last few
days, today has seen several things go right, so I have hopes.
I am really pleased to see Eva R getting to grips with the
sources, very positive stuff.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 12:03:05 EDT
From daniel.odonnell at uleth.ca Wed Jun 13 12:38:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 10:38:07 -0600 Subject: [tei-council] Ticket 110 Message-ID: <1181752687.9538.9.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 13 Jun 2007 10:38:07 -0600
Hi all,
I'd handled the ticket business wrong for three of mine, so I'll be
sending the comments for the council (as opposed to typos) out one after
the other.
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/110 (MS Description)
Here all the typos I'd found have been reported and fixed. There is one
issue though: custodialHistory looks to me suspiciously like the newly
redefined "event" element.
-dan
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 12:40:16 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 12:49:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 17:49:15 +0100 Subject: [tei-council] Ticket 110 In-Reply-To: <1181752687.9538.9.camel@localhost> Message-ID: <4670200B.3060205@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 13 Jun 2007 17:49:15 +0100
Daniel O'Donnell wrote:
> Here all the typos I'd found have been reported and fixed. There is one
> issue though: custodialHistory looks to me suspiciously like the newly
> redefined "event" element.
>
>
do you mean ?
but anyway, can I suggest that we hold off on this area until
the revised ND with persons, places and orgs is done? Then
someone should read that, followed by MS, and see whether
some bits of MS can be normalized using ND. Maybe
Matthew would be the best placed person to do this
with Daniel, as representing the two ends of the spectrum.[1]
A word of warning, tho - beware of cross-module
dependency. To use event, state and trait in MS
would really mean putting them in the core, or
having a simple model in MS which would
be richer if namesdates was loaded.
Personally, I think the latter is an elegant way to work,
but it would require some delicate work, which I
believe would be a distraction this month.
[1] you can decide yourself what the spectrum is :-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 12:49:19 EDT
From daniel.odonnell at uleth.ca Wed Jun 13 13:08:35 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 11:08:35 -0600 Subject: [tei-council] Trac 152 (TC) Message-ID: <1181754515.9538.17.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 13 Jun 2007 11:08:35 -0600
Here are some changes for TC:
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152
* Reverse TC and PH--This was assigned to Syd
* We should mention that app is a special form of choice in TC,
because we do so in the element description for choice: "For a
specialized version of for encoding multiple witnesses of a
single work, see section 15.1 The Apparatus Entry, Readings, and
Witnesses."
* 15.1.1: "The attributes loc, from, and to, are used to link the
apparatus entry to the base text. Several methods may be used for
such linkage, each involving a slightly different usage for these
attributes. Linkage between text and apparatus is described below in
section 15.2 Linking the Apparatus to the Text."
* * This needs clarification, since apparatus can also exist
without a base text: How about: "The attributes loc, from, and
to, are used to link the apparatus entry to the base text , if
present. In such cases, s everal methods may be used for such
linkage, each involving a slightly different usage for these
attributes. Linkage between text and apparatus is described
below in section 15.2 Linking the Apparatus to the Text. For the
use of the app element without a base text see... "
* 15.1.2: The example from Klaeber may need a note explaining that
while Klaeber's readings themselves record information about the
text, they are treated as typographic features in the variorum
apparatus. (Lou made this point most forcefully--perhaps he should
supply the language)?
* 15.1.4.3: In the example with <witness xml:id="c" included="#Cp
#La #Sl2">Constant Group c</witness>, a better approach would be
to nest the actual members of this group in an apparatus-like
structure:

Constant Group c

Corpus Christi Oxford MS 198
British Library Lansdowne 851
British Library Sloane MS 1686


-dan
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 13:10:44 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Jun 13 17:54:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 13 Jun 2007 22:54:55 +0100 Subject: [tei-council] Trac 152 (TC) In-Reply-To: <1181754515.9538.17.camel@localhost> Message-ID: <467067AF.7050407@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 13 Jun 2007 22:54:55 +0100
Daniel O'Donnell wrote:
> Here are some changes for TC:
> http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152
>
> * Reverse TC and PH--This was assigned to Syd
>
I'm open-minded as to whether this really needs doing; final disposition
of the chapters is something we have already decided to defer anyway.
> * We should mention that app is a special form of choice in TC,
> because we do so in the element description for choice: "For a
> specialized version of for encoding multiple witnesses of a
> single work, see section 15.1 The Apparatus Entry, Readings, and
>
OK, have added a para :

The app element is in one sense a more sophisticated and
complex version of the choice element introduced in target="#COEDCOR"/> as a way of marking points where the encoding of a
passage
in a single source may be carried out in more than one way. Unlike
choice, however, the app element allows for the
representation of many different versions of the same passage taken
from different sources.


> * 15.1.1: "The attributes loc, from, and to, are used to link the
> apparatus entry to the base text. Several methods may be used for
> such linkage, each involving a slightly different usage for these
> attributes. Linkage between text and apparatus is described below in
> section 15.2 Linking the Apparatus to the Text."
> * * This needs clarification, since apparatus can also exist
> without a base text: How about: "The attributes loc, from, and
> to, are used to link the apparatus entry to the base text , if
> present. In such cases, s everal methods may be used for such
> linkage, each involving a slightly different usage for these
> attributes. Linkage between text and apparatus is described
> below in section 15.2 Linking the Apparatus to the Text. For the
> use of the app element without a base text see... "
>
OK : (TCAPPS)
> * 15.1.2: The example from Klaeber may need a note explaining that
> while Klaeber's readings themselves record information about the
> text, they are treated as typographic features in the variorum
> apparatus. (Lou made this point most forcefully--perhaps he should
> supply the language)?
>
Already done, I think.
> * 15.1.4.3: In the example with <witness xml:id="c" included="#Cp
> #La #Sl2">Constant Group c</witness>, a better approach would be
> to nest the actual members of this group in an apparatus-like
> structure:
>
> Constant Group c
>
> Corpus Christi Oxford MS 198
> British Library Lansdowne 851
> British Library Sloane MS 1686
>
>
>
>
>
Also already done: I think there was another ticket about removing the
@include attribute which caused me to do it, but I cant now find it
> -dan
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jun 13 2007 - 17:58:19 EDT

From daniel.odonnell at uleth.ca Wed Jun 13 19:58:54 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 17:58:54 -0600 Subject: [tei-council] Trac 152 (TC) In-Reply-To: <467067AF.7050407@computing-services.oxford.ac.uk> Message-ID: <1181779134.13724.0.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 13 Jun 2007 17:58:54 -0600
Thanks Lou, on both tickets.
-dan
On Wed, 2007-06-13 at 22:54 +0100, Lou Burnard wrote:
> Daniel O'Donnell wrote:
> > Here are some changes for TC:
> > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152
> >
> > * Reverse TC and PH--This was assigned to Syd
> >
> I'm open-minded as to whether this really needs doing; final disposition
> of the chapters is something we have already decided to defer anyway.
> > * We should mention that app is a special form of choice in TC,
> > because we do so in the element description for choice: "For a
> > specialized version of for encoding multiple witnesses of a
> > single work, see section 15.1 The Apparatus Entry, Readings, and
> >
> OK, have added a para :
>
>

The app element is in one sense a more sophisticated and
> complex version of the choice element introduced in
> target="#COEDCOR"/> as a way of marking points where the encoding of a
> passage
> in a single source may be carried out in more than one way. Unlike
> choice, however, the app element allows for the
> representation of many different versions of the same passage taken
> from different sources.


>
>
> > * 15.1.1: "The attributes loc, from, and to, are used to link the
> > apparatus entry to the base text. Several methods may be used for
> > such linkage, each involving a slightly different usage for these
> > attributes. Linkage between text and apparatus is described below in
> > section 15.2 Linking the Apparatus to the Text."
> > * * This needs clarification, since apparatus can also exist
> > without a base text: How about: "The attributes loc, from, and
> > to, are used to link the apparatus entry to the base text , if
> > present. In such cases, s everal methods may be used for such
> > linkage, each involving a slightly different usage for these
> > attributes. Linkage between text and apparatus is described
> > below in section 15.2 Linking the Apparatus to the Text. For the
> > use of the app element without a base text see... "
> >
>
> OK : (TCAPPS)
>
> > * 15.1.2: The example from Klaeber may need a note explaining that
> > while Klaeber's readings themselves record information about the
> > text, they are treated as typographic features in the variorum
> > apparatus. (Lou made this point most forcefully--perhaps he should
> > supply the language)?
> >
>
> Already done, I think.
>
> > * 15.1.4.3: In the example with <witness xml:id="c" included="#Cp
> > #La #Sl2">Constant Group c</witness>, a better approach would be
> > to nest the actual members of this group in an apparatus-like
> > structure:
> >
> > Constant Group c
> >
> > Corpus Christi Oxford MS 198
> > British Library Lansdowne 851
> > British Library Sloane MS 1686
> >
> >
> >
> >
> >
>
> Also already done: I think there was another ticket about removing the
> @include attribute which caused me to do it, but I cant now find it
> > -dan
> >
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 13 2007 - 20:01:04 EDT
From Syd_Bauman at Brown.edu Wed Jun 13 23:39:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 13 Jun 2007 23:39:41 -0400 Subject: [tei-council] change/@date should be change/@when, no? Message-ID: <18032.47229.480045.401203@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 13 Jun 2007 23:39:41 -0400
I'm thinking that the date= attribute of the element should
be renamed to when=. This seems better for 2 reasons:
* matches when= of ,
From Syd_Bauman at Brown.edu Wed Jun 13 23:43:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 13 Jun 2007 23:43:23 -0400 Subject: [tei-council] change/@date should be change/@when, no? In-Reply-To: <18032.47229.480045.401203@emt.wwp.brown.edu> Message-ID: <18032.47451.463903.993544@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 13 Jun 2007 23:43:23 -0400
Oh, and doesn't the same hold for value= of ? Shouldn't it
be when=, too? (I think so, but it is less obvious than for ;
a bit hard for me to think through both because of the late hour and
because I'm not at all convinced should exist. :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jun 13 2007 - 23:43:27 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jun 14 04:09:02 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 14 Jun 2007 09:09:02 +0100 Subject: [tei-council] change/@date should be change/@when, no? In-Reply-To: <18032.47451.463903.993544@emt.wwp.brown.edu> Message-ID: <4670F79E.7090009@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 14 Jun 2007 09:09:02 +0100
Syd Bauman wrote:
> Oh, and doesn't the same hold for value= of ? Shouldn't it
> be when=, too? (I think so, but it is less obvious than for ;
> a bit hard for me to think through both because of the late hour and
> because I'm not at all convinced should exist. :-)
>
>
docDate has as much right to existence as the other doc* things I think.
But yes, both it and change should take a @when (I won't argue for a
@period)
While we're wreaking havoc with existing documents, it occurred to me
this morning that there was no other good reason why we shouldn't rename
@notBefore as @after and @notAfter as @before.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 04:12:29 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 04:30:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 09:30:01 +0100 Subject: [tei-council] change/@date should be change/@when, no? In-Reply-To: <4670F79E.7090009@computing-services.oxford.ac.uk> Message-ID: <4670FC89.6010209@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 09:30:01 +0100
Lou Burnard wrote:
>
> While we're wreaking havoc with existing documents, it occurred to me
> this morning that there was no other good reason why we shouldn't
> rename @notBefore as @after and @notAfter as @before.
I don't like that much. notBefore and notAfter make sense to me. but I defer
to others common expectations.
I think you could try that on the persons+places ad hoc list of people?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 04:30:04 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jun 14 04:40:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 14 Jun 2007 09:40:51 +0100 Subject: [tei-council] change/@date should be change/@when, no? In-Reply-To: <4670FC89.6010209@oucs.ox.ac.uk> Message-ID: <4670FF13.8010703@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 14 Jun 2007 09:40:51 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>>
>> While we're wreaking havoc with existing documents, it occurred to me
>> this morning that there was no other good reason why we shouldn't
>> rename @notBefore as @after and @notAfter as @before.
> I don't like that much. notBefore and notAfter make sense to me. but I
> defer
> to others common expectations.
>
It was just a pre-breakfast thought...
> I think you could try that on the persons+places ad hoc list of people?
>
Which reminds me: we ought to include the Vilnius attendees in that ad
hoc list. Might be worth setting up a (shortlived) maillist?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 04:44:17 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 04:51:00 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 09:51:00 +0100 Subject: [tei-council] change/@date should be change/@when, no? In-Reply-To: <4670FF13.8010703@computing-services.oxford.ac.uk> Message-ID: <46710174.2040403@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 09:51:00 +0100
Lou Burnard wrote:
>Which reminds me: we ought to include the Vilnius attendees in that ad
hoc list.
> Might be worth setting up a (shortlived) maillist?
yes; why don't we set up a mailling list specifically
for discussion of the new ND draft, add everyone who
has attended a places/names meeting, and invite others
on TEI-L to join in? there is such a lot of stuff in there that
is new or changed, it really needs a thorough public
shakedown. We can reasonably offer an 8 week
consultation on this; it just needs you to add and
, I think, to get the skeleton in place.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 04:51:02 EDT

From cwittern at gmail.com Thu Jun 14 08:22:32 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 14 Jun 2007 21:22:32 +0900 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <2D42E3D7-4CBD-429F-8AFC-BDB68C9566BC@indiana.edu> Message-ID: <5268d87d0706140522s4e1f73ffl5a675b3527dd67f9@mail.gmail.com>
From: Christian Wittern
Date: Thu, 14 Jun 2007 21:22:32 +0900
Council members,
comments on this proposals are appreciated. I hope we can reach a
decision on this at tomorrows telco.
Christian
---------- Forwarded message ----------
From: John A. Walsh edu>
Date: 14-Jun-2007 20:48
Subject: Re: [tei-council] DRAFT Agenda for the TEI Council
teleconference on June 15, 2007 at 1200 UTC
To: Wittern Christian com>

Christian,
If it's not to late to add an item to the agenda, I would like to
discuss the recent TEI-L and TEI-council threads on @rend. We need
to decide whether to change @rend's datatype to a pointer. Based on
the discussions, my preference is back to having two attributes,
@rend and @rendref (or some such name). @rend would remain as it is.
@rendref would be a pointer to one or more formally described
rendition styles. This gives us the flexibility of XHTML with its
@class/@style attributes with a pointing attribute (xhtml:class/
tei:rendref) and an inline style attribute (xhtml:style/tei:rend),
but in our case both @rend and @rendref describe the rendering of the
*source* document, so we would not be duplicating functionality of HTML.
Feel free to forward this on to council if you want to add the agenda
item.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> On Jun 11, 2007, at 9:14 PM, Wittern Christian wrote: > > DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at > 1200 UTC > > Expected to participate: > > Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James > Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian > Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern > > excused: Tone Merete Bruvik > > ============================================================ > How to connect: > > We will use the highspeedconferencing.com service again. > > Participants can use their skype account (www.skype.com) or regular > phones to call. When calling via skype, *please use a headset*. If > in doubt, it might be better to call via regular phone. Numbers as > follow: > >> From Skype call +99008278525675 > In the US, call 1-712-432-4000 > Calling from Europe, call > In Austria: 0820 400 01562 > In Belgium: 0703 59 984 > In France: 0826 100 266 > In Germany 01805 00 7620 > In UK: 0870 119 2350 > other places: call to US:-( > Enter Conference Room Number : 5326922 > (this is Sebastian's Conference room) > ============================================================ > > Please read through the following (including the linked pages) before > the meeting. > > ============================================================ > > 1) Open action items > > There are a lot of open action items registered in TRAC. The > planning-and-deadline > sub committee (DSC) has tried to organize them in a more coherent > list also > ordered by importance and degree of difficulty, available at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > The DSC members have individually contacted the action holders and > inquired about progress. We will start with reports from the DSC. > > * Consolidated reports on outstanding actions from Daniel, > Sebastian and > Christian > [we will try to get these also in writing to the council list > prior to > the meeting] > > 2) To discuss > > Some of the items scheduled for action in Berlin look a bit unclear or > need further discussion. We should briefly try to clarify these > issues: > > * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge > corpus > chapter into DS. > * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think > ST and its position in the Guidelines soon > * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re- > work NH > > 3) Reports > > * Places meeting at Kings. (Arianna / Lou) > > * ISO FSD activity (LR) > > 4) Further planning > > * The main question here is how much time we can allow for solving the > remaining technical issues and how to divide up the tasks. > Again, please have a careful look at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap > > 5) next meeting > Mid/end of July > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 08:22:38 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 08:43:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 13:43:04 +0100 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <5268d87d0706140522s4e1f73ffl5a675b3527dd67f9@mail.gmail.com> Message-ID: <467137D8.2010002@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 13:43:04 +0100
so we all agree that the TEI says nothing about output rendition? should we
concretely suggest using html:class / html:style?
I find @rend and @rendref rather hard to swallow. I know the
TEI is famously indecisive, but this seems going too far. I suppose
if it was a choice of @rend *or* @rendRef it would be slightly nicer.
What scares me is adding a new attribute to att.global, because
it becomes so visible to everyone. What you _could_ have is
@rendRef supplied by an optional module, but then what else
would that contain?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 08:43:08 EDT
From James.Cummings at computing-services.oxford.ac.uk Thu Jun 14 09:42:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 14 Jun 2007 14:42:34 +0100 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <467137D8.2010002@oucs.ox.ac.uk> Message-ID: <467145CA.1010805@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 14 Jun 2007 14:42:34 +0100
I know this isn't the issue under consideration, but I've always had a
problem with @rend being in the att.global class myself.
@rend is defined as indicating "how the element in question was rendered or
presented in the source text." While this makes sense to me for every
element underneath text in the hierarchy, it still bothers me in
the header.
According to the Guidelines as they stand
does not say the revisionDesc should be printed out in italics, but that it
was in italics in the original. This makes no sense to me because
revisionDesc summarizes the change history for the electronic file and is
not present in the source. Similarly, what does ,
or really
mean if these elements did not appear in the source text?
If TEI says nothing about output rendition (which is, I think, a strength
rather than a failing), then wouldn't it make sense for @rend to only be
allowed on elements which in one way or another reflect the source text,
rather than provide information about the electronic text. (Ignoring, for
the moment theoretical questions of transcriptions from images of
syntax-highlighted TEI XML.)
I have yet to be convinced of its utility on such elements if the
definition remains,as I think it should, solely to do the source document
for the TEI encoded version.
-James
Sebastian Rahtz wrote:
> so we all agree that the TEI says nothing about output rendition? should we
> concretely suggest using html:class / html:style?
>
> I find @rend and @rendref rather hard to swallow. I know the
> TEI is famously indecisive, but this seems going too far. I suppose
> if it was a choice of @rend *or* @rendRef it would be slightly nicer.
>
> What scares me is adding a new attribute to att.global, because
> it becomes so visible to everyone. What you _could_ have is
> @rendRef supplied by an optional module, but then what else
> would that contain?
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 09:42:38 EDT

From dporter at uky.edu Thu Jun 14 09:45:18 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 14 Jun 2007 09:45:18 -0400 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <467145CA.1010805@computing-services.oxford.ac.uk> Message-ID: <96f3df640706140645q20095d5dn9aedc25caa2c3d0@mail.gmail.com>
From: Dot Porter
Date: Thu, 14 Jun 2007 09:45:18 -0400
I agree absolutely 100% with what James says here. It's the same
argument I make to some I know who would like to see a global @coords
attribute (which would contain coordinate values for an image file).
Why on earth would we want a @coords attribute on ? I
think @rend fall under this as well.
Dot
On 6/14/07, James Cummings
oxford.ac.uk> wrote:
> I know this isn't the issue under consideration, but I've always had a
> problem with @rend being in the att.global class myself.
>
> @rend is defined as indicating "how the element in question was rendered or
> presented in the source text." While this makes sense to me for every
> element underneath text in the hierarchy, it still bothers me in
> the header.
>
> According to the Guidelines as they stand
> does not say the revisionDesc should be printed out in italics, but that it
> was in italics in the original. This makes no sense to me because
> revisionDesc summarizes the change history for the electronic file and is
> not present in the source. Similarly, what does ,
> or really
> mean if these elements did not appear in the source text?
>
> If TEI says nothing about output rendition (which is, I think, a strength
> rather than a failing), then wouldn't it make sense for @rend to only be
> allowed on elements which in one way or another reflect the source text,
> rather than provide information about the electronic text. (Ignoring, for
> the moment theoretical questions of transcriptions from images of
> syntax-highlighted TEI XML.)
>
> I have yet to be convinced of its utility on such elements if the
> definition remains,as I think it should, solely to do the source document
> for the TEI encoded version.
>
> -James
>
> Sebastian Rahtz wrote:
> > so we all agree that the TEI says nothing about output rendition? should we
> > concretely suggest using html:class / html:style?
> >
> > I find @rend and @rendref rather hard to swallow. I know the
> > TEI is famously indecisive, but this seems going too far. I suppose
> > if it was a choice of @rend *or* @rendRef it would be slightly nicer.
> >
> > What scares me is adding a new attribute to att.global, because
> > it becomes so visible to everyone. What you _could_ have is
> > @rendRef supplied by an optional module, but then what else
> > would that contain?
> >
>
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 09:45:21 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 09:52:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 14:52:39 +0100 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <96f3df640706140645q20095d5dn9aedc25caa2c3d0@mail.gmail.com> Message-ID: <46714827.4030000@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 14:52:39 +0100
Given that 95% of the elements *can* occur in the text,
it would be a pain to add all of them to a "att.renderable"
class, leaving 5% *not* members of that class. Isn't
it easier to let sleeping dogs lie, and accept that
its a bit weird?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 09:52:42 EDT
From Syd_Bauman at Brown.edu Thu Jun 14 09:56:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 14 Jun 2007 09:56:57 -0400 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <46714827.4030000@oucs.ox.ac.uk> Message-ID: <18033.18729.862186.824231@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 14 Jun 2007 09:56:57 -0400
> Given that 95% of the elements *can* occur in the text, it would be
> a pain to add all of them to a "att.renderable" class, leaving 5%
> *not* members of that class. Isn't it easier to let sleeping dogs
> lie, and accept that its a bit weird?
Yes, it is easier. That doesn't mean it's better or the right thing
to do.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 09:57:01 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 10:01:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 15:01:30 +0100 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <18033.18729.862186.824231@emt.wwp.brown.edu> Message-ID: <46714A3A.7090703@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 15:01:30 +0100
Syd Bauman wrote:
>> Given that 95% of the elements *can* occur in the text, it would be
>> a pain to add all of them to a "att.renderable" class, leaving 5%
>> *not* members of that class. Isn't it easier to let sleeping dogs
>> lie, and accept that its a bit weird?
>>
>
> Yes, it is easier. That doesn't mean it's better or the right thing
> to do
>
if we are going to add more or less all elements to an explicit
class, might as well scrap implict membership of
att.global entirely and do @xml:id and @n (etc)
in the normal way?
i'm easy. just seems like a distraction to me.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 10:01:33 EDT
From laurent.romary at loria.fr Thu Jun 14 10:04:19 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 14 Jun 2007 16:04:19 +0200 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <18033.18729.862186.824231@emt.wwp.brown.edu> Message-ID:
From: Laurent Romary
Date: Thu, 14 Jun 2007 16:04:19 +0200
It does, since it goes towards a simplificatin of element
descriptions. Do think that our users not only look at a behaviour
(e.g. constraints in an XML editor), they potentially face the
situation where they will have to tune their own schemas by getting
into the (Roma or native ODD) sources. The more links there, the more
complex the TEI architecture will be to understand. I would let the
sleeping dog dog quiet.
Laurent

Le 14 juin 07 ? 15:56, Syd Bauman a ?crit :
>> Given that 95% of the elements *can* occur in the text, it would be
>> a pain to add all of them to a "att.renderable" class, leaving 5%
>> *not* members of that class. Isn't it easier to let sleeping dogs
>> lie, and accept that its a bit weird?
>
> Yes, it is easier. That doesn't mean it's better or the right thing
> to do.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 10:05:53 EDT

From James.Cummings at computing-services.oxford.ac.uk Thu Jun 14 10:22:56 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 14 Jun 2007 15:22:56 +0100 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <46714A3A.7090703@oucs.ox.ac.uk> Message-ID: <46714F40.8060303@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 14 Jun 2007 15:22:56 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>>> Given that 95% of the elements *can* occur in the text, it would be
>>> a pain to add all of them to a "att.renderable" class, leaving 5%
>>> *not* members of that class. Isn't it easier to let sleeping dogs
>>> lie, and accept that its a bit weird?
>>>
>>
>> Yes, it is easier. That doesn't mean it's better or the right thing
>> to do
>>
> if we are going to add more or less all elements to an explicit
> class, might as well scrap implict membership of
> att.global entirely and do @xml:id and @n (etc)
> in the normal way?
>
> i'm easy. just seems like a distraction to me.
I do actually agree with Sebastian and Laurent, that we probably shouldn't
worry too much about it now. If there was a good way to have an
att.global-for-everything-under-text which elements only got when they were
used as a descendant of , then that would be fine. (i.e.

in the
header didn't have @rend but

inside a

inside did.) But
since I don't think we are able to accomplish that -- in a straightforward
and reasonable way -- then we should probably just shrug our shoulders,
maybe note something about the compromise in the Guidelines, and move on.
As long as we agree that @rend says nothing about output and only source,
then I'm happy.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 10:23:00 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 10:28:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 15:28:55 +0100 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <46714F40.8060303@computing-services.oxford.ac.uk> Message-ID: <467150A7.4080705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 15:28:55 +0100
James Cummings wrote:
>
> If there was a good way to have an
> att.global-for-everything-under-text which elements only got when they were
> used as a descendant of , then that would be fine. (i.e.

in the
> header didn't have @rend but

inside a

inside did.)
er, thanks but no thanks. implementing that is a project
for the future....

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 10:28:58 EDT

From Syd_Bauman at Brown.edu Thu Jun 14 11:42:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 14 Jun 2007 11:42:52 -0400 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <467150A7.4080705@oucs.ox.ac.uk> Message-ID: <18033.25084.536423.901814@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 14 Jun 2007 11:42:52 -0400
> er, thanks but no thanks. implementing that is a project
> for the future....
??

Warning: in general use of the @rend
attribute within the <teiHeader> is non-sensical.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 11:43:08 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 14 12:00:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 14 Jun 2007 17:00:46 +0100 Subject: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <18033.25084.536423.901814@emt.wwp.brown.edu> Message-ID: <4671662E.10900@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 14 Jun 2007 17:00:46 +0100
Syd Bauman wrote:
>> er, thanks but no thanks. implementing that is a project
>> for the future....
>>
>
> ??
>
>
> Warning: in general use of the @rend
> attribute within the <teiHeader> is non-sensical.
>
>
oh, if you allow Schematron in, problem solved!
I was thinking of doing it in relax
you might as well just add that rule, Syd?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 12:00:49 EDT

From daniel.odonnell at uleth.ca Thu Jun 14 13:06:28 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 14 Jun 2007 11:06:28 -0600 Subject: Choice and RDG content model (Re: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...")) In-Reply-To: <467150A7.4080705@oucs.ox.ac.uk> Message-ID: <1181840788.5362.25.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 14 Jun 2007 11:06:28 -0600
Since we are raising this kind of thing, let me ask one too:
Should we not seriously consider changing the content model of choice
and of rdg (which is a related issue) to something similar to that for
floating text? Currently both can contain only phrase level and global
elements.
There are two reasons for this:
1) choice is a logical relationship rather than a natural part of the
document hierarchy. That is to say, the function that choice
performs--grouping alternate or encodings (I would say alternate or
simultaneous text orencodings)--is not something that logically must
occur at a given point in a document hierarchy. I can have paragraphs or
even divs that are alternates for each other (e.g. prose and verse
translations of Boethian metra spring to mind), there is no reason why I
could not have alternates for entire texts (the Dictionary of the
Khazars [sp?] comes in male and female versions).
2) rdg is a child of app which is a specialised version of choice (as we
say in the element definition. In a recent discussion on tei-l, we had a
question about encoding variants where one witness has an extra line (or
is missing one). This is quite a common case, even though our current
definition of rdg does not allow you to indicate that one or more of the
collated rdg's consists of more than one line.
Some use cases: Edward van Houtte's Electronic Teleurgang van het
Waterhoek collates witnesses on a paragraph by paragraph basis. My
Caedmon's Hymn has some witnesses that are missing lines at some points
and have extra lines at others. In the Anglo-Saxon poetic records, some
variants involve variation in the order of lines.
This is not something that print apparatus have handled very well in the
past--Dobbie's edition of Caedmon's Hymn just prints the additional
lines but doesn't indicate that the variants involve the addition of a
metrical line. But we can do better. The information is useful and ought
to be encoded.
What say all ye merry councilors?
-dan
On Thu, 2007-06-14 at 15:28 +0100, Sebastian Rahtz wrote:
> James Cummings wrote:
> >
> > If there was a good way to have an
> > att.global-for-everything-under-text which elements only got when they were
> > used as a descendant of , then that would be fine. (i.e.

in the
> > header didn't have @rend but

inside a

inside did.)
> er, thanks but no thanks. implementing that is a project
> for the future....
>
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 13:08:42 EDT
From Syd_Bauman at Brown.edu Thu Jun 14 14:56:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 14 Jun 2007 14:56:36 -0400 Subject: [tei-council] mimeType= In-Reply-To: <466FA016.2020707@oucs.ox.ac.uk> Message-ID: <18033.36708.762337.521071@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 14 Jun 2007 14:56:36 -0400
> Recommendation
> --------------
> New class, att.internetMedia (or whatever) that defines the mimeType=
> attribute ...
Done.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 14:56:41 EDT
From jawalsh at indiana.edu Thu Jun 14 15:01:13 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 14 Jun 2007 15:01:13 -0400 Subject: [tei-council] comments on HD Message-ID: <6B9B9512-D35A-441E-BDC2-75D8A35CF135@indiana.edu>
From: John A. Walsh
Date: Thu, 14 Jun 2007 15:01:13 -0400
Catching up on tasks before conference call, here are my comments,
from Berlin, on HD chapter:
HD comments.
SGML Reference in 3.1.1: "The element should be clearly
distinguished both from the prolog, which comprises either the XML
declaration or the SGML"
Perhaps "computer file" should be replaced with the phrase "digital
object," which is now the common terminology for something like a TEI
text, which could be a single file or multiple files.
DTD reference in 3.1.1: "The element should be clearly
distinguished both from the prolog, which comprises either the XML
declaration or the SGML declaration, and the document type
declaration (see chapter A Gentle Introduction to XML); and from the
front matter of the text itself (for which see section 5.4 Front
Matter)."

The discussion of adding phrases like "a machine readable
transcription" should perhaps be removed. Library catalogs, online
stores, etc. all have mechanisms, other than the title, for
distinguishing among versions and media types. So users shoulndn't
have trouble distinguishing between _Gone with the Wind_, the book on
paper, the film on film, the film on DVD, the film on VHS, or the
book as digital file.
DTD reference in 3.2.1: "The TITLE, AUTHOR, NAME, RESPSTMT, and RESP
elements are declared in file teicore2.dtd, not here."
typo in 3.2.2: "version,level" [need space after comma]
SGML reference in 3.3: " (tagging declaration) provides
detailed information about the tagging applied to an SGML or XML
document."
SGML reference in 3.3.5.3: "The milestone referencing scheme, though
conceptually simple, is not supported by a generic SGML or XML
parser. Its use places a correspondingly greater burden of
verification and accuracy on the encoder."
formatting note: attributes are not distincly formatted in the prose
of the guidelines. See 3.3.3, after "It may contain a prose
description only, or one or more of the following specialized
elements:..."
organization question: The guidelines describe, in a bulleted list,
the seven child elements of . Then there is a
paragraph about model.editorialDeclPar and then another bulleted list
about the questions these seven child elements might address.
Perhaps these two bulleted lists could be collapsed into one. The
single bulleted list could describe the element *and* the questions
it is meant to address.

3.3.5:
Reference to DTD (sort of): multiple references to "document type"
in the discussion of the refsDecl/@doctype attribute.

SGML reference in 3.3.5.3: "The milestone referencing scheme, though
conceptually simple, is not supported by a generic SGML or XML parser."
URL is 3.4.3: This section references "http://www.browncorpus.org".
The link appears to be dead, and if the working link can be found, it
should probably be encoded as a ref so it appears as an clickable
link in the HTML guidelines.
DTD reference in 3.5: In a code example:
On 13 March 1997 key="lmayer.ins">Lauryn S. Mayer
began capture using Author/Editor v. 3.1 on Mac with
version 1.0.14 of DTD.

On 12 June 1997 key="lmayer.ins" xml:id="LM">Lauryn S. Mayer
began entering corrections with version 1.1.2a of DTD

-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 15:01:18 EDT

From jawalsh at indiana.edu Thu Jun 14 15:04:00 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 14 Jun 2007 15:04:00 -0400 Subject: [tei-council] VE comments Message-ID:
From: John A. Walsh
Date: Thu, 14 Jun 2007 15:04:00 -0400
Catching up on tasks before conference call, here are my comments,
from Berlin, on VE chapter:
VE. Comments
typo: "the actual rhyming word or word:"
Sestet and couplet do note denote metre: "Sestet? and ?couplet? might
conceivably also be used as the values of the met attribute in a
metrical analysis."
In Coleridge's Frost at Midnight examples, the first has a type
attribute; subsequent s do not. Is this intentional?
error, can contain a head: "One reason for preferring the former
version is that the items encoded as
may contain non-metrical
elements, such headings or paragraphs, whereas elements may
contain only metrical lines."
No other comments; no references to DTDs, SGML, or P4.
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 15:04:04 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jun 14 17:56:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 14 Jun 2007 22:56:11 +0100 Subject: [tei-council] Trac #346 Message-ID: <4671B97B.2070508@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 14 Jun 2007 22:56:11 +0100
I have now completed the first attempt at a major overhaul of chapter
ND, integrating the results from the meetings at Kings and Vilnius
earlier this year.
A lot of work remains to be done, but I think there's enough material
here to demonstrate
that the framework and the basic ideas from those meetings are sound
enough to go forward to P5, with good will and a following wind.
Assuming that Council shares my view that this should proceed, I have
set up a mailing list to handle further work on reviewing this chapter.
Initially this will have attendees from the
two meetings but it would be good to expose the chapter to the wider TEI
community for comment as soon as possible, since it contains much that
is new and may be controversial.
And, of course, council members who wish to join the list should also do
so: just send an empty message to tei-chars-subscribe_at_maillist.ox.ac.uk
(and dont ask why it is called tei-chars)
The idea would be to solicit comments within a short timescale -- up to
six weeks, say -- so that we have some hope of acting on them in time
for 1.0

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 17:59:39 EDT

From conal.tuohy at vuw.ac.nz Thu Jun 14 20:43:47 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 15 Jun 2007 12:43:47 +1200 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <467137D8.2010002@oucs.ox.ac.uk> Message-ID: <1181868227.3515.45.camel@localhost>
From: Conal Tuohy
Date: Fri, 15 Jun 2007 12:43:47 +1200
On Thu, 2007-06-14 at 13:43 +0100, Sebastian Rahtz wrote:
> so we all agree that the TEI says nothing about output rendition? should we
> concretely suggest using html:class / html:style?
It's probably worth pointing out that in HTML, the class and style
attributes are not in a namespace, so we can't just "borrow" them in
this way.
> I find @rend and @rendref rather hard to swallow. I know the
> TEI is famously indecisive, but this seems going too far. I suppose
> if it was a choice of @rend *or* @rendRef it would be slightly nicer.
I tend to agree. I know if I had "@rendref" (as a pointer to a
tei:rendition), I would probably use it in place of rend everywhere. In
certain circumstances it might be considered easier for encoders to be
able to encode rendition information inline (using @rend), but I think
this would tend to be where there are a large number of distinct
renditions being encoded. For most uses of @rend which *I* have seen, it
would be easily replaced with a reference.
> What scares me is adding a new attribute to att.global, because
> it becomes so visible to everyone. What you _could_ have is
> @rendRef supplied by an optional module, but then what else
> would that contain?
That seems reasonable to me. Does it matter if the optional module
doesn't include anything else?
Would it be enough for the optional module to redefine @rend as a
pointer? Would that be a "clean" modification of tei_all?
Otherwise, if a new attribute name is required (distinct from @rend),
what about calling it "rendition" - to match the name of the element to
which it refers?
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 20:50:03 EDT
From cwittern at gmail.com Thu Jun 14 21:05:07 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 15 Jun 2007 10:05:07 +0900 Subject: Choice and RDG content model (Re: rend= not global? (was "Re: Fwd: [tei-council] DRAFT Agenda for ...")) In-Reply-To: <1181840788.5362.25.camel@localhost> Message-ID: <4671E5C3.8020700@gmail.com>
From: Wittern Christian
Date: Fri, 15 Jun 2007 10:05:07 +0900
Dear Council members,
I tried to forward this to tei-council yesterday, but it never appeared
here. For the record I am pasting it now again as reply to this topic,
since I think that makes the point a bit clearer.

-- pasted message --
Dear Council members,
Daniel has send me the following in reply to my call for agenda items.
I told him that this would require a discussion on tei-council based on
a written proposal after which it might appear on the agenda if
necessary. So to open the discussion, here is the proposal.
My own reaction is: I see the problem, have been bitten by it myself a
couple of times. However, might be a bit too big for
most cases and potentially opens up a can of worms. On the other hand,
this can might already be open with the existence of ...
We do have some outstanding actions dealing with stuff from the textcrit
module, so my suggestion for a course of action would be to consider
this proposal in that context, if Council feels that it should be added
as a work item at all.
All the best,
Christian
Daniel O'Donnell wrote:
> Hi Christian,
>
> I don't know if you want me to circulate this to council or not, but
> here is the issue:
>
> I would like us to reconsider the content model of at least two
> elements: choice and rdg. The issues are related.
>
>
> rdg is the easiest one: currently its description is as follows:
>
>
>
>> element rdg
>> {
>> att.global.attributes,
>> att.textCritical.attributes,
>> (
>> text
>> | model.gLike
>> | model.phrase
>> | model.inter
>> | model.global
>> | model.rdgPart
>> )*
>> }
>>
>
>
> The problem with this is illustrated by the recent discussion on tei-l
> concerning witnesses that have additional lines of poetry in them: rdg
> can't handle this case without some kind of work-around because it can't
> contain lines and paragraphs as it is currently formulated.
>
> I can give two examples, in addition to the recent discussion on tei-l
> to show that this is a relatively common case. One (in print) is the
> textual apparatus in Elliott Van Kirk Dobbie's edition of Caedmon's Hymn
> in the Anglo-Saxon poetic records (where several late witnesses are
> missing lines in some places and have additional lines elsewhere. A
> second is Edward Vanhoutte's edition of Teleurgang van 't Waterhoek,
> where he uses a collation unit of the paragraph in comparing the various
> editions of his subject text. In my dissertation I also frequently ran
> into a few cases where I was using the verse line as a collation unit in
> comparing witneses to poems--for example where witnesses had reverse
> lines.
>
> I suspect logically for reasons I'll get to in a minute that in fact
> that rdg like choice should have a content model very similar to
> floating text. Although all the examples I've given are at the chunk
> level, I can easily see a situation arise where it is the presence or
> absence of a text that is the collation unit: e.g. in various
> translations and redactions of the Consolation of Philosophy, perhaps
> were metra are missing, or perhaps in editions of an anthology of the
> Canterbury Tales. While you might argue that these examples are divs, I
> don't see a logical reason why an entire floating text might not be
> missing.
>
> Print apparatus do not handle readings larger than the phrase that well
> either, BTW: In Dobbie's edition of Caedmon's Hymn, he gives no
> indication that the text he reproduces as the reading from some of his
> witnesses represents more than a single line, even though it does. But
> this is in my view an artifact of the medium rather than a logical
> constraint on readings: in electronic form we can do better.
>
> My argument for expanding choice is slightly more logical than based on
> use cases, though there have been some discussions of places where using
> choice to group elements larger than the phrase would also be useful.
> Basically, we started on choice as a way of dealing with the janus tags
> (expan/abbr, etc.). This is reflected in our current definition of the
> tag as something that "groups a number of alternative encodings for the
> same point in a text."
>
> During our initial discussion of the element in the lead up to proposing
> it to council, however, it became clear that the element was actually
> more than an expression of alternate encodings, but rather an expression
> of the existence of alternatives (of content or encoding) for a given
> point in the textual stream. It was this that led to our additional
> comment: "For a specialized version of for encoding multiple
> witnesses of a single work, see section 15.1 The Apparatus Entry,
> Readings, and Witnesses."
>
> In fact, there is no logical reason why alternative content, views, or
> encoding can't exist at any level of a text. I might have different
> forwards for different audiences. I might have different texts for
> different genders (e.g. I have a book--which I can't find on the shelf
> right now--that comes in Male and Female Editions). I might have summary
> paragraphs and detailed paragraphs.
>
> Finally, I'd like to suggest there is an additional reason why choice
> and rdg should be able to contain a much larger content model: they are
> not really part of a document hierarchy at all: they express logical
> relationships rather than hierarchical. Choice (and app, its more
> specialised cousin) acquires its meaning from the fact that it groups
> children, not from the fact that it has a parent. It is logically
> possible to group the largest elements of any text, and textual
> apparatus in the TEI definition do not need to be attached to part of
> any larger text (you can encode an entire series of witnesses as similar
> a series of collated rdgs rather than as an adjunct to a running
> critical text).
>
> Anyway, in both cases, I believe the content model should be similar to
> that used for floating text.
>
>
>
>> {
>> att.global.attributes,
>> att.declaring.attributes,
>> att.typed.attributes,
>> (
>> model.global*,
>> ( front, model.global* )?,
>> ( body | group ),
>> model.global*,
>> ( back, model.global* )?
>> )
>> }
>>
>
> -dan
>
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN -- end pasted message -- Daniel O'Donnell wrote: > Since we are raising this kind of thing, let me ask one too: > > Should we not seriously consider changing the content model of choice > and of rdg (which is a related issue) to something similar to that for > floating text? Currently both can contain only phrase level and global > elements. > > There are two reasons for this: > > 1) choice is a logical relationship rather than a natural part of the > document hierarchy. That is to say, the function that choice > performs--grouping alternate or encodings (I would say alternate or > simultaneous text orencodings)--is not something that logically must > occur at a given point in a document hierarchy. I can have paragraphs or > even divs that are alternates for each other (e.g. prose and verse > translations of Boethian metra spring to mind), there is no reason why I > could not have alternates for entire texts (the Dictionary of the > Khazars [sp?] comes in male and female versions). > > 2) rdg is a child of app which is a specialised version of choice (as we > say in the element definition. In a recent discussion on tei-l, we had a > question about encoding variants where one witness has an extra line (or > is missing one). This is quite a common case, even though our current > definition of rdg does not allow you to indicate that one or more of the > collated rdg's consists of more than one line. > > Some use cases: Edward van Houtte's Electronic Teleurgang van het > Waterhoek collates witnesses on a paragraph by paragraph basis. My > Caedmon's Hymn has some witnesses that are missing lines at some points > and have extra lines at others. In the Anglo-Saxon poetic records, some > variants involve variation in the order of lines. > > This is not something that print apparatus have handled very well in the > past--Dobbie's edition of Caedmon's Hymn just prints the additional > lines but doesn't indicate that the variants involve the addition of a > metrical line. But we can do better. The information is useful and ought > to be encoded. > > What say all ye merry councilors? > > -dan > > On Thu, 2007-06-14 at 15:28 +0100, Sebastian Rahtz wrote: > >> James Cummings wrote: >> >>> If there was a good way to have an >>> att.global-for-everything-under-text which elements only got when they were >>> used as a descendant of , then that would be fine. (i.e.

in the >>> header didn't have @rend but

inside a

inside did.) >>> >> er, thanks but no thanks. implementing that is a project >> for the future.... >> >> >> >> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 21:05:13 EDT
From Syd_Bauman at Brown.edu Thu Jun 14 21:06:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 14 Jun 2007 21:06:44 -0400 Subject: on rend= and rendRef= (was "Re: Fwd: [tei-council] DRAFT Agenda for ...") In-Reply-To: <1181868227.3515.45.camel@localhost> Message-ID: <18033.58916.427467.728748@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 14 Jun 2007 21:06:44 -0400
> > I suppose if it was a choice of @rend *or* @rendRef it would be
> > slightly nicer.
> I tend to agree. I know if I had "@rendref" (as a pointer to a
> tei:rendition), I would probably use it in place of rend
> everywhere.
One of the important uses for having both simultaneously would to be
able to say "this is rendered just like it says at
#thingRend, *except* that it is also small caps" or whatever. I.e.,
to use rend= to override portions of what is specified by rendRef=.
Or, for example, to have a default rendition for footnotes:
place(foot) align(left)
weight(bold) first-indent(1)
and then specify the detail of the anchor character on the element
itself:
quack!

> > What scares me is adding a new attribute to att.global, because
> > it becomes so visible to everyone. What you _could_ have is
> > @rendRef supplied by an optional module, but then what else would
> > that contain?
>
> That seems reasonable to me.
Me too, although
a) I don't wonder if rendRef= should be in att.global, and rend=
should be ostracized for those who want to say a lot of detail
about rendition;
b) I wonder if the 'transcr' module (can we rename that?) defined by
chapter "PH-PrimarySources" would be the right place for whichever
attribute is *not* in global.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 21:06:49 EDT

From jawalsh at indiana.edu Thu Jun 14 22:21:33 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 14 Jun 2007 22:21:33 -0400 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <1181868227.3515.45.camel@localhost> Message-ID: <8FC164B6-7260-46E9-B8B3-EEA841138E47@indiana.edu>
From: John A. Walsh
Date: Thu, 14 Jun 2007 22:21:33 -0400
On Jun 14, 2007, at 8:43 PM, Conal Tuohy wrote:
> I tend to agree. I know if I had "@rendref" (as a pointer to a
> tei:rendition), I would probably use it in place of rend
> everywhere. In
> certain circumstances it might be considered easier for encoders to be
> able to encode rendition information inline (using @rend), but I think
> this would tend to be where there are a large number of distinct
> renditions being encoded.
Conal,
The case you describe--documents with a large number of distinct
references--is, I think, the main legitimate argument for keeping
@rend alongside something like @rendref. It also answers the less
legitimate calls for backwards compatibility with P4.
John
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 22:21:38 EDT
From cwittern at gmail.com Thu Jun 14 22:23:32 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 15 Jun 2007 11:23:32 +0900 Subject: [tei-council] Great Unified Report from the DSC Message-ID: <4671F824.7090206@gmail.com>
From: Wittern Christian
Date: Fri, 15 Jun 2007 11:23:32 +0900
Dear Council members,
Here is the Great Unified Report on progress made since the last
meeting.
The one-line summary is: We are doing good, but tons of things remain
to be done.
The rest of this document is in two parts: A list of outstanding
actions in ** A ** and under ** B ** an annotated list of things that
are mostly done or on their way to there.
** A ** Outstanding actions
There are six areas which need to be done by end of July:
1) names/places/dates/orgs (includes trac 346, 347, 329, 307). This
is more or less done, involving a lot of changes in ND. It is being
reviewed by the Places ad hoc work group, and will be released
as a complete chapter revision when tested by them.
2) witDetail/ witList/ witGroup, and charters (action 2, trac 342, 332, 314) (for LB). not
started.
3) add/del/supplied issues (trac 301, 331, action 6) (for LB). not started
4) the header element for application info (trac 315). in progress by SR
5) the new chapter on what an ODD processor does (for SR). not
started
6) FSD Stuff
plus some low-impact things (actions 12, 14, 19)
** B ** Progress report
Here is the whole story, told as commentary on http://www.tei-c.org/Council/tcm30-notes.xml?style=printable

n Importance Ease Resp
0 high high LB change name of to
and mention its existence in HD
*done*
1 high high SB TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/329.
Merge att.datable and
att.dateTime, using new name for value/dateValue
*done. (New name is when=)*
2 high low DO proposal for dropping .
TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/332.
Change to , allow
it to self-nest,
and drop included. Work out what Gautier Poupeau really wants.
* outstanding, tackle with other textcrit/ed stuff *
3 high low DO Raise issue of editors' names on title
page at Board
* done (report from Dan) *
4 high low LB, MD, DO, TMB, SB TRAC
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/331. Solve
the substitution et al. issue
* pending => end of June / beg of July *
5 high medium LB TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/330.
Work on AB
* postponed *
6 high medium LB improve wording discussing use of
in an example transcription
* ?? *
7 medium high DP find out ISBD recommendations, and
suggest re-wording of paragraph in HD
* done * (link added)
8 medium high SB TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/338.
Regularize glosses on *specs passim
* scheduled for last week of June *
9 medium low SB create model.headLike
Lou & I are conversing
about this now; I think he expects to have this done in a few
hours.
10 low high DP send rest of errors to Council list
* done and processed *
11 low high DP Recommend keeping "machine-readable
transcription" or not
My recommendation would be to take them out, both "machine-readable
transcription" and "electronic version".
I'm afraid I don't agree so we should perhaps discuss this point.
12 low high Eds fix wording in description of
* outstanding *
13 low high JW post errors noticed in VE
* posted 2007-06-15 *
14 low high LB Add discussion of PIs to CO.8.2.2
* outstanding *
15 low high SB Change to in MS
Unless unforeseen difficulties crop up, I'll try to have this done
before the conference call.
16 low high SB Finish 3066 to 4646 update
* scheduled for late July *
17 low high SB create 2nd proposal for q and
said, post both
I'm hoping for early July.
18 low high SB move to a free standing ODD
* pending *
19 low high eds. remove wording of description of resp
in prose PH.1.2 & PH.1.3
* outstanding *
20 low low DB, MD TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/339.
Stemma modeling using graph elements
* outstanding *
21 low low JW TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/334.
Write up his thoughts & today's council discussion on rendition
* posted 2007-06-14: *
We need to decide whether to change @rend's datatype
to a pointer. Based on the discussions, my preference is back to
having two attributes, @rend and @rendref (or some such name). @rend
would remain as it is. @rendref would be a pointer to one or more
formally described rendition styles.
22 low medium JW TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/336.
Draft paras on metadata standards 2007-05-05; put JW
paras in appropriate place at end of HD 2007-05-12
* posted 2007-06-15 *
23 low medium SB Discuss calendar in the prose. Point out no regularization
of other calendars in the prose. Explain W3C vs ISO date
attrs in prose
* Mid July *
============================================================
4. Other TRAC tickets not listed above (only those with comments listed)
============================================================
TRAC 291 text and image encoding conal
FT_Tables__Formulae__and_Graphics
I have updated the "facsimile" Trac ticket with
several attached files, consisting of a re-encoding of the Comenius
SVG example, plus the ODD and the rest of the demo I showed in Berlin.
The updates to the Trac ticket are described here:
http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/291#comment:3
(skipped rest of list, no further comments)

All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 14 2007 - 22:23:38 EDT

From Syd_Bauman at Brown.edu Thu Jun 14 22:32:51 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 14 Jun 2007 22:32:51 -0400 Subject: [tei-council] on clean-up In-Reply-To: <4671F824.7090206@gmail.com> Message-ID: <18033.64083.199032.477514@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 14 Jun 2007 22:32:51 -0400
CW -- thanks for posting this. Perfect timing, I was just about to
quote tcm30-notes :-)
> 8 medium high SB TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/338.
> Regularize glosses on *specs passim
> * scheduled for last week of June *
It's not just the glosses *on* the *specs that need to be looked at
and worked on, it is also the glosses *in* them. This makes this a
"low" ease project, and one that will almost certainly run into 1st
week of July. (There are well over 2200 descendants of
*spec.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 14 2007 - 22:32:55 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 15 04:09:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 15 Jun 2007 09:09:23 +0100 Subject: [tei-council] on clean-up In-Reply-To: <18033.64083.199032.477514@emt.wwp.brown.edu> Message-ID: <46724933.1000202@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 15 Jun 2007 09:09:23 +0100
Maybe I am misunderstanding, but I thought this action was actually
rather simple, if tedious.
foreach *Spec
a) does it have a name which is not an ordinary english word or phrase?
b) if it does, there should be no gloss; if there is a gloss, zap it and
move on.
c) if it does not have such a name, does it have a gloss which explains
the *spec name ? if so, move on; if not, create one
I guess this should take an average of 1 minute per *spec, so that makes
about 400 minutes. OK you need meal breaks, time to look out of the
window and think of higher things, etc. But I still don't see how it can
take more than a couple of days.
So I must be missing something. Please expound!

Syd Bauman wrote:
> CW -- thanks for posting this. Perfect timing, I was just about to
> quote tcm30-notes :-)
>
>
>> 8 medium high SB TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/338.
>> Regularize glosses on *specs passim
>> * scheduled for last week of June *
>>
>
> It's not just the glosses *on* the *specs that need to be looked at
> and worked on, it is also the glosses *in* them. This makes this a
> "low" ease project, and one that will almost certainly run into 1st
> week of July. (There are well over 2200 descendants of
> *spec.)
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 04:12:53 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jun 15 04:16:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 15 Jun 2007 09:16:55 +0100 Subject: [tei-council] Great Unified Report from the DSC In-Reply-To: <4671F824.7090206@gmail.com> Message-ID: <46724AF7.2090308@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 15 Jun 2007 09:16:55 +0100
Wittern Christian wrote:
> 1) names/places/dates/orgs (includes trac 346, 347, 329, 307). This
> is more or less done, involving a lot of changes in ND. It is being
> reviewed by the Places ad hoc work group, and will be released
> as a complete chapter revision when tested by them.
>
>
See my mailing of last night.

> 2) witDetail/ witList/ witGroup, and charters (action 2, trac 342, 332, 314) (for LB). not
> started.
>
It has started -- I removed the constituents attribute and revised quite
a bit of prose
> 3) add/del/supplied issues (trac 301, 331, action 6) (for LB). not started
>
>
input from MJD at Berlin still hasn';t been looked at: adhoc group
proposed by DPOD hasn't done anything yet
> 4) the header element for application info (trac 315). in progress by SR
>
> 5) the new chapter on what an ODD processor does (for SR). not
> started
>
> 6) FSD Stuff
>
>
I hope to start on this next.
> 6 high medium LB improve wording discussing use of
> in an example transcription
> * ?? *
>
I think this was from Dot, and I think I have answered it. See trac
ticket on TS

> 9 medium low SB create model.headLike
>
> Lou & I are conversing
> about this now; I think he expects to have this done in a few
> hours.
>
>
Was done Weds pm but I forgot to tell Syd (I also screwed up the change
log entry so it's not evident that I did it: sorry!)

> 11 low high DP Recommend keeping "machine-readable
> transcription" or not
> My recommendation would be to take them out, both "machine-readable
> transcription" and "electronic version".
> I'm afraid I don't agree so we should perhaps discuss this point.
>
>
> 12 low high Eds fix wording in description of
> * outstanding *
>
I dont know what this means, so until someone comes up with a proposed
rewording this isn't going to get done.
> 14 low high LB Add discussion of PIs to CO.8.2.2
> * outstanding *
>
>
where did this come from? and why would you want to discuss PIs in the
core chapter?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 04:20:26 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 05:23:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 10:23:36 +0100 Subject: Fwd: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <1181868227.3515.45.camel@localhost> Message-ID: <46725A98.70805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 10:23:36 +0100
Conal Tuohy wrote:
> On Thu, 2007-06-14 at 13:43 +0100, Sebastian Rahtz wrote:
>
>> so we all agree that the TEI says nothing about output rendition? should we
>> concretely suggest using html:class / html:style?
>>
>
> It's probably worth pointing out that in HTML, the class and style
> attributes are not in a namespace, so we can't just "borrow" them in
> this way.
>
true. you have to define them yourself.
>
> renditions being encoded. For most uses of @rend which *I* have seen, it
> would be easily replaced with a reference.
>
yes. but the feeling on TEI-L seemed to be very firmly
of the opinion that it would be too big a change at this
point.
>
> That seems reasonable to me. Does it matter if the optional module
> doesn't include anything else?#
>
technically, no.
> Would it be enough for the optional module to redefine @rend as a
> pointer? Would that be a "clean" modification of tei_all?
>
no!!!!!
> Otherwise, if a new attribute name is required (distinct from @rend),
> what about calling it "rendition" - to match the name of the element to
> which it refers?
>
hmm. are there parallels?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 05:23:41 EDT
From arianna.ciula at kcl.ac.uk Fri Jun 15 07:07:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 15 Jun 2007 12:07:56 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <466DF388.9090409@gmail.com> Message-ID: <4672730C.9040001@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 15 Jun 2007 12:07:56 +0100
Am I on the wrong conference room 5326922? nobody seems to have joined
yet...
Arianna
Wittern Christian wrote:
> DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC
>
> Expected to participate:
>
> Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James
> Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian
> Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
>
> excused: Tone Merete Bruvik
>
> ============================================================
> How to connect:
>
> We will use the highspeedconferencing.com service again.
>
> Participants can use their skype account (www.skype.com) or regular
> phones to call. When calling via skype, *please use a headset*. If
> in doubt, it might be better to call via regular phone. Numbers as follow:
>
>>From Skype call +99008278525675
> In the US, call 1-712-432-4000
> Calling from Europe, call
> In Austria: 0820 400 01562
> In Belgium: 0703 59 984
> In France: 0826 100 266
> In Germany 01805 00 7620
> In UK: 0870 119 2350
> other places: call to US:-(
> Enter Conference Room Number : 5326922
> (this is Sebastian's Conference room)
> ============================================================
>
> Please read through the following (including the linked pages) before
> the meeting.
>
> ============================================================
>
> 1) Open action items
>
> There are a lot of open action items registered in TRAC. The planning-and-deadline
> sub committee (DSC) has tried to organize them in a more coherent list also
> ordered by importance and degree of difficulty, available at
> http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
> The DSC members have individually contacted the action holders and
> inquired about progress. We will start with reports from the DSC.
>
> * Consolidated reports on outstanding actions from Daniel, Sebastian and
> Christian
> [we will try to get these also in writing to the council list prior to
> the meeting]
>
> 2) To discuss
>
> Some of the items scheduled for action in Berlin look a bit unclear or
> need further discussion. We should briefly try to clarify these
> issues:
>
> * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge corpus
> chapter into DS.
> * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think
> ST and its position in the Guidelines soon
> * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re-work NH
>
> 3) Reports
>
> * Places meeting at Kings. (Arianna / Lou)
>
> * ISO FSD activity (LR)
>
> 4) Further planning
>
> * The main question here is how much time we can allow for solving the
> remaining technical issues and how to divide up the tasks.
> Again, please have a careful look at
> http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
> and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap
>
> 5) next meeting
> Mid/end of July
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 07:08:29 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 07:11:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 12:11:22 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <4672730C.9040001@kcl.ac.uk> Message-ID: <467273DA.7080004@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 12:11:22 +0100
Arianna Ciula wrote:
> Am I on the wrong conference room 5326922? nobody seems to have joined
> yet...
we're on summer time. wait an hour
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 07:11:24 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 15 07:06:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 15 Jun 2007 12:06:10 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <4672730C.9040001@kcl.ac.uk> Message-ID: <467272A2.2010901@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 15 Jun 2007 12:06:10 +0100
The theory round here is that you're an hour early!
Arianna Ciula wrote:
> Am I on the wrong conference room 5326922? nobody seems to have joined
> yet...
>
> Arianna
>
> Wittern Christian wrote:
>> DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at
>> 1200 UTC
>>
>> Expected to participate:
>>
>> Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James
>> Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian
>> Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
>>
>> excused: Tone Merete Bruvik
>>
>> ============================================================
>> How to connect:
>>
>> We will use the highspeedconferencing.com service again.
>>
>> Participants can use their skype account (www.skype.com) or regular
>> phones to call. When calling via skype, *please use a headset*. If
>> in doubt, it might be better to call via regular phone. Numbers as
>> follow:
>>
>>> From Skype call +99008278525675
>> In the US, call 1-712-432-4000
>> Calling from Europe, call
>> In Austria: 0820 400 01562
>> In Belgium: 0703 59 984
>> In France: 0826 100 266
>> In Germany 01805 00 7620
>> In UK: 0870 119 2350
>> other places: call to US:-(
>> Enter Conference Room Number : 5326922
>> (this is Sebastian's Conference room)
>> ============================================================
>>
>> Please read through the following (including the linked pages) before
>> the meeting.
>>
>> ============================================================
>>
>> 1) Open action items
>>
>> There are a lot of open action items registered in TRAC. The
>> planning-and-deadline
>> sub committee (DSC) has tried to organize them in a more coherent list
>> also
>> ordered by importance and degree of difficulty, available at
>> http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
>> The DSC members have individually contacted the action holders and
>> inquired about progress. We will start with reports from the DSC.
>>
>> * Consolidated reports on outstanding actions from Daniel, Sebastian and
>> Christian
>> [we will try to get these also in writing to the council list prior to
>> the meeting]
>>
>> 2) To discuss
>>
>> Some of the items scheduled for action in Berlin look a bit unclear or
>> need further discussion. We should briefly try to clarify these
>> issues:
>>
>> * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge corpus
>> chapter into DS.
>> * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think
>> ST and its position in the Guidelines soon
>> * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re-work NH
>>
>> 3) Reports
>>
>> * Places meeting at Kings. (Arianna / Lou)
>>
>> * ISO FSD activity (LR)
>>
>> 4) Further planning
>>
>> * The main question here is how much time we can allow for solving the
>> remaining technical issues and how to divide up the tasks.
>> Again, please have a careful look at
>> http://www.tei-c.org/Council/tcm30-notes.xml?style=printable
>> and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap
>>
>> 5) next meeting
>> Mid/end of July
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 07:11:38 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 07:17:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 12:17:49 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <466DF388.9090409@gmail.com> Message-ID: <4672755D.50401@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 12:17:49 +0100
I am fairly sure the UK number is *0870 738 0760*
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 07:17:52 EDT
From djbpitt+tei at pitt.edu Fri Jun 15 08:06:55 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 15 Jun 2007 08:06:55 -0400 Subject: [tei-council] conference call number change Message-ID: <467280DF.1030300@pitt.edu>
From: David J Birnbaum
Date: Fri, 15 Jun 2007 08:06:55 -0400
Dear TEI Council,
The access number for the conference call from the US has apparently
been changed from 1-712-432-4000 to 1-605-475-8500.
Best ,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 08:06:59 EDT
From dporter at uky.edu Fri Jun 15 08:23:13 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 15 Jun 2007 08:23:13 -0400 Subject: Fwd: [tei-council] List of items from Berlin In-Reply-To: <466F12E1.5090109@computing-services.oxford.ac.uk> Message-ID: <96f3df640706150523i36e8c22bo5e07effdc85b7d1e@mail.gmail.com>
From: Dot Porter
Date: Fri, 15 Jun 2007 08:23:13 -0400
All,
Here are the specifics on my comment on the use of and Lou's
reaction, and a link to the chapter.
Dot
---------- Forwarded message ----------
From: Lou Burnard oxford.ac.uk>
Date: Jun 12, 2007 5:40 PM
Subject: Re: [tei-council] List of items from Berlin
To: Dot Porter edu>
Cc: tei-council village.virginia.edu>
> 7.3.1: I believe that there is an incorrect usage of in the
> second example.
This is a rather strange use of I agree, but not I think
completely wrong. The problem is that the transcriber (this is a real
example, by the way, not one I made up!) is interested in the kinds of
segment primarily, and wants to show that for the purpose of
segmentation the repeated words should be deleted. In the original
typescript they do this by transcribing it and then... deleting it (with
overstriking). So that's what I have encoded. I have tried to reword it
a bit to explain what's going on.
http://www.tei-c.org/release/doc/tei-p5-doc/html/TS.html#TSSA
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 08:23:16 EDT
From dporter at uky.edu Fri Jun 15 08:47:04 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 15 Jun 2007 08:47:04 -0400 Subject: Fwd: [tei-council] List of items from Berlin In-Reply-To: <96f3df640706141914t831124er14ede33525c67651@mail.gmail.com> Message-ID: <96f3df640706150547h430025e8h196a01de239e6563@mail.gmail.com>
From: Dot Porter
Date: Fri, 15 Jun 2007 08:47:04 -0400
Hi Everyone,
I have to leave soon and will miss discussion of the facsimile ODD and
chapter. I sent this message to the list last night but I know at
least Conal didn't receive it (it had a hefty .zip attachment). Con
has put the files up on Trac to please refer to that - Conal, can you
send a direct link to the trac ticket?
I think Conal has done a great job with this and I hope that my
modifications are acceptable to council.
Thanks,
Dot
---------- Forwarded message ----------
From: Dot Porter edu>
Date: Jun 14, 2007 10:14 PM
Subject: Re: [tei-council] List of items from Berlin
To: Lou Burnard oxford.ac.uk>
Cc: tei-council village.virginia.edu>

Hello all,
On 6/12/07, Lou Burnard oxford.ac.uk> wrote:
> > 10: Linking
> > 10.4.3: Three-way alignment. This section needs to be reexamined in
> > light of the current work on facsimile/image markup, and I am working
> > on this currently.
> >
> I see Conal has just posted a whole mass of things. Hoorah!
>
>
I've taken a look at the odd file that Conal posted and have made a
number of modifications. I wasn't able to get that original file to
validate against the tei_odds.rng that I output from Roma, so most of
the changes were just for validation (all changes are listed in the
revisionDesc). I did make two pretty substantial modifications that
are in the spirit of simplicity, and I think we'll be remiss if we
don't include these:
1) Add @url to for those instances when there is one and only one
facsimile image for each page. I also added @width and @height to
to parallel . Make it clear in the Guidelines that when one uses
@url, @width or @height on one is not to use the structures
in the header. I don't know if there is a way to enforce this in the
schema.
2) Created a new attribute @coords (based on the METS attribute of the
same name), added it to att.coordinates, which was added to and
. The datatype of this attribute is a string, simply a list
of coordinate values. I think this should function similar to above,
in that if one uses @coords one should not use the attributes
available in att.projection - but again I don't know if there is a way
to enforce this in the schema.
I output an .rng file based on the ODD and have been working with it
this evening. This is based on some work I'm already doing, and I'm
trying to see how I might fit this current work into these new
structures. The file isn't in very good shape but I attach it and the
image files it references in case anyone is interested (a lot of the
values etc. are just for show...).
I haven't had time to look at Conal's changes to the Linking chapter
text, however Syd and I will be together in Victoria next week and we
have talked about sitting down there and working on it together.
Look forward to speaking to everyone tomorrow,
Dot
Attached:
test-facsimile.xml - sample xml file, relies on fax.rng
several .jpg files, which are pointed to in the xml file
fax-dot.odd - Conal's odd with Dot's modifications
tei_odds.rng - schema against which the odd validates
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 08:47:07 EDT

From Conal.Tuohy at vuw.ac.nz Fri Jun 15 09:09:24 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Sat, 16 Jun 2007 01:09:24 +1200 Subject: [tei-council] facsimile markup example Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABAB9C@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Sat, 16 Jun 2007 01:09:24 +1200
I would be grateful in particular if council members could comment on the revised Comenius example here:
http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/SA-LinkingSegmentationAlignment.xml
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 09:09:46 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 12:35:02 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 17:35:02 +0100 Subject: [tei-council] new title of namedates module Message-ID: <4672BFB6.8000604@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 17:35:02 +0100
Well, I'm shocked, I am afraid. Entirely misleading and uninformative.
Remember that the module name itself needs changing if the title changes.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 12:35:06 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 12:50:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 17:50:33 +0100 Subject: [tei-council] current guidelines Message-ID: <4672C359.7090305@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 17:50:33 +0100
FWIW, I have tweaked http://tei.oucs.ox.ac.uk/Guidelines/index.xml a little
to make it more useful for grabbing and reading a current chapter. It
should be updated every 10 minutes
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 12:50:37 EDT
From Syd_Bauman at Brown.edu Fri Jun 15 14:43:37 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 15 Jun 2007 14:43:37 -0400 Subject: [tei-council] on clean-up In-Reply-To: <46724933.1000202@computing-services.oxford.ac.uk> Message-ID: <18034.56793.26223.379756@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 15 Jun 2007 14:43:37 -0400
I think your algorithm is exactly right, it's just the loop control
that needs to be expanded:
foreach *Spec or attDef or valItem
And two additional steps, inserted before (a):
i) does it already have a which glosses the name of the item being
defined? If so, change it to
ii) does it already have a which describes the semantics of
the item being described? If so, change it to

> foreach *Spec
>
> a) does it have a name which is not an ordinary english word or phrase?
>
> b) if it does, there should be no gloss; if there is a gloss, zap it and
> move on.
>
> c) if it does not have such a name, does it have a gloss which explains
> the *spec name ? if so, move on; if not, create one
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 15 2007 - 14:43:41 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 15 14:50:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jun 2007 19:50:31 +0100 Subject: [tei-council] on clean-up In-Reply-To: <18034.56793.26223.379756@emt.wwp.brown.edu> Message-ID: <4672DF77.7030306@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 15 Jun 2007 19:50:31 +0100
Syd Bauman wrote:
> I think your algorithm is exactly right, it's just the loop control
> that needs to be expanded:
>
> foreach *Spec or attDef or valItem
>
>
lets be precise here :-}
foreach *Spec
{ check gloss/desc}
foreach attDef
{check gloss/desc}
foreach valItem
{check gloss/desc}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 14:50:35 EDT
From daniel.odonnell at uleth.ca Fri Jun 15 18:35:21 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 15 Jun 2007 16:35:21 -0600 Subject: [tei-council] new title of namedates module In-Reply-To: <4672BFB6.8000604@oucs.ox.ac.uk> Message-ID: <1181946921.9132.3.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 15 Jun 2007 16:35:21 -0600
On Fri, 2007-06-15 at 17:35 +0100, Sebastian Rahtz wrote:
> Well, I'm shocked, I am afraid. Entirely misleading and uninformative.
>
> Remember that the module name itself needs changing if the title changes.
Or part of a much larger plot to get that element from physical
bibliography in: custodialEvent or whatever it is called.
-dan
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 15 2007 - 18:37:42 EDT
From James.Cummings at computing-services.oxford.ac.uk Sat Jun 16 11:44:49 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 16 Jun 2007 16:44:49 +0100 Subject: [tei-council] new title of namedates module In-Reply-To: <1181946921.9132.3.camel@localhost> Message-ID: <46740571.8020708@computing-services.oxford.ac.uk>
From: James Cummings
Date: Sat, 16 Jun 2007 16:44:49 +0100
Daniel O'Donnell wrote:
> On Fri, 2007-06-15 at 17:35 +0100, Sebastian Rahtz wrote:
>> Well, I'm shocked, I am afraid. Entirely misleading and uninformative.
>>
>> Remember that the module name itself needs changing if the title changes.
>
> Or part of a much larger plot to get that element from physical
> bibliography in: custodialEvent or whatever it is called.
I must agree with Sebastian. I strongly feel that the new name is entirely
misleading and uninformative. While I will agree that 'names and dates' now
does the chapter a disservice by not recognising the amount of material for
describing persons/places/organisations, I believe that "Historical Data" is
really misleading.
Are you telling me that my tables of historical information are not historical
data? Or that my transcriptions aren't historical (or aren't data)? Just seems
misleading and prone to creating confusion to me.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 16 2007 - 11:44:53 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 16 11:36:40 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 16 Jun 2007 16:36:40 +0100 Subject: [tei-council] new title of namedates module In-Reply-To: <46740571.8020708@computing-services.oxford.ac.uk> Message-ID: <46740388.7050802@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 16 Jun 2007 16:36:40 +0100
I'd suggest "People, places and names"
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 16 2007 - 11:46:48 EDT
From James.Cummings at oucs.ox.ac.uk Sat Jun 16 14:06:33 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 16 Jun 2007 19:06:33 +0100 Subject: [tei-council] Minutes for teleconference, TC M 31 Message-ID: <467426A9.2020807@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 16 Jun 2007 19:06:33 +0100
Dear Council,
An initial draft of the minutes of yesterday's teleconference are now available.
Please let me know of any typos, corrections, inaccuracies. There were a
number of instances where I couldn't clearly hear due dates etc. so I'd ask all
members of council to double-check the minutes. There are a number of actions
given to all the council, thus everyone should be interested in checking.
http://www.tei-c.org/Council/tcm31.xml?style=printable
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 16 2007 - 14:06:36 EDT
From cwittern at gmail.com Sun Jun 17 19:03:18 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 18 Jun 2007 08:03:18 +0900 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <467426A9.2020807@oucs.ox.ac.uk> Message-ID: <4675BDB6.2060408@gmail.com>
From: Wittern Christian
Date: Mon, 18 Jun 2007 08:03:18 +0900
James Cummings wrote:
> Dear Council,
>
> An initial draft of the minutes of yesterday's teleconference are now
> available. Please let me know of any typos, corrections,
> inaccuracies. There were a number of instances where I couldn't
> clearly hear due dates etc. so I'd ask all members of council to
> double-check the minutes. There are a number of actions given to all
> the council, thus everyone should be interested in checking.
Excellent, thanks a lot, James. The minutes seem to cover what we
discussed pretty well.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jun 17 2007 - 19:03:40 EDT
From arianna.ciula at kcl.ac.uk Mon Jun 18 05:20:18 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 18 Jun 2007 10:20:18 +0100 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <467426A9.2020807@oucs.ox.ac.uk> Message-ID: <46764E52.4090509@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 18 Jun 2007 10:20:18 +0100
"Council members unable to participate: Tone Merete Bruvik (TMB);
Arianna Ciula (AC)!" ????
I was there!
Now I understand why nobody listened to me when I was clarifying some of
the issues discussing in Berlin based on my notes...nobody could hear me
or, worse, everybody thought I wasn't there!
Arianna
James Cummings wrote:
> Dear Council,
>
> An initial draft of the minutes of yesterday's teleconference are now
> available. Please let me know of any typos, corrections, inaccuracies.
> There were a number of instances where I couldn't clearly hear due dates
> etc. so I'd ask all members of council to double-check the minutes.
> There are a number of actions given to all the council, thus everyone
> should be interested in checking.
>
> http://www.tei-c.org/Council/tcm31.xml?style=printable
>
> -James
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 18 2007 - 05:20:25 EDT
From James.Cummings at computing-services.oxford.ac.uk Mon Jun 18 05:39:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 18 Jun 2007 10:39:52 +0100 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <46764E52.4090509@kcl.ac.uk> Message-ID: <467652E8.3050909@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 18 Jun 2007 10:39:52 +0100
Arianna Ciula wrote:
> "Council members unable to participate: Tone Merete Bruvik (TMB);
> Arianna Ciula (AC)!" ????
>
> I was there!
>
> Now I understand why nobody listened to me when I was clarifying some of
> the issues discussing in Berlin based on my notes...nobody could hear me
> or, worse, everybody thought I wasn't there!
My deepest apologies! I've corrected the minutes and resubmitted them to
perforce. There were a number of people who I didn't hear clearly for
whatever reason. I certainly don't think that anyone would ignore you
intentionally!
Again, apologies,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 18 2007 - 05:39:55 EDT
From cwittern at gmail.com Mon Jun 18 23:53:43 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 19 Jun 2007 12:53:43 +0900 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <46764E52.4090509@kcl.ac.uk> Message-ID: <46775347.2070401@gmail.com>
From: Wittern Christian
Date: Tue, 19 Jun 2007 12:53:43 +0900
Arianna Ciula wrote:
> "Council members unable to participate: Tone Merete Bruvik (TMB);
> Arianna Ciula (AC)!" ????
>
> I was there!
>
> Now I understand why nobody listened to me when I was clarifying some
> of the issues discussing in Berlin based on my notes...nobody could
> hear me or, worse, everybody thought I wasn't there!
>
Sorry, Arianna, I for one could not hear you! I had seen your message
immediately before the call and expected you to be there, though. Could
it be that your microphone was not working properly?
Hope that we will do better on the next call!
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 18 2007 - 23:53:49 EDT

From conal.tuohy at vuw.ac.nz Wed Jun 20 23:30:16 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 21 Jun 2007 15:30:16 +1200 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <46775347.2070401@gmail.com> Message-ID: <1182396616.30531.49.camel@localhost>
From: Conal Tuohy
Date: Thu, 21 Jun 2007 15:30:16 +1200
In the previous meeting, I was late arriving (due to time zone
confusion) and I found that, although I could hear everything, no-one
could hear me at all. Initially I was disconcerted by everyone's
rudeness, since I know you are all wonderfully polite people, but
eventually I gave up and figured it was a software problem. I know in
that case that my microphone was working correctly, and I successfully
tested my Skype setup after the teleconference, using the Skype test
service. I suspect that highspeedconferencing.com is at fault - is there
perhaps a maximum number of attendees who may speak?
Con
On Tue, 2007-06-19 at 12:53 +0900, Wittern Christian wrote:
> Arianna Ciula wrote:
> > "Council members unable to participate: Tone Merete Bruvik (TMB);
> > Arianna Ciula (AC)!" ????
> >
> > I was there!
> >
> > Now I understand why nobody listened to me when I was clarifying some
> > of the issues discussing in Berlin based on my notes...nobody could
> > hear me or, worse, everybody thought I wasn't there!
> >
> Sorry, Arianna, I for one could not hear you! I had seen your message
> immediately before the call and expected you to be there, though. Could
> it be that your microphone was not working properly?
>
> Hope that we will do better on the next call!
>
> Christian
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 21 2007 - 10:59:17 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jun 21 11:29:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 21 Jun 2007 16:29:51 +0100 Subject: [tei-council] Minutes for teleconference, TC M 31 In-Reply-To: <1182396616.30531.49.camel@localhost> Message-ID: <467A996F.6010504@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Thu, 21 Jun 2007 16:29:51 +0100
I could hear you at least some of the time, Conal. So apologies if I was
one of those being rude!
However, we do seem to have found a serious drawback with this mode of
operation....

Conal Tuohy wrote:
> In the previous meeting, I was late arriving (due to time zone
> confusion) and I found that, although I could hear everything, no-one
> could hear me at all. Initially I was disconcerted by everyone's
> rudeness, since I know you are all wonderfully polite people, but
> eventually I gave up and figured it was a software problem. I know in
> that case that my microphone was working correctly, and I successfully
> tested my Skype setup after the teleconference, using the Skype test
> service. I suspect that highspeedconferencing.com is at fault - is there
> perhaps a maximum number of attendees who may speak?
>
> Con
>
> On Tue, 2007-06-19 at 12:53 +0900, Wittern Christian wrote:
>
>> Arianna Ciula wrote:
>>
>>> "Council members unable to participate: Tone Merete Bruvik (TMB);
>>> Arianna Ciula (AC)!" ????
>>>
>>> I was there!
>>>
>>> Now I understand why nobody listened to me when I was clarifying some
>>> of the issues discussing in Berlin based on my notes...nobody could
>>> hear me or, worse, everybody thought I wasn't there!
>>>
>>>
>> Sorry, Arianna, I for one could not hear you! I had seen your message
>> immediately before the call and expected you to be there, though. Could
>> it be that your microphone was not working properly?
>>
>> Hope that we will do better on the next call!
>>
>> Christian
>>
>>
>>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 21 2007 - 11:30:18 EDT

From James.Cummings at computing-services.oxford.ac.uk Fri Jun 22 09:21:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 22 Jun 2007 14:21:53 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <465E8E50.5070108@oucs.ox.ac.uk> Message-ID: <467BCCF1.3050306@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 22 Jun 2007 14:21:53 +0100
James Cummings wrote:
> Could I remind all the council that each one of you is meant to send Dot
> and I (though send to my email address) a minimum of 5 ways you'd improve
> the formatting of the HTML version of the Guidelines.
>
> No deadline was set for that, but I'd like to now suggest that each of you
> do this by the 5 June 2007..
Hi There!
Each member of the council was meant to sent me 5 suggestions for the
formatting of the Guidelines. These should be formatting suggestions for
the HTML version of Guidelines themselves, not the construction,
organisation or navigation of the TEI website as a whole. If you have not
done it, please do so now. I have put the suggestions received so far up
on the wiki at:
http://www.tei-c.org.uk/wiki/index.php/GuidelinesFormattingSuggestions
If your suggestions are not there (a couple have been rephrased), it means
I must not have received them, please re-send them.
Best,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 09:21:58 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 09:52:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 14:52:54 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BCCF1.3050306@computing-services.oxford.ac.uk> Message-ID: <467BD436.7020708@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 14:52:54 +0100
I hope that you are not going to pass these on unadulterated to the
programmer, James?
Too many of them are like "Better styling of all Relax NG examples"
which does not really provide much a spec for what to change.....
I'd also point out that there is no such thing as "Website issue". These
are (currently) entirely free-standing web pages. the web server adds
nothing.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 09:52:57 EDT
From James.Cummings at computing-services.oxford.ac.uk Fri Jun 22 10:15:58 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 22 Jun 2007 15:15:58 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BD436.7020708@oucs.ox.ac.uk> Message-ID: <467BD99E.5050306@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 22 Jun 2007 15:15:58 +0100
Sebastian Rahtz wrote:
> I hope that you are not going to pass these on unadulterated to the
> programmer, James?
No, I was going to tidy them up organise them by type of thing, and then
make myself a list of things to look at. What programmer is it you're
referring to? As long as Dot and I, having
> Too many of them are like "Better styling of all Relax NG examples"
> which does not really provide much a spec for what to change.....
In that case, that is a rephrased one where various people said things like
"Better pretty printing of Relax NG fragments", etc. and so I summarised
it.
> I'd also point out that there is no such thing as "Website issue". These
> are (currently) entirely free-standing web pages. the web server adds
> nothing.
Sorry, I don't buy that. While it is true that these are free-standing
webpages, the reason Guidelines have the the TEI logo in the top right-hand
corner , the title in the place where it is, a navbar, a 'Skip Links' link,
etc. is to make them fit in with the current website. I don't believe it
is in the remit of looking at the formatting of the Guidelines to redesign
the super-structure in which it is placed. Surely the layout of the title,
etc., are going to have to change to fit in with whatever Virginia come up
with as the new website. While I'll give some thought to the toc issue
that several people raised, the main aim is to get a consistent and
attractive presentation of the content in the rh-col div. As far as I'm
concerned everything outside of that is bound to change depending on the
new website that it will be a part of. Surely you can't be suggesting
that, users should be presented with an entirely different look and feel to
the superstructure of the page than the rest of the TEI site?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:16:01 EDT
From James.Cummings at oucs.ox.ac.uk Fri Jun 22 10:20:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 22 Jun 2007 15:20:51 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BD99E.5050306@computing-services.oxford.ac.uk> Message-ID: <467BDAC3.5060700@oucs.ox.ac.uk>
From: James Cummings
Date: Fri, 22 Jun 2007 15:20:51 +0100
James Cummings wrote:
> Sebastian Rahtz wrote:
>> I hope that you are not going to pass these on unadulterated to the
>> programmer, James?
>
> No, I was going to tidy them up organise them by type of thing, and then
> make myself a list of things to look at. What programmer is it you're
> referring to? As long as Dot and I, having

I seemed to not finish my sentence there. I meant "As long as Dot and I,
having discussed it, understand what we mean, surely that is all that matters?

>
>> Too many of them are like "Better styling of all Relax NG examples"
>> which does not really provide much a spec for what to change.....
>
> In that case, that is a rephrased one where various people said things like
> "Better pretty printing of Relax NG fragments", etc. and so I summarised
> it.
>
>> I'd also point out that there is no such thing as "Website issue". These
>> are (currently) entirely free-standing web pages. the web server adds
>> nothing.
>
> Sorry, I don't buy that. While it is true that these are free-standing
> webpages, the reason Guidelines have the the TEI logo in the top right-hand
> corner , the title in the place where it is, a navbar, a 'Skip Links' link,
> etc. is to make them fit in with the current website. I don't believe it
> is in the remit of looking at the formatting of the Guidelines to redesign
> the super-structure in which it is placed. Surely the layout of the title,
> etc., are going to have to change to fit in with whatever Virginia come up
> with as the new website. While I'll give some thought to the toc issue
> that several people raised, the main aim is to get a consistent and
> attractive presentation of the content in the rh-col div. As far as I'm
> concerned everything outside of that is bound to change depending on the
> new website that it will be a part of. Surely you can't be suggesting
> that, users should be presented with an entirely different look and feel to
> the superstructure of the page than the rest of the TEI site?
>
> -James
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:20:56 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 10:21:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 15:21:09 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BD99E.5050306@computing-services.oxford.ac.uk> Message-ID: <467BDAD5.7030108@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 15:21:09 +0100
James Cummings wrote:
>
> What programmer is it you're
> referring to?
I was assuming you were goinng do dump on me :-}
>
> Sorry, I don't buy that. While it is true that these are free-standing
> webpages, the reason Guidelines have the the TEI logo in the top right-hand
> corner , the title in the place where it is, a navbar, a 'Skip Links' link,
> etc. is to make them fit in with the current website.
you reckon? not in my book.
> I don't believe it
> is in the remit of looking at the formatting of the Guidelines to redesign
> the super-structure in which it is placed. Surely the layout of the title,
> etc., are going to have to change to fit in with whatever Virginia come up
> with as the new website.
what about the people who view them locally?
> Surely you can't be suggesting
> that, users should be presented with an entirely different look and feel to
> the superstructure of the page than the rest of the TEI site?
>
"entirely", no; "different", yes possibly. this sort of material
is very different from the normal run of the mill stuff on the TEI site.
I might well argue that the Guidelines web site should be quite
distinct from the Consortium, possibly a different server,
alongside eg Roma.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:21:13 EDT

From James.Cummings at computing-services.oxford.ac.uk Fri Jun 22 10:30:50 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 22 Jun 2007 15:30:50 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BDAD5.7030108@oucs.ox.ac.uk> Message-ID: <467BDD1A.8060402@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 22 Jun 2007 15:30:50 +0100
Sebastian Rahtz wrote:
> I was assuming you were goinng do dump on me :-}
Well, probably, for those bits we can't figure out ourselves.
>> Sorry, I don't buy that. While it is true that these are free-standing
>> webpages, the reason Guidelines have the the TEI logo in the top right-hand
>> corner , the title in the place where it is, a navbar, a 'Skip Links' link,
>> etc. is to make them fit in with the current website.
> you reckon? not in my book.
Why else does it look practically identical to the rest of the site then?

>> I don't believe it
>> is in the remit of looking at the formatting of the Guidelines to redesign
>> the super-structure in which it is placed. Surely the layout of the title,
>> etc., are going to have to change to fit in with whatever Virginia come up
>> with as the new website.
> what about the people who view them locally?
They'll look the same I assume. Just because they are generated locally
doesn't mean they shouldn't have the same format of logo/title/etc.

>> Surely you can't be suggesting
>> that, users should be presented with an entirely different look and feel to
>> the superstructure of the page than the rest of the TEI site?
>>
> "entirely", no; "different", yes possibly. this sort of material
> is very different from the normal run of the mill stuff on the TEI site.
That is true, I suppose. I was going to use the W3C as an example, and say
that most of there pages look the same (I was thinking of the Specs.) But
then I randomly went to http://www.w3.org/XML/Query/ (ugh!) and a few other
pages and realised, that no, they do all look fairly different.
> I might well argue that the Guidelines web site should be quite
> distinct from the Consortium, possibly a different server,
> alongside eg Roma.
Wouldn't this be confusing for users? Why would they become members of
this consortium thing if the Guidelines seem to have nothing to do with it
and are over there? There might be practical benefits though.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:30:54 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 10:33:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 15:33:10 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BDAC3.5060700@oucs.ox.ac.uk> Message-ID: <467BDDA6.3000106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 15:33:10 +0100
James Cummings wrote:
> I seemed to not finish my sentence there. I meant "As long as Dot and I,
> having discussed it, understand what we mean, surely that is all that matters?
>
that's good; but then there is the stage of translating the "we
understand the problem,
and we know what we want it to do" into concrete specifications.
I suspect there are 3 layers to this work:
1) grab the right info in the right order from the ODD specs
and arrange it as a table of a list or whatever; and
rewrite examplel pretty-printer;
2) get the CSS right so that paragraphs come out in blue;
3) do cool stuff like a dynamic floating TOC on the right-hand side
and you and Dot will need to have a clear idea of what
resources you will have available to assign to each of these :-}

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:33:13 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 10:37:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 15:37:50 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BDD1A.8060402@computing-services.oxford.ac.uk> Message-ID: <467BDEBE.9030900@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 15:37:50 +0100
James Cummings wrote:
> Why else does it look practically identical to the rest of the site then?
>
cos the site uses the default XSL just like the gdelines do...
>
> They'll look the same I assume. Just because they are generated locally
> doesn't mean they shouldn't have the same format of logo/title/etc.
>
but the infrastructure of skip links, whatever, will be there too.
>
>
> Wouldn't this be confusing for users? Why would they become members of
> this consortium thing if the Guidelines seem to have nothing to do with it
> and are over there?
one can make the linkage clear, without mixing reference material
and marketing material
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 10:37:53 EDT
From daniel.odonnell at uleth.ca Fri Jun 22 12:49:30 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 22 Jun 2007 10:49:30 -0600 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BDD1A.8060402@computing-services.oxford.ac.uk> Message-ID: <1182530970.6847.5.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 22 Jun 2007 10:49:30 -0600

> > I might well argue that the Guidelines web site should be quite
> > distinct from the Consortium, possibly a different server,
> > alongside eg Roma.
>
> Wouldn't this be confusing for users? Why would they become members of
> this consortium thing if the Guidelines seem to have nothing to do with it
> and are over there? There might be practical benefits though.
It seems to me that associating the consortium quite firmly with its
main deliverable is a strong desideratum. Ultimately all our main
products and services should be at least from the user's perspective on
the "same" site. Of course it doesn't mean the same server, but we
should be aiming at seamlessness, IMO.
>
> -James
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 12:49:34 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 13:00:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 18:00:15 +0100 Subject: [tei-council] rendition in ODD Message-ID: <467C001F.8010008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 18:00:15 +0100
What do people think about allowing as a child of classSpec
and elementSpec?
This would provide a place to store some default CSS, for example, and
allow Roma
to generate a proposed CSS for each customization.
I'd also like to add a "scheme" attribute to , to let me say

or the like (or maybe name="span"/>).
Any thoughts? James and I batted this around around, we reckon
we could automate a lot of the production of CSS renditions of TEI->HTML
or direct TEI.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 13:00:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 22 13:01:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 22 Jun 2007 18:01:37 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <1182530970.6847.5.camel@localhost> Message-ID: <467C0071.4000607@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 22 Jun 2007 18:01:37 +0100
Daniel O'Donnell wrote:
>
> It seems to me that associating the consortium quite firmly with its
> main deliverable is a strong desideratum.
yes; but using an identical layout for committee minutes
and for the Guidelines is rather a crude way to achieve that.
The Gidlines should follow the TEI Consortium branding
rules, is the way I would put it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 13:01:40 EDT
From daniel.odonnell at uleth.ca Fri Jun 22 13:24:46 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 22 Jun 2007 11:24:46 -0600 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467C0071.4000607@oucs.ox.ac.uk> Message-ID: <1182533086.6847.41.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 22 Jun 2007 11:24:46 -0600
On Fri, 2007-06-22 at 18:01 +0100, Sebastian Rahtz wrote:
> Daniel O'Donnell wrote:
> >
> > It seems to me that associating the consortium quite firmly with its
> > main deliverable is a strong desideratum.
> yes; but using an identical layout for committee minutes
> and for the Guidelines is rather a crude way to achieve that.
> The Gidlines should follow the TEI Consortium branding
> rules, is the way I would put it.
Absolutely. I was only talking about deliberately keeping them separate
in some way.
>
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 22 2007 - 13:24:50 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 22 17:39:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 22 Jun 2007 22:39:28 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467C001F.8010008@oucs.ox.ac.uk> Message-ID: <467C4190.9050100@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 22 Jun 2007 22:39:28 +0100
Sebastian Rahtz wrote:
> What do people think about allowing as a child of
> classSpec and elementSpec?
> This would provide a place to store some default CSS, for example, and
> allow Roma
> to generate a proposed CSS for each customization.
>
> I'd also like to add a "scheme" attribute to , to let me say
>
>
>
> or the like (or maybe
> name="span"/>).
>
> Any thoughts? James and I batted this around around, we reckon
> we could automate a lot of the production of CSS renditions of TEI->HTML
> or direct TEI.
>
I thought we'd agreed that the ODD specification was frozen several
months ago?
And what is the existing element for, if not supplying
default formatting behaviour in precisely this way?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 22 2007 - 17:43:37 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 23 05:03:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 23 Jun 2007 10:03:56 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467C4190.9050100@computing-services.oxford.ac.uk> Message-ID: <467CE1FC.60801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 23 Jun 2007 10:03:56 +0100
Lou Burnard wrote:
> I thought we'd agreed that the ODD specification was frozen several
> months ago?
garn
>
> And what is the existing element for, if not supplying
> default formatting behaviour in precisely this way?
>
indeed. I am just suggesting its class membership be extended to allow
it inside *Spec.
re @scheme on , I think that we simply have not
thought through how to use yet. adding @scheme
to @uri is the equivalent of @key vs @ref, for the same reason.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 23 2007 - 05:04:00 EDT

From lou.burnard at computing-services.oxford.ac.uk Sat Jun 23 05:48:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 23 Jun 2007 10:48:37 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467CE1FC.60801@oucs.ox.ac.uk> Message-ID: <467CEC75.9040104@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 23 Jun 2007 10:48:37 +0100
Sebastian Rahtz wrote:
>
>>
>> And what is the existing element for, if not supplying
>> default formatting behaviour in precisely this way?
>>
> indeed. I am just suggesting its class membership be extended to allow
> it inside *Spec.
>
but rendition, even default rendition, is not a property of the element
itself, but of the document in which it appears. so it should not be
polluting the *spec, but tidily wrapped up in the header for the
document in question, where it belongs,

> re @scheme on , I think that we simply have not
> thought through how to use yet. adding @scheme
> to @uri is the equivalent of @key vs @ref, for the same reason.
>
>
this seems less contentious, in that I agree we havent thought through
how equiv is supposed to be used.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 05:52:50 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 23 06:11:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 23 Jun 2007 11:11:41 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467CEC75.9040104@computing-services.oxford.ac.uk> Message-ID: <467CF1DD.8000304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 23 Jun 2007 11:11:41 +0100
Lou Burnard wrote:
> but rendition, even default rendition, is not a property of the
> element itself, but of the document in which it appears. so it should
> not be polluting the *spec, but tidily wrapped up in the header for
> the document in question, where it belongs,
so 50,000 documents each of which say that should be in italic
have to have 50,000 elements?
gimme break.
when I make an ODD, I say that _in this project_ @rend on will have
values
"bold", "underline" and "subscript", because I have observed this in my
documents.
I also want to record how to render those in CSS using font-style or
whatever.
what is more natural, and One Document Does it all-like, to store these
font-style
things with the relevant ?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 23 2007 - 06:11:46 EDT

From lou.burnard at computing-services.oxford.ac.uk Sat Jun 23 07:28:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 23 Jun 2007 12:28:59 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467CF1DD.8000304@oucs.ox.ac.uk> Message-ID: <467D03FB.8060507@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 23 Jun 2007 12:28:59 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> but rendition, even default rendition, is not a property of the
>> element itself, but of the document in which it appears. so it should
>> not be polluting the *spec, but tidily wrapped up in the header for
>> the document in question, where it belongs,
> so 50,000 documents each of which say that should be in italic
> have to have 50,000 elements?
> gimme break.
I don't think this is relevant. It would be equally annoying to have the
50,000 ways I might choose to process a cluttering up a single
elementSpec wouldn't it? In any real case where you had 50,000
documents to process uniformly, you'd do it by using a single stylesheet
anyway: and didn't we just agree that what stylesheet you can use is
nothing to do with a schema specification?
I thought the specific use case under consideration was how to format
the TEI Guidelines, which is a single document. It makes sense to me to
document the intended rendition for that in its header. Adding proposed
renditional hints for all the element specs which happen to be used in
the schema for that document makes less sense and, in my view, is
un-necessary for the use case in hand.
>
> when I make an ODD, I say that _in this project_ @rend on will
> have values
> "bold", "underline" and "subscript", because I have observed this in
> my documents.
> I also want to record how to render those in CSS using font-style or
> whatever.
> what is more natural, and One Document Does it all-like, to store
> these font-style
> things with the relevant ?
Your argument would make more sense if we wanted to use the ODD to
document a stylesheet, but that hasn't been proposed sfaics. Or is this
argument really about the respective roles of the header and the ODD?
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 07:33:13 EDT
From laurent.romary at loria.fr Sat Jun 23 07:30:03 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 23 Jun 2007 13:30:03 +0200 Subject: [tei-council] rendition in ODD In-Reply-To: <467CF1DD.8000304@oucs.ox.ac.uk> Message-ID: <7852F74A-39C0-4C15-9188-847B5EC06AC5@loria.fr>
From: Laurent Romary
Date: Sat, 23 Jun 2007 13:30:03 +0200
I have just understood what Sebastian meant there and I think he is
going in the right direction, i.e. ODD specifications, with their
capacities of representing hierarchies of schema, could be used to
express constraints ranging from general TEI specifications, down to
project specific constraints and even, at times, document specific
ones. The trade-off here is to view rendering constraints either as
something you would like to put +in+ the document (in the header) or
outside, in particular when you would want to share the constraints
among various documents (without having all of them gathered in a TEI
corpus).
Bref, I like the idea...
Laurent
Le 23 juin 07 ? 12:11, Sebastian Rahtz a ?crit :
> Lou Burnard wrote:
>> but rendition, even default rendition, is not a property of the
>> element itself, but of the document in which it appears. so it
>> should not be polluting the *spec, but tidily wrapped up in the
>> header for the document in question, where it belongs,
> so 50,000 documents each of which say that should be in
> italic have to have 50,000 elements?
> gimme break.
>
> when I make an ODD, I say that _in this project_ @rend on will
> have values
> "bold", "underline" and "subscript", because I have observed this
> in my documents.
> I also want to record how to render those in CSS using font-style
> or whatever.
> what is more natural, and One Document Does it all-like, to store
> these font-style
> things with the relevant ?
>
>
> --
> Sebastian Rahtz
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 07:35:20 EDT
From lou.burnard at computing-services.oxford.ac.uk Sat Jun 23 07:52:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 23 Jun 2007 12:52:39 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <7852F74A-39C0-4C15-9188-847B5EC06AC5@loria.fr> Message-ID: <467D0987.1000601@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 23 Jun 2007 12:52:39 +0100
I don't doubt that this is an interesting and possible evolution for the
ODD specification, but I would rather not make this development right
now without thinking it through properly. My point is just that it is
not currently in scope for what we can hope to achieve for TEI P5
release 1.0 and that we already have an adequate means of solving the
specific problem in hand, viz using rendition in the header.

Laurent Romary wrote:
> I have just understood what Sebastian meant there and I think he is
> going in the right direction, i.e. ODD specifications, with their
> capacities of representing hierarchies of schema, could be used to
> express constraints ranging from general TEI specifications, down to
> project specific constraints and even, at times, document specific
> ones. The trade-off here is to view rendering constraints either as
> something you would like to put +in+ the document (in the header) or
> outside, in particular when you would want to share the constraints
> among various documents (without having all of them gathered in a TEI
> corpus).
> Bref, I like the idea...
> Laurent
>
> Le 23 juin 07 ? 12:11, Sebastian Rahtz a ?crit :
>
>> Lou Burnard wrote:
>>> but rendition, even default rendition, is not a property of the
>>> element itself, but of the document in which it appears. so it
>>> should not be polluting the *spec, but tidily wrapped up in the
>>> header for the document in question, where it belongs,
>> so 50,000 documents each of which say that should be in italic
>> have to have 50,000 elements?
>> gimme break.
>>
>> when I make an ODD, I say that _in this project_ @rend on will
>> have values
>> "bold", "underline" and "subscript", because I have observed this in
>> my documents.
>> I also want to record how to render those in CSS using font-style or
>> whatever.
>> what is more natural, and One Document Does it all-like, to store
>> these font-style
>> things with the relevant ?
>>
>>
>> --Sebastian Rahtz
>> Information Manager, Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 07:56:53 EDT

From laurent.romary at loria.fr Sat Jun 23 08:42:35 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 23 Jun 2007 14:42:35 +0200 Subject: [tei-council] rendition in ODD In-Reply-To: <467D0987.1000601@computing-services.oxford.ac.uk> Message-ID: <7F7FF5B2-52A5-4341-8F99-EE20945E1616@loria.fr>
From: Laurent Romary
Date: Sat, 23 Jun 2007 14:42:35 +0200
I would also agree with this point. Anyhow, we should probably keep
on one of the post 1.0 face to face council meeting a discussion on
the role of ODD and its evolution.
Le 23 juin 07 ? 13:52, Lou Burnard a ?crit :
> I don't doubt that this is an interesting and possible evolution
> for the ODD specification, but I would rather not make this
> development right now without thinking it through properly. My
> point is just that it is not currently in scope for what we can
> hope to achieve for TEI P5 release 1.0 and that we already have an
> adequate means of solving the specific problem in hand, viz using
> rendition in the header.
>
>
> Laurent Romary wrote:
>> I have just understood what Sebastian meant there and I think he
>> is going in the right direction, i.e. ODD specifications, with
>> their capacities of representing hierarchies of schema, could be
>> used to express constraints ranging from general TEI
>> specifications, down to project specific constraints and even, at
>> times, document specific ones. The trade-off here is to view
>> rendering constraints either as something you would like to put +in
>> + the document (in the header) or outside, in particular when you
>> would want to share the constraints among various documents
>> (without having all of them gathered in a TEI corpus).
>> Bref, I like the idea...
>> Laurent
>>
>> Le 23 juin 07 ? 12:11, Sebastian Rahtz a ?crit :
>>
>>> Lou Burnard wrote:
>>>> but rendition, even default rendition, is not a property of the
>>>> element itself, but of the document in which it appears. so it
>>>> should not be polluting the *spec, but tidily wrapped up in the
>>>> header for the document in question, where it belongs,
>>> so 50,000 documents each of which say that should be in
>>> italic have to have 50,000 elements?
>>> gimme break.
>>>
>>> when I make an ODD, I say that _in this project_ @rend on
>>> will have values
>>> "bold", "underline" and "subscript", because I have observed this
>>> in my documents.
>>> I also want to record how to render those in CSS using font-style
>>> or whatever.
>>> what is more natural, and One Document Does it all-like, to store
>>> these font-style
>>> things with the relevant ?
>>>
>>>
>>> --Sebastian Rahtz
>>> Information Manager, Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 08:44:17 EDT
From laurent.romary at loria.fr Sat Jun 23 08:42:35 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 23 Jun 2007 14:42:35 +0200 Subject: [tei-council] rendition in ODD In-Reply-To: <467D0987.1000601@computing-services.oxford.ac.uk> Message-ID: <1182603677.0000@hypermail.dummy>
From: Laurent Romary
Date: Sat, 23 Jun 2007 14:42:35 +0200
I would also agree with this point. Anyhow, we should probably keep
on one of the post 1.0 face to face council meeting a discussion on
the role of ODD and its evolution.
Le 23 juin 07 ? 13:52, Lou Burnard a ?crit :
> I don't doubt that this is an interesting and possible evolution
> for the ODD specification, but I would rather not make this
> development right now without thinking it through properly. My
> point is just that it is not currently in scope for what we can
> hope to achieve for TEI P5 release 1.0 and that we already have an
> adequate means of solving the specific problem in hand, viz using
> rendition in the header.
>
>
> Laurent Romary wrote:
>> I have just understood what Sebastian meant there and I think he
>> is going in the right direction, i.e. ODD specifications, with
>> their capacities of representing hierarchies of schema, could be
>> used to express constraints ranging from general TEI
>> specifications, down to project specific constraints and even, at
>> times, document specific ones. The trade-off here is to view
>> rendering constraints either as something you would like to put +in
>> + the document (in the header) or outside, in particular when you
>> would want to share the constraints among various documents
>> (without having all of them gathered in a TEI corpus).
>> Bref, I like the idea...
>> Laurent
>>
>> Le 23 juin 07 ? 12:11, Sebastian Rahtz a ?crit :
>>
>>> Lou Burnard wrote:
>>>> but rendition, even default rendition, is not a property of the
>>>> element itself, but of the document in which it appears. so it
>>>> should not be polluting the *spec, but tidily wrapped up in the
>>>> header for the document in question, where it belongs,
>>> so 50,000 documents each of which say that should be in
>>> italic have to have 50,000 elements?
>>> gimme break.
>>>
>>> when I make an ODD, I say that _in this project_ @rend on
>>> will have values
>>> "bold", "underline" and "subscript", because I have observed this
>>> in my documents.
>>> I also want to record how to render those in CSS using font-style
>>> or whatever.
>>> what is more natural, and One Document Does it all-like, to store
>>> these font-style
>>> things with the relevant ?
>>>
>>>
>>> --Sebastian Rahtz
>>> Information Manager, Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jun 23 2007 - 09:00:11 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 23 10:58:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 23 Jun 2007 15:58:14 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467D03FB.8060507@computing-services.oxford.ac.uk> Message-ID: <467D3506.2020609@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 23 Jun 2007 15:58:14 +0100
Lou Burnard wrote:
> I don't think this is relevant. It would be equally annoying to have
> the 50,000 ways I might choose to process a cluttering up a
> single elementSpec wouldn't it?
you put the rendition at the point of divergence. so a document level
rendition would obviously
override a schema-level one (like we used to do with DTDs)
> In any real case where you had 50,000 documents to process uniformly,
> you'd do it by using a single stylesheet anyway: and didn't we just
> agree that what stylesheet you can use is nothing to do with a schema
> specification?
did we?
>
> I thought the specific use case under consideration was how to format
> the TEI Guidelines, which is a single document.
no, not at all. What James and I wanted was a way to record a default
rendition of elements
within a given ODD customization, to provide a visualization in a TEI
editor.
formatting of the Guidelines was not in our minds at all, sorry if the
parallel conversation
on the Boared list confused you!
> Your argument would make more sense if we wanted to use the ODD to
> document a stylesheet, but that hasn't been proposed sfaics.
thats yet another subject, but I am not proposing it here. I am proposing
to include enough info in the ODD to generate various visualization
stylesheets
from a single source for a given customization.
> Or is this argument really about the respective roles of the header
> and the ODD?
no, I dont think so
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 23 2007 - 10:58:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 23 11:00:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 23 Jun 2007 16:00:34 +0100 Subject: [tei-council] rendition in ODD In-Reply-To: <467D0987.1000601@computing-services.oxford.ac.uk> Message-ID: <467D3592.5030402@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 23 Jun 2007 16:00:34 +0100
Lou Burnard wrote:
> I don't doubt that this is an interesting and possible evolution for
> the ODD specification, but I would rather not make this development
> right now without thinking it through properly. My point is just that
> it is not currently in scope for what we can hope to achieve for TEI
> P5 release 1.0 and that we already have an adequate means of solving
> the specific problem in hand, viz using rendition in the header.
>
just to make it clear, this proposal was not related at all to any of
the P5 1.0 tasks,
it was a new suggestion I thought might be so trivial it could get under
the radar.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jun 23 2007 - 11:00:38 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 25 12:04:05 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Jun 2007 17:04:05 +0100 Subject: [tei-council] Guidelines formattin Message-ID: <467FE775.6060007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 25 Jun 2007 17:04:05 +0100
those of you who made requests may like to
check http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml
now. I have made a few changes:
- backlinks from footnotes to text
- toggleable display between RNG and RNC display of schema
- process and right
- remove spurious notes from top level
- proper recursive display of class members
- redid the highlighting of XML code to allow distinct renditions of
element name, attribute name, attribute value, comments etc (tho
not all used, as it makes the page look like a fruit salad if you are
not careful)
I might sort out parent lists soon if I feel strong.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 12:04:10 EDT
From arianna.ciula at kcl.ac.uk Mon Jun 25 15:06:11 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 25 Jun 2007 20:06:11 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <467BDDA6.3000106@oucs.ox.ac.uk> Message-ID: <46801223.1070309@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 25 Jun 2007 20:06:11 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
> 3) do cool stuff like a dynamic floating TOC on the right-hand side
We should be careful with 'cool' things as this that may break
compatibility between browsers etc. and simplicity is good...but you
know this better than me.
By the way, looking at the list at
http://www.tei-c.org.uk/wiki/index.php/GuidelinesFormattingSuggestions I
am not sure I agree with point 6: why should the navigation bar go to
the right? I would agree that we could also have a contextual navigation
bar on the right if useful (e.g. chapter by chapter) and/or, better,
breadcrumbs (as suggested under number 27), but the main navigation for
the guidelines (full toc) should stay on the left, I think.
If not too late I would add the following:
- have 'back to top' after a certain number of divisions
- it would be good to have somewhere (if it's already there and I
haven't seen it...sorry in advance) a citation system so that people can
refer to specific sections of the guidelines. This is not directly
related to the style, but the style can help a lot especially if
consistency (e.g. internal numbering of paragraphs) is kept between
default html and PDF for instance and if there is some indication of a
date of publication different from the year.
- labels to switch between languages
- meaningful strings in title tags (see for instance links from first
few paragraphs at
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=CC)
- I saw that the running lists of elements/classes have disappeared.
Now, they were not beautiful, but I think we need some sort of index of
elements/classes/macros different from the pages with the full specs.
They are very useful to find things.
- there are also some issues in the specs:
- e.g. order and repetition of chapters under Note
- I think the module should also have a link to the chapter where
that module is described
orry for the delay...
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 15:06:22 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 25 17:04:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Jun 2007 22:04:10 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <46801223.1070309@kcl.ac.uk> Message-ID: <46802DCA.2060300@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 25 Jun 2007 22:04:10 +0100
Arianna Ciula wrote:
> - have 'back to top' after a certain number of divisions
can you explain this further? I dislike that sort of feature fairly
intensely, but
maybe it is just me. What algorithm do you propose fo rthis?
> - it would be good to have somewhere (if it's already there and I
> haven't seen it...sorry in advance) a citation system so that people
> can refer to specific sections of the guidelines. This is not directly
> related to the style, but the style can help a lot especially if
> consistency (e.g. internal numbering of paragraphs) is kept between
> default html and PDF for instance and if there is some indication of a
> date of publication different from the year.
we have numbered sections. surely that is all you need? ie "its in
section 16.3"? what else
could we have?
> - labels to switch between languages
thats a whole new area to consider
> - meaningful strings in title tags (see for instance links from first
> few paragraphs at
> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=CC)
I am not entirely sure why this does not "just work". I will investigate/.
> - I saw that the running lists of elements/classes have disappeared.
> Now, they were not beautiful, but I think we need some sort of index
> of elements/classes/macros different from the pages with the full
> specs. They are very useful to find things.
you'll have an index eventually, I assume.
> - there are also some issues in the specs:
> - e.g. order and repetition of chapters under Note
got an example I can use to work on?
> - I think the module should also have a link to the chapter where
> that module is described
I may be able to do that now.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 17:04:15 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 25 18:42:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Jun 2007 23:42:51 +0100 Subject: [tei-council] Guidelines formatting Message-ID: <468044EB.5010702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 25 Jun 2007 23:42:51 +0100
yes, the big day has arrived, at
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
you can see the parentage of elements, classes and macros. Now,
I think its silly and unwieldy, but does it make those people who
have been asking for it for years happy?
If you feel very strong and awake, see if you can find a flaw in my
algorithm.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 18:42:55 EDT
From cwittern at gmail.com Mon Jun 25 18:54:00 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 26 Jun 2007 07:54:00 +0900 Subject: [tei-council] Guidelines formattin In-Reply-To: <467FE775.6060007@oucs.ox.ac.uk> Message-ID: <46804788.5020104@gmail.com>
From: Wittern Christian
Date: Tue, 26 Jun 2007 07:54:00 +0900
Sebastian Rahtz wrote:
> those of you who made requests may like to
> check http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml
> now. I have made a few changes:
>
> - backlinks from footnotes to text
> - toggleable display between RNG and RNC display of schema
This is one I silently hoped for, but did not dare mentioning because it
seemed like a tad too big. Great!
You do still (or again) have problems with the formatting here, for
example the documentation lines in RNG tend to run way out of the box,
the page, and everything.
> - process and right
> - remove spurious notes from top level
Not exactly sure what that means, but you still have "include"
statements that seem a bit out of place.
On the whole, looks a lot better now.
Cheers,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 18:54:17 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 25 19:10:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 00:10:33 +0100 Subject: [tei-council] Guidelines formattin In-Reply-To: <46804788.5020104@gmail.com> Message-ID: <46804B69.4030306@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 00:10:33 +0100
Wittern Christian wrote:
>
> You do still (or again) have problems with the formatting here, for
> example the documentation lines in RNG tend to run way out of the box,
> the page, and everything.
can you give me an example?
>
>> - process and right
>> - remove spurious notes from top level
> Not exactly sure what that means, but you still have "include"
> statements that seem a bit out of place.
I have not touched those <> things, I am waiting for someone
to have a good idea on how to solve it.
I must stress that I am not trying to pre-empt James and Dot's redesign
at all.
I am simply fixing some long-standing bugs, to give them the right data
to work out how to display.
Unless someone finds a bug in this, I am stopping this brief holiday
and going back to writing the IM chapter
(http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=IM,
oh that joyful task)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jun 25 2007 - 19:10:38 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jun 25 19:23:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 26 Jun 2007 00:23:12 +0100 Subject: [tei-council] Guidelines formatting In-Reply-To: <468044EB.5010702@oucs.ox.ac.uk> Message-ID: <46804E60.5040706@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 26 Jun 2007 00:23:12 +0100
Sebastian Rahtz wrote:
> yes, the big day has arrived, at
> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
>
> you can see the parentage of elements, classes and macros. Now,
> I think its silly and unwieldy, but does it make those people who
> have been asking for it for years happy?
>
This looks more than silly to me. Does anyone seriously want the
Guidelines to look like this?
It's misleading too -- it implies that everyone will always be using
teiall, and it doesn't indicate the macros and model classes which are
what really determines parent/child relationships in the TEI model, so
you can't use it to work out how you might customize the TEI properly.
I haven't heard people asking for this for years. In fact, the last time
I remember any discussion of it was many years ago, and the conclusion
then was that it only made sense to produce this kind of listing for
specific TEI schemas (the example then was tei lite, but now I guess
we'd propose tei tite for this dubious privilege) and certainly not for
the whole of the guidelines.

> If you feel very strong and awake, see if you can find a flaw in my
> algorithm.
>
which algorithm would that be then?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jun 25 2007 - 19:27:44 EDT

From cwittern at gmail.com Tue Jun 26 01:11:52 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 26 Jun 2007 14:11:52 +0900 Subject: [tei-council] Guidelines formattin In-Reply-To: <46804B69.4030306@oucs.ox.ac.uk> Message-ID: <4680A018.1090709@gmail.com>
From: Wittern Christian
Date: Tue, 26 Jun 2007 14:11:52 +0900
Sebastian Rahtz wrote:
> Wittern Christian wrote:
>>
>> You do still (or again) have problems with the formatting here, for
>> example the documentation lines in RNG tend to run way out of the
>> box, the page, and everything.
> can you give me an example?
I am looking at
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=TC,
scrolling down to the second box where it says RNG, right after
Class: att.rdgPart
RNC






contains a list of one or more sigla indicating the witnesses
which begin or end at this point.








If you now click on RNG to display the XML version, the documentation will extend beyond the Browser window almost to the Korean peninsula

>>
>>> - process and right
>>> - remove spurious notes from top level
>> Not exactly sure what that means, but you still have "include"
>> statements that seem a bit out of place.
>
> I must stress that I am not trying to pre-empt James and Dot's
> redesign at all.
> I am simply fixing some long-standing bugs, to give them the right data
> to work out how to display.
>
> Unless someone finds a bug in this, I am stopping this brief holiday
> and going back to writing the IM chapter
> (http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=IM,
> oh that joyful task)
>
Great, on all counts. And BTW, I like looking at the parents, it makes
the whole thing a lot more fun!
All the best
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 01:12:09 EDT

From cwittern at gmail.com Tue Jun 26 01:18:06 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 26 Jun 2007 14:18:06 +0900 Subject: [tei-council] Guidelines formatting In-Reply-To: <46804E60.5040706@computing-services.oxford.ac.uk> Message-ID: <4680A18E.9000508@gmail.com>
From: Wittern Christian
Date: Tue, 26 Jun 2007 14:18:06 +0900
Lou Burnard wrote:
> Sebastian Rahtz wrote:
>> yes, the big day has arrived, at
>> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
>>
>> you can see the parentage of elements, classes and macros. Now,
>> I think its silly and unwieldy, but does it make those people who
>> have been asking for it for years happy?
>>
> This looks more than silly to me. Does anyone seriously want the
> Guidelines to look like this?
Well, hum, yes!! At least the reference section of the online version.
>
> It's misleading too -- it implies that everyone will always be using
> teiall, and it doesn't indicate the macros and model classes which are
> what really determines parent/child relationships in the TEI model, so
> you can't use it to work out how you might customize the TEI properly.
This will of course be generated from your personal ODD, including only
those elements you actually included, I am sure.
>
> I haven't heard people asking for this for years. In fact, the last
> time I remember any discussion of it was many years ago, and the
> conclusion then was that it only made sense to produce this kind of
> listing for specific TEI schemas (the example then was tei lite, but
> now I guess we'd propose tei tite for this dubious privilege) and
> certainly not for the whole of the guidelines.
I just recently heard two or three people lamenting about the lack of
this list within earshot. Maybe I am socializing with the wrong
people. But seriously, if there is doubt about it's usefulness, I think
this would be a good topic to solicit input from TEI-L via surveymonkey
(Although we might want to hold this off until we have a complete
proposal for layout features).
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 01:18:24 EDT
From conal.tuohy at vuw.ac.nz Tue Jun 26 01:58:43 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 26 Jun 2007 17:58:43 +1200 Subject: [tei-council] Guidelines formatting In-Reply-To: <46804E60.5040706@computing-services.oxford.ac.uk> Message-ID: <1182837523.30531.236.camel@localhost>
From: Conal Tuohy
Date: Tue, 26 Jun 2007 17:58:43 +1200
On Tue, 2007-06-26 at 00:23 +0100, Lou Burnard wrote:
> Sebastian Rahtz wrote:
> > yes, the big day has arrived, at
> > http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
> >
> > you can see the parentage of elements, classes and macros. Now,
> > I think its silly and unwieldy, but does it make those people who
> > have been asking for it for years happy?
> >
> This looks more than silly to me. Does anyone seriously want the
> Guidelines to look like this?
I think it's a handy feature, but it could use some improvement, maybe.
> it doesn't indicate the macros and model classes which are
> what really determines parent/child relationships in the TEI model, so
> you can't use it to work out how you might customize the TEI properly.
That's true. It's still useful for encoders though as a quick reference.
Otherwise, you have to click through model classes, which is an obstacle
if you don't know the internal anatomy of the TEI.
Perhaps the allowable parents could be integrated into the display of
the element's class?
i.e. each class would have its own "Parents" list (of the parent
elements whose content model includes that class). Is that feasible?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 26 2007 - 02:06:28 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 03:56:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 08:56:35 +0100 Subject: [tei-council] Guidelines formatting In-Reply-To: <46804E60.5040706@computing-services.oxford.ac.uk> Message-ID: <4680C6B3.1050209@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 08:56:35 +0100
Lou Burnard wrote:
>
> It's misleading too -- it implies that everyone will always be using
> teiall, and it doesn't indicate the macros and model classes which are
> what really determines parent/child relationships in the TEI model, so
> you can't use it to work out how you might customize the TEI properly.
true. we tried to get it out of P4 too, but gave in eventually :-{
>
>> If you feel very strong and awake, see if you can find a flaw in my
>> algorithm.
>>
> which algorithm would that be then?
>
>
I hope you don't think I made these lists _by hand_? it involves
some devious XSLT, and the underlying method may be wrong.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 03:56:37 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 04:21:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 09:21:56 +0100 Subject: [tei-council] Guidelines formatting In-Reply-To: <1182837523.30531.236.camel@localhost> Message-ID: <4680CCA4.7060805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 09:21:56 +0100
Conal Tuohy wrote:
>
>
> I think it's a handy feature, but it could use some improvement, maybe.
>
what would you like it to do?
> Perhaps the allowable parents could be integrated into the display of
> the element's class?
>
> i.e. each class would have its own "Parents" list (of the parent
> elements whose content model includes that class). Is that feasible?
>
>
see eg
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFCLA#model.entryParts
doesn't this already do what you suggest?
what I _could_ do is list as parents only those elements which
_directly_ reference
the current element, and leave the rest of it to be explored via model
classes and
macros. but it can take some considerable clambering to find things: eg
up to a macroSpec,
then look at classes referenced by that, then at classes of which those
classes are
members, and so on.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 04:22:00 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 04:30:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 09:30:33 +0100 Subject: [tei-council] Guidelines formattin In-Reply-To: <4680A018.1090709@gmail.com> Message-ID: <4680CEA9.7070909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 09:30:33 +0100
Wittern Christian wrote:
> I am looking at
> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=TC,
> scrolling down to the second box where it says RNG, right after
>
> Class: att.rdgPart
>
> ....
>
> If you now click on RNG to display the XML version, the
> documentation will extend beyond the Browser window almost to the
> Korean peninsula
>
sorry, not for me using Firefox or IE6 under Windows.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 04:30:36 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jun 26 04:59:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 26 Jun 2007 09:59:59 +0100 Subject: [tei-council] Guidelines formatting In-Reply-To: <4680A18E.9000508@gmail.com> Message-ID: <4680D58F.2060208@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 26 Jun 2007 09:59:59 +0100
Let me make clear that I'm not objecting to the display of ancestor
information as such. On the contrary I think this is a really important
component of the reference documentation. What I'm objecting to is the
flattened list of all possible ancestors in the current prototype. This
can only confuse those people who are not immediately led to assume
that the TEI scheme is entirely mad because it allows (eg) a
inside a )
The most important thing we have introduced in P5 is the class system.
It's the way we want people to understand the Guidelines, and it's the
ONLY way they can effectively customize the system, which is one of our
declared goals for P5. We've also put huge amounts of effort into
getting the class system a bit more consistent and meaningful. So why
don't we reflect that effort in this list? We give the class membership
for elements separately from the parents: why not merge the two? why not
format it in the same way as the Members list i.e. as className
[classMemberList]?
It would also be good if the classMemberList were formatted differently,
or displayed on a click, in both cases.
Secondly, in your comments below Chris you recomment both that this
full and flattened list of parents should be in the full documentation,
and that it should be in the documentation for your own customization. I
would support the second position, but not the first.

Wittern Christian wrote:
> Lou Burnard wrote:
>> Sebastian Rahtz wrote:
>>> yes, the big day has arrived, at
>>> http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
>>>
>>> you can see the parentage of elements, classes and macros. Now,
>>> I think its silly and unwieldy, but does it make those people who
>>> have been asking for it for years happy?
>>>
>> This looks more than silly to me. Does anyone seriously want the
>> Guidelines to look like this?
> Well, hum, yes!! At least the reference section of the online version.
>>
>> It's misleading too -- it implies that everyone will always be using
>> teiall, and it doesn't indicate the macros and model classes which
>> are what really determines parent/child relationships in the TEI
>> model, so you can't use it to work out how you might customize the
>> TEI properly.
> This will of course be generated from your personal ODD, including
> only those elements you actually included, I am sure.
>
>>
>> I haven't heard people asking for this for years. In fact, the last
>> time I remember any discussion of it was many years ago, and the
>> conclusion then was that it only made sense to produce this kind of
>> listing for specific TEI schemas (the example then was tei lite, but
>> now I guess we'd propose tei tite for this dubious privilege) and
>> certainly not for the whole of the guidelines.
> I just recently heard two or three people lamenting about the lack of
> this list within earshot. Maybe I am socializing with the wrong
> people. But seriously, if there is doubt about it's usefulness, I
> think this would be a good topic to solicit input from TEI-L via
> surveymonkey (Although we might want to hold this off until we have a
> complete proposal for layout features).
>
> Christian
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 26 2007 - 05:04:33 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 05:09:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 10:09:42 +0100 Subject: [tei-council] Guidelines formatting In-Reply-To: <4680D58F.2060208@computing-services.oxford.ac.uk> Message-ID: <4680D7D6.7050005@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 10:09:42 +0100
I have put up a new version. See what you think.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 05:09:45 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 05:46:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 10:46:54 +0100 Subject: [tei-council] members and parents Message-ID: <4680E08E.2010701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 10:46:54 +0100
See display now. More rational and consistent, I hope.
(as Lou noted to me, need to find better labels, but thats another matter)
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 05:46:57 EDT
From arianna.ciula at kcl.ac.uk Tue Jun 26 08:54:07 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 26 Jun 2007 13:54:07 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <46802DCA.2060300@oucs.ox.ac.uk> Message-ID: <46810C6F.2060300@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 26 Jun 2007 13:54:07 +0100
Sebastian Rahtz wrote:
> Arianna Ciula wrote:
>> - have 'back to top' after a certain number of divisions
> can you explain this further? I dislike that sort of feature fairly
> intensely, but
> maybe it is just me. What algorithm do you propose fo rthis?
e.g. back to top after 3/4
elements? I prefer scrolling up myself,
but I know people like that feature and it adds up to the usuability of
the site when pages are so long.
>> - it would be good to have somewhere (if it's already there and I
>> haven't seen it...sorry in advance) a citation system so that people
>> can refer to specific sections of the guidelines. This is not directly
>> related to the style, but the style can help a lot especially if
>> consistency (e.g. internal numbering of paragraphs) is kept between
>> default html and PDF for instance and if there is some indication of a
>> date of publication different from the year.
> we have numbered sections. surely that is all you need? ie "its in
> section 16.3"? what else
> could we have?
I was thinking of P5.1 etc. i.e. some ways of defining the editions or
also a more precise date at the bottom of each page.
>> - there are also some issues in the specs:
>> - e.g. order and repetition of chapters under Note
> got an example I can use to work on?
See specs for where '8.3.1 Information on Written and Spoken
Forms' appears twice.
Thank-you,
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 08:54:25 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jun 26 09:05:24 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 26 Jun 2007 14:05:24 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <46810C6F.2060300@kcl.ac.uk> Message-ID: <46810F14.8020201@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 26 Jun 2007 14:05:24 +0100
Arianna Ciula wrote:
>
> See specs for where '8.3.1 Information on Written and Spoken
> Forms' appears twice.
>
That's actually an error in the source, which I have just fixed.
L
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 26 2007 - 09:09:59 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jun 26 09:25:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 26 Jun 2007 14:25:01 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <46810C6F.2060300@kcl.ac.uk> Message-ID: <468113AD.1090701@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 26 Jun 2007 14:25:01 +0100
This is getting better...
Why is the GI name repeated in the top left box in each element spec? it
is redundant, and hence confusing. I quite liked the format where the
top row of each box contained the GI and the description on a pale gray
background, which is one way of removing the redundancy. Or make the
description span both columns of the box?
Is there still no way of making the boxes all the same width?
Do we need the module name as well as the module chapter title? (and btw
wasn't someone supposed to be coming up with new module names?)
Still too many colours in the example displays for my taste. Attribute
values are part of the tag and shouldn't be in a different colour.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jun 26 2007 - 09:29:36 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 10:01:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 15:01:03 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <46810C6F.2060300@kcl.ac.uk> Message-ID: <46811C1F.5040709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 15:01:03 +0100
Arianna Ciula wrote:
>
> I was thinking of P5.1 etc. i.e. some ways of defining the editions or
> also a more precise date at the bottom of each page.
>
ah, ok, yes; that should be part of the design. better put in James' wiki...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 10:01:06 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 10:03:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 15:03:10 +0100 Subject: [tei-council] Formatting of the Guidelines In-Reply-To: <468113AD.1090701@computing-services.oxford.ac.uk> Message-ID: <46811C9E.6040304@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 15:03:10 +0100
Lou Burnard wrote:
>
> Why is the GI name repeated in the top left box in each element spec?
> it is redundant, and hence confusing. I quite liked the format where
> the top row of each box contained the GI and the description on a pale
> gray background, which is one way of removing the redundancy. Or make
> the description span both columns of the box?
I'll see what I can do there.
>
> Is there still no way of making the boxes all the same width?
just CSS, I'll leave that to James and Dot
>
> Do we need the module name as well as the module chapter title?
cos they convey different info.
> (and btw wasn't someone supposed to be coming up with new module names?)
yup. you :-}
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 10:03:12 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 26 16:07:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Jun 2007 21:07:01 +0100 Subject: [tei-council] more layout Message-ID: <468171E5.8040008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 26 Jun 2007 21:07:01 +0100
sorry, could not resist fiddling again. Hope you like the new
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFTAG
look, ma, all the tables are the same width.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jun 26 2007 - 16:07:06 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 27 09:18:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 27 Jun 2007 14:18:17 +0100 Subject: [tei-council] more formattimg Message-ID: <46826399.1070705@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 27 Jun 2007 14:18:17 +0100
ok, I lied. I have changed it all again,
see http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFCLA now.
you should find it an even smoother experience.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 27 2007 - 09:18:21 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 27 10:58:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 27 Jun 2007 15:58:29 +0100 Subject: [tei-council] another release of P5 Message-ID: <46827B15.9080505@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 27 Jun 2007 15:58:29 +0100
I have let things slip a bit by putting a slightly later database
underneath Roma than
the official release, and I'd like to clean that up next week if I can
by making
a new complete release.
Can any of you preparing material or making fixes tell me
if you have stuff in the pipeline that you want me to wait for,
or things in place that you think are seriously misleading?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jun 27 2007 - 10:58:34 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 28 11:53:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 28 Jun 2007 16:53:14 +0100 Subject: [tei-council] datatype of @n in att.global Message-ID: <4683D96A.5010702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 28 Jun 2007 16:53:14 +0100
I have been caught out a lot of times today by the fact that
the value of "n" is constrained so that it cannot contain spaces.
Given that it "gives a number (or other label) for an element, which is
not necessarily unique within the document", I think
this is unreasonable. One can easily imagine
labels such as "45 (3)" , "Documents and Settings/foo.xml"
or "No. 6" (as in "come in No. 6, your time is up".
I humbly petition the court that space be allowed
in att.global/@n
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 11:53:17 EDT
From arianna.ciula at kcl.ac.uk Thu Jun 28 13:52:08 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 28 Jun 2007 18:52:08 +0100 Subject: [tei-council] more formattimg In-Reply-To: <46826399.1070705@oucs.ox.ac.uk> Message-ID: <4683F548.3010704@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 28 Jun 2007 18:52:08 +0100
I think the 'used by' list for each class should be alphabetical if
possible.
Arianna
Sebastian Rahtz wrote:
> ok, I lied. I have changed it all again,
> see http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFCLA now.
> you should find it an even smoother experience.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 13:52:33 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 28 17:02:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 28 Jun 2007 22:02:57 +0100 Subject: [tei-council] more formattimg In-Reply-To: <4683F548.3010704@kcl.ac.uk> Message-ID: <46842201.2030905@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 28 Jun 2007 22:02:57 +0100
Arianna Ciula wrote:
> I think the 'used by' list for each class should be alphabetical if
> possible.
>
eminently reasonable request, duly granted. should be in place shortly.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 17:03:02 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 28 17:14:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 28 Jun 2007 22:14:23 +0100 Subject: [tei-council] Guidelines draft rendering on tei.oucs.ox.ac.uk Message-ID: <468424AF.8000506@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 28 Jun 2007 22:14:23 +0100
Sorry, the server has entered never-never land, in a way I cannot fix
myself.
I'll let you know when my colleagues with Power wake up.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 17:14:27 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 28 17:26:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 28 Jun 2007 22:26:19 +0100 Subject: [tei-council] oxford tei server Message-ID: <4684277B.4080903@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 28 Jun 2007 22:26:19 +0100
amazingly, my colleagues with Power [1] responded in 3 minutes. back online
[1] aka a VMWare Server console
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 17:26:22 EDT
From conal.tuohy at vuw.ac.nz Thu Jun 28 18:29:31 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 29 Jun 2007 10:29:31 +1200 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4683D96A.5010702@oucs.ox.ac.uk> Message-ID: <1183069771.22867.7.camel@localhost>
From: Conal Tuohy
Date: Fri, 29 Jun 2007 10:29:31 +1200
On Thu, 2007-06-28 at 16:53 +0100, Sebastian Rahtz wrote:
> I have been caught out a lot of times today by the fact that
> the value of "n" is constrained so that it cannot contain spaces.
> Given that it "gives a number (or other label) for an element, which is
> not necessarily unique within the document", I think
> this is unreasonable. One can easily imagine
> labels such as "45 (3)" , "Documents and Settings/foo.xml"
> or "No. 6" (as in "come in No. 6, your time is up".
>
> I humbly petition the court that space be allowed
> in att.global/@n
I vote yes
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jun 28 2007 - 18:37:39 EDT
From cwittern at gmail.com Thu Jun 28 20:55:41 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 29 Jun 2007 09:55:41 +0900 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <1183069771.22867.7.camel@localhost> Message-ID: <4684588D.60904@gmail.com>
From: Wittern Christian
Date: Fri, 29 Jun 2007 09:55:41 +0900
Conal Tuohy wrote:
> On Thu, 2007-06-28 at 16:53 +0100, Sebastian Rahtz wrote:
>
>> I have been caught out a lot of times today by the fact that
>> the value of "n" is constrained so that it cannot contain spaces.
>> Given that it "gives a number (or other label) for an element, which is
>> not necessarily unique within the document", I think
>> this is unreasonable. One can easily imagine
>> labels such as "45 (3)" , "Documents and Settings/foo.xml"
>> or "No. 6" (as in "come in No. 6, your time is up".
>>
>> I humbly petition the court that space be allowed
>> in att.global/@n
>>
>
> I vote yes
>
+1
To be honest, I am surprised that space is not allowed in @n, so it
looks more like a corrigible mistake to me.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jun 28 2007 - 20:55:47 EDT
From James.Cummings at computing-services.oxford.ac.uk Fri Jun 29 05:14:38 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 29 Jun 2007 10:14:38 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4683D96A.5010702@oucs.ox.ac.uk> Message-ID: <4684CD7E.4090408@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 29 Jun 2007 10:14:38 +0100
Sebastian Rahtz wrote:
> I have been caught out a lot of times today by the fact that
> the value of "n" is constrained so that it cannot contain spaces.
> Given that it "gives a number (or other label) for an element, which is
> not necessarily unique within the document", I think
> this is unreasonable. One can easily imagine
> labels such as "45 (3)" , "Documents and Settings/foo.xml"
> or "No. 6" (as in "come in No. 6, your time is up".
>
> I humbly petition the court that space be allowed
> in att.global/@n

In playing devil's advocate, I'd like to call as witness, one Sebastian
P.Q. Rahtz. Mr Rahtz, did you not around 2006-09-05T08:33 in a discussion
of renaming filenames, respond to Lou Burnard's suggestion that we could
"supply them as values for the @n attribute on s" with the sarcastic
quip that "We wouldn't want to abuse @n with free text now would we...."?
The labels you indicate above are compound ones, that could easily be given
in some form which does not require spaces. (And file paths really
shouldn't be used as labels.) The description refers to 'a number' (or
label), that is a *single* number. "45 (3)" is two numbers, though could
easily be given as 45-3 or something else and massaged in processing.
If we allow spaces inside @n, then won't people just naturally abuse this
element with real free text? Isn't part of the point of datatypes to help
protect people from themselves?
-James
P.S. I'm frankly a bit ambivalent about this, but thought someone should at
least attempt to provide an opposing point of view.
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 05:14:42 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 05:36:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 10:36:29 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684CD7E.4090408@computing-services.oxford.ac.uk> Message-ID: <4684D29D.4040907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 10:36:29 +0100
James Cummings wrote:
>
> In playing devil's advocate, I'd like to call as witness, one Sebastian
> P.Q. Rahtz. Mr Rahtz, did you not around 2006-09-05T08:33 in a discussion
> of renaming filenames, respond to Lou Burnard's suggestion that we could
> "supply them as values for the @n attribute on s" with the sarcastic
> quip that "We wouldn't want to abuse @n with free text now would we...."?
>
i plead insanity, m'lud
> The labels you indicate above are compound ones, that could easily be given
> in some form which does not require spaces.
oh yeah? in what sense is "6 (3)" different from "6.3" as valid
use of @n to record a section number?
> (And file paths really
> shouldn't be used as labels.)
why not? again, how is it different from 6.2?
> The description refers to 'a number' (or
> label), that is a *single* number. "45 (3)" is two numbers, though could
> easily be given as 45-3 or something else and massaged in processing.
>
that just means the is wrong. @n is used, surely, to record
(eg) the number-like prefix on heading? so "42" is fine, we all agree;
and I am sure you would also accept "4.2" _because it looks like a
number_. It ain't. its 4 and 2 separated by a "."; in which case why
not separated by a space?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 05:36:32 EDT

From James.Cummings at computing-services.oxford.ac.uk Fri Jun 29 05:47:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 29 Jun 2007 10:47:53 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684D29D.4040907@oucs.ox.ac.uk> Message-ID: <4684D549.3050401@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 29 Jun 2007 10:47:53 +0100
Sebastian Rahtz wrote:
> i plead insanity, m'lud
Your motion is accepted, so the rest of your message will be treated as the
ravings of a deranged lunatic.
> oh yeah? in what sense is "6 (3)" different from "6.3" as valid
> use of @n to record a section number?
It has a space, which makes it two numbers or labels, and the definition
says it should have one. Space is a magical thing which although it is a
character just like others has this weird semantics of creating two
separate things in people's minds when you put it in the middle of a string
of alphanumeric characters.
> why not? again, how is it different from 6.2?
Cuz it has spaces in. If you want to use filepaths, use something that
gives you and attribute with xsd:anyURI perhaps. Storing a filepath seems
like storing textual information in addition to simply a number for the
element to me.
> that just means the is wrong. @n is used, surely, to record
> (eg) the number-like prefix on heading? so "42" is fine, we all agree;
> and I am sure you would also accept "4.2" _because it looks like a
> number_. It ain't. its 4 and 2 separated by a "."; in which case why
> not separated by a space?
Because Space is magical dude.
-James
Ok, not very good arguments, I know. Does anyone feel strongly that @n
should remain data.word?
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 05:47:56 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 05:58:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 10:58:12 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684D549.3050401@computing-services.oxford.ac.uk> Message-ID: <4684D7B4.3040401@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 10:58:12 +0100
James Cummings wrote:
> It has a space, which makes it two numbers or labels, and the definition
> says it should have one. Space is a magical thing which although it is a
> character just like others has this weird semantics of creating two
> separate things in people's minds when you put it in the middle of a string
> of alphanumeric characters.
>
I reject this spurious notion entirely. Were we in France, we'd write
1000 as 1{tiny space}000.
what about "1,000"? a number or not?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 05:58:15 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 29 06:09:22 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 29 Jun 2007 11:09:22 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684D7B4.3040401@oucs.ox.ac.uk> Message-ID: <4684DA52.8030107@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 29 Jun 2007 11:09:22 +0100
Sebastian Rahtz wrote:
> James Cummings wrote:
>> It has a space, which makes it two numbers or labels, and the definition
>> says it should have one. Space is a magical thing which although it is a
>> character just like others has this weird semantics of creating two
>> separate things in people's minds when you put it in the middle of a
>> string
>> of alphanumeric characters.
>>
> I reject this spurious notion entirely. Were we in France, we'd write
> 1000 as 1{tiny space}000.
>
> what about "1,000"? a number or not?
>
When people decode strings of characters they bring to them two
different kinds of grammar: the formal grammar of the language, and the
equally powerful but less frequently formalized grammar of expectation
and context. To insist on either grammar as the sole arbiter is to
invite derision. So to a French reader the {tinyspace} between two sets
of digit strings is as effective a way of combining the digit strings
together as is the comma to the non-French reader. In either case a new
exception rule to the default behaviour of the space or the comma has to
be learned, but learning exception rules is one thing people are really
really good at.
So James is right to say that space "separates things in people's mind"
and Sebastian is right to say "not always", and I think we just have to
make an arbitrary decision here about which schema datatype is closest
to the combination of rules we want to enforce.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 29 2007 - 06:12:16 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 06:20:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 11:20:11 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684DA52.8030107@computing-services.oxford.ac.uk> Message-ID: <4684DCDB.2060300@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 11:20:11 +0100
pragmatically, if I meet in a document
4 (3) Alternatives to Litigation
and this is determined to be a header, am
I not right to mark this up as

Alternatives to Litigation
? If I am right, then the only way to avoid my
plea is to say "but no book ever has done this" :-}
If I am wrong, how _do_ I mark it up?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 06:20:15 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 29 06:24:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 29 Jun 2007 11:24:59 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684DCDB.2060300@oucs.ox.ac.uk> Message-ID: <4684DDFB.3070004@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 29 Jun 2007 11:24:59 +0100
Sebastian Rahtz wrote:
> pragmatically, if I meet in a document
>
> 4 (3) Alternatives to Litigation
>
> and this is determined to be a header, am
> I not right to mark this up as
>
>

> Alternatives to Litigation
>
> ? If I am right, then the only way to avoid my
> plea is to say "but no book ever has done this" :-}
>
> If I am wrong, how _do_ I mark it up?
>
One school of thought is to ask why this text uses such a strange
numbering system and encode the purposes behind it. What does "4 (3)"
mean? If it means "the third subsection of part 4", then we would regard
this as a formatting issue. You shouldn't encode it at all: the
stylesheet is expected to generate it. If it means "this is chapter 4
even though it's actually the third chapter", you should use just n="4"
(and equally generate the " (3)" in your stylesheet). If it means "this
is chapter 4 according to me and chapter 3 according to Denkin,
Watersmith and Vole's 1892 edition, then you should be bunging in some
s
Another school of thought is to say if it matters that much to you, bung
it into the , possibly separating it off as a
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 06:32:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 11:32:45 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684DDFB.3070004@computing-services.oxford.ac.uk> Message-ID: <4684DFCD.5080104@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 11:32:45 +0100
Lou Burnard wrote:
> One school of thought is to ask why this text uses such a strange
> numbering system and encode the purposes behind it. What does "4 (3)"
> mean? If it means "the third subsection of part 4", then we would
> regard this as a formatting issue. You shouldn't encode it at all: the
> stylesheet is expected to generate it.
that's ducking the issue. if the stylesheet always generates it, what is
@n for at all?
it's traditionally been used to record the number, no? you mean @n should
be "4.3"?
the Guidelines have a helpful example of @n:



-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 06:32:48 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jun 29 06:36:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 29 Jun 2007 11:36:56 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684DFCD.5080104@oucs.ox.ac.uk> Message-ID: <4684E0C8.10204@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 29 Jun 2007 11:36:56 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> One school of thought is to ask why this text uses such a strange
>> numbering system and encode the purposes behind it. What does "4 (3)"
>> mean? If it means "the third subsection of part 4", then we would
>> regard this as a formatting issue. You shouldn't encode it at all: the
>> stylesheet is expected to generate it.
> that's ducking the issue. if the stylesheet always generates it, what is
> @n for at all?
> it's traditionally been used to record the number, no? you mean @n should
> be "4.3"?
>
> the Guidelines have a helpful example of @n:
>
>
>
>
>

The discussion at #STGA says:

The n attribute allows identifying information (e.g.
chapter numbers, etc.) to be encoded even if it would not be a legal
xml:id value. Its value may be any string of characters;
typically it is a number or other similar enumerator or label.
So the letter of the law is on your side. James's concerns about
possible misuse are appropriate however: we really don't want to see
things like

or


-- that's what

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 07:51:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 12:51:25 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684E0C8.10204@computing-services.oxford.ac.uk> Message-ID: <4684F23D.9040709@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 12:51:25 +0100
Lou Burnard wrote:
>
>

The n attribute allows identifying information (e.g.
> chapter numbers, etc.) to be encoded even if it would not be a legal
> xml:id value. Its value may be any string of characters;
> typically it is a number or other similar enumerator or label.
>
if you look at things _in the Guidelines_, there is plenty of evidence
to suggest
that spaces can easily be expected within current parameters. Either
all these @n's are evil, or our datatype is wrong. I am puzzled, I confess,
ad to why some of these are not being reported as errors.
catDesc.xml:
change.xml: LB Added examples to
section 3
divGen.xml:
fLib.xml:
fvLib.xml:
list.xml: And if anyone does spare
one, he is to pay for the

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 07:51:28 EDT

From Syd_Bauman at Brown.edu Fri Jun 29 09:19:43 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 29 Jun 2007 09:19:43 -0400 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <4684F23D.9040709@oucs.ox.ac.uk> Message-ID: <18053.1775.865279.826308@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 29 Jun 2007 09:19:43 -0400
I'm afraid this whole litigation is mis-placed. Space is allowed in
@n. It is defined as



meaning that it can be made of letters, digits, punctuation
characters, symbols, or whitespace.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 29 2007 - 09:19:48 EDT
From Syd_Bauman at Brown.edu Fri Jun 29 09:34:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 29 Jun 2007 09:34:14 -0400 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <18053.1775.865279.826308@emt.wwp.brown.edu> Message-ID: <18053.2646.494519.1109@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 29 Jun 2007 09:34:14 -0400
Sorry, I should have taken a moment to explain that.
The refers to a single occurrence of a
'data.word', which itself can contain no whitespace (nor any other
separators, marks, nor "other" characters, e.g. control characters).
The maxOccurs="unbounded" on the element means that any
number of whitespace-separated occurrences of data.word may occur as
the value of n=.

> I'm afraid this whole litigation is mis-placed. Space is allowed in
> @n. It is defined as
>
>
>
> meaning that it can be made of letters, digits, punctuation
> characters, symbols, or whitespace.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 29 2007 - 09:34:17 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 09:37:28 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 14:37:28 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <18053.1775.865279.826308@emt.wwp.brown.edu> Message-ID: <46850B18.4020009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 14:37:28 +0100
Syd Bauman wrote:
> I'm afraid this whole litigation is mis-placed. Space is allowed in
> @n. It is defined as
>
>
>
> meaning that it can be made of letters, digits, punctuation
> characters, symbols, or whitespace.
>
yikes! you mean its all a red herring? in that case
I am going mad.... have to go back and check why
all those errors appeared.
o the Spec for data.word is wrong?

Attributes using this datatype must contain a single
word which contains only letters, digits,
punctuation characters, or symbols: thus it cannot include
whitespace.


-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 09:37:31 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 09:40:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 14:40:44 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <18053.2646.494519.1109@emt.wwp.brown.edu> Message-ID: <46850BDC.3050805@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 14:40:44 +0100
I've found my mistake. I am such an idiot.
Many many apologies for wasting your time for the last 2 days!
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 09:40:48 EDT
From James.Cummings at oucs.ox.ac.uk Fri Jun 29 10:11:44 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 29 Jun 2007 15:11:44 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <46850BDC.3050805@oucs.ox.ac.uk> Message-ID: <46851320.4040408@oucs.ox.ac.uk>
From: James Cummings
Date: Fri, 29 Jun 2007 15:11:44 +0100
Sebastian Rahtz wrote:
> I've found my mistake. I am such an idiot.
>
> Many many apologies for wasting your time for the last 2 days!
I don't think any of my arguments were strong enough to convince me that I
should be arguing to change this to a single data.word.
Though, I would still discourage the use of spaces in @n and use
From Syd_Bauman at Brown.edu Fri Jun 29 10:51:13 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 29 Jun 2007 10:51:13 -0400 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <46850BDC.3050805@oucs.ox.ac.uk> Message-ID: <18053.7265.494194.414381@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 29 Jun 2007 10:51:13 -0400
> so the Spec for data.word is wrong?

Attributes using this datatype must contain a single
word which contains only letters, digits,
punctuation characters, or symbols: thus it cannot include
whitespace.


Really interesting point. This is a leftover from our rapid change
from plural datatypes to singular datatypes with number of occurences
controlled by the surrounding element. The spec isn't
wrong, it correctly describes data.word. However, roughly 1/4 of all
times this datatype is used, it is used in a maxOccurs=unbounded>. Does Council think the remaks in data.word
should the remarks mention this?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jun 29 2007 - 10:51:32 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 29 10:57:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 29 Jun 2007 15:57:17 +0100 Subject: [tei-council] datatype of @n in att.global In-Reply-To: <18053.7265.494194.414381@emt.wwp.brown.edu> Message-ID: <46851DCD.1020409@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 29 Jun 2007 15:57:17 +0100
Syd Bauman wrote:
> The spec isn't
> wrong, it correctly describes data.word. However, roughly 1/4 of all
> times this datatype is used, it is used in a
> maxOccurs=unbounded>. Does Council think the remaks in data.word
> should the remarks mention this?
>
probably. its the sort of thing is for, after all.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jun 29 2007 - 10:57:23 EDT

From Syd_Bauman at Brown.edu Wed Jul 4 21:47:28 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Jul 2007 21:47:28 -0400 (EDT) Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? Message-ID: <200707050147.l651lSrP017956@perseus.services.brown.edu>
From: Syd Bauman
Date: Wed, 4 Jul 2007 21:47:28 -0400 (EDT)
I was unable to close TRAC ticket 338 because the server was not
responding in a timely fashion, if at all. The machine does respond
to pings just fine, though.
---------
Should "gi" (as in , gi= of , locus="gi" of
or ) be glossed as "generic identifier" or as "element
name"?
---------
data.outputMeasurement has the gloss "HTML dimension". See
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-data.outputMeasurement.html.
Some thoughts:
* I think there should be some examples in there: most people don't
casually read regular expressions the way many of us do. I plan to
add some soon.
* The gloss is clearly not right. This datatype is currently only
used for width= and height= of and . But
does it need a gloss? Should its name be changed instead (or in
addition)?
---------
I found that most model.*Like classes did not have glosses, but a few
did. As the "class made up of elements that are in some way like *"
semantic is consistent, I removed those few glosses.
---------
As for the doctype= attribute of , I gave it a gloss, but
I'm not sure I understand this attribute. I *think* it might have
been intended to deal with using different reference declarations for
each of a variety of DTDs which might have been used at the same time
ala CONCUR, but I'm not sure.
---------
We gave the ident= of its name in order to parallel the
ident= of , , etc. I don't wonder if a more
semantically appropriate name would be better. RFC 3066 and its
successor RFC 4646 call the thing they describe (which is the value
of ident= of ) a "tag". Back when we were setting this up I
thought that tag= was too confusing a name for an attribute. But now
I'm not so sure. It seems better than ident=. Could use langTag= or
languageIdentifier= or rfc4646= (ick), I suppose.
Note that for we use tag= ('cause there's only one), and
for we use tags= ('cause there's likely more than
one). So I'm leaning towards tag=.
Thoughts?
---------
I did not gloss "hand" as in @hand, , , ,
etc. Speak up if you think it should be glossed (and say what the
gloss should be).
---------
Why doesn't have the military grid reference system as a value
of datum=?
Does anyone have strong opinions about whether proper nouns like
"World Geodetic System" should be glossed with initial caps or not?
---------
The most amusing gloss I deleted was that for 'model.recordingPart',
which read "dates and date ranges". :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 04 2007 - 21:47:32 EDT
From Syd_Bauman at Brown.edu Wed Jul 4 21:51:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Jul 2007 21:51:02 -0400 (EDT) Subject: [tei-council] a little out-of-date? Message-ID: <200707050151.l651p2Oa019865@perseus.services.brown.edu>
From: Syd Bauman
Date: Wed, 4 Jul 2007 21:51:02 -0400 (EDT)
Seems to me the value "tags" of the method= attribute of
is a bit outdated.

indicates the method adopted to indicate corrections within the text.


corrections have been made silently


corrections have been represented using editorial tags



Conservative proposal: add a gloss to the value that says "encoded"
Liberal proposal: change the value "tags" to the value "encoded" or
"markup", and change the description to read
"corrections have been marked up with editorial
encoding" or some such.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 04 2007 - 21:51:04 EDT
From Syd_Bauman at Brown.edu Wed Jul 4 21:51:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Jul 2007 21:51:21 -0400 (EDT) Subject: [tei-council] oversimplification: isn't measured Message-ID: <200707050151.l651pLw3000592@draco.services.brown.edu>
From: Syd Bauman
Date: Wed, 4 Jul 2007 21:51:21 -0400 (EDT)
In Berlin the TEI Council requested the creation of a new element,
, which would replace the special-purpose
element. Was part of the point of this exercise to eliminate the
special-purpose , , and as well, using (e.g.)
or some such instead?
In any case, the implementation as it now stands seems problematic.
Most importantly, the element has been added to the class
att.measured and removed from att.measurement, which means it has
traded in its quantity= attribute for an extent= attribute. This
seems just wrong. "Extent" has a connotation in English of distance
or area, and is not as general in its meaning as "quantity", which
conveys exactly what the semantics of the attribute are for the
element. After all, there are lots of things that are
measured for which the semantic "extent" does not apply:
e.g., the number of liters of gasoline (or the number of litres of
petrol :-), the number of cookies in the cookie jar, the number of cords
of wood, the baud rate of a modem.
Secondly, the "suggested values include" list for unit= has lost
all the suggested values that don't make sense when measuring a page.
For the element, I don't see why TEI should not provide
standard values for all sorts of possible units. There really is no
point in having some encoders use "m", some use "meter", and others
use "metre" to express the same thing. While I admit it is a long
list, there exists an international standard for many of these, why
not use 'em?
Furthermore, the element permits text content. Is there
a reason for this? I'm not sure it makes sense, but may well be
missing something. No other <*Grp> element permits mixed content
except the dictionary element . (Although and
do permit

.)

Proposal
--------
* move back to att.measurement
* remove text from content of ? (if it seems important,
put model.pLike in?)
* change , , and to a single element ,
which bears a dir= or dim= attribute whose value may be one of
"height", "width", and "depth". This new element could be empty
(quantity always expressed on quantity=, extent=, or value=
attribute) or could have content of text or macro.xtext. (I'd leave
it to David and Matthew to decide on that.)
* do this by changing att.measured to att.extent; this class gets the
new dir= or dim= attribute, has a unit= with only sensible
suggested values (as it now has -- no change needed) and loses the
commodity= attribute, which makes no sense. It also gets a
quantity=, extent=, or value= attribute of data.numeric.

What do you think?
For the old attributes of att.measurement, see
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-att.measurement.html
For the current attributes of att.measured, see
http://tei.oucs.ox.ac.uk/Guidelines/en/guidelines-en.xml.ID=REFCLA#att.measured
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 04 2007 - 21:51:59 EDT

From Syd_Bauman at Brown.edu Wed Jul 4 21:51:16 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Jul 2007 21:51:16 -0400 (EDT) Subject: [tei-council] better constraints Message-ID: <200707050151.l651pGUX000589@draco.services.brown.edu>
From: Syd Bauman
Date: Wed, 4 Jul 2007 21:51:16 -0400 (EDT)
There are a few elements in the TEI scheme which should, I think,
have their *content* constrained to an appropriate datatype. In
paricular:
element current declaration should be
------- ------- ----------- ------ --
text data.name
text data.name
macro.xtext data.name
Any objections?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 04 2007 - 21:51:19 EDT
From djbpitt+tei at pitt.edu Wed Jul 4 23:49:06 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 04 Jul 2007 23:49:06 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <200707050151.l651pLw3000592@draco.services.brown.edu> Message-ID: <468C6A32.1000804@pitt.edu>
From: David J Birnbaum
Date: Wed, 04 Jul 2007 23:49:06 -0400
Dear Syd (cc Council),
> * change , , and to a single element ,
> which bears a dir= or dim= attribute whose value may be one of
> "height", "width", and "depth". This new element could be empty
> (quantity always expressed on quantity=, extent=, or value=
> attribute) or could have content of text or macro.xtext. (I'd leave
> it to David and Matthew to decide on that.)
>
> What do you think?
>
A single element , which admits an attribute to distinguish
height from width from depth, creates the opportunity to record multiple
heights but no width, etc. When I specify the page measurements in a
manuscript description, I require exactly one height and exactly one
width, and my (custom) schema keeps me from doubling one or omitting the
other (these are two completely independent problems). For what it's
worth, I also specify a fixed order for the two measurements, not
because one order is inherently better than another (although I think
that is the case), but because if you permit either order, you increase
the opportunity for a user not to notice whether he or she has omitted
something that should not be omitted.
The opportunity to omit a specification that in practice must not be
omitted or to encode twice a specification that in practice must be
encoded only once arises frequently in the TEI. It is often a
consequence of the proliferation of 'repeatable or groups' (although not
only of 'repeatable or groups'), which have become even more numerous
since we implemented the class system. We may decide that the benefits
of that system justify the price (reduced control and precision) in some
cases, but since we want no more than one height and one width when we
give the dimensions of a folio (and the same plus depth for certain
other measurements), would it not be more reliable to use a model that
reduces the opportunity to deviate from those requirements?
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 04 2007 - 23:49:10 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 00:45:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 00:45:05 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <468C6A32.1000804@pitt.edu> Message-ID: <18060.30545.525610.210407@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 00:45:05 -0400
On the one hand, I couldn't agree with you more, David: we do pay a
heavy price for the class system, and in some cases I doubt it is
worth it. But I suggested a model of
dimension*
with attributes for height, width, and depth as a better alternative
to what we have now:
( height | width | depth )*
as opposed to what would be really nice control:
height, width, depth?
(BTW, I think I used the name in the previous post, which is
a bit silly, as that name is already taken. Of course, we could use
that same element ... the semantics aren't all that different.)
I have to think about the argument that it is easier to create a
customization that expresses control if we leave the three separate
elements. It is not all that hard with only one.


Need one (and only one) height


Need one (and only one) width


At most one depth allowed


But you're right, that is harder than changing the content model of
. Of course, because we now have a generic ,
it does mean you wouldn't be able to use it for other things. Who
knows, you might need to describe a medical manuscript with a blood
pressure in the incipit someday!
> A single element , which admits an attribute to distinguish
> height from width from depth, creates the opportunity to record
> multiple heights but no width, etc. When I specify the page
> measurements in a manuscript description, I require exactly one
> height and exactly one width, and my (custom) schema keeps me from
> doubling one or omitting the other (these are two completely
> independent problems). For what it's worth, I also specify a fixed
> order for the two measurements, not because one order is inherently
> better than another (although I think that is the case), but
> because if you permit either order, you increase the opportunity
> for a user not to notice whether he or she has omitted something
> that should not be omitted.
>
> The opportunity to omit a specification that in practice must not
> be omitted or to encode twice a specification that in practice must
> be encoded only once arises frequently in the TEI. It is often a
> consequence of the proliferation of 'repeatable or groups'
> (although not only of 'repeatable or groups'), which have become
> even more numerous since we implemented the class system. We may
> decide that the benefits of that system justify the price (reduced
> control and precision) in some cases, but since we want no more
> than one height and one width when we give the dimensions of a
> folio (and the same plus depth for certain other measurements),
> would it not be more reliable to use a model that reduces the
> opportunity to deviate from those requirements?
I hope I'm not babbling. It's *way* past bedtime -- 'night!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 00:45:10 EDT
From James.Cummings at oucs.ox.ac.uk Thu Jul 5 03:29:45 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 05 Jul 2007 08:29:45 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <200707050147.l651lSrP017956@perseus.services.brown.edu> Message-ID: <468C9DE9.2070405@oucs.ox.ac.uk>
From: James Cummings
Date: Thu, 05 Jul 2007 08:29:45 +0100
Syd Bauman wrote:
> I was unable to close TRAC ticket 338 because the server was not
> responding in a timely fashion, if at all. The machine does respond
> to pings just fine, though.
>
> ---------
>
> Should "gi" (as in , gi= of , locus="gi" of
> or ) be glossed as "generic identifier" or as "element
> name"?
Generic identifier.
> ---------
>
> data.outputMeasurement has the gloss "HTML dimension". See
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-data.outputMeasurement.html.
> Some thoughts:
>
> * I think there should be some examples in there: most people don't
> casually read regular expressions the way many of us do. I plan to
> add some soon.
>
> * The gloss is clearly not right. This datatype is currently only
> used for width= and height= of and . But
> does it need a gloss? Should its name be changed instead (or in
> addition)?
I'd remove the gloss entirely.
> We gave the ident= of its name in order to parallel the
> ident= of , , etc. I don't wonder if a more
> semantically appropriate name would be better. RFC 3066 and its
> successor RFC 4646 call the thing they describe (which is the value
> of ident= of ) a "tag". Back when we were setting this up I
> thought that tag= was too confusing a name for an attribute. But now
> I'm not so sure. It seems better than ident=. Could use langTag= or
> languageIdentifier= or rfc4646= (ick), I suppose.
I don't find @ident confusing or too inappropriate. Most people won't know the
RFCs use 'tag' and may get confused by other meanings of tag?
> Note that for we use tag= ('cause there's only one), and
> for we use tags= ('cause there's likely more than
> one). So I'm leaning towards tag=.
Or rename those ident. ;-) Wile I have no problem with ident, if tag is more
consistent, I don't really have any strong objections to that, only a mild
unease because of the way 'tag' is used.
-James
>
> I did not gloss "hand" as in @hand, , , ,
> etc. Speak up if you think it should be glossed (and say what the
> gloss should be).
Seems obvious to me.
> Does anyone have strong opinions about whether proper nouns like
> "World Geodetic System" should be glossed with initial caps or not?
Most uses of it in prose tend to be capitalised, but I would guess this is down
to the editorial style guide.
> The most amusing gloss I deleted was that for 'model.recordingPart',
> which read "dates and date ranges". :-)
Oops. And still does on the last stable release. Interesting that no one has
pointed that out!
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-model.recordingPart.html
My thoughts, for what they are worth,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 03:29:51 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 5 04:43:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 05 Jul 2007 09:43:14 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <200707050147.l651lSrP017956@perseus.services.brown.edu> Message-ID: <468CAF22.5060909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 05 Jul 2007 09:43:14 +0100
Syd Bauman wrote:
> I was unable to close TRAC ticket 338 because the server was not
> responding in a timely fashion, if at all. The machine does respond
> to pings just fine, though.
>
sorry, it was stuck in a black hole for reasons I never
understand, out of memory and the like. kicked.
> We gave the ident= of its name in order to parallel the
> ident= of , , etc. I don't wonder if a more
> semantically appropriate name would be better. RFC 3066 and its
> successor RFC 4646 call the thing they describe (which is the value
> of ident= of ) a "tag". Back when we were setting this up I
> thought that tag= was too confusing a name for an attribute. But now
> I'm not so sure. It seems better than ident=. Could use langTag= or
> languageIdentifier= or rfc4646= (ick), I suppose.
>
if any change, make it verbose, ie languageIdentifier.
its only used a few times in a document, so better if its
as self-explanatory as possble.
> Why doesn't have the military grid reference system as a value
> of datum=?
>
cos its a secret
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 04:43:18 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 5 04:48:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 05 Jul 2007 09:48:37 +0100 Subject: [tei-council] better constraints In-Reply-To: <200707050151.l651pGUX000589@draco.services.brown.edu> Message-ID: <468CB065.2030003@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 05 Jul 2007 09:48:37 +0100
Syd Bauman wrote:
> There are a few elements in the TEI scheme which should, I think,
> have their *content* constrained to an appropriate datatype. In
> paricular:
>
> element current declaration should be
> ------- ------- ----------- ------ --
> text data.name
> text data.name
> macro.xtext data.name
>
> Any objections?
>
there are usages of which will break if you do that, such as
ptr target="#Ham01245"/.
and binary value="false"
o decide first if those are misguided.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 04:48:41 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 5 04:58:14 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Jul 2007 09:58:14 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <200707050147.l651lSrP017956@perseus.services.brown.edu> Message-ID: <468CB2A6.30308@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 05 Jul 2007 09:58:14 +0100
Syd Bauman wrote:
---------
>
> Should "gi" (as in , gi= of , locus="gi" of
> or ) be glossed as "generic identifier" or as "element
> name"?
>
> ---------
Interesting question. The problem is that we have another element
() which is presumably glossed as "identifier", so the clear
implication for those who don't know the back history is that is
somehow more general than . Whereas the reverse is actually the
case -- is very specifically only for one kind of identifier: an
element name. It's called because that's what it was called in SGML!
So my opinion is that the gloss should actually say "XML element name",
but that there should be a sentence in the explaining why it's
called "gi". We do the same kind of thing for
A more radical proposal which occurs to me this morning is that we
should maybe merge this element with (and call it ). Few have
ever understood the distinction, and even in the text of the Guidelines
I don't think it's applied consistently. Which suggests it's not a
distinction really worth making.
>
> data.outputMeasurement has the gloss "HTML dimension". See
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-data.outputMeasurement.html.
> Some thoughts:
>
> * I think there should be some examples in there: most people don't
> casually read regular expressions the way many of us do. I plan to
> add some soon.
>
> * The gloss is clearly not right. This datatype is currently only
> used for width= and height= of and . But
> does it need a gloss? Should its name be changed instead (or in
> addition)?
Changing its name might be a good idea, but it certainly needs no gloss
in its current form, since its name is composed of dictionary words.
>
> ---------
>
> I found that most model.*Like classes did not have glosses, but a few
> did. As the "class made up of elements that are in some way like *"
> semantic is consistent, I removed those few glosses.
>
> ---------
ee rule stated above
>
> As for the doctype= attribute of , I gave it a gloss, but
> I'm not sure I understand this attribute. I *think* it might have
> been intended to deal with using different reference declarations for
> each of a variety of DTDs which might have been used at the same time
> ala CONCUR, but I'm not sure.
yes, I think so too: look at the Lachman example in the old version of NH.

>
> ---------
>
> We gave the ident= of its name in order to parallel the
> ident= of , , etc. I don't wonder if a more
> semantically appropriate name would be better. RFC 3066 and its
> successor RFC 4646 call the thing they describe (which is the value
> of ident= of ) a "tag". Back when we were setting this up I
> thought that tag= was too confusing a name for an attribute. But now
> I'm not so sure. It seems better than ident=. Could use langTag= or
> languageIdentifier= or rfc4646= (ick), I suppose.
>
> Note that for we use tag= ('cause there's only one), and
> for we use tags= ('cause there's likely more than
> one). So I'm leaning towards tag=.
>
> Thoughts?
>
Notwithstanding what I said above (about the confusing element), I
am half inclined to agree. The other half of my inclination is to apply
a different general principle, keep this as @ident, and make the current
@tag/s into @key/s
> ---------
>
> I did not gloss "hand" as in @hand, , , ,
> etc. Speak up if you think it should be glossed (and say what the
> gloss should be).
>
> ---------
It should not be glossed. It is a dictionary word.
>
> Why doesn't have the military grid reference system as a value
> of datum=?
I am not sure what you mean. Are you saying that the default datum
should be different from what it is, or that the datum should be
specified on ? If the former, we were assured by at least one
expert at the Kings meeting that the WDS was the right choice and have
seen no evidence to the contrary; if the latter, because that's what
is for.
>
> Does anyone have strong opinions about whether proper nouns like
> "World Geodetic System" should be glossed with initial caps or not?
>
> ---------
They shouldn't be glossed at all: they are dictionary words. But WGS
gets capitals because it is a proper name.,
>
> The most amusing gloss I deleted was that for 'model.recordingPart',
> which read "dates and date ranges". :-)
>
Ah Kut and Paste, what strange paths they those comedians lead us into ...

> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 05:01:43 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 5 05:09:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 05 Jul 2007 10:09:34 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <468CB54E.1080606@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 05 Jul 2007 10:09:34 +0100
Lou Burnard wrote:
>
>
> A more radical proposal which occurs to me this morning is that we
> should maybe merge this element with (and call it ). Few
> have ever understood the distinction, and even in the text of the
> Guidelines I don't think it's applied consistently. Which suggests
> it's not a distinction really worth making.
the example for is hi rend="it", which is short hand for
<hi rend="it">; which is not quite the same
as teiHeader. You might use the latter for making an index entry,
for instance.
o constraining to force you to use when you mean
looks like a good thing, but
it does not stop the simple abuse of teiHeader.
seems like the one to drop, if at all.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 05:09:37 EDT
From James.Cummings at computing-services.oxford.ac.uk Thu Jul 5 05:15:10 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 05 Jul 2007 10:15:10 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <468CB69E.2090307@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 05 Jul 2007 10:15:10 +0100
Lou Burnard wrote:
>> Should "gi" (as in , gi= of , locus="gi" of
>> or ) be glossed as "generic identifier" or as "element
>> name"?
> A more radical proposal which occurs to me this morning is that we
> should maybe merge this element with (and call it ). Few have
> ever understood the distinction, and even in the text of the Guidelines
> I don't think it's applied consistently. Which suggests it's not a
> distinction really worth making.
This argues that the text of the Guidelines needs to be cleaned up and be
consistent. Although it is a distinction that few choose to make, I think
it is still important in some cases. And the Guidelines would be the
use-case I'd suggest. But, if it isn't really used there, or used
properly, then maybe tag isn't needed! I'm quite sure gi is used.
Although it is a subtle distinction, I think it is important for the TEI to
preserve these, especially for those elements used in discussing markup
languages.
> Notwithstanding what I said above (about the confusing element), I
> am half inclined to agree. The other half of my inclination is to apply
> a different general principle, keep this as @ident, and make the current
> @tag/s into @key/s
I'm generally in favour of more @keys so don't see this as a bad thing.
More unkempt thoughts,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 05:15:15 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 5 05:19:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Jul 2007 10:19:54 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <468CB54E.1080606@oucs.ox.ac.uk> Message-ID: <468CB7BA.8030307@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 05 Jul 2007 10:19:54 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>>
>>
>> A more radical proposal which occurs to me this morning is that we
>> should maybe merge this element with (and call it ). Few
>> have ever understood the distinction, and even in the text of the
>> Guidelines I don't think it's applied consistently. Which suggests
>> it's not a distinction really worth making.
> the example for is hi rend="it", which is short hand for
> <hi rend="it">; which is not quite the same
> as teiHeader. You might use the latter for making an index entry,
> for instance.
>
> so constraining to force you to use when you mean
> looks like a good thing, but
> it does not stop the simple abuse of teiHeader.
>
> seems like the one to drop, if at all.
>

You are simply re-stating the intended difference between the two
elements, which is not at issue here. My observation is that people do
not think the distinction is worth making, with the consequence that
both forms of abuse (foo and foo bah="humbug") are
quite commonplace. And if you say to someone "what is that thing with
pointy brackets round it" they will say "it's a tag" without thinking
about its components.
Is anyone sane ever going to want to do
foo bar=humbug
I doubt it. Which means that by introducing a distinction between a tag
that contains just a gi (foo) and one that contains something
else as well (foo bah="humbug") we've obscured one of the
occurrences of foo for index making purposes.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 05:23:24 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 5 05:26:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 05 Jul 2007 10:26:39 +0100 Subject: [tei-council] Glosses, glosses, everywhere, and what do you all think? In-Reply-To: <468CB7BA.8030307@computing-services.oxford.ac.uk> Message-ID: <468CB94F.3060003@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 05 Jul 2007 10:26:39 +0100
Lou Burnard wrote:
> My observation is that people do not think the distinction is worth
> making, with the consequence that both forms of abuse (foo
> and foo bah="humbug") are quite commonplace.
but you _could_ stop the latter with Syd's proposed constraint.
but I tend to agree, merge 'em.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 05:26:43 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 5 07:13:21 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Jul 2007 12:13:21 +0100 Subject: [tei-council] a little out-of-date? In-Reply-To: <200707050151.l651p2Oa019865@perseus.services.brown.edu> Message-ID: <468CD251.6080408@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 05 Jul 2007 12:13:21 +0100
change to

corrections have been represented using markup

Call me a liberal, I don't care....

Syd Bauman wrote:
> Seems to me the value "tags" of the method= attribute of
> is a bit outdated.
>
>
> indicates the method adopted to indicate corrections within the text.
>
>
> corrections have been made silently
>
>
> corrections have been represented using editorial tags
>
>
>
>
> Conservative proposal: add a gloss to the value that says "encoded"
>
> Liberal proposal: change the value "tags" to the value "encoded" or
> "markup", and change the description to read
> "corrections have been marked up with editorial
> encoding" or some such.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 07:16:42 EDT

From Syd_Bauman at Brown.edu Thu Jul 5 10:00:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:00:58 -0400 Subject: [tei-council] on gi (was "Glosses, glosses, everywhere, and what do you all think?") In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <18060.63898.347820.364349@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:00:58 -0400
> > Should "gi" (as in , gi= of , locus="gi" of
> > or ) be glossed as "generic identifier" or as "element
> > name"?
JC> Generic identifier.
LB> ... the gloss should actually say "XML element name", but that
LB> there should be a sentence in the explaining why it's >
LB> called "gi".
I like Lou's idea here, a lot.

LB> [merge and ]
SR, JC, LB> [discussion of idea]
I emphatically think of these two as separate things, think the
distinction is important, and worth keeping. I would not mind
dropping in favor of at all, but the need for
for discussing elements qua elements is extremely important.
(Some would argue renamed to , but I like the legacy
name, myself.)
In the words of that famous first communication between Charles
Goldfarb and Uri Rubinsky, "tag ≠ element!".

I am planning to implement Lou's gloss and remarks soon, but will
hold off on dropping until there is some kind of consensus or
vote.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:01:02 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Jul 5 10:01:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Jul 2007 15:01:42 +0100 Subject: [tei-council] on gi (was "Glosses, glosses, everywhere, and what do you all think?") In-Reply-To: <18060.63898.347820.364349@emt.wwp.brown.edu> Message-ID: <468CF9C6.3020909@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 05 Jul 2007 15:01:42 +0100
Syd Bauman wrote:
>
> In the words of that famous first communication between Charles
> Goldfarb and Uri Rubinsky, "tag ≠ element!".
>
Make that "Yuri". URIs came later.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:04:55 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 10:05:31 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:05:31 -0400 Subject: on data.outputMeasurement (was "Re: [tei-council] Glosses, glosses, ...") In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <18060.64171.630912.917899@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:05:31 -0400
SB> [what about gloss of data.outputMeasurement ?]
JC> I'd remove the gloss entirely.
LB> Changing its name might be a good idea, but it certainly needs no
LB> gloss in its current form, since its name is composed of
LB> dictionary words.

Good, agreed. I have removed the gloss (not checked in yet).
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:05:35 EDT

From Syd_Bauman at Brown.edu Thu Jul 5 10:17:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:17:41 -0400 Subject: on language ID (was "Re: [tei-council] Glosses, glosses, everywhere, and ...") In-Reply-To: <468CB69E.2090307@computing-services.oxford.ac.uk> Message-ID: <18060.64901.2225.157136@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:17:41 -0400
JC> I don't find @ident confusing or too inappropriate. Most people
JC> won't know the RFCs use 'tag' and may get confused by other
JC> meanings of tag?
JC> Or rename those ident. ;-) Wile I have no problem with ident, if
JC> tag is more consistent, I don't really have any strong objections
JC> to that, only a mild unease because of the way 'tag' is used.
SR> if any change, make it verbose, ie languageIdentifier. its only
SR> used a few times in a document, so better if its as
SR> self-explanatory as possble.
LB> Notwithstanding what I said above (about the confusing
LB> element), I am half inclined to agree. The other half of my
LB> inclination is to apply a different general principle, keep this
LB> as @ident, and make the current @tag/s into @key/s
JC> I'm generally in favour of more @keys so don't see this as a bad
JC> thing.
I lean away from overloading key= and ident=. While the mechanism is
the same, the semantics here are quite different than those used for,
e.g., .
If Sebastian's observation that will not occur often in
any given TEI document applies to and
too, then perhaps all three should be renamed together.
I mildly prefer "langTag" or "languageTag" to "languageIdentifier",
but don't really care very much. (They all have the disadvantage of
repeating part of the semantic information of the element name, but
such is life, I suppose.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:17:43 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 10:23:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:23:05 -0400 Subject: [tei-council] on gi In-Reply-To: <468CF9C6.3020909@computing-services.oxford.ac.uk> Message-ID: <18060.65225.825864.464527@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:23:05 -0400
> Make that "Yuri". URIs came later.
Ack! Absolutely right, you are. And it's written *right there* on the
SGML Handbook on the shelf ... sigh. And of course, my spell-checker
was no help, here. :-)
Apologies to Yuri, may he rest in peace. Wonderful fellow, he was.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:23:09 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 10:34:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:34:42 -0400 Subject: on server (was "Re: [tei-council] Glosses, glosses, everywhere, and what ...") In-Reply-To: <468CAF22.5060909@oucs.ox.ac.uk> Message-ID: <18061.386.657194.171832@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:34:42 -0400
> > I was unable to close TRAC ticket 338 because the server was not
> > responding in a timely fashion, if at all. The machine does
> > respond to pings just fine, though.
> sorry, it was stuck in a black hole for reasons I never understand,
> out of memory and the like. kicked.
Check, thanks. Ticket closed.
Roma was giving me trouble last night, too, but seems to be fine now.
I presume it was fighting for the same memory.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:34:53 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 10:43:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 10:43:09 -0400 Subject: on datum= (was "Re: [tei-council] Glosses, glosses, everywhere, ...") In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <18061.893.901595.845648@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 10:43:09 -0400
SB> Why doesn't have the military grid reference system as a value
SB> of datum=?
SR> cos its a secret
Not a very well-kept one. (See below :-)

LB> I am not sure what you mean. ...
Sorry, wasn't very explicit there.
The datum= attribute of the element has 4 sample values,
but only has 3:

datum= of datum= of
(open list) (closed list)
----- ----- ------- -----
WGS84 WGS84
MGRS
OSGB36 OSGB36
ED50 ED50
other
I am far from an expert, and was not at the meetings, but without
further information I'd be inclined to make them both "semi" lists
with the values used on .
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 10:43:13 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Jul 5 11:03:20 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Jul 2007 16:03:20 +0100 Subject: on datum= (was "Re: [tei-council] Glosses, glosses, everywhere, ...") In-Reply-To: <18061.893.901595.845648@emt.wwp.brown.edu> Message-ID: <468D0838.7060100@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 05 Jul 2007 16:03:20 +0100
Syd Bauman wrote:
> SB> W
> LB> I am not sure what you mean. ...
>
> Sorry, wasn't very explicit there.
>
> The datum= attribute of the element has 4 sample values,
> but only has 3:
>
> datum= of datum= of
> (open list) (closed list)
> ----- ----- ------- -----
> WGS84 WGS84
> MGRS
> OSGB36 OSGB36
> ED50 ED50
> other
>
> I am far from an expert, and was not at the meetings, but without
> further information I'd be inclined to make them both "semi" lists
> with the values used on .
>=

Ah, thanks for clarifying. This is a blunder. there should be no @datum
attribute on

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 11:06:34 EDT

From Syd_Bauman at Brown.edu Thu Jul 5 11:10:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 11:10:22 -0400 Subject: [tei-council] Re: on datum= In-Reply-To: <468D0838.7060100@computing-services.oxford.ac.uk> Message-ID: <18061.2526.566485.828056@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 11:10:22 -0400
> Ah, thanks for clarifying. This is a blunder. there should be no
> @datum attribute on
Check, will fix.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 11:10:26 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 11:13:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 11:13:47 -0400 Subject: on capitalization in glosses (was "Re: [tei-council] Glosses, glosses ...") In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <18061.2731.544589.365293@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 11:13:47 -0400
SB> Does anyone have strong opinions about whether proper nouns like
SB> "World Geodetic System" should be glossed with initial caps or
SB> not?
JC> Most uses of it in prose tend to be capitalised, but I would
JC> guess this is down to the editorial style guide.
LB> They shouldn't be glossed at all: they are dictionary words. But
LB> WGS gets capitals because it is a proper name.,
Sorry, I was not being clear. In general, all glosses are all lower
case. The only current exceptions are acronyms ("XML", "MIME", "ODD",
"TEI", "FSD"). But what if the gloss itself is a proper noun? The
example is the attribute value "WGS84" should have a gloss of either
"World Geodetic System" or "world geodetic system".
And yes, this is a question of editorial policy primarily aimed at
Lou.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 11:13:51 EDT
From James.Cummings at computing-services.oxford.ac.uk Thu Jul 5 11:19:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 05 Jul 2007 16:19:27 +0100 Subject: on capitalization in glosses (was "Re: [tei-council] Glosses, glosses ...") In-Reply-To: <18061.2731.544589.365293@emt.wwp.brown.edu> Message-ID: <468D0BFF.4070008@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 05 Jul 2007 16:19:27 +0100
Syd Bauman wrote:
>
> Sorry, I was not being clear. In general, all glosses are all lower
> case. The only current exceptions are acronyms ("XML", "MIME", "ODD",
> "TEI", "FSD"). But what if the gloss itself is a proper noun? The
> example is the attribute value "WGS84" should have a gloss of either
> "World Geodetic System" or "world geodetic system".
I'd vote for the former.
> And yes, this is a question of editorial policy primarily aimed at
> Lou.
But yes, it should be consistent with whatever editorial policy is, and I
know I've never internalised that.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 05 2007 - 11:19:31 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 11:20:07 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 11:20:07 -0400 Subject: [tei-council] better constraints In-Reply-To: <468CB065.2030003@oucs.ox.ac.uk> Message-ID: <18061.3111.996845.980296@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 11:20:07 -0400
> ptr target="#Ham01245"/.
> and binary value="false"
>
> so decide first if those are misguided.
They are not just misguided, they are corrigible errors and have been
corrected.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 11:20:11 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 11:22:50 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 11:22:50 -0400 Subject: [tei-council] a little out-of-date? In-Reply-To: <468CD251.6080408@computing-services.oxford.ac.uk> Message-ID: <18061.3274.344208.352419@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 11:22:50 -0400
> change to
>
> corrections have been represented using markup
>
> Call me a liberal, I don't care....
Done (changed tagdoc, that is. :-) Not checked in yet.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 11:22:52 EDT
From Syd_Bauman at Brown.edu Thu Jul 5 12:30:07 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Jul 2007 12:30:07 -0400 Subject: on doctype= (was "Re: [tei-council] Glosses, glosses, everywhere, and what ...") In-Reply-To: <468CB2A6.30308@computing-services.oxford.ac.uk> Message-ID: <18061.7311.720897.531271@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 5 Jul 2007 12:30:07 -0400
> > As for the doctype= attribute of , I gave it a gloss,
> > but I'm not sure I understand this attribute. I *think* it might
> > have been intended to deal with using different reference
> > declarations for each of a variety of DTDs which might have been
> > used at the same time ala CONCUR, but I'm not sure.
>
> yes, I think so too: look at the Lachman example in the old version
> of NH.
Right. So I think it's pretty clear that this attribute needs to be
updated.
My gut instinct is to see if anyone needs this functionality the hard
way: just ditch it.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 05 2007 - 12:30:11 EDT
From Syd_Bauman at Brown.edu Sun Jul 8 16:20:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 8 Jul 2007 16:20:04 -0400 Subject: [tei-council] please see Language Identification update Message-ID: <18065.18164.433575.797661@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 8 Jul 2007 16:20:04 -0400
This updating of RFC 3066 has turned out to be a bit of a chore. I
have checked in a new version of CH, which has a largely rewritten
section on language identification. (Should be available at
http://tei.oucs.ox.ac.uk/Guidelines/CH.html, I think, but that server
is giving me proxy errors now -- Sebastian, does it need another
kick? In the meantime you can see it at
http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/CH.html#CHSH.)
The output still looks a bit screwy for the fact that //list/head is
not getting processed (the output HTML just has an empty

with
class="listhead"). But besides that, I'd like people to take a look
at it and send to me or post any thoughts or suggestions. In
particular, I am wondering whether or not the Guidelines should
provide a pointer to the IANA registry itself.[1]
Notes
-----
[1] http://www.iana.org/assignments/language-subtag-registry
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 08 2007 - 16:20:08 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 8 16:41:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 08 Jul 2007 21:41:49 +0100 Subject: [tei-council] please see Language Identification update In-Reply-To: <18065.18164.433575.797661@emt.wwp.brown.edu> Message-ID: <46914C0D.6060007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 08 Jul 2007 21:41:49 +0100
Syd Bauman wrote
> Should be available at
> http://tei.oucs.ox.ac.uk/Guidelines/CH.html, I think, but that server
> is giving me proxy errors now -- Sebastian, does it need another
> kick?
its just grinding, load average of 5.63.
I'm probably going to have to take that tei.oucs.ox.ac.uk/Guidelines/
thing down. The machine can't cope. I'll switch it to making static
HTML.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jul 08 2007 - 16:41:54 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 8 16:46:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 08 Jul 2007 21:46:48 +0100 Subject: [tei-council] please see Language Identification update In-Reply-To: <18065.18164.433575.797661@emt.wwp.brown.edu> Message-ID: <46914D38.4010204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 08 Jul 2007 21:46:48 +0100
Syd Bauman wrote:
> The output still looks a bit screwy for the fact that //list/head is
> not getting processed (the output HTML just has an empty

with
> class="listhead").
>
silly error in XSL, just committed a fix to Sourceforge. That
must have been in place for years....

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jul 08 2007 - 16:46:54 EDT

From lou.burnard at computing-services.oxford.ac.uk Sun Jul 8 18:55:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 08 Jul 2007 23:55:08 +0100 Subject: [tei-council] please see Language Identification update In-Reply-To: <46914C0D.6060007@oucs.ox.ac.uk> Message-ID: <46916B4C.4020303@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 08 Jul 2007 23:55:08 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote
>> Should be available at
>> http://tei.oucs.ox.ac.uk/Guidelines/CH.html, I think,
make that
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CH.html
>> but that server
>> is giving me proxy errors now -- Sebastian, does it need another
>> kick?
> its just grinding, load average of 5.63.
>
> I'm probably going to have to take that tei.oucs.ox.ac.uk/Guidelines/
> thing down. The machine can't cope. I'll switch it to making static
> HTML.
>
Boo hiss, just when it was starting to be really useful!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 08 2007 - 19:00:27 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 04:05:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 09:05:50 +0100 Subject: [tei-council] please see Language Identification update In-Reply-To: <46916B4C.4020303@computing-services.oxford.ac.uk> Message-ID: <4691EC5E.1070403@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 09:05:50 +0100
Lou Burnard wrote:
>>
>> I'm probably going to have to take that tei.oucs.ox.ac.uk/Guidelines/
>> thing down. The machine can't cope. I'll switch it to making static
>> HTML.
>>
> Boo hiss, just when it was starting to be really useful!
>
its on the same rebuild cycle (every 10 minutes),
so the effect is just the same.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 04:05:54 EDT

From cwittern at gmail.com Mon Jul 9 04:28:29 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 09 Jul 2007 17:28:29 +0900 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC Message-ID: <4691F1AD.2050404@gmail.com>
From: Wittern Christian
Date: Mon, 09 Jul 2007 17:28:29 +0900
Dear Council members,
This is just a reminder that we have a scheduled telecon coming up next week
on Tuesday (I triple checked and hope I got it right this time).
As usual, please look at
http://www.tei-c.org/Council/tcm31.xml?style=printable and finish any open
issues that have deadlines coming up soon (or even overdue deadlines). It
would be good if you could report on this to the list before the telecon. I
would also like to ask those preparing documents for review to post them by
Friday so that we have the weekend to digest it.
Again as usual, I am collecting items for the agenda. If you feel something
is missing in our plans or else something that is in need of attention and
discussion, please drop me a line.
One last thing, in view of the technical difficulties with the past 2
meetings: Sebastian, could you please check with highspeedconferencing to
see if this could be a problem on their side? And for all of us: Should we
rather go back to the previous setup of using the Univ. of Michigan
conference system? Please voice your opinions.
All the best,
Christian Wittern
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 04:28:36 EDT
From Syd_Bauman at Brown.edu Mon Jul 9 10:57:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Jul 2007 10:57:42 -0400 Subject: [tei-council] Re: on doctype= In-Reply-To: <18061.7311.720897.531271@emt.wwp.brown.edu> Message-ID: <18066.19686.829318.480597@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 9 Jul 2007 10:57:42 -0400
> > yes, I think so too: look at the Lachman example in the old version
> > of NH.
>
> Right. So I think it's pretty clear that this attribute needs to be
> updated.
> My gut instinct is to see if anyone needs this functionality the hard
> way: just ditch it.
So are there any objections to the removal of doctype= of ?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 10:57:46 EDT
From Syd_Bauman at Brown.edu Mon Jul 9 11:03:01 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Jul 2007 11:03:01 -0400 Subject: [tei-council] please see Language Identification update In-Reply-To: <46914D38.4010204@oucs.ox.ac.uk> Message-ID: <18066.20005.461575.760172@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 9 Jul 2007 11:03:01 -0400
> silly error in XSL, just committed a fix to Sourceforge. That
> must have been in place for years....
Yes, it has been. Thanks for the fix.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 11:03:06 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 12:15:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 17:15:18 +0100 Subject: [tei-council] appInfo Message-ID: <46925F16.3050107@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 17:15:18 +0100
I was tasked at Berlin with looking at the request from
Martin Holmes and getting him to agree to the simpler model Council
thought was more appropriate.
After discussion with Martin, I came up with
http://tei.oucs.ox.ac.uk/P5/Test/testappinfo.odd
and its parallel testappinfo.xml. It re-expresses
his stuff in more generic TEI terms (so I claim).
The basic idea is a new child of
holding one or more elements. These have
mandatory @ident and @version attributes, plus dating.
Their mimimum child is a
From Syd_Bauman at Brown.edu Mon Jul 9 16:59:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Jul 2007 16:59:36 -0400 Subject: [tei-council] formatting glitch: encoding inside Message-ID: <18066.41400.353675.281968@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 9 Jul 2007 16:59:36 -0400
Attn: Dot & James
While not necessarily among my top 5 things, I have just noticed that
the phrase-level encoding of the content of elementSpec/desc does not
get transformed into proper HTML. See, e.g., the description of
at
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-egXML.html,
which has "in which the egXML element itself", whereas it should have
"in which the <egXML> element itself".
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 16:59:41 EDT
From Syd_Bauman at Brown.edu Mon Jul 9 17:46:17 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Jul 2007 17:46:17 -0400 Subject: [tei–council] TRAC ticket 329 –– time to close? Message-ID: <18066.44201.973842.429702@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 9 Jul 2007 17:46:17 -0400
Is everyone happy with how dating attributes are handled now? Can I
close TRAC ticket 329 as done?
The only thing that Council requested that was not implemented was
that the when= attribute is not in alternation with one or more of
from=, to=, notBefore=, and notAfter=. This turns out not to be
possible to do with the current implementation of ODD. We could, of
course, add a Schematron rule to cover this circumstance.[1]
Also, the period= attribute was added (at the request of the
placographers, I think), and I don't know what would be Council's
pleasure on how it should interact with the other att.datable
attributes.
Notes
-----
[1]
The when= attribute should not be used in
combination with the from=, to=, notBefore=, or

Although that context is obviously wrong, it doesn't include all
the other elements that are members of att.datable. Anyone think
of a clever way to say context="member of class att.datable"? My
knee-jerk reaction is obviously wrong, as even if it's valid
XPath, the elements and attributes being queried are not in the
current document, but rather are in the expanded and simplified
ODD generated by `roma`:
//*[local-name()=//elementSpec/classes/memberOf[@key='att.datable']/@ident]
Besides, isn't that asking for the ident= of memberOf? I wanted
the ident= of , of course. Sigh. Perhaps
//*[local-name()=//elementSpec[classes/memberOf[@key='att.datable']]/@ident
would be more like it?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 17:46:22 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 17:54:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 22:54:32 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <18066.44201.973842.429702@emt.wwp.brown.edu> Message-ID: <4692AE98.10807@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 22:54:32 +0100
Syd Bauman wrote:
> Is everyone happy with how dating attributes are handled now?
I have a tiny niggling dislike of getting the iso variants when I load
"namesdates",
because I do that quite often, and I feel the iso* things are another
level more obscure.
In an ideal world I'd want them in another module.
> Anyone think
> of a clever way to say context="member of class att.datable"?
put the rule in the classSpec for att.datable, and tell the ODD software
to _do the right thing_ by copying the pattern into all the right places.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 17:54:38 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 17:58:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 22:58:10 +0100 Subject: [tei-council] namesdates == "Historical data" Message-ID: <4692AF72.80204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 22:58:10 +0100
I reckon Lou's had enough fun with this, and its time to
put a stop to it.
Hands up all those who think that
"Historical data" is simply the wrong title for this chapter,
which deals with , ,
and the naming and dating stuff.
I'd also note that no-one is currently tasked
with finalizing the names of modules. Is
anyone bothered?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 17:58:15 EDT
From Syd_Bauman at Brown.edu Mon Jul 9 18:07:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Jul 2007 18:07:42 -0400 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692AE98.10807@oucs.ox.ac.uk> Message-ID: <18066.45486.413542.72834@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 9 Jul 2007 18:07:42 -0400
> I have a tiny niggling dislike of getting the iso variants when I
> load "namesdates", because I do that quite often, and I feel the
> iso* things are another level more obscure. In an ideal world I'd
> want them in another module.
In which module? I can't think of one more appropriate for the
detailed encoding of dates and times than one with "dates" in its
name.
(BTW, I presented the exact same argument for moving , ,
, and out of tagdocs. I didn't even mention .)

> > Anyone think of a clever way to say context="member of class
> > att.datable"?
> put the rule in the classSpec for att.datable, and tell the ODD
> software to _do the right thing_ by copying the pattern into all
> the right places.
I had not imagined that it would be possible to get the ODD software
to do the right thing before 01 Nov, but if you think it's possible,
I don't mind. What would one put in the Schematron fragment that the
ODD software would recognize as its hook? Or would there be some sort
of implicit rule "if you see or elements
floating about w/o a context, insert those Schematron elements into a
rule with content='me' for each 'me' in members of this class"?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 18:07:47 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 9 18:04:20 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Jul 2007 23:04:20 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692AE98.10807@oucs.ox.ac.uk> Message-ID: <4692B0E4.8010709@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 09 Jul 2007 23:04:20 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> Is everyone happy with how dating attributes are handled now?
> I have a tiny niggling dislike of getting the iso variants when I load
> "namesdates",
> because I do that quite often, and I feel the iso* things are another
> level more obscure.
> In an ideal world I'd want them in another module.
I have more than a tiny dislike -- I *hate it* -- but I dont have a
solution, other than to throw the whole idea of supporting both W3C and
ISO date formats out the window. Why didn't we just make our minds up to
support one or the other by default? It's not hard for someone to
redefine if they want to.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 18:09:42 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 9 18:05:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Jul 2007 23:05:43 +0100 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <4692AF72.80204@oucs.ox.ac.uk> Message-ID: <4692B137.9060108@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 09 Jul 2007 23:05:43 +0100
Sebastian Rahtz wrote:
> I reckon Lou's had enough fun with this, and its time to
> put a stop to it.
>
> Hands up all those who think that
> "Historical data" is simply the wrong title for this chapter,
> which deals with , ,
> and the naming and dating stuff.
You should also ask for an alternative proposal.
>
> I'd also note that no-one is currently tasked
> with finalizing the names of modules. Is
> anyone bothered?
>
Last time I asked about this you told me I was charged with the job of
naming them.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 18:11:04 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 18:12:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 23:12:27 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692B0E4.8010709@computing-services.oxford.ac.uk> Message-ID: <4692B2CB.8080000@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 23:12:27 +0100
Lou Burnard wrote:
> I have more than a tiny dislike -- I *hate it* -- but I dont have a
> solution, other than to throw the whole idea of supporting both W3C
> and ISO date formats out the window. Why didn't we just make our minds
> up to support one or the other by default? It's not hard for someone
> to redefine if they want to.
but we *did* make our minds up, to support both formats (and others to
come), in the manner as implemented.
you can have it out again in P6.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 18:12:32 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 18:18:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 23:18:21 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <18066.45486.413542.72834@emt.wwp.brown.edu> Message-ID: <4692B42D.1080605@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 23:18:21 +0100
Syd Bauman wrote:
> In which module? I can't think of one more appropriate for the
> detailed encoding of dates and times than one with "dates" in its
> name.
>
in a new module, I meant. its not *wrong* in "namesdates" at all, but my
argument
is that its an order of magnitude more obscure than the rest of the module,
>
> I had not imagined that it would be possible to get the ODD software
> to do the right thing before 01 Nov, but if you think it's possible,
> I don't mind.
It's possible. I didn't say *I* would implement it :-} Surely someone
else here has
the skills and interest to pick up some of these tasks? we're entering
P5 World in
a parlous state if I am the only person able to fix bugs in, or extend,
the ODD-processing
software. ......
[and anyone who says "but it isn't documented" can expect a call from me
with a hammer aimed at their kneecaps]
> What would one put in the Schematron fragment that the
> ODD software would recognize as its hook? Or would there be some sort
> of implicit rule "if you see or elements
> floating about w/o a context, insert those Schematron elements into a
> rule with content='me' for each 'me' in members of this class"?
>
something like that, yes. I had not really thought it out.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 18:18:26 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 18:21:05 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 23:21:05 +0100 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <4692B137.9060108@computing-services.oxford.ac.uk> Message-ID: <4692B4D1.2040000@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 23:21:05 +0100
Lou Burnard wrote:
>
> You should also ask for an alternative proposal.
Arianna made one, I think, which seemed sensible.
"Names, places, people and dates" would do me just fine :-}
>
> Last time I asked about this you told me I was charged with the job of
> naming them.
oh, OK.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 18:21:10 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 9 18:17:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Jul 2007 23:17:53 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <18066.45486.413542.72834@emt.wwp.brown.edu> Message-ID: <4692B411.9040707@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 09 Jul 2007 23:17:53 +0100
Syd Bauman wrote:
>> I have a tiny niggling dislike of getting the iso variants when I
>> load "namesdates", because I do that quite often, and I feel the
>> iso* things are another level more obscure. In an ideal world I'd
>> want them in another module.
>>
>
> In which module? I can't think of one more appropriate for the
> detailed encoding of dates and times than one with "dates" in its
> name.
>
>
Actually, I thought we *did* decide to require the user to load a
different module if they wanted ISO dates. But this was in Kyoto and
the written record is not clear on the matter.

> (BTW, I presented the exact same argument for moving , ,
> , and out of tagdocs. I didn't even mention .)
>
>
I don't remember you advancing this argument, but someone else (Sylvain
Loiseau) remarked to me the other day that he found the mixture of
techdoc things and specifically meta things in the TD chapter very
confusing.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 09 2007 - 18:23:15 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 9 18:27:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 09 Jul 2007 23:27:37 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692B411.9040707@computing-services.oxford.ac.uk> Message-ID: <4692B659.2070708@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 09 Jul 2007 23:27:37 +0100
Lou Burnard wrote:
> Actually, I thought we *did* decide to require the user to load a
> different module if they wanted ISO dates. But this was in Kyoto and
> the written record is not clear on the matter.
I concur, we did specify that; but when Syd reported the action done
he said something to the effect that he had not implemented that bit,
and we didn't say nowt at the time. Then again I may be mis-remembering.
> I don't remember you advancing this argument, but someone else
> (Sylvain Loiseau) remarked to me the other day that he found the
> mixture of techdoc things and specifically meta things in the TD
> chapter very confusing.
do you mean , , and should go in the core, or in a
new module?
now you mention it, it _would_ be good to hoick them out of TD.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 18:27:43 EDT
From cwittern at gmail.com Mon Jul 9 18:53:43 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 10 Jul 2007 07:53:43 +0900 Subject: [tei-council] appInfo In-Reply-To: <46925F16.3050107@oucs.ox.ac.uk> Message-ID: <4692BC77.2000000@gmail.com>
From: Wittern Christian
Date: Tue, 10 Jul 2007 07:53:43 +0900
Sebastian Rahtz wrote:
> I was tasked at Berlin with looking at the request from
> Martin Holmes and getting him to agree to the simpler model Council
> thought was more appropriate.
>
> After discussion with Martin, I came up with
> http://tei.oucs.ox.ac.uk/P5/Test/testappinfo.odd
> and its parallel testappinfo.xml. It re-expresses
> his stuff in more generic TEI terms (so I claim).
>
> The basic idea is a new child of
> holding one or more elements. These have
> mandatory @ident and @version attributes, plus dating.
> Their mimimum child is a
> readable name for the application. Other contents may
> be

(content whatever you want), or specific
> elements which identify components of the document
> the app has monkeyed with.
This looks pretty fine to me as far as it goes.
The example would better serve its purpose if the pointed-at portions
actually were somewhere in that file, at the moment I can just assume
that I got the idea right.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 18:54:00 EDT

From cwittern at gmail.com Mon Jul 9 19:11:55 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 10 Jul 2007 08:11:55 +0900 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692B411.9040707@computing-services.oxford.ac.uk> Message-ID: <4692C0BB.1030305@gmail.com>
From: Wittern Christian
Date: Tue, 10 Jul 2007 08:11:55 +0900
Lou Burnard wrote:
> Syd Bauman wrote:
>>> I have a tiny niggling dislike of getting the iso variants when I
>>> load "namesdates", because I do that quite often, and I feel the
>>> iso* things are another level more obscure. In an ideal world I'd
>>> want them in another module.
>>>
>>
>> In which module? I can't think of one more appropriate for the
>> detailed encoding of dates and times than one with "dates" in its
>> name.
>>
>
> Actually, I thought we *did* decide to require the user to load a
> different module if they wanted ISO dates. But this was in Kyoto and
> the written record is not clear on the matter.
>
The idea then was, as far as I remember, to put them in a separate
module, which still seems appropriate to me.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 09 2007 - 19:12:12 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 03:57:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 08:57:46 +0100 Subject: [tei-council] appInfo In-Reply-To: <4692BC77.2000000@gmail.com> Message-ID: <46933BFA.5020504@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 08:57:46 +0100
Wittern Christian wrote:
>
>
> The example would better serve its purpose if the pointed-at portions
> actually were somewhere in that file, at the moment I can just assume
> that I got the idea right.
I'd add that; if Sourceforge's Subversion would come back....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 03:57:48 EDT
From laurent.romary at loria.fr Tue Jul 10 04:15:45 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Jul 2007 10:15:45 +0200 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <4691F1AD.2050404@gmail.com> Message-ID: <84BF4B37-98FA-42C0-85B6-E62EA1F95278@loria.fr>
From: Laurent Romary
Date: Tue, 10 Jul 2007 10:15:45 +0200
Dear all,
The action item on the dictionary chapter is done. The chapter has
been updated and checked in for the editors (Lou?) to revise it.
Best,
Laurent

Le 9 juil. 07 ? 10:28, Wittern Christian a ?crit :
> Dear Council members,
>
> This is just a reminder that we have a scheduled telecon coming up
> next week
> on Tuesday (I triple checked and hope I got it right this time).
>
> As usual, please look at
> http://www.tei-c.org/Council/tcm31.xml?style=printable and finish
> any open
> issues that have deadlines coming up soon (or even overdue
> deadlines). It
> would be good if you could report on this to the list before the
> telecon. I
> would also like to ask those preparing documents for review to post
> them by
> Friday so that we have the weekend to digest it.
>
> Again as usual, I am collecting items for the agenda. If you feel
> something
> is missing in our plans or else something that is in need of
> attention and
> discussion, please drop me a line.
>
> One last thing, in view of the technical difficulties with the past 2
> meetings: Sebastian, could you please check with
> highspeedconferencing to
> see if this could be a problem on their side? And for all of us:
> Should we
> rather go back to the previous setup of using the Univ. of Michigan
> conference system? Please voice your opinions.
>
> All the best,
>
> Christian Wittern
>
> --
> Christian Wittern
> Institute for Research in Humanities, Kyoto University
> 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 04:17:23 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 04:30:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 09:30:16 +0100 Subject: [tei-council] appInfo In-Reply-To: <46933BFA.5020504@oucs.ox.ac.uk> Message-ID: <46934398.1080100@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 09:30:16 +0100
Sebastian Rahtz wrote:
> if Sourceforge's Subversion would come back....
>
stupid me. I had not read Sourceforge's warning notes.
now working for me.
added some stuff to make pointers join up
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 04:30:19 EDT
From arianna.ciula at kcl.ac.uk Tue Jul 10 06:06:24 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 10 Jul 2007 11:06:24 +0100 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <4692B4D1.2040000@oucs.ox.ac.uk> Message-ID: <46935A20.7020407@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 10 Jul 2007 11:06:24 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>>
>> You should also ask for an alternative proposal.
> Arianna made one, I think, which seemed sensible.
This is what I had sent to the place list:
- title: in a way I like the new title, but I agree with Sebastian that
may be misleading so something like: 'People, places and organisations:
data and time' may be more precise...don't know
>
> "Names, places, people and dates" would do me just fine :-}
but the above sounds also fine.
Arianna
>>
>> Last time I asked about this you told me I was charged with the job of
>> naming them.
> oh, OK.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 06:06:32 EDT
From arianna.ciula at kcl.ac.uk Tue Jul 10 06:09:27 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 10 Jul 2007 11:09:27 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <18066.44201.973842.429702@emt.wwp.brown.edu> Message-ID: <46935AD7.5050603@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 10 Jul 2007 11:09:27 +0100
Syd Bauman wrote:
> Also, the period= attribute was added (at the request of the
> placographers, I think), and I don't know what would be Council's
> pleasure on how it should interact with the other att.datable
> attributes.
good! now someone will have to add examples etc. in the new ND chapter.
Arianna
>
> Notes
> -----
> [1]
> > @notAfter )"> The when= attribute should not be used in
> combination with the from=, to=, notBefore=, or
>
> Although that context is obviously wrong, it doesn't include all
> the other elements that are members of att.datable. Anyone think
> of a clever way to say context="member of class att.datable"? My
> knee-jerk reaction is obviously wrong, as even if it's valid
> XPath, the elements and attributes being queried are not in the
> current document, but rather are in the expanded and simplified
> ODD generated by `roma`:
> //*[local-name()=//elementSpec/classes/memberOf[@key='att.datable']/@ident]
> Besides, isn't that asking for the ident= of memberOf? I wanted
> the ident= of , of course. Sigh. Perhaps
> //*[local-name()=//elementSpec[classes/memberOf[@key='att.datable']]/@ident
> would be more like it?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 06:09:52 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 10 08:26:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Jul 2007 13:26:54 +0100 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <84BF4B37-98FA-42C0-85B6-E62EA1F95278@loria.fr> Message-ID: <46937B0E.5060908@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 10 Jul 2007 13:26:54 +0100
The chapter was received a week or more ago, but I had some problems
getting it to validate. There were two chief areas of difficult -- one
relating to the use of and its changed content model; the other
relating to the section on "Using attribute values to capture alternate
views" (#DIMVAV)
As regards the first, I think we now have a xcontent model for cit which
does what is required without upsetting either DTD or XSD processorsm,
bvut it would be helpful if someone could check.
As regards the second, (which I don't think has been modified since P3)
much of what it proposes seems at variance with practice elsewhere in
the Guidelines, notably in the recommendation to use text valued
attributes. In the light of the availability of much of this
section seems at best eccentric. It would be very helpful if someone
could read this attentively and make some suggestions -- or some
reassuring noises!

Laurent Romary wrote:
> Dear all,
> The action item on the dictionary chapter is done. The chapter has been
> updated and checked in for the editors (Lou?) to revise it.
> Best,
> Laurent
>
>
> Le 9 juil. 07 ? 10:28, Wittern Christian a ?crit :
>
>> Dear Council members,
>>
>> This is just a reminder that we have a scheduled telecon coming up
>> next week
>> on Tuesday (I triple checked and hope I got it right this time).
>>
>>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 08:27:01 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 08:51:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 13:51:14 +0100 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <46937B0E.5060908@computing-services.oxford.ac.uk> Message-ID: <469380C2.5080504@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 13:51:14 +0100
Lou Burnard wrote:
> As regards the first, I think we now have a xcontent model for cit
> which does what is required without upsetting either DTD or XSD
> processorsm, bvut it would be helpful if someone could check.
I can confirm that it generates XSD, DTD and RNG which are internally
valid, and that
the examples in the chapter validate. Laurent, I changed so that

is no longer allowed as a child, I assume thats OK? If you have other
test files,
please send me some of them to incorporate in the general P5 test suite.
I won't comment on the prose cos I aint looked...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 08:51:20 EDT
From laurent.romary at loria.fr Tue Jul 10 10:00:11 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Jul 2007 16:00:11 +0200 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <469380C2.5080504@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Tue, 10 Jul 2007 16:00:11 +0200
was not directly a member of the model but through the new
class we indicated: how did you do the change?

Le 10 juil. 07 ? 14:51, Sebastian Rahtz a ?crit :
> Lou Burnard wrote:
>> As regards the first, I think we now have a xcontent model for cit
>> which does what is required without upsetting either DTD or XSD
>> processorsm, bvut it would be helpful if someone could check.
> I can confirm that it generates XSD, DTD and RNG which are
> internally valid, and that
> the examples in the chapter validate. Laurent, I changed so
> that
> is no longer allowed as a child, I assume thats OK? If you have
> other test files,
> please send me some of them to incorporate in the general P5 test
> suite.
>
> I won't comment on the prose cos I aint looked...
>
> --
> Sebastian Rahtz Information Manager, Oxford University
> Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 10:06:22 EDT

From laurent.romary at loria.fr Tue Jul 10 10:06:59 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Jul 2007 16:06:59 +0200 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <46937B0E.5060908@computing-services.oxford.ac.uk> Message-ID:
From: Laurent Romary
Date: Tue, 10 Jul 2007 16:06:59 +0200
As to the second: I would say that such lexicograpic data in
attributes are not as touto bear as plain text content (which we want
to avoid). Besides, this section of the guidelines is really useful
as a tutorial on what types of encoding strategies one would want to
use, but not so much about the way to actually encode.
Bref, I have the feeling we could leave it the way it is.
[Is it reassuring?]
Laurent

Le 10 juil. 07 ? 14:26, Lou Burnard a ?crit :
> The chapter was received a week or more ago, but I had some
> problems getting it to validate. There were two chief areas of
> difficult -- one relating to the use of and its changed
> content model; the other relating to the section on "Using
> attribute values to capture alternate views" (#DIMVAV)
>
> As regards the first, I think we now have a xcontent model for cit
> which does what is required without upsetting either DTD or XSD
> processorsm, bvut it would be helpful if someone could check.
>
> As regards the second, (which I don't think has been modified
> since P3) much of what it proposes seems at variance with practice
> elsewhere in the Guidelines, notably in the recommendation to use
> text valued attributes. In the light of the availability of
> much of this section seems at best eccentric. It would be
> very helpful if someone could read this attentively and make some
> suggestions -- or some reassuring noises!
>
>
> Laurent Romary wrote:
>> Dear all,
>> The action item on the dictionary chapter is done. The chapter has
>> been updated and checked in for the editors (Lou?) to revise it.
>> Best,
>> Laurent
>> Le 9 juil. 07 ? 10:28, Wittern Christian a ?crit :
>>> Dear Council members,
>>>
>>> This is just a reminder that we have a scheduled telecon coming
>>> up next week
>>> on Tuesday (I triple checked and hope I got it right this time).
>>>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 10:08:38 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jul 10 10:17:21 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Jul 2007 15:17:21 +0100 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: Message-ID: <469394F1.1020006@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 10 Jul 2007 15:17:21 +0100
Laurent Romary wrote:
> As to the second: I would say that such lexicograpic data in attributes
> are not as touto bear as plain text content (which we want to avoid).
What does "touto bear" mean?
> Besides, this section of the guidelines is really useful as a tutorial
> on what types of encoding strategies one would want to use, but not so
> much about the way to actually encode.
I am not interested in an "encoding strategy" which is at variance with
"the way to actually encode". The Guidelines are supposed to give
practical advice not speculate about how you might do things maybe if...
> Bref, I have the feeling we could leave it the way it is.
Well we could but only if we are happy to contradict ourselves.
> [Is it reassuring?]
No, not very!
> Laurent
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 10:17:28 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 11:13:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 16:13:30 +0100 Subject: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: Message-ID: <4693A21A.6010608@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 16:13:30 +0100
Laurent Romary wrote:
> was not directly a member of the model but through the new
> class we indicated: how did you do the change?
I removed model.entryParts.top from the model; you already had
model.entryParts there,
and all .top seemed to add was . Does this break your requirements?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 11:13:36 EDT
From laurent.romary at loria.fr Tue Jul 10 11:13:34 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Jul 2007 17:13:34 +0200 Subject: !SPAM? Re: [tei-council] upcoming teleconference for the TEI Council on Jul 17 1200 UTC In-Reply-To: <4693A21A.6010608@oucs.ox.ac.uk> Message-ID: <3CC1550B-238B-4E1B-B6A1-C2C499EF5368@loria.fr>
From: Laurent Romary
Date: Tue, 10 Jul 2007 17:13:34 +0200
No, it's perfect!
Thanks,
Laurent
Le 10 juil. 07 ? 17:13, Sebastian Rahtz a ?crit :
> Laurent Romary wrote:
>> was not directly a member of the model but through the new
>> class we indicated: how did you do the change?
> I removed model.entryParts.top from the model; you already had
> model.entryParts there,
> and all .top seemed to add was . Does this break your
> requirements?
>
> --
> Sebastian Rahtz Information Manager, Oxford University
> Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 11:15:35 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 10 11:50:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Jul 2007 16:50:41 +0100 Subject: [tei-council] trac #332 Message-ID: <4693AAD1.5000603@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 10 Jul 2007 16:50:41 +0100
I believe I have now resolved this ticket, by adding witList to
model.listLike, and adding model.listLike to the content for sourceDesc.
I've also added prose to TC which explains when to use witness, msdesc,
or bibl, all of which may legitimately be the target for a @wit
attribute in a reading.
Thinking about this, however, I find myself wondering why we have added
listPerson, listOrg and listPlace to the class model.biblLike rather
than to the class model.listLike, which would seem to make better sense
semantically.
Anyone object if I move them?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 11:50:47 EDT
From arianna.ciula at kcl.ac.uk Tue Jul 10 12:53:00 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 10 Jul 2007 17:53:00 +0100 Subject: [tei-council] please see Language Identification update In-Reply-To: <18065.18164.433575.797661@emt.wwp.brown.edu> Message-ID: <4693B96C.5090802@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 10 Jul 2007 17:53:00 +0100
Hi Syd,
I am not that competent in judging the content of this chapter, but here
are some notes on misspellings and similar:
- first time you mention Unicode I would add a link to its website or a
footnote with the link.
- as you suggest I would add links to IANA (I had made the same comments
for the ND chapter and now the links are there in the footnotes if you
want to use the same reference)
- word repetition --> 'We say that the single and double-storey symbols
both represent one and the same the same abstract character a'
- missing link or old reference --> '(see further 6.3 Highlighting and
Quotation)'
- misspelling --> 'Such documentation does cannot of itself guarantee
proper display'
- missing links --> 'some discussion of related matters is given in
Chapter 18 Transcription of Primary Sources, and Chapter 25
Representation of non-standard Characters and Glyphs' [...] 'Further
advice on the matter of locally-defined characters is contained in
Chapter 25 Representation of non-standard Characters and Glyphs.'
- mis-punctuation --> 'Ligatures (.e.g. the joining [...]'
- 'though for historians of typography their presence and form in a
given edition' --> I would say 'though for palaeographers and historians
of typography their presence and form in a given manuscript or edition'
Best,
Arianna
Syd Bauman wrote:
> This updating of RFC 3066 has turned out to be a bit of a chore. I
> have checked in a new version of CH, which has a largely rewritten
> section on language identification. (Should be available at
> http://tei.oucs.ox.ac.uk/Guidelines/CH.html, I think, but that server
> is giving me proxy errors now -- Sebastian, does it need another
> kick? In the meantime you can see it at
> http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/CH.html#CHSH.)
>
> The output still looks a bit screwy for the fact that //list/head is
> not getting processed (the output HTML just has an empty

with
> class="listhead"). But besides that, I'd like people to take a look
> at it and send to me or post any thoughts or suggestions. In
> particular, I am wondering whether or not the Guidelines should
> provide a pointer to the IANA registry itself.[1]
>
> Notes
> -----
> [1] http://www.iana.org/assignments/language-subtag-registry
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 12:53:22 EDT

From Syd_Bauman at Brown.edu Tue Jul 10 14:12:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 10 Jul 2007 14:12:36 -0400 Subject: [tei-council] please see Language Identification update In-Reply-To: <4693B96C.5090802@kcl.ac.uk> Message-ID: <18067.52244.672626.808858@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 10 Jul 2007 14:12:36 -0400
> I am not that competent in judging the content of this chapter, but
> here are some notes on misspellings and similar: ...
Whoo-hoo! Thanks, Arianna. I plan to go through the list in detail
tomorrow, then ask Michael Beddow (the original author) and Deb
Anderson (a linguist involved both with Unicode and TEI) to take a
look at the corrected version.
Thanks again!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 14:12:40 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 15:55:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 20:55:46 +0100 Subject: [tei-council] formatting glitch: encoding inside In-Reply-To: <18066.41400.353675.281968@emt.wwp.brown.edu> Message-ID: <4693E442.4060404@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 20:55:46 +0100
Syd Bauman wrote:
> While not necessarily among my top 5 things, I have just noticed that
> the phrase-level encoding of the content of elementSpec/desc does not
> get transformed into proper HTML. See, e.g., the description of
> at
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-egXML.html,
> which has "in which the egXML element itself", whereas it should have
> "in which the <egXML> element itself".
>
I can't say it was a pleasure fixing this (a vile little excursion into
the byways),
but fixed it should now be in Subversion
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 15:55:50 EDT
From Syd_Bauman at Brown.edu Tue Jul 10 17:48:13 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 10 Jul 2007 17:48:13 -0400 Subject: [tei-council] formatting glitch: encoding inside In-Reply-To: <4693E442.4060404@oucs.ox.ac.uk> Message-ID: <18067.65181.231973.461584@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 10 Jul 2007 17:48:13 -0400
Thanks, Sebastian!
> I can't say it was a pleasure fixing this (a vile little excursion
> into the byways), but fixed it should now be in Subversion
I have to admit I'm a bit curious: was it any more than changing
something like into
soemthing like ? Or was the hard part finding
the right spot?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 10 2007 - 17:48:17 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 10 18:00:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Jul 2007 23:00:12 +0100 Subject: [tei-council] formatting glitch: encoding inside In-Reply-To: <18067.65181.231973.461584@emt.wwp.brown.edu> Message-ID: <4694016C.7050508@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 10 Jul 2007 23:00:12 +0100
Syd Bauman wrote:
>
> I have to admit I'm a bit curious: was it any more than changing
> something like into
> soemthing like ? Or was the hard part finding
> the right spot?
>
the problem was that the same template is called when making marked-up
output and when making schemas. in the latter case, I dont want the
markup code
getting through. the code is complicated by the need to choose the right

depending on language. In the event, I ended up making a zillion
attempts to get it right.
the good news is that all and handling
is in a single template....

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 18:00:17 EDT

From James.Cummings at oucs.ox.ac.uk Tue Jul 10 21:23:01 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Jul 2007 02:23:01 +0100 Subject: [tei-council] formatting glitch: encoding inside In-Reply-To: <18067.65181.231973.461584@emt.wwp.brown.edu> Message-ID: <469430F5.9060401@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 11 Jul 2007 02:23:01 +0100
Syd Bauman wrote:
> Thanks, Sebastian!
>
>> I can't say it was a pleasure fixing this (a vile little excursion
>> into the byways), but fixed it should now be in Subversion
>
> I have to admit I'm a bit curious: was it any more than changing
> something like into
> soemthing like ? Or was the hard part finding
> the right spot?
I was going to say that I'd add it to the wiki for the list of things for us to
look at (Dot and I are both in Leeds atm), but it seems because it was a
procedural-based problem rather than a css/style-based problem Sebastian has
leapt in there and fixed it. (Many thanks!)
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 21:23:08 EDT
From James.Cummings at oucs.ox.ac.uk Tue Jul 10 21:28:20 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Jul 2007 02:28:20 +0100 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <46935A20.7020407@kcl.ac.uk> Message-ID: <46943234.5090602@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 11 Jul 2007 02:28:20 +0100
Arianna Ciula wrote:
> Sebastian Rahtz wrote:
>> Lou Burnard wrote:
>>>
>>> You should also ask for an alternative proposal.
>> Arianna made one, I think, which seemed sensible.
>
> This is what I had sent to the place list:
>
> - title: in a way I like the new title, but I agree with Sebastian that
> may be misleading so something like: 'People, places and organisations:
> data and time' may be more precise...don't know
>
>>
>> "Names, places, people and dates" would do me just fine :-}
>
> but the above sounds also fine.
I also disliked 'historical data'. The others are slightly unwieldy, but
certainly more accurate. What about: "Names, dates, people, and places" (just
diff order).
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 10 2007 - 21:28:27 EDT
From cwittern at gmail.com Wed Jul 11 07:46:40 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 11 Jul 2007 20:46:40 +0900 Subject: [tei-council] *Please reply*: infrastructure for telecon Message-ID: <5268d87d0707110446h3d39ec71qb79c9fbe7ab1faf7@mail.gmail.com>
From: Christian Wittern
Date: Wed, 11 Jul 2007 20:46:40 +0900
Dear Council members,
As I said in my mail two days ago, we need to decide urgently what
service to use for our next telecon. Concerns have been raised that
the problem Arianna and Conal had on the last conferences might be due
to a technical glitch at highspeedconferencing -- I am wondering if
we should switch back to the Indiana conferencing system? Opinions?
Other options?
Feedback appreciated,
Christian

-- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 07:46:44 EDT

From cwittern at gmail.com Wed Jul 11 07:48:01 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 11 Jul 2007 20:48:01 +0900 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <46943234.5090602@oucs.ox.ac.uk> Message-ID: <5268d87d0707110448q5108a878wa7cc757371dd8aba@mail.gmail.com>
From: Christian Wittern
Date: Wed, 11 Jul 2007 20:48:01 +0900
On 11/07/07, James Cummings ox.ac.uk> wrote:
>
> I also disliked 'historical data'. The others are slightly unwieldy, but
> certainly more accurate. What about: "Names, dates, people, and places" (just
> diff order).
>
This looks most appropriate to me, if slightly barock in length.
Christian

-- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 07:48:05 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Jul 11 08:17:02 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Jul 2007 13:17:02 +0100 Subject: [tei-council] namesdates == "Historical data" In-Reply-To: <5268d87d0707110448q5108a878wa7cc757371dd8aba@mail.gmail.com> Message-ID: <4694CA3E.1040909@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 11 Jul 2007 13:17:02 +0100
Christian Wittern wrote:
> On 11/07/07, James Cummings ox.ac.uk> wrote:
>
>>
>> I also disliked 'historical data'. The others are slightly unwieldy, but
>> certainly more accurate. What about: "Names, dates, people, and
>> places" (just
>> diff order).
>>
>
> This looks most appropriate to me, if slightly barock in length.
>
> Christian
>
>
I think the title is the thing that concerns me least about the current
state of this chapter. However, in the hope that this might lead to
people focussing on some of its other manifest shortcomings, I have now
renamed it as proposed above.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 08:17:10 EDT
From cwittern at gmail.com Wed Jul 11 08:18:35 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 11 Jul 2007 21:18:35 +0900 Subject: [tei-council] please see Language Identification update In-Reply-To: <18067.52244.672626.808858@emt.wwp.brown.edu> Message-ID: <5268d87d0707110518u7889007ayc50e1960f177783d@mail.gmail.com>
From: Christian Wittern
Date: Wed, 11 Jul 2007 21:18:35 +0900
Syd,
I had a brief look and think it looks fine as it is, modulo some of
the glitches reported by Arianna.
On 11/07/07, Syd Bauman edu> wrote:
> > I am not that competent in judging the content of this chapter, but
> > here are some notes on misspellings and similar: ...
>
> Whoo-hoo! Thanks, Arianna. I plan to go through the list in detail
> tomorrow, then ask Michael Beddow (the original author) and Deb
> Anderson (a linguist involved both with Unicode and TEI) to take a
> look at the corrected version.
While Michael did most of the chapter, I think it was me who drafted
the language part (which was tucked on later); all the more reason to
let him have a look at it!
All the best,

-- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 08:18:39 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 11 08:21:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 11 Jul 2007 13:21:58 +0100 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <5268d87d0707110446h3d39ec71qb79c9fbe7ab1faf7@mail.gmail.com> Message-ID: <4694CB66.9030508@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 11 Jul 2007 13:21:58 +0100
highspeedconferencing claim that the limit is 500 people.
there may well be issues, but they do not admit to any.
were you on Skype or landline, Conal and Arianna?
I have to sadly say that I have mismatched my diaries,
and will not be able to attend on Tuesday; I am in
a conference at York (which I had believed was the week
after ...).
I will be submitting reports on what I have done
by tomorrow evening.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 08:22:02 EDT
From dporter at uky.edu Wed Jul 11 08:42:15 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 11 Jul 2007 13:42:15 +0100 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <5268d87d0707110446h3d39ec71qb79c9fbe7ab1faf7@mail.gmail.com> Message-ID: <96f3df640707110542u2033d53dk92d1dd0834c84eff@mail.gmail.com>
From: Dot Porter
Date: Wed, 11 Jul 2007 13:42:15 +0100
I call in on a landline, as long as the call is toll free for me and
everyone is able to participate I have no preference as to service.
Dot
On 7/11/07, Christian Wittern com> wrote:
> Dear Council members,
>
> As I said in my mail two days ago, we need to decide urgently what
> service to use for our next telecon. Concerns have been raised that
> the problem Arianna and Conal had on the last conferences might be due
> to a technical glitch at highspeedconferencing -- I am wondering if
> we should switch back to the Indiana conferencing system? Opinions?
> Other options?
>
> Feedback appreciated,
>
> Christian
>
>
>
> --
> Christian Wittern, Kyoto
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 08:42:18 EDT

From arianna.ciula at kcl.ac.uk Wed Jul 11 09:12:48 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 11 Jul 2007 14:12:48 +0100 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <4694CB66.9030508@oucs.ox.ac.uk> Message-ID: <4694D750.5090700@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 11 Jul 2007 14:12:48 +0100
I was using skype and didn't have any problem before in previous
calls...so the issue may have been on my end.
Arianna
Sebastian Rahtz wrote:
> highspeedconferencing claim that the limit is 500 people.
> there may well be issues, but they do not admit to any.
>
> were you on Skype or landline, Conal and Arianna?
>
> I have to sadly say that I have mismatched my diaries,
> and will not be able to attend on Tuesday; I am in
> a conference at York (which I had believed was the week
> after ...).
>
> I will be submitting reports on what I have done
> by tomorrow evening.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 09:12:51 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Jul 11 09:48:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Jul 2007 14:48:28 +0100 Subject: [tei-council] ODD notes Message-ID: <4694DFAC.6010107@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 11 Jul 2007 14:48:28 +0100
Here's a brief list of some ODD issues raised by Sylvain Loiseau when I
met him in Paris last week.
1. Can an ODD document contain more than one element? The
schema permits this, but the current toolkit expects to produce only one
set of outputs. So either multiple schemaSpec elements should generate
an error or the current toolkit needs enhancing
2. Why is not a member of model.oddRef?
3. If ODD is meant to be fully general there ought to be some way of
specifying the base collection of modules which are to be combined by
reference from within a schemaSpec, defaulting to "tei". A @base
attribute on the schemaSpec might do this (not to be confused with
xml:base however)
4. When deleting (eg) an elementSpec, why is it necessary to specify the
module? this is redundant, surely.
5. Should the text of the TEI Guidelines not include a
somewhere, generating (presumably) tei_all?
6. We don't specify anywhere in what circumstances order is significant
for the declarations within a , nor that only the
declarations contained by one (either directly or via moduleRef,
specGrpRef etc) are used in the output schema. Should declarations not
so contained generate an error?
7. What is the rationale for declaring classes local to a module instead
of as part of the infrastructure module?
Sylvain, for those who don't know him, is (amongst other interesting
things) working on a project at LIMSI to convert the French wikipedia
into TEI XML markup
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 09:48:37 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 11 09:57:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 11 Jul 2007 14:57:22 +0100 Subject: [tei-council] Re: ODD notes In-Reply-To: <4694DFAC.6010107@computing-services.oxford.ac.uk> Message-ID: <4694E1C2.4080105@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 11 Jul 2007 14:57:22 +0100
Lou Burnard wrote:
>
> 1. Can an ODD document contain more than one element? The
> schema permits this, but the current toolkit expects to produce only
> one set of outputs. So either multiple schemaSpec elements should
> generate an error or the current toolkit needs enhancing
I will treat this as bug report for the XSL tools
>
> 3. If ODD is meant to be fully general there ought to be some way of
> specifying the base collection of modules which are to be combined by
> reference from within a schemaSpec, defaulting to "tei". A @base
> attribute on the schemaSpec might do this (not to be confused with
> xml:base however)
I agree. any objections?
>
> 4. When deleting (eg) an elementSpec, why is it necessary to specify
> the module? this is redundant, surely.
I will look at schema to see if we can trap this. probably @module and
@mode are alternates;
is that true, Syd?
>
> 5. Should the text of the TEI Guidelines not include a
> somewhere, generating (presumably) tei_all?
quite possibly. thats a big question, related to whether we should
generate modular schemas
>
> 6. We don't specify anywhere in what circumstances order is
> significant for the declarations within a , nor that only
> the declarations contained by one (either directly or via moduleRef,
> specGrpRef etc) are used in the output schema. Should declarations not
> so contained generate an error?
I will look at the schema to see if we can do this

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 09:57:27 EDT

From Syd_Bauman at Brown.edu Wed Jul 11 13:12:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Jul 2007 13:12:35 -0400 Subject: [tei-council] ODD notes In-Reply-To: <4694DFAC.6010107@computing-services.oxford.ac.uk> Message-ID: <18069.3971.536338.832183@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 11 Jul 2007 13:12:35 -0400
> 1. Can an ODD document contain more than one element?
> The schema permits this, but the current toolkit expects to produce
> only one set of outputs. So either multiple schemaSpec elements
> should generate an error or the current toolkit needs enhancing
I pointed this out to Sebastian a few years ago; he said that the
current toolkit was not about to be able to handle multiple
s, so we added the doucmentation into the --help message
of `roma` that says only the first is processed.
I think ODD should allow multiple s, but `roma` (and
Roma) should be more forceful about giving an "I'm sorry, I can't
do that" message than it is now. If no one else wants to do this, I
will try to get to it by the weekend.

> 3. If ODD is meant to be fully general there ought to be some way
> of specifying the base collection of modules which are to be
> combined by reference from within a schemaSpec, defaulting to
> "tei". A @base attribute on the schemaSpec might do this (not to be
> confused with xml:base however)
I dont' understand this at all. Can you explain with an example, maybe?

> 4. When deleting (eg) an elementSpec, why is it necessary to specify the
> module? this is redundant, surely.
Seems silly to me, too. (It would make sense if we could have a
in module 'bar' and a different in module 'blort', but we
can't, so it's redundant.)

> 5. Should the text of the TEI Guidelines not include a
> somewhere, generating (presumably) tei_all?
Errr ... it takes us away from our "*all* uses of TEI are
customizations" stand, but other than that sort of principled reason,
I don't know why not.

> 6. We don't specify anywhere in what circumstances order is significant
> for the declarations within a , nor that only the
> declarations contained by one (either directly or via moduleRef,
> specGrpRef etc) are used in the output schema. Should declarations not
> so contained generate an error?
I didn't think order was significant, at least not in one's
customization ODD. I also didn't realize any *Spec declarations were
valid outside of a . Are they?
I may not be thinking clearly ... may have a better perspective after
I eat; also will look at #7 then.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 13:12:41 EDT

From Syd_Bauman at Brown.edu Wed Jul 11 14:03:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Jul 2007 14:03:58 -0400 Subject: [tei-council] Re: ODD notes In-Reply-To: <4694E1C2.4080105@oucs.ox.ac.uk> Message-ID: <18069.7054.3029.301232@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 11 Jul 2007 14:03:58 -0400
> > 3. If ODD is meant to be fully general there ought to be some way of
> > specifying the base collection of modules ...
> I agree. any objections?
I don't understand it well enough to object, I'm afraid.

> > 4. When deleting (eg) an elementSpec, why is it necessary to
> > specify the module? this is redundant, surely.
> I will look at schema to see if we can trap this. probably @module
> and @mode are alternates; is that true, Syd?
Isn't module= needed when mode="add"?

> quite possibly. thats a big question, related to whether we should
> generate modular schemas
I don't grok the relationship.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 14:04:03 EDT

From daniel.odonnell at uleth.ca Wed Jul 11 14:06:47 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Jul 2007 12:06:47 -0600 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <5268d87d0707110446h3d39ec71qb79c9fbe7ab1faf7@mail.gmail.com> Message-ID: <1184177207.30295.3.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 11 Jul 2007 12:06:47 -0600
This was the first time I've had a problem with the
highspeedconferencing and I use it for a number of things.
But I'm happy with whatever the others decide: I suppose we can't afford
to have it go wrong again.
-dan
On Wed, 2007-07-11 at 20:46 +0900, Christian Wittern wrote:
> Dear Council members,
>
> As I said in my mail two days ago, we need to decide urgently what
> service to use for our next telecon. Concerns have been raised that
> the problem Arianna and Conal had on the last conferences might be due
> to a technical glitch at highspeedconferencing -- I am wondering if
> we should switch back to the Indiana conferencing system? Opinions?
> Other options?
>
> Feedback appreciated,
>
> Christian
>
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 14:07:08 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 11 14:17:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 11 Jul 2007 19:17:29 +0100 Subject: [tei-council] Re: ODD notes In-Reply-To: <18069.7054.3029.301232@emt.wwp.brown.edu> Message-ID: <46951EB9.3070009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 11 Jul 2007 19:17:29 +0100
Syd Bauman wrote:
>>> 3. If ODD is meant to be fully general there ought to be some way of
>>> specifying the base collection of modules ...
>>>
>> I agree. any objections?
>>
>
> I don't understand it well enough to object, I'm afraid.
>
the point is that says "go get
namedates from Somewhere, You Know Where." This is taken
to be "The TEI". What Sylvain is saying is that we have no
formal record of this, and that
would give some documentary context for the @key on moduleRef
>
>> I will look at schema to see if we can trap this. probably @module
>> and @mode are alternates; is that true, Syd?
>>
>
> Isn't module= needed when mode="add"?
>
no, because at the schemaSpec level there are no modules
any more.
>
>> quite possibly. thats a big question, related to whether we should
>> generate modular schemas
>>
>
> I don't grok the relationship.
>
I am thinking that if the default output of The TEI is "tei_all",
then the modular schema fragments become even more
redundant.
I think we can afford to leave this on hold for the moment;
its more important to freeze the *Spec, and thus freeze
instance documents.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 14:17:34 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 11 14:22:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 11 Jul 2007 19:22:44 +0100 Subject: [tei-council] ODD notes In-Reply-To: <18069.3971.536338.832183@emt.wwp.brown.edu> Message-ID: <46951FF4.5080509@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 11 Jul 2007 19:22:44 +0100
Syd Bauman wrote:
> I think ODD should allow multiple s, but `roma` (and
> Roma) should be more forceful about giving an "I'm sorry, I can't
> do that" message than it is now. If no one else wants to do this, I
> will try to get to it by the weekend.
>
I looked at this again just now, and I have to say that
making Roma and friends do multiple schemas would
be hard. The XSL makes a lot of use of xsl:key, which
looks over the whole file. The only short-term solution
would be a preprocessor to split a ODD into a
series of new self-contained files.
I agree, the message should be stronger.
>
> I didn't think order was significant, at least not in one's
> customization ODD.
it is, if you make macros and want a DTD. Macros
have to be declared in the right order. Also,
classes get turned into entities in DTD-land, so there
too the order can matter. SADLY!
> I also didn't realize any *Spec declarations were
> valid outside of a . Are they?
>
apart from inside a schemaSpec and in a
they should not be allowed. we need to look at the
schema to see how to control this better.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 11 2007 - 14:22:49 EDT
From conal.tuohy at vuw.ac.nz Wed Jul 11 17:21:09 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 12 Jul 2007 09:21:09 +1200 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <5268d87d0707110446h3d39ec71qb79c9fbe7ab1faf7@mail.gmail.com> Message-ID: <1184188869.3244.293.camel@localhost>
From: Conal Tuohy
Date: Thu, 12 Jul 2007 09:21:09 +1200
I was using Skype the last 2 times. The last call was OK for me ... but
the previous call I had problems. I could hear everyone but I don't
think anyone heard me ... at the end I managed to get a message via Dot
(using Google Talk) to the effect that I was there. At the time I
thought it might have been a Skype problem, but I was able to make a
Skype test call successfully, so if it relates to Skype it is perhaps an
issue with the interface between Skype and highspeedconferencing.com
I would vote to try again with highspeedconferencing.com, but perhaps
with a more formal roll-call at the start, so we can get a better handle
on the problem, if it still exists?
C
On Wed, 2007-07-11 at 20:46 +0900, Christian Wittern wrote:
> Dear Council members,
>
> As I said in my mail two days ago, we need to decide urgently what
> service to use for our next telecon. Concerns have been raised that
> the problem Arianna and Conal had on the last conferences might be due
> to a technical glitch at highspeedconferencing -- I am wondering if
> we should switch back to the Indiana conferencing system? Opinions?
> Other options?
>
> Feedback appreciated,
>
> Christian
>
>
>
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 17:29:12 EDT
From cwittern at gmail.com Wed Jul 11 18:49:27 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 12 Jul 2007 07:49:27 +0900 Subject: [tei-council] trac #332 In-Reply-To: <4693AAD1.5000603@computing-services.oxford.ac.uk> Message-ID: <5268d87d0707111549q69eb33e8w67b327047266876b@mail.gmail.com>
From: Christian Wittern
Date: Thu, 12 Jul 2007 07:49:27 +0900
On 11/07/07, Lou Burnard oxford.ac.uk> wrote:
> I believe I have now resolved this ticket, by adding witList to
> model.listLike, and adding model.listLike to the content for sourceDesc.
> I've also added prose to TC which explains when to use witness, msdesc,
> or bibl, all of which may legitimately be the target for a @wit
> attribute in a reading.
Great.
>
> Thinking about this, however, I find myself wondering why we have added
> listPerson, listOrg and listPlace to the class model.biblLike rather
> than to the class model.listLike, which would seem to make better sense
> semantically.
>
> Anyone object if I move them?
Please do so, I think that is where everybody would expect them to live.
Cheers,
Christian

-- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 18:49:32 EDT

From cwittern at gmail.com Wed Jul 11 21:08:27 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 12 Jul 2007 10:08:27 +0900 Subject: [tei-council] ODD notes In-Reply-To: <46951FF4.5080509@oucs.ox.ac.uk> Message-ID: <46957F0B.2060403@gmail.com>
From: Christian Wittern
Date: Thu, 12 Jul 2007 10:08:27 +0900
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> I think ODD should allow multiple s, but `roma` (and
>> Roma) should be more forceful about giving an "I'm sorry, I can't
>> do that" message than it is now. If no one else wants to do this, I
>> will try to get to it by the weekend.
>>
> I looked at this again just now, and I have to say that
> making Roma and friends do multiple schemas would
> be hard. The XSL makes a lot of use of xsl:key, which
> looks over the whole file. The only short-term solution
> would be a preprocessor to split a ODD into a
> series of new self-contained files.
What's the use case for multiple schemaSpecs anyway?
Wouldn't it be easier to simply disallow more than one?
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 11 2007 - 21:08:35 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 12 03:38:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jul 2007 08:38:56 +0100 Subject: [tei-council] ODD notes In-Reply-To: <46957F0B.2060403@gmail.com> Message-ID: <4695DA90.9010807@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 12 Jul 2007 08:38:56 +0100
Christian Wittern wrote:
> What's the use case for multiple schemaSpecs anyway? Wouldn't it be
> easier to simply disallow more than one?
>
it would be elegant to have all the TEI Exemplars specified in a single
ODD file, perhaps.
but for the current set of tools, the reengineering involved would be
too great
at this time.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 12 2007 - 03:39:01 EDT

From Syd_Bauman at Brown.edu Thu Jul 12 10:37:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Jul 2007 10:37:05 -0400 Subject: [tei-council] ODD notes In-Reply-To: <4695DA90.9010807@oucs.ox.ac.uk> Message-ID: <18070.15505.50608.880970@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 12 Jul 2007 10:37:05 -0400
> > What's the use case for multiple schemaSpecs anyway? Wouldn't it
> > be easier to simply disallow more than one?
If one were developing 2 or 3 similar TEI languages that had slightly
different schemas for whatever reason, it would be nice to develop
them in the same ODD.
Imagine, e.g., that we wanted to have a schema for capture that had a
few syntactic sugar shortcuts that we didn't want in our "real"
schema. But all the ohter customizations are the same. Might be nice
to create & document both of these in the same ODD.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 12 2007 - 10:37:17 EDT
From Syd_Bauman at Brown.edu Thu Jul 12 11:22:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Jul 2007 11:22:46 -0400 Subject: [tei-council] *Please reply*: infrastructure for telecon In-Reply-To: <1184188869.3244.293.camel@localhost> Message-ID: <18070.18246.380311.36038@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 12 Jul 2007 11:22:46 -0400
I typically use Skype, but have a landline next to me to switch to if
Skype gives me trouble. At this time I have no opinion on which
service we should use.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 12 2007 - 11:22:50 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 12 12:26:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Jul 2007 17:26:06 +0100 Subject: [tei-council] facsimile markup example In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABAB9C@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <4696561E.8080202@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 12 Jul 2007 17:26:06 +0100
Conal Tuohy wrote:
> I would be grateful in particular if council members could comment on the revised Comenius example here:
>
> http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/SA-LinkingSegmentationAlignment.xml
>
I apologise for taking so long to get round to looking at this (about a
month, by my reckoning).
Am I right in thinking that the only changes you've made in the text of
SA are (a) change Xpath to Xpointer at one point
(b) replace the SVG example by one using the (as yet undefined)
element?
Is there are a rather fuller description of the proposed element in
existence somewhere? (fuller than what's in the fax.odd file attached
to the TRAC ticket, that is)
Do you envisage as being in a module of its own, or in an existing
module? if so, which? (PH or FT would seem the logical place)
The supplied ODD defines large numbers of attributes repeatedly, which
would probably be better done as an attribute class.

Just to check that I have understood this properly, are

blah blah

and


blah blah

exactly equivalent ways of showing that page one looks like "foo.jpg"
and has textual content "blah blah"?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 12 2007 - 12:26:11 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 12 14:01:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jul 2007 19:01:33 +0100 Subject: [tei-council] report on what I have done, for council next week Message-ID: <46966C7D.8020501@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 12 Jul 2007 19:01:33 +0100
12 July. Report to TEI council by Sebastian Rahtz.
a) Roma.
Current trac tickets reporting errors have been
resolved. The next two tasks are:
1. merge in Ioan Bernevig's "jerusalem" variant which
provides sanity checking of an ODD
2. bearing in mind the new strictures of customization,
redesign Roma to put added elements in a new namespace
by default.
b) TEI XSL stylesheets for generating schemas and documentations.
Some items were cherry-picked from JC/DP's list of issues,
and a new design for HTML display of reference material
has been put into place. The next two tasks are:

1. implement any changes JC/DP request, if they involve
complex hacking of the XSL (JC and DP will work on
the CSS and obvious changes to XSL _ad lib_)
2. re-start work on PDF generation to provide a framework for
design work.
c) addition to the header.
This has been designed, and agreed with Martin Holmes, and
is awaiting agreement from Council; it also needs wrapping
prose in the HD chapter.
d) The Implementation section of the "using TEI" chapter.
The first draft of this is complete, but it will need
thorough reviewing. I am hoping that our French colleagues
can do a lot of feedback on this, notably the people at Nancy
who have supervised Ioan Bernevig, and Sylvain Loiseau.
e) P5 release.
I had planned a release last week, but at that point P5
was broken (in a small way, regarding , but technically
broke), so I have held off. Next weekend, maybe?
f) namesdates chapter.
I have spent a fair amount of time working with this
on real data, and have successfully used it for the
Lexicon Of Greek Personal Names (65000 records) and a
description of Oxford University (generating KML output).
I have also made a conversion of sample data from
the Barrington Atlas of the classical world, to assist
Tom Elliott. This has shown up some issues about certainty
and evidence which need to be resolved.
On the back of this, it seems necessary to add @resp and @cert
(ie att.editLike) to , and , and to make
@resp multi-valued. It would be good to have this confirmed.
If I have any spare time, I will attempt to convert
my Protestant Cemetery data to new canonical TEI format.
g) Internationalization translation of and .
This is proceeding. Japanese and Spanish are more or less
fully in place. Italian is half-complete, the rest awaited
daily. I am assured Chinese and German are done, but are not
yet with me (I'll believe them when I see them...). French
has been restarted by Jean-Luc Benoit after a hiatus caused
by the death of Pierre-Yves Duchesmin, and I am assured that
they will deliver.
When all the translations are in, a major task for
September is reconciliation and filling-in. All
the translations need to be checked in cases where
the English has changed (mercifully, not that many, I think);
and translations must be added for and
added since the text was issued to translators. I am confident
that generating the list of problems and tasks can
be automated OK, and I will keep fingers crossed that the
translators will come back and finish off.

h) I have entirely failed to look at the page facsimile things,
I am afraid
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 12 2007 - 14:01:49 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 12 15:49:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jul 2007 20:49:17 +0100 Subject: [tei-council] IM chapter Message-ID: <469685BD.1090103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 12 Jul 2007 20:49:17 +0100
the draft I referred to is now at
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/USE.html#IM
its very unlikely that I have covered all the details, or explained
everything
clearly, so feel free to comment on almost any part of it.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 12 2007 - 15:49:20 EDT
From Syd_Bauman at Brown.edu Thu Jul 12 16:11:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Jul 2007 16:11:38 -0400 (EDT) Subject: [tei-council] please see Language Identification update In-Reply-To: <4693B96C.5090802@kcl.ac.uk> Message-ID: <200707122011.l6CKBcqF013008@draco.services.brown.edu>
From: Syd Bauman
Date: Thu, 12 Jul 2007 16:11:38 -0400 (EDT)
> - first time you mention Unicode I would add a link to its website or a
> footnote with the link.
Sounds reasonable. I presume you mean the first time in the chapter,
rather than the first time in the Guidelines (it occurs in the
Introductory Note and in the gentle introduction, both of which are
before this "chapter"), or the first time in the language
identification section. Done.

> - as you suggest I would add links to IANA
OK, as no one else has expressed an opinion, it's in. Once we're
being explicit about where to get the language subtag, it seems to
make sense to say so for the other subtags as well. So I added
pointers to the ISO 15924 list, the ISO 3166 list, and the UN M.49
list also.

> (I had made the same comments for the ND chapter and now the links
> are there in the footnotes if you want to use the same reference)
I am not as convinced that this vague level of detail, as it were,
should be spelled out in ND as it is. I think the reference to
language identification probably should be the only reference there.
That paragraph needs some work in other ways; I may take a crack at
it later today.

> - word repetition --> 'We say that the single and double-storey symbols
> both represent one and the same the same abstract character a'
Check, fixed.

> - missing link or old reference --> '(see further 6.3 Highlighting and
> Quotation)'
Egads! This seemed like a problem worth investigating, so I checked
and found 7 other instances of this problem in the Guidelines and
fixed 'em. (3 of which were also in this chapter, which you had
noticed, below :-)
Lou -- two of these were references FS to FD, where it looked like
you probably made changes so that the FS.xml file would work to
generate the ISO text without having to do work in the XSLT.

> - misspelling --> 'Such documentation does cannot of itself guarantee
> proper display'
I didn't notice any misspelling, but it's not English. Sentence
reworded.

> - missing links --> ...
Fixed as mentioned above.

> - mis-punctuation --> 'Ligatures (.e.g. the joining [...]'
Fixed.

> - 'though for historians of typography their presence and form in a
> given edition' --> I would say 'though for palaeographers and
> historians of typography their presence and form in a given
> manuscript or edition'
OK, as no one has objected, done.

Thanks again, Arianna!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 12 2007 - 16:11:41 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 12 17:05:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jul 2007 22:05:14 +0100 Subject: [tei-council] Re: ODD notes In-Reply-To: <3150.82.123.163.192.1184269824.squirrel@keo.limsi.fr> Message-ID: <4696978A.9090804@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 12 Jul 2007 22:05:14 +0100
sloiseau_at_limsi.fr wrote:
> Why not a include/@href="..." (like in rng) or import (like in xsl) (or
> the mechanism systemId / publicId, but it is perhaps related to the DTD
> world).
>
you can always use XInclude if you want. The point of the key= mechanism
is that it does _not_ point to a URL, because the material may come
from a database query, or some local file, or anything; we don't
want to commit an ODD to the method used to locate the P5 source
> The problem with a namespace (as with @base = TEI) is perhaps that with
> "cascading odd", there is no way for a derived odd to express which
> intermediate ODD it relies upon.
>
true. I wish I thought cascading odds genuinely worked.
you _could_ use instead of @key, but thats
rather under-implemented. I'd have to do some work to make that
behave properly.
> An advantage Lou pointed out is that with a base reference, there is no
> need anymore for this strange , which is the only
> moduleRef which is:
> - mandatory
> - not including element, but other grammatical units (the attribute and
> element classes).
>
well, that would need some playing around with to get right. the "tei"
module
is genuine and must be read.
>
> I have a question related to this point: in case of cascading odds, does
> this mean that one can no longer refer to the initial modules?
>
hmm. I think so
> For instance, suppose a first odd refers to several modules (namesdate,
> linking, analysis), and a second odd, extending the first one, want to
> remove a module. Is this no more possible?
>
I'd have to experiment with this to see what I have actually
implemented. I may well
have got it wrong, and so broken cascades.
>
>> I am thinking that if the default output of The TEI is "tei_all",
>> then the modular schema fragments become even more
>> redundant.
>>
>
> I don't understand. What are modular schema?
>
>
part of the output of P5 is a set of DTD and RELAXNG modules, which
can be included in your own schema using native tools (such as RELAXNG's
)

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 12 2007 - 17:05:20 EDT

From cwittern at gmail.com Thu Jul 12 17:38:59 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 13 Jul 2007 06:38:59 +0900 Subject: [tei-council] service for telecon Message-ID: <46969F73.7040108@gmail.com>
From: Christian Wittern
Date: Fri, 13 Jul 2007 06:38:59 +0900
Dear Council members,
from the feedback I have seen on and off list, it seems that most feel it
worthwhile to stay with our current setup and see if the glitches are really
with the system provided by highspeedconferencing.
I usually make a roll-call and take notes of attendants, but after a few
minutes we tend to start the conference and what happens then might not have
my full attention. So if nobody reacts to your welcome message, you might
be hit by the "mysterious mike bug" and have to try to connect a second
time, maybe using a different type of service.
The details about how to connect will be as usual part of the agenda, which
I hope to have ready at this time tomorrow. (No promises, since I am
traveling and connectivity might vanish).
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 12 2007 - 17:39:20 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jul 13 07:03:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Jul 2007 12:03:55 +0100 Subject: [tei-council] FSD Message-ID: <46975C1B.3070809@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 13 Jul 2007 12:03:55 +0100
As I reported last time we discussed this, the ISO workgroup has now
produced and will shortly be voting on a completely new document, which
will be part 2 of the existing ISO 24610. This new document is
unfortunately maintained as a single LaTeX file, which makes it very
difficult to keep in step with the P5 ODD source.
It contains one section which corresponds more or less exactly with the
P5 chapter on FSD, and I have therefore manually collated the two,
making all revisions necessary in the latter to bring it in line with
the former. The ISO draft also adds a great deal of useful background
material at various places, ranging from detailed examples to formal
definitions for basic feature-structure concepts, which in another life
I would like to have integrated into the Guidelines as well, but this is
simply impossible within the current time frame. What I have done
therefore is added the following sentence to the TEI chapter:
"This chapter relies upon, but does not reproduce, formal definitions
and descriptions presented more thoroughly in the ISO standard, which
should be consulted in case of ambiguity or uncertainty."
Time permitting, I would still like to try to integrate FS and FD into a
single chapter, but I cannot realistically promise this for 1 August.
There are also still a few unresolved technical issues, which it would
be easier to address if the two chapters were integrated.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 13 2007 - 07:04:03 EDT
From lou.burnard at computing-services.oxford.ac.uk Fri Jul 13 09:25:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Jul 2007 14:25:13 +0100 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <200707050151.l651pLw3000592@draco.services.brown.edu> Message-ID: <46977D39.2000900@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 13 Jul 2007 14:25:13 +0100
Syd Bauman wrote:
> In Berlin the TEI Council requested the creation of a new element,
> , which would replace the special-purpose
> element. Was part of the point of this exercise to eliminate the
> special-purpose , , and as well, using (e.g.)
> or some such instead?

No, I don't think so. The specific elements are permitted as children of
as an alternation to text. As I remember the discussion, we
recognises that most institutions would always supply dimensions in
their own specific sequence, and might not want therefore to tag the
height etc. explicitly. Compare the element, which just knows that
you give lat and long in that order.
>
> In any case, the implementation as it now stands seems problematic.
> Most importantly, the element has been added to the class
> att.measured and removed from att.measurement, which means it has
> traded in its quantity= attribute for an extent= attribute. This
> seems just wrong. "Extent" has a connotation in English of distance
> or area, and is not as general in its meaning as "quantity", which
> conveys exactly what the semantics of the attribute are for the
> element.
I agree "extent" is a slightly strange name for this: how about @count?

>
> Secondly, the "suggested values include" list for unit= has lost
> all the suggested values that don't make sense when measuring a page.
> For the element, I don't see why TEI should not provide
> standard values for all sorts of possible units. There really is no
The international standard is referenced, and I've certainly no
objection to adding a few more examples taken from it

lement permits text content. Is there
> a reason for this? I'm not sure it makes sense, but may well be
> missing something.
See above
No other <*Grp> element permits mixed content
> except the dictionary element . (Although and
> do permit

.)
>
>
> Proposal
> --------
>
> * move back to att.measurement
>
Cant see anything to be gained by doing this, other than the confusion
of now having two classes with the same meaning

> * remove text from content of ? (if it seems important,
> put model.pLike in?)
>
Not a good idea in my view, for reasons given above

> * change , , and to a single element ,
> which bears a dir= or dim= attribute whose value may be one of
> "height", "width", and "depth". This new element could be empty
> (quantity always expressed on quantity=, extent=, or value=
> attribute) or could have content of text or macro.xtext. (I'd leave
> it to David and Matthew to decide on that.)
we already have an element called , meaning something subtly
different. What you;re proposing tho sounds just like to me!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 13 2007 - 09:25:18 EDT

From daniel.odonnell at uleth.ca Fri Jul 13 14:13:30 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Fri, 13 Jul 2007 12:13:30 -0600 Subject: [tei-council] Choice and App/rdg again Message-ID: <1184350410.21180.21.camel@odonned-eng06>
From: Dan O'Donnell
Date: Fri, 13 Jul 2007 12:13:30 -0600
Hi all,
Since we are thinking about content models, let me re-raise the issue
with choice and app/rdg: my view is that the current phrase-level model
is two restrictive.
Choice is an obvious one: simultaneity is a logical concept not a point
in a document hierarchy, there is no reason why one cannot have points
in texts in which one is to choose between alternative content or
sequences of marked up text at the level of the paragraph, division, or,
as I pointed out in the case of the Dictionary of the Khazars (which has
male and female versions), entire texts.
rdg within app is perhaps less obvious as we tend to think of readings
as lists of words in collations. But once again it is not difficult to
think of use cases in which units larger than the phrase might be
collated: we had an example on tei-l when somebody was asking about
additions or omissions of lines in two versions of a poem; different
versions of a text might have entire additional chapters (the Diary of
Anne Frank springs to mind), and authors can change, add, or suppress
paragraphs: a use case of the latter is Edward Van Houtte's SGML edition
of Teleurgang van het Waterhoek, which is collated by paragraph.
Traditionally apparatus have not handled units-larger than the phrase
very well. In Dobbie's 1942 edition of Caedmon's Hymn, the apparatus
prints an additional line found in two witnesses but doesn't indicate
that the distinction is that there is an additional metrical unit, not
simple some more words. In the critical edition of Het Achterhuis (the
Diary of Anne Frank), the do the collation as a quasi-parallel text:
when text is missing in one version or the other they put in dots; if it
has been moved they reproduce it twice once where it appears in the
particular witness and once in square brackets where it appears in the
base text.
The TEI apparatus model is much more flexible than its print
predecessor: in both Waterhoek and Achterhuis, the text could have been
encoded as a series of apparatus entries without a base text the way we
suggest in the guidelines... except that rdg can't contain

or


and hence neither Edward nor our mythical encoder of the Critical
Edition of the Diary of Anne Frank can't indicate that they are
collating paragraphs and/or diary entries.
I raised this earlier and discussion petered out. I'm pretty worried
about the current model however. I have seen quite a number of
discussions over the years that suggest to me that people run into
unreasonable limitations of the models very quickly.
-dan
-- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 13 2007 - 14:05:36 EDT
From Syd_Bauman at Brown.edu Fri Jul 13 21:44:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Jul 2007 21:44:41 -0400 Subject: [tei-council] Choice and App/rdg again In-Reply-To: <1184350410.21180.21.camel@odonned-eng06> Message-ID: <18072.10889.54745.241011@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 13 Jul 2007 21:44:41 -0400
Daniel --
> ... let me re-raise the issue with choice and app/rdg: my view is
> that the current phrase-level model is [too] restrictive.
OK, but let me point out that even if you convince us that
should contain paragraph-level or div-level chunks, this is *way* too
big a change to even be *considered* for P5 1.0.
But convincing me, at least, is going to be hard, not because of any
lack of truth in your argument that encodings of things larger than
phrases may occur in alternation -- I'm completely with you there.
But rather it is difficult because changing the content of
to allow things larger than a place where it itself can appear is
very problematic: all of a sudden you can have
s inside of
s so long as there's a between the two. Quite bizarre.
Perhaps not impossible to get around with sincere warnings and
Schematron, but no small matter either way.
But perhaps equally important, this may not be necessary. We already
have reasonable encoding methods for alternation. These include the
(and ) element(s):







And the exclude= attribute:

Holy alternation, Batman!


Holy fledermaus, Altman!
One could argue that

Dairy
Diary

is essentially the same as
Dairy
Diary
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 13 2007 - 21:44:46 EDT
From lou.burnard at computing-services.oxford.ac.uk Sat Jul 14 11:07:14 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 14 Jul 2007 16:07:14 +0100 Subject: [tei-council] Choice and App/rdg again In-Reply-To: <18072.10889.54745.241011@emt.wwp.brown.edu> Message-ID: <4698E6A2.5@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Sat, 14 Jul 2007 16:07:14 +0100
Just for the record, I am in 100% agreement with Syd on this!
is not meant to be used in the way Daniel suggests; is the
recommended method for dealing with such things.
Lou
Syd Bauman wrote:
> Daniel --
>
>
>> ... let me re-raise the issue with choice and app/rdg: my view is
>> that the current phrase-level model is [too] restrictive.
>>
>
> OK, but let me point out that even if you convince us that
> should contain paragraph-level or div-level chunks, this is *way* too
> big a change to even be *considered* for P5 1.0.
>
> But convincing me, at least, is going to be hard, not because of any
> lack of truth in your argument that encodings of things larger than
> phrases may occur in alternation -- I'm completely with you there.
>
> But rather it is difficult because changing the content of
> to allow things larger than a place where it itself can appear is
> very problematic: all of a sudden you can have
s inside of
> s so long as there's a between the two. Quite bizarre.
> Perhaps not impossible to get around with sincere warnings and
> Schematron, but no small matter either way.
>
> But perhaps equally important, this may not be necessary. We already
> have reasonable encoding methods for alternation. These include the
> (and ) element(s):
>
>

>


>


>

>


>


>
>
> And the exclude= attribute:
>
>
>

Holy alternation, Batman!


>

Holy fledermaus, Altman!


>
>
> One could argue that
>
> Dairy
> Diary
>
> is essentially the same as
> Dairy
> Diary
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jul 14 2007 - 11:07:21 EDT
From Syd_Bauman at Brown.edu Sat Jul 14 16:28:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 14 Jul 2007 16:28:29 -0400 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <4692C0BB.1030305@gmail.com> Message-ID: <18073.12781.823263.916452@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 14 Jul 2007 16:28:29 -0400
> The idea then was, as far as I remember, to put them in a separate
> module, which still seems appropriate to me.
OK, then.
1. I think I can still close this ticket, as it was not about what
module *-iso= attributes go in, but about what attributes go in
what classes.
2. If we want to yank the *-iso= attributes to their own module, what
should that module be called? Should it not still be declared in
the chapter on Names, Dates, People, and Places?
I propose

Attributes for ISO 8601 Format Dates
Attributes for normalized temporal information using ISO 8601 formats

In the ND-NamesDates.xml file.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jul 14 2007 - 16:28:34 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sat Jul 14 17:16:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Jul 2007 22:16:24 +0100 Subject: [tei–council] TRAC ticket 329 –– time to close? In-Reply-To: <18073.12781.823263.916452@emt.wwp.brown.edu> Message-ID: <46993D28.6010505@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 14 Jul 2007 22:16:24 +0100
Syd Bauman wrote:
> 2. If we want to yank the *-iso= attributes to their own module, what
> should that module be called? Should it not still be declared in
> the chapter on Names, Dates, People, and Places?
>
sounds reasonable
> I propose
>
>
> Attributes for ISO 8601 Format Dates
> Attributes for normalized temporal information using ISO 8601 formats
>
>
> In the ND-NamesDates.xml file.
>
sounds eminently reasonable.
do we still have hard-wired tables of modules anywhere?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jul 14 2007 - 17:16:28 EDT
From cwittern at gmail.com Sat Jul 14 19:53:43 2007 From: cwittern at gmail.com (Christian Wittern) Date: Sun, 15 Jul 2007 08:53:43 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC Message-ID: <46996207.8070300@gmail.com>
From: Christian Wittern
Date: Sun, 15 Jul 2007 08:53:43 +0900
DRAFT Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC
Expected to participate:
Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna
Ciula, James Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter,
Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
excused:
Sebastian Rahtz
============================================================
How to connect:
We will use the highspeedconferencing.com service again. Hope it works OK.
Participants can use their skype account (www.skype.com) or regular
phones to call. When calling via skype, *please use a headset*. If
in doubt, it might be better to call via regular phone. Numbers as follow:
>From Skype call +99008278525675
Here are the latest access numbers from the h'speed website as of 2007-07-14:
Country Code PLUS Cell Phone?
US 1 605-475-8500 Yes
UK 44 0870 738 0760 Yes
Germany 49 01805 00 76 46 Yes
France 33 0826 100 275 Yes
other places: call to US:-(
Enter Conference Room Number : 5326922
(this is Sebastian's Conference room)
============================================================
Please read through the following (including the linked pages) before
the meeting.
============================================================
1) Open action items
* We will look at the open action items from the last meeting
(http://www.tei-c.org/Council/tcm31.xml?style=printable) first.
* For the remaining, as far as I can see from the list at
http://lists.village.virginia.edu/pipermail/tei-council/2007/003098.html
section A) there is mainly
3) add/del/supplied issues (trac 301, 331, action 6) (for LB). not
started
which is not covered by the other list but should be covered.
[I have problems accessing parts of trac at the moment, so if I have
overlooked something please notify me]
2) Reports / review
* Layout of the Guidelines (JC/DP)

3) next meeting
Mid/End August?
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Jul 14 2007 - 19:54:03 EDT

From daniel.odonnell at uleth.ca Sun Jul 15 04:51:50 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Jul 2007 02:51:50 -0600 Subject: [tei-council] Choice and App/rdg again In-Reply-To: <4698E6A2.5@computing-services.oxford.ac.uk> Message-ID: <1184489511.14986.29.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 15 Jul 2007 02:51:50 -0600
So if I understand things aright, what we're saying is that we have two
kinds of apparatus and two kinds of ways of indicating alternate
encodings: one for phrases, and one for units larger than the phrase.
In the case of textual apparatus, this seems bizarre. If Anne Frank
deletes a word from one draft to the next or deletes an entire diary
entry, I fail to see how these are different from a point of view of
collation. They are both textual variants. The question is whether or
not we can capture the extra information that we know--i.e. that a
missing material is actually an entire entry or just a word. Likewise
with C??dmon's Hymn: when Dobbie doesn't indicate that the extra "words"
he includes in his apparatus are actually a metrical line, he is hiding
information he knows. I don't see why we would willingly continue this.
The fact remains that for some texts--including real use cases--the unit
of collation is larger than the phrase. This is a fact of textual
criticism.
As for choice, Syd raises an interesting question: why have choice at
all if
> One could argue that
> >
> > Dairy
> > Diary
> >
> > is essentially the same as
> > Dairy
> > Diary
If @exclude was renamed @alternate or @choice or something, and doing
this removed the problem of limiting choice only to the level of the
phrase, then I'd say get rid of it and make @alternate|@choice global.
My point is that the idea of simultaneity is not hierarchical--it is a
logical distinction. Even if we stick to the most restrictive
understanding of choice--that it involves encoding only and not content
(something I'd argue is a mistake)--it is simply not true that there is
anything inherently phrasal about the logical connection between the
options choice contains. Thus logically, given our definition of choice
as "groups a number of alternative encodings for the same point in a
text" both of the following encodings ought to be correct:

Text Encoding Initiative
TEI



The text encoding initiative is an organisation devoted to the
development and maintenance of standards for the encoding of texts. It
is built on a consortium model, with four hosts and an elected board and
council




The text encoding initiative is an organisation devoted to the
development and maintenance of standards for the encoding of texts.


It is built on a consortium model, with four hosts and an elected
board and council
In fact, only the first is.
Since I had to add the divs in the second example purely to distinguish
between the options, this may point to a deeper problem. Maybe what is
really going on here is that we have a couple of standard cases in which
we understand what the options are (abbr|expan, sic|corr, etc.) and a
more generic model where what is going on is something like
choice/option/otherStuff|option/otherStuff.
Me, I'm agnostic about whether the alterneity/simultaneity is
represented by element or attribute--attribute is cleaner, given the
issues of divs within segs Syd raises, perhaps--but I don't see any
evidence arguing that the actual idea of choice is hierarchical. A quick
and dirty element solution is to have phraseChoice, chunkChoice,
etc.--not my solution, but evidence that it ain't insurmountable.
I think choice is one of the most interesting additions to P5--I'd
really like to get the idea right.
-dan

On Sat, 2007-07-14 at 16:07 +0100, Lou's Laptop wrote:
> Just for the record, I am in 100% agreement with Syd on this!
> is not meant to be used in the way Daniel suggests; is the
> recommended method for dealing with such things.
>
> Lou
>
> Syd Bauman wrote:
> > Daniel --
> >
> >
> >> ... let me re-raise the issue with choice and app/rdg: my view is
> >> that the current phrase-level model is [too] restrictive.
> >>
> >
> > OK, but let me point out that even if you convince us that
> > should contain paragraph-level or div-level chunks, this is *way* too
> > big a change to even be *considered* for P5 1.0.
> >
> > But convincing me, at least, is going to be hard, not because of any
> > lack of truth in your argument that encodings of things larger than
> > phrases may occur in alternation -- I'm completely with you there.
> >
> > But rather it is difficult because changing the content of
> > to allow things larger than a place where it itself can appear is
> > very problematic: all of a sudden you can have

s inside of
> > s so long as there's a between the two. Quite bizarre.
> > Perhaps not impossible to get around with sincere warnings and
> > Schematron, but no small matter either way.
> >
> > But perhaps equally important, this may not be necessary. We already
> > have reasonable encoding methods for alternation. These include the
> > (and ) element(s):
> >
> >

> >


> >


> >

> >


> >


> >
> >
> > And the exclude= attribute:
> >
> >
> >

Holy alternation, Batman!


> >

Holy fledermaus, Altman!


> >
> >
> > One could argue that
> >
> > Dairy
> > Diary
> >
> > is essentially the same as
> > Dairy
> > Diary
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jul 15 2007 - 04:52:27 EDT
From daniel.odonnell at uleth.ca Sun Jul 15 15:17:57 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Jul 2007 13:17:57 -0600 Subject: [tei-council] More on choice and app / rdg Message-ID: <1184527077.7833.50.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 15 Jul 2007 13:17:57 -0600
I've been thinking all morning about the choice/rdg issue and think I
may see both what the problem is and a solution.
First of all, for choice, I think the problem is that our description
represents one view of choice (a view that agrees with my view, in fact)
as a generic indicator of simultaneity, while the content model
represents a different model--basically of something that we might call
"Janus Tag Container" (which makes sense, of course, because that's how
it came about).
I agree with Syd now that changing the model to match the description is
too big a job for P5. Since the same thing can be handled more or less
using @exclude (although I'd prefer @alternate or @choice as the name),
and expanding choice would involve the issues of divs in segs and such
not, I'm not sure that a post P5 change would be good, since it would be
quite a major change and I think we should be aiming at long term
stability.
So given that, perhaps what we need to do is change the description to
match the content model and perhaps modify the content model very
slightly. Rather than "groups a number of alternative encodings for the
same point in a text" I think we should change the description to
something like "groups original and editorial states of text where these
can be seen as alternates" (not perfect, but the point is to indicate
that choice is specifically associated with TC elements, not alternate
encodings of any kind). And given that this is really an "editorial
choice" tag rather, I wonder if we shouldn't look into including all or
most of the elements in ??3.4. I.e. currently model.choicePart contains
, , , , , , and . It
seems to me it should also contain (since that is also an
editorial intervention that can have a corresponding "original" state)
and probably , , and . So in other words,
everything in model.pPart.edit except (which is odd there anyway,
since unlike all other members of this class, it doesn't describe a text
or an editorial intervention, but collects lists of readings).
If we do this, BTW, it also partially solves what seemed to me to be
Syd's worrying point that choice/option1|option2 is the same as
option1_at_exclude="option2" vs. option2_at_exclude="option1": given that why
create the choice element at all. I think the answer is that it exists
because it is marking a discrete structure in an electronic text:
*editorial/transcriptional* alternation rather than simple alterity.
So a reversal of my earlier position.
This does return us to app and rdg though. Here I think two things.
First of all, that the rdg content model simply is inadequate and does
not represent obvious and common use cases. Textual variation commonly
involves addition, omission, or variation in the order of chunk-level
elements and rdg must be able to accommodate that. So its content model
should have at least model.divPart. But as the Anne Frank example
suggests, variants can be even bigger than that: you can add/omit/alter
entire sections of texts: diary entries, chapters, front and back matter
elements. Especially if you are using the Parallel Segmentation method,
it is important to be able to capture these as well, so I'd say you
might even want to include front, body, and back or at least
model.divLike.
The second thing is the location of app in
pPartEditorial/pPartTranscriptional. I don't see why it is included in
phrase level elements like this. It seems pretty clearly different from
the other members of pPartTranscriptional in that

all say something about the text, whereas app simply lists examples of
text. Also, apparatus traditionally stand on their own on the page,
making them chunk- or inter-like in my book. It seems to me app belongs
in model.listLike alongside list and listBibl.
My final point involves our claim that app is a specialised form of
choice. I've always held this to be true, and, if it has a lem, I
suppose you could maintain that it still fits the proposal I make above
for describing choice as really being a container for grouping editorial
interventions with the original form. But if we do go with the more
specialised definition of choice, I'd argue that app actually isn't a
specialised form of choice after all, since there is no editorial
intervention in a text encoding using the parallel segmentation method
without a base text. If we restrict choice to "editorial/transcriptional
alternates," then I think I reluctantly have to conclude that app isn't
a form of choice, but just a type of list.
-dan
>
>

>

The text encoding initiative is an organisation devoted to the
> development and maintenance of standards for the encoding of texts. It
> is built on a consortium model, with four hosts and an elected board
> and
> council


>

>

>

The text encoding initiative is an organisation devoted to the
> development and maintenance of standards for the encoding of
> texts.


>

It is built on a consortium model, with four hosts and an elected
> board and council


>

>
Should be

-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jul 15 2007 - 15:18:35 EDT

From lou.burnard at computing-services.oxford.ac.uk Sun Jul 15 19:58:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 16 Jul 2007 00:58:06 +0100 Subject: [tei-council] facsimile odd Message-ID: <469AB48E.2030304@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 16 Jul 2007 00:58:06 +0100
Unless I've grossly misunderstood it, Conal's proposal may be summarized
as follows:
a) we define a new element , a member of model.sourceDescPart
b) we define a new attribute class, att.projection and make a
member of it, along with a small number of other existing "container"
elements like

, , and . Dot also proposes an attribute @coords.
c) we define a new element , a member of model.graphicLike
d) is used as a wrapper for one or more s, each
representing a page image; it can also contain s which define
particular zones within the page.
e) can point into text transcript by means of special attribute
@start (indicates a ); s point to elements in the transcript
using @corresp
And here, probably revealing the grossness of my understanding, are some
comments on each of the above points:
a) I don't think this element belongs in sourceDesc. If contains
the images constituting a digital facsimile, then it isn't metadata
about that facsimile, it *is* the facsimile. I might want to record in
the sourceDesc other things (e.g. where I nicked the images from) which
wouldn't form part of the facsimile proper.
b) the class seems to combine two different kinds of attribute: ones
like @top and @right which define where something else is within a
graphic; and ones like @xscale and @rotate which define how a graphic is
to be rendered in a given context. I really don't understand how these
attributes are intended to be used though.
c) doesn't make much sense except with reference to a ;
it can't therefore be a member of model.graphicLike, since this would
allow it to stand in place of a
d) seems rather restrictive (not to say unpronounceable) as a name:
could I use it, for example, to wrap images of Sebastian's gravestones?
Is the only difference between a and an that one corresponds
with a conventional visual unit -- the page -- and the other with any
arbitrary subsection of it? suppose each of my images shows a 2-page
spread: would each one be a with each page image being an ?
e) why two different attributes for pointing into the text? How do I
point from text into image?
I haven't got very far trying to answer these questions, but as far as I
have I'd like to suggest that
(1) we should be thinking of defining a different element to contain a
collection of digital images, which would be analogous to the existing
element: let's call it for the moment. A can appear
where a (but not a ) can in the TEI model.
(2) It contains one or more elements defining a two dimensional
space which is represented in the facsimile
(3) a contains one or more elements, each of which
gives a visual representation of the zone in question, using differing
scales, rotations etc.
(4) a may also optionally contain other s, each of which
contains a visual representation of some subset of the parent zone,
again possibly using different scales or rotations.
(5) alignment of image and text is done throughout using existing TEI
mechanisms -- i.e. we use @corresp to point from one to the other, or we
use a standoff alignment map.
Please tell me if this is far too simplistic an approach -- it doesn't
seem to me a million miles away from the proposal we have though.
Lou

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 15 2007 - 20:03:51 EDT

From Syd_Bauman at Brown.edu Sun Jul 15 22:32:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Jul 2007 22:32:29 -0400 Subject: [tei-council] proposals available Message-ID: <18074.55485.385352.218382@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 15 Jul 2007 22:32:29 -0400
The two separate proposals for the new element are now
available in http://www.tei-c.org/Drafts/said/ (or will be as soon as
the server syncs). The two proposals are in files called
said-asis
said-q-hi
and each has .odd source and derived .doc.html, .rnc, and .rng files.
The two proposals are very similar. The only difference is how the
element is defined. In the latter ("said-q-hi") proposal, the
Guidelines are explicit that can be used for any of the various
underlying reasons that gets represented with quotation marks. I
prefer this proposal, in part because I think lots of people already
use this way.
Here is a quick executive summary:
is for direct speech (or its discursive equivalents: e.g.
reported thought or speech, dialog, etc.), whether real or
contrived, typically as part of the current text, although I
suppose one could imagine otherwise. Most common usage is
likely to be a character's spoken words in a novel or a
person's spoken words reported in a non-fiction article. In
English prose it will very often be associated with phrases
like "he said", or "she asked". is not a viable child
of .
is for material that is quoted from sources outside the text,
whether correctly or not, whether real or contrived, whether
originally spoken or written. Most common usage is likely to
be quoting passages from other documents. May be used in a
dictionary for real or contrived examples of usage.
is still a viable child of .
--------- said-asis: ---------
is for passages quoted from elsewhere; in narrative, either
direct or indirect speech or something being quoted from outside
the text; in dictionaries, real or contrived examples of usage.
is still a viable child of , for those who don't use the
more specific .
--------- said-q-hi: ---------
is for any of a number of features when differentiating among
them is not desired, e.g. because it is economically not feasible
or simply not of interest for the current purpose. Items that may
be encoded this way include
- representation of speech or thought
- quotation
- technical terms and glosses
- passages mentioned, not used
- authorial distance
and perhaps even
- from a foreign language
- linguistically distinct
- emphasized
- any other use of quotation marks in the source

Some tangentially related items I noticed:
* I think the example with should be re-worked
so that the who= attributes are pointing to s, but as I
don't speak French (that is French, right? -- there should really
be an xml:lang= on the , no?) I am not a good choice to do
that work.
* In the last example of the section, the word "language" is encoded
as a , but I don't think that's right. I'm not very
confident about what *is* right, but I'd prefer to
. (I suppose we could ask the co-author of the source
for the example, Terry Langendoen, who chaired the committee on
text analysis and interpretation back in the early 1990s :-)

Some unrelated changes I've made in the ODD:
* lowercase 'm' -> uppercase 'M' in description of em dash
* "the quotation is marked up as part of a concurrent but independent
hierarchy" changed to "the quotation is marked up using stand-off
markup", as we don't do concurrent hierarchies any more
* "the quotation boundaries are represented by empty milestone tags"
to "the quotation boundaries are represented by empty segment
boundary delimiter elements", as they're *not* milestones!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 15 2007 - 22:32:34 EDT

From Syd_Bauman at Brown.edu Sun Jul 15 22:40:15 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Jul 2007 22:40:15 -0400 Subject: [tei-council] proposals available In-Reply-To: <18074.55485.385352.218382@emt.wwp.brown.edu> Message-ID: <18074.55951.270592.295159@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 15 Jul 2007 22:40:15 -0400
Forgot to mention --
There is a hole in the definition of 's aloud= attribute: what
is coded as aloud="true" really should include speech that is
expressed in sign language, also. At the moment I'm inclined to just
change the wording of the attribute description so that sign language
is included, but perhaps the entire attribute has to be rethought.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 15 2007 - 22:40:19 EDT
From cwittern at gmail.com Mon Jul 16 01:22:10 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 16 Jul 2007 14:22:10 +0900 Subject: [tei-council] proposals available In-Reply-To: <18074.55485.385352.218382@emt.wwp.brown.edu> Message-ID: <469B0082.4050403@gmail.com>
From: Christian Wittern
Date: Mon, 16 Jul 2007 14:22:10 +0900
Syd Bauman wrote:
> The two separate proposals for the new element are now
> available in http://www.tei-c.org/Drafts/said/ (or will be as soon as
> the server syncs). The two proposals are in files called
> said-asis
> said-q-hi
> and each has .odd source and derived .doc.html, .rnc, and .rng files.
>
> The two proposals are very similar. The only difference is how the
> element is defined. In the latter ("said-q-hi") proposal, the
> Guidelines are explicit that can be used for any of the various
> underlying reasons that gets represented with quotation marks. I
> prefer this proposal, in part because I think lots of people already
> use this way.
>
I think this is the crucial point in the whole proposal. Not clearing
up the muddy semantics of all three elements (said, q and quote) while
introducing a new one would be a mistake, I think, especially in light
of the frequency this is debated on TEI-L.
So I will go with the new proposal which modifies .
One question that will need to be considered is which of these will go
into TEI Lite? Is it only ? And will now also allow ?
Was there anything about in the proposal? If yes, I missed it.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 16 2007 - 01:22:31 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 16 04:47:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 16 Jul 2007 09:47:06 +0100 Subject: [tei-council] proposals available In-Reply-To: <18074.55485.385352.218382@emt.wwp.brown.edu> Message-ID: <469B308A.1000501@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 16 Jul 2007 09:47:06 +0100
I'm still only mildly enthusiastic about the introduction of ,
which seems to me a step too far in the interpretive direction, but
realise I'm probably in a minority. If the majority view prevails, then
I much prefer the "said-q-hi" implementation of it to the other one.
Assuming that this proposal carries, I think the chapter should include
some examples (presented as alternatives) using , to reinforce the
point that this is analogous to .
Do we still want the list of entity names now that we don't really
support character entities? In effect, these are now just suggested
values for @rend, and mostly rather obscure ones at that.
The example from Terry Langendoen's book was chosen by Michael as a
little gesture of appreciation to TL, so Michael is probably the person
to ask about how it should be tagged! FWIW, though, I don't think
is right: "language" isn't being defined in this example, it's being
talked about. Hence the use of .

Syd Bauman wrote:
> The two separate proposals for the new element are now
> available in http://www.tei-c.org/Drafts/said/ (or will be as soon as
> the server syncs). The two proposals are in files called
> said-asis
> said-q-hi
> and each has .odd source and derived .doc.html, .rnc, and .rng files.
>
> The two proposals are very similar. The only difference is how the
> element is defined. In the latter ("said-q-hi") proposal, the
> Guidelines are explicit that can be used for any of the various
> underlying reasons that gets represented with quotation marks. I
> prefer this proposal, in part because I think lots of people already
> use this way.
>
> Here is a quick executive summary:
>
> is for direct speech (or its discursive equivalents: e.g.
> reported thought or speech, dialog, etc.), whether real or
> contrived, typically as part of the current text, although I
> suppose one could imagine otherwise. Most common usage is
> likely to be a character's spoken words in a novel or a
> person's spoken words reported in a non-fiction article. In
> English prose it will very often be associated with phrases
> like "he said", or "she asked". is not a viable child
> of .
>
> is for material that is quoted from sources outside the text,
> whether correctly or not, whether real or contrived, whether
> originally spoken or written. Most common usage is likely to
> be quoting passages from other documents. May be used in a
> dictionary for real or contrived examples of usage.
> is still a viable child of .
>
> --------- said-asis: ---------
> is for passages quoted from elsewhere; in narrative, either
> direct or indirect speech or something being quoted from outside
> the text; in dictionaries, real or contrived examples of usage.
> is still a viable child of , for those who don't use the
> more specific .
>
> --------- said-q-hi: ---------
> is for any of a number of features when differentiating among
> them is not desired, e.g. because it is economically not feasible
> or simply not of interest for the current purpose. Items that may
> be encoded this way include
> - representation of speech or thought
> - quotation
> - technical terms and glosses
> - passages mentioned, not used
> - authorial distance
> and perhaps even
> - from a foreign language
> - linguistically distinct
> - emphasized
> - any other use of quotation marks in the source
>
>
> Some tangentially related items I noticed:
>
> * I think the example with should be re-worked
> so that the who= attributes are pointing to s, but as I
> don't speak French (that is French, right? -- there should really
> be an xml:lang= on the , no?) I am not a good choice to do
> that work.
>
> * In the last example of the section, the word "language" is encoded
> as a , but I don't think that's right. I'm not very
> confident about what *is* right, but I'd prefer to
> . (I suppose we could ask the co-author of the source
> for the example, Terry Langendoen, who chaired the committee on
> text analysis and interpretation back in the early 1990s :-)
>
>
> Some unrelated changes I've made in the ODD:
>
> * lowercase 'm' -> uppercase 'M' in description of em dash
>
> * "the quotation is marked up as part of a concurrent but independent
> hierarchy" changed to "the quotation is marked up using stand-off
> markup", as we don't do concurrent hierarchies any more
>
> * "the quotation boundaries are represented by empty milestone tags"
> to "the quotation boundaries are represented by empty segment
> boundary delimiter elements", as they're *not* milestones!
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 04:52:54 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 16 05:00:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 16 Jul 2007 10:00:06 +0100 Subject: [tei-council] proposals available In-Reply-To: <469B0082.4050403@gmail.com> Message-ID: <469B3396.6040809@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 16 Jul 2007 10:00:06 +0100
Christian Wittern wrote:
>
> I think this is the crucial point in the whole proposal. Not clearing
> up the muddy semantics of all three elements (said, q and quote) while
> introducing a new one would be a mistake, I think, especially in light
> of the frequency this is debated on TEI-L.
I am afraid that this is an inherently muddy topic...
> So I will go with the new proposal which modifies .
I assume by this you are expressing the same preference as I am?
> One question that will need to be considered is which of these will go
> into TEI Lite? Is it only ? And will now also allow ?
>
TEI Lite currently has both and , and this has silenced
several critics of it, so I am reluctant to change it. should also
allow , however.
> Was there anything about in the proposal? If yes, I missed it.
>
No. Should there be?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 05:05:54 EDT

From laurent.romary at loria.fr Mon Jul 16 05:08:30 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 16 Jul 2007 11:08:30 +0200 Subject: [tei-council] proposals available In-Reply-To: <469B3396.6040809@computing-services.oxford.ac.uk> Message-ID:
From: Laurent Romary
Date: Mon, 16 Jul 2007 11:08:30 +0200
Dear all,
I would also support to keep in whatever happens for the
rest of the proposal. I feel a bit like Lou on the issue of ,
i.e. not highly enthousiastic...
Best,
Laurent
Le 16 juil. 07 ? 11:00, Lou Burnard a ?crit :
> Christian Wittern wrote:
>>
>> I think this is the crucial point in the whole proposal. Not
>> clearing up the muddy semantics of all three elements (said, q and
>> quote) while introducing a new one would be a mistake, I think,
>> especially in light of the frequency this is debated on TEI-L.
>
> I am afraid that this is an inherently muddy topic...
>> So I will go with the new proposal which modifies .
>
> I assume by this you are expressing the same preference as I am?
>
>> One question that will need to be considered is which of these
>> will go into TEI Lite? Is it only ? And will now also
>> allow ?
>>
> TEI Lite currently has both and , and this has silenced
> several critics of it, so I am reluctant to change it. should
> also allow , however.
>
>> Was there anything about in the proposal? If yes, I missed it.
>>
> No. Should there be?
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 05:10:11 EDT
From cwittern at gmail.com Mon Jul 16 06:07:36 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 16 Jul 2007 19:07:36 +0900 Subject: [tei-council] proposals available In-Reply-To: <469B3396.6040809@computing-services.oxford.ac.uk> Message-ID: <469B4368.50300@gmail.com>
From: Christian Wittern
Date: Mon, 16 Jul 2007 19:07:36 +0900
Lou Burnard wrote:
> Christian Wittern wrote:
>
>> So I will go with the new proposal which modifies .
>
> I assume by this you are expressing the same preference as I am?
Yes, indeed.
>
>> One question that will need to be considered is which of these will
>> go into TEI Lite? Is it only ? And will now also allow ?
>>
> TEI Lite currently has both and , and this has silenced
> several critics of it, so I am reluctant to change it. should
> also allow , however.
>
That is fine then, at least with me.
>> Was there anything about in the proposal? If yes, I missed it.
>>
> No. Should there be?
>
>
No, it just escaped me until a few moments ago why this was called
"said-q-hi".
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 16 2007 - 06:07:56 EDT

From James.Cummings at oucs.ox.ac.uk Mon Jul 16 06:42:40 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 16 Jul 2007 11:42:40 +0100 Subject: [tei-council] proposals available In-Reply-To: <18074.55485.385352.218382@emt.wwp.brown.edu> Message-ID: <469B4BA0.5020503@oucs.ox.ac.uk>
From: James Cummings
Date: Mon, 16 Jul 2007 11:42:40 +0100
Syd Bauman wrote:
> The two proposals are very similar. The only difference is how the
> element is defined. In the latter ("said-q-hi") proposal, the
> Guidelines are explicit that can be used for any of the various
> underlying reasons that gets represented with quotation marks. I
> prefer this proposal, in part because I think lots of people already
> use this way.
I would agree, and prefer the said-q-hi implementation. In my mind 'hi' is
a super element indicating all sorts of highlighting, 'q' is a more
specific version indicating things-in-quotation-marks, and then I guess
such things as mentioned, soCalled, term, etc. But for some reason
foreign, distinct, emph are more hiLike in my mind than qLike. Perhaps
this comes from them usually not being indicated by quotation marks? Not sure.
In any case I think said-q-hi is better than leaving q how it was.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 16 2007 - 06:42:45 EDT
From Syd_Bauman at Brown.edu Mon Jul 16 12:32:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Jul 2007 12:32:21 -0400 Subject: [tei-council] proposals available In-Reply-To: <469B3396.6040809@computing-services.oxford.ac.uk> Message-ID: <18075.40341.50718.660415@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 16 Jul 2007 12:32:21 -0400
CW> One question that will need to be considered is which of these
CW> will go into TEI Lite? Is it only ?
My gut instinct is that TEI Tite should have only , and that Lite
should either have all three (, , and ), or only .

LB> TEI Lite currently has both and , and this has
LB> silenced several critics of it, so I am reluctant to change it.
Good point. I wonder if critics would be happy with just in the
new system where explicitly has the expanded semantics? I bet
some would.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 12:32:26 EDT

From Syd_Bauman at Brown.edu Mon Jul 16 12:54:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Jul 2007 12:54:40 -0400 Subject: [tei-council] proposals available In-Reply-To: <469B308A.1000501@computing-services.oxford.ac.uk> Message-ID: <18075.41680.994914.124576@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 16 Jul 2007 12:54:40 -0400
> Assuming that this proposal carries, I think the chapter should
> include some examples (presented as alternatives) using , to
> reinforce the point that this is analogous to .
I think that's a good idea.

> Do we still want the list of entity names now that we don't really
> support character entities? In effect, these are now just suggested
> values for @rend, and mostly rather obscure ones at that.
Really good question. I think the first bit of that whole paragraph
(which is an awfully long paragraph that should probably be broken
up) could be replaced by a single sentence that boils down to
"indicate the quotation marks used in the rend= attribute; you can
type in the right charaacters, or used numeric character references,
or (if you don't mind having a DOCTYPE declaration) use named entity
references".
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 12:54:44 EDT

From James.Cummings at oucs.ox.ac.uk Mon Jul 16 18:45:14 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 16 Jul 2007 23:45:14 +0100 Subject: [tei-council] Guidelines Formatting Status Update Message-ID: <469BF4FA.8050804@oucs.ox.ac.uk>
From: James Cummings
Date: Mon, 16 Jul 2007 23:45:14 +0100
Christian Wittern writes:
> I wonder if you could give us an update on the status of the layout work for
> the Guidelines? Work done so far, work expected, schedule and main issues
> would be what I would like to see covered.

Work done so far:
- So far the work has been almost entirely on Sebastian's part. He has solved
many of the straightforward bugs, and some more complicated new additions (such
as being able to toggle between RNG/RNC in schema fragments). See
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/
- We solicited and added suggestions for changes to the guidelines the TEI wiki
and have been thinking about some of the other issues. See
http://www.tei-c.org.uk/wiki/index.php/GuidelinesFormattingSuggestions
Work expected:
- We will address all the concerns expressed in the wiki page, either finding a
solution or reporting to council that we're unable to solve the problem for
whatever reason
- If additional items occur to council members they can add them to the wiki
- We will also be adding and then dealing with a number of more minor issues as
they arise
- We will where possible provide necessary CSS to solve these issues back to
Sebastian to double-check, and in the case we can't get it working at very
minimum least explain what we'd like to do and why it isn't working for us
- The end product should be an XHTML version of the Guidelines with more
consistent and up-to-date formatting
- Once the XHTML guidelines are in a decent format, we'll make recommendations
for how some of these issues should be dealt with in the PDF output of the
guidelines
Schedule:
3 Aug: Report back to Council on progress so far and any outstanding issues
7 Sep: All issues should be resolved and/or reported to Sebastian and/or Council
Dot and I are having an online meeting later this week to kick things off again.
Main Issues:
- One of the issues which vexes us is how much we should worry about structural
issues involved with the overall website navigation. We believe that the
presentation of the Guidelines (although essentially an independent output of
the TEI) needs to be integrated with the look of the website. As a result any
changes we make to such elements of the website (marked as 'website issue' on
the wiki) will be in keeping with the current website and hopefully able to be
migrated without too many problems to a new updated TEI-C website.
- Some of the changes may require a tiny bit of javascript (hopefully that will
degrade sensibly in non-javascript-enabled browsers), and although we may be
able to get this working ourselves we will report back if we aren't able to.

-James and Dot
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 16 2007 - 18:45:19 EDT

From djbpitt+tei at pitt.edu Mon Jul 16 21:09:37 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 16 Jul 2007 21:09:37 -0400 Subject: [tei-council] tei stemma model Message-ID: <469C16D1.8010001@pitt.edu>
From: David J Birnbaum
Date: Mon, 16 Jul 2007 21:09:37 -0400
Dear Council,
At our last conference call, Council charged Matthew and me with coming
up with a proposal for modeling stemmata codicum (a specific type of
acyclic directed graph) within a TEI framework. In anticipation of
tomorrow's conference call, a proposal along those lines is now
available at:
http://clover.slavic.pitt.edu/~djb/private/article.html
This is a temporary URL, but it will be valid at least through the call.
I am still working on developing the XSLT needed to convert directly
from the descriptive model proposed in this article to SVG (an indirect
approach is already incorporated in the report), but that won't be ready
in time for tomorrow's call. Otherwise the report is more or less
complete, and, I hope, ready for discussion by Council.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 21:09:44 EDT
From daniel.odonnell at uleth.ca Mon Jul 16 21:40:13 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 16 Jul 2007 19:40:13 -0600 Subject: [tei-council] Title Page credits Message-ID: <1184636413.9644.1.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 16 Jul 2007 19:40:13 -0600
Hi all,
Here are the credits as approved by the board subject to minor
correction (typos, etc.):

> That intellectual responsibility for the P5 Guidelines be attributed
> as
> >>> follows:
> >>>
> >>> 1. Title Page
> >>>
> >>> TEI P5: Guidelines for text encoding and interchange.
> >>>
> >>> By the TEI Consortium
> >>>
> >>> 5th Edition
> >>>
> >>> Originally edited by C M Sperberg McQueen and Lou Burnard for the
> >>> ACH-ALLC-ACL TExt Encoding Initiative.
> >>>
> >>> Now entirely revised and expanded under the supervision of the
> >>> Technical
> >>> Council of the TEI Consortium, edited by Lou Burnard and Syd
> Bauman.
> >>>
> >>> 2. "Second Title Page" or Equivalent
> >>>
> >>> P1: 1990, CMSMcQ & LB
> >>> P2: 1992, CMSMcQ & LB
> >>> P3: 1994, CMSMcQ & LB
> >>> P4: 2000, LB, SB, & SdR
> >>> P5: 2007, LB & SB
> >>>
> >>> 3. Acknowledgments
> >>>
> >>> Names of Council Chairs, Council Members, working group
> memberships,
> >>> etc.
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 16 2007 - 21:40:18 EDT

From Syd_Bauman at Brown.edu Mon Jul 16 22:44:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Jul 2007 22:44:29 -0400 Subject: [tei-council] report on my actions Message-ID: <18076.11533.783816.997450@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 16 Jul 2007 22:44:29 -0400
To help speed up tomorrow's call, here's a status report on the
actions assigned to me from last call, the minutes or which are at
http://www.tei-c.org/Council/tcm31.xml?style=printable:
* Regularize glosses on *specs passim.
Done.
* Review current wording in light of Council's recommendation.
I've checked in a toned down version of the passage for Lou to
review, but since I didn't tell him I was going to do so, he may
not have the chance to look at it before the call.
* Change q to quote in MS.
Done.
* Finish 3066 to 4646 update.
Done. (It turned out really to be more of an RFC 3066 to BCP 47
update, btw.)
* create second said proposal for q and said, post both.
Done.
* move postscript to a free standing ODD.
NOT done. Depending what else gets piled on my plate this
conference call, I hope to have this done within a week.
* remove wording of description of resp in prose PH.1.2 & PH.1.3.
I believe this action was to remove the word "confidence" from the
description of the resp= attribute, which has been done.
* Discuss merging of Corpus chapter in DS, and if necessary come up
with concrete proposals for implementation (or not).
I'm sorry to report that, not only wasn't this action completed,
until I read the minutes just now, I had no recollection that it
existed, let alone that I was supposed to be involved with it.
* Editors to integrate final Dictionary revisions into Guidelines.
Well, Lou certainly did a lot of work two weeks ago or so on
integrating DI revisions. I can't take any credit, but nor can I
report on its completeness.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 16 2007 - 22:44:35 EDT
From cwittern at gmail.com Tue Jul 17 04:01:01 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 17 Jul 2007 17:01:01 +0900 Subject: [tei-council] REVISED Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC Message-ID: <469C773D.2080009@gmail.com>
From: Christian Wittern
Date: Tue, 17 Jul 2007 17:01:01 +0900
Dear Council members,
please find below the revised agenda for the telecon later today. In light
of the proposals that have been circulated since I issued the draft agenda,
I added a new agenda item for reviewing them.
Looking forward to talk to you later,
Christian

REVISED Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC
Expected to participate:
Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna
Ciula, James Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter,
Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
excused:
Sebastian Rahtz
============================================================
How to connect:
We will use the highspeedconferencing.com service again. Hope it works OK.
Participants can use their skype account (www.skype.com) or regular
phones to call. When calling via skype, *please use a headset*. If
in doubt, it might be better to call via regular phone. Numbers as follow:
>From Skype call +99008278525675
Here are the latest access numbers from the h'speed website as of 2007-07-14:
Country Code PLUS Cell Phone?
US 1 605-475-8500 Yes
UK 44 0870 738 0760 Yes
Germany 49 01805 00 76 46 Yes
France 33 0826 100 275 Yes
other places: call to US:-(
Enter Conference Room Number : 5326922
(this is Sebastian's Conference room)
============================================================
Please read through the following (including the linked pages) before
the meeting.
============================================================
1) Open action items
* We will look at the open action items from the last meeting
(http://www.tei-c.org/Council/tcm31.xml?style=printable) first.
* For the remaining, as far as I can see from the list at
http://lists.village.virginia.edu/pipermail/tei-council/2007/003098.html
section A) there is mainly
3) add/del/supplied issues (trac 301, 331, action 6) (for LB). not
started
which is not covered by the other list but should be covered.
[I have problems accessing parts of trac at the moment, so if I have
overlooked something please notify me]
2) Reports
* Layout of the Guidelines (JC/DP
http://lists.village.virginia.edu/pipermail/tei-council/2007/003315.html)
3) Review
* content model of rdg (DD,
http://lists.village.virginia.edu/pipermail/tei-council/2007/003303.html)
* said proposal (SB, http://www.tei-c.org/Drafts/said/ and
http://lists.village.virginia.edu/pipermail/tei-council/2007/003305.html)
* stemma model (DB,
http://clover.slavic.pitt.edu/~djb/private/article.html)
4) next meeting
Mid/End August?
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 04:01:11 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 17 04:09:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Jul 2007 09:09:46 +0100 Subject: [tei-council] REVISED Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC In-Reply-To: <469C773D.2080009@gmail.com> Message-ID: <469C794A.1010909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 17 Jul 2007 09:09:46 +0100
can you discuss the proposal, please? I'd
like to get closure on that if possible.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 04:09:50 EDT

From Conal.Tuohy at vuw.ac.nz Tue Jul 17 07:18:50 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 17 Jul 2007 23:18:50 +1200 Subject: [tei-council] facsimile markup example In-Reply-To: <4696561E.8080202@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB1@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Tue, 17 Jul 2007 23:18:50 +1200
Conal Tuohy wrote:
> I would be grateful in particular if council members could comment on the revised Comenius example here:
>
> http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/SA-LinkingSegmentationAlignment.xml
>
Thanks Lou!
Lou wrote:
> Am I right in thinking that the only changes you've made in the text of
> SA are (a) change Xpath to Xpointer at one point
> (b) replace the SVG example by one using the (as yet undefined)
> element?
You are correct. The changes I made from the original were:
* the svg:svg is replaced with a tei:pg (the physical page),
* each svg:view is replaced with a tei:area (a rectangular region of the page),
* the svg:image is replaced with a tei:graphic (an image of the page)
* the svg:rect elements are ignored (I'd argue they should be the responsibility of presentational stylesheets rather than in the base encoding),
* the markup of the English and Latin text has not changed,
* neither has the linkGrp which aligns the English and Latin text and the areas of the image.

> Is there are a rather fuller description of the proposed element in
> existence somewhere? (fuller than what's in the fax.odd file attached
> to the TRAC ticket, that is)
I have a version of it with more text. At present it's not in a state that's acceptable to Roma, but I'm working on it. I'm sorry about that ... I will post something shortly though.
> Do you envisage as being in a module of its own, or in an existing
> module? if so, which? (PH or FT would seem the logical place)
I envisaged it as an entirely separate module, though it clearly depends on FT (for graphics). I think it is a separate concern entirely from encoding figures and so on, and there'd often be situations where tei:graphic was needed without the facsimile markup.
> Just to check that I have understood this properly, are

blah blah

and


blah blah

> exactly equivalent ways of showing that page one looks like "foo.jpg"
> and has textual content "blah blah"?
Not really, the pb element is still empty (I think! unless Dot changed that :-) and is merely linked to the element by reference. The pg element contains only graphics and areas, not text. The bits of text are linked to the area elements by reference. It is a kind of (graphical) stand-off markup, with respect to the text.
Con

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 07:19:14 EDT

From Conal.Tuohy at vuw.ac.nz Tue Jul 17 07:56:08 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 17 Jul 2007 23:56:08 +1200 Subject: [tei-council] facsimile odd In-Reply-To: <469AB48E.2030304@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB2@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Tue, 17 Jul 2007 23:56:08 +1200
Lou Burnard wrote:
> Unless I've grossly misunderstood it, Conal's proposal may be summarized
> as follows:
>
> a) we define a new element , a member of model.sourceDescPart
> b) we define a new attribute class, att.projection and make a
> member of it, along with a small number of other existing "container"
> elements like

, , and . Dot also proposes an attribute @coords.
That's correct.
The element represents a physical page.
The att.projection attributes define the location of something in terms of a coordinate space.
In the case of tei:area, the att.projection attributes would define a rectangular area on a page, which would be represented by a tei:pg element. Typically the tei:pg would be the parent element of the tei:area, but because tei:pb can be linked to tei:pg, even elements within the body of the text have an applicable tei:pg (namely the tei:pg which is linked to the tei:pb which precedes the element).
Pretty much every other element usable within tei:text COULD be a member of att.projection, if the encoder needed to assign it a location on the page. In the sample ODD, we've merely added tei:p, tei:ab and tei:seg. Again, the coordinates of these elements are to be interpreted as locations on the page represented by the tei:pg which applies to the page break preceding those elements.
> c) we define a new element , a member of model.graphicLike
> d) is used as a wrapper for one or more s, each
> representing a page image; it can also contain s which define
> particular zones within the page.
> e) can point into text transcript by means of special attribute
> @start (indicates a ); s point to elements in the transcript
> using @corresp
All true.
>
> And here, probably revealing the grossness of my understanding, are some
> comments on each of the above points:
>
> a) I don't think this element belongs in sourceDesc. If contains
> the images constituting a digital facsimile, then it isn't metadata
> about that facsimile, it *is* the facsimile. I might want to record in
> the sourceDesc other things (e.g. where I nicked the images from) which
> wouldn't form part of the facsimile proper.
I'd be open to this ... could it go in a new teiHeader child: facsimileDesc?
But to my mind, the tei:pg elements ARE descriptions of the source material. I could be misinterpreting this though, I admit.
> b) the class seems to combine two different kinds of attribute: ones
> like @top and @right which define where something else is within a
> graphic; and ones like @xscale and @rotate which define how a graphic is
> to be rendered in a given context. I really don't understand how these
> attributes are intended to be used though.
You are right that this is perhaps overly complicated. The idea was to allow textual elements to be identified as being e.g. oriented vertically or diagonally on the page, etc.
But a simplification would be to distribute the attributes differently between the 2 attribute classes like so:
att.projection should define scale factors and rotation. The members of this class should be the model.graphicLike elements which are children of the tei:pg elements. The projection attributes would define the mapping between the physical page and the various tei:graphic images of that page.
att.coordinates would define the location of textual elements (or tei:area elements, which are the stand-off proxies of textual elements) within a page.
> c) doesn't make much sense except with reference to a ;
> it can't therefore be a member of model.graphicLike, since this would
> allow it to stand in place of a
I would say that an which was the child of a

, for instance, would make sense with reference to the images of the page, which are just the s which are children of the which points to the which precedes the

e.g. schematically:



...

...


A square picture of something

> d) seems rather restrictive (not to say unpronounceable) as a name:
> could I use it, for example, to wrap images of Sebastian's gravestones?
I agree. But yes, it should cover gravestones as well.
> Is the only difference between a and an that one corresponds
> with a conventional visual unit -- the page -- and the other with any
> arbitrary subsection of it? suppose each of my images shows a 2-page
> spread: would each one be a with each page image being an ?
No, you'd have 2 elements, each containing the same tei:graphic/@url value, but the graphics would have different graphical offsets with respect to the which enclosed them. The right-hand page would have a big negative @left offset to indicate that a vertical line down the centre of the graphic corresponded to the left edge of the page.
> e) why two different attributes for pointing into the text? How do I
> point from text into image?d
You can either assign coordinates to fragments of text, or link them to area elements.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 07:56:48 EDT
From Conal.Tuohy at vuw.ac.nz Tue Jul 17 07:57:43 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 17 Jul 2007 23:57:43 +1200 Subject: [tei-council] facsimile odd In-Reply-To: <469AB48E.2030304@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB3@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Tue, 17 Jul 2007 23:57:43 +1200
Lou wrote:
> (5) alignment of image and text is done throughout using existing TEI
> mechanisms -- i.e. we use @corresp to point from one to the other, or we
> use a standoff alignment map.
I think the problem with that is that people (also) desperately want to assign coordinates directly to textual elements such as p.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 07:59:24 EDT
From cwittern at gmail.com Tue Jul 17 07:59:13 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 17 Jul 2007 20:59:13 +0900 Subject: [tei-council] REVISED Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC In-Reply-To: <469C794A.1010909@oucs.ox.ac.uk> Message-ID: <469CAF11.4040707@gmail.com>
From: Christian Wittern
Date: Tue, 17 Jul 2007 20:59:13 +0900
Sebastian Rahtz wrote:
> can you discuss the proposal, please? I'd
> like to get closure on that if possible.
>
>
Yes, sorry, I must have missed that, we will put that on under item 3 as
well.
You will have no chance to defend it though?
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 07:59:53 EDT

From dporter at uky.edu Tue Jul 17 08:06:50 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:06:50 -0400 Subject: [tei-council] facsimile odd In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB3@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <96f3df640707170506o5cb61a4ao10b49076e039b06c@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:06:50 -0400
On 7/17/07, Conal Tuohy ac.nz> wrote:
> Lou wrote:
>
> > (5) alignment of image and text is done throughout using existing TEI
> > mechanisms -- i.e. we use @corresp to point from one to the other, or we
> > use a standoff alignment map.
>
> I think the problem with that is that people (also) desperately want to assign coordinates directly to textual elements such as p.
>
Yes - and to scribal elements such as abbr, add, and to other
descriptive elements such as damage and unclear.
Dot
> Con
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:06:54 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 17 08:07:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Jul 2007 13:07:23 +0100 Subject: [tei-council] REVISED Agenda for the TEI Council teleconference on July 17, 2007 at 1200 UTC In-Reply-To: <469CAF11.4040707@gmail.com> Message-ID: <469CB0FB.7020007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 17 Jul 2007 13:07:23 +0100
Christian Wittern wrote:
>
>> can you discuss the proposal, please? I'd
>> like to get closure on that if possible.
>>
>>
>>
> Yes, sorry, I must have missed that, we will put that on under item 3 as
> well.
> You will have no chance to defend it though?
>
I am looking for agreement that I can deviate
slightly from what was agreed in Berlin..... ie not
have to 100% open model for appInfo

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:07:29 EDT

From dporter at uky.edu Tue Jul 17 08:20:25 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:20:25 -0400 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <96f3df640706210922x318bdca0k5d0105c57967151c@mail.gmail.com> Message-ID: <96f3df640707170520q23b0e1fkc848af7fe1fe1aa4@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:20:25 -0400
---------- Forwarded message ----------
From: Dot Porter edu>
Date: Jun 21, 2007 12:22 PM
Subject: Facsimile meeting, 6/20
To: Syd Bauman edu>, Martin Holmes
ca>, Conal Tuohy com>

Hi Syd, Martin, Conal,
Here are the notes from yesterday's meeting between me, Syd and
Martin. We took a look at the facsimile odd and came up with several
recommended modifications:
1) The header element is very specific to a codex structure. We
discussed changing this element to something more general such as
or even (which leaves the door open to
other media besides image files). This element would contain a pointer
to class milestoneLike, so one could point not only to but to
other milestones as well ( for example). Presumably once the
physical bibliography work is incorporated into the TEI this kind of
functionality would be directly available there as well.
2) We also discussed making a @sourceMedia or @sourceImage attribute
available to milestoneLike elements (not only ) in the text. This
could allow for two-way linking (so we could link from the text into
the header), but would also serve the same purpose as @URL - to link
to external files.
3) In the ODD file with my modifications (though I'm not sure for
Conal's file that I modified), is nested within along with
. There is no clear relationship between the and
elements except that they are within the same . We
recommend removing from and instead allowing several
tags which could point to the same image, but with different
coordinate values attached. So if I want to store coordinates for
every line on a manuscript page, I have a separate for each
line, each with different coordinates attached:







We didn't discuss how this might work when mapping betwen different image files.
(Martin and Syd, I didn't take very good notes of this discussion so
please chime in if I've misrepresented our discussion.)
Thanks,
Dot
-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:20:31 EDT

From dporter at uky.edu Tue Jul 17 08:20:44 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:20:44 -0400 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <467AB0EC.2020505@uvic.ca> Message-ID: <96f3df640707170520u2459ff59p4c87abc415299e3f@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:20:44 -0400
---------- Forwarded message ----------
From: Martin Holmes ca>
Date: Jun 21, 2007 1:10 PM
Subject: Re: Facsimile meeting, 6/20
To: Dot Porter edu>
Cc: Syd Bauman edu>, Conal Tuohy com>

Hi all,
This is really clear -- thanks indeed. On reflection, I like the idea of
mapping FROM the element TO the document element (
etc.) best, because it would allow multiple images/media to be
associated with the same document element. So you might have this in the
header:






with this in the text:

o that the same page element can be associated with different
resolutions of graphic. Also, you could then have this:



and in the text:

where the column can be associated with a segment of the page image.
This seems to me to give us complete flexibility in associating any part
of any image with any element on the page, and letting the rendering
process determine the best image to use for a particular context based
on all the options available. We also discussed putting an optional
mimeType attribute on sourceMedia, so that if you want to make it clear
that the file is (say) a QuickTime movie, you can do so.
I think it's important that this be a generally applicable system (any
appropriate element in the text, any type of media file) rather than
specific (images and codex pages) because lots of real-life projects are
not constrained to pages (e.g. the Graves diary, which has enclosures of
postcards, bullfight tickets, telegrams etc.).
Cheers,
Martin
Dot Porter wrote:
> Hi Syd, Martin, Conal,
>
> Here are the notes from yesterday's meeting between me, Syd and
> Martin. We took a look at the facsimile odd and came up with several
> recommended modifications:
>
> 1) The header element is very specific to a codex structure. We
> discussed changing this element to something more general such as
> or even (which leaves the door open to
> other media besides image files). This element would contain a pointer
> to class milestoneLike, so one could point not only to but to
> other milestones as well ( for example). Presumably once the
> physical bibliography work is incorporated into the TEI this kind of
> functionality would be directly available there as well.
> 2) We also discussed making a @sourceMedia or @sourceImage attribute
> available to milestoneLike elements (not only ) in the text. This
> could allow for two-way linking (so we could link from the text into
> the header), but would also serve the same purpose as @URL - to link
> to external files.
> 3) In the ODD file with my modifications (though I'm not sure for
> Conal's file that I modified), is nested within along with
> . There is no clear relationship between the and
> elements except that they are within the same . We
> recommend removing from and instead allowing several
> tags which could point to the same image, but with different
> coordinate values attached. So if I want to store coordinates for
> every line on a manuscript page, I have a separate for each
> line, each with different coordinates attached:
>
>
>
>
>
> coords="11,121,3,14"/>
>
> coords="15,352,388,124"/>
>
> coords="11,26,33,74"/>
>
>
> We didn't discuss how this might work when mapping betwen different
> image files.
>
> (Martin and Syd, I didn't take very good notes of this discussion so
> please chime in if I've misrepresented our discussion.)
>
> Thanks,
> Dot
>
-- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes_at_uvic.ca) Half-Baked Software, Inc. (mholmes_at_halfbakedsoftware.com) martin_at_mholmes.com -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:21:02 EDT

From dporter at uky.edu Tue Jul 17 08:21:12 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:21:12 -0400 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <4ec2900f0706212321l70c42be3od518a8b29b43edd3@mail.gmail.com> Message-ID: <96f3df640707170521n4793d7b8oe1a4eeed44f7ae40@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:21:12 -0400
---------- Forwarded message ----------
From: Conal Tuohy com>
Date: Jun 22, 2007 2:21 AM
Subject: Re: Facsimile meeting, 6/20
To: mholmes_at_uvic.ca
Cc: Dot Porter edu>, Syd Bauman edu>

Hi Martin
Following up on this discussion a bit late ... sorry for that.
I think your suggestions are based on based on a misunderstanding of
the intended role of the (page) element in the draft schema:
It is emphatically NOT a representation of an image file (for which
the tei:graphic should be used).
Neither is intended to be used as a unit of analysis (i.e. to say -
here is a region on the page). The element is intended to be
used for that. So in your example below, the area on the page occupied
by column 1 would be represented by an element within the
appropriate page.
I think if you consider the pg element in that light, and the
element as your unit of graphical analysis, then you can see that you
can associate arbitrary areas on a page with arbitrary bits of text.
When you come to present a graphical view of a piece of text, you can
pick from any of the graphic elements which are in the same pg as the
area, so long as those graphic elements have bounding boxes which
overlap the area's bounding box (i.e. so long as the area of the
coverage of the graphic overlaps with the area of coverage of the
).
Does that make sense?
Cheers
Con
On 22/06/07, Martin Holmes ca> wrote:
> Hi all,
>
> This is really clear -- thanks indeed. On reflection, I like the idea of
> mapping FROM the element TO the document element (
> etc.) best, because it would allow multiple images/media to be
> associated with the same document element. So you might have this in the
> header:
>
>
>
>
>
>
>
>
>
> with this in the text:
>
>
>
> so that the same page element can be associated with different
> resolutions of graphic. Also, you could then have this:
>
>
>
>
>
> and in the text:
>
>
>
> where the column can be associated with a segment of the page image.
> This seems to me to give us complete flexibility in associating any part
> of any image with any element on the page, and letting the rendering
> process determine the best image to use for a particular context based
> on all the options available. We also discussed putting an optional
> mimeType attribute on sourceMedia, so that if you want to make it clear
> that the file is (say) a QuickTime movie, you can do so.
>
> I think it's important that this be a generally applicable system (any
> appropriate element in the text, any type of media file) rather than
> specific (images and codex pages) because lots of real-life projects are
> not constrained to pages (e.g. the Graves diary, which has enclosures of
> postcards, bullfight tickets, telegrams etc.).
>
> Cheers,
> Martin
>
> Dot Porter wrote:
> > Hi Syd, Martin, Conal,
> >
> > Here are the notes from yesterday's meeting between me, Syd and
> > Martin. We took a look at the facsimile odd and came up with several
> > recommended modifications:
> >
> > 1) The header element is very specific to a codex structure. We
> > discussed changing this element to something more general such as
> > or even (which leaves the door open to
> > other media besides image files). This element would contain a pointer
> > to class milestoneLike, so one could point not only to but to
> > other milestones as well ( for example). Presumably once the
> > physical bibliography work is incorporated into the TEI this kind of
> > functionality would be directly available there as well.
> > 2) We also discussed making a @sourceMedia or @sourceImage attribute
> > available to milestoneLike elements (not only ) in the text. This
> > could allow for two-way linking (so we could link from the text into
> > the header), but would also serve the same purpose as @URL - to link
> > to external files.
> > 3) In the ODD file with my modifications (though I'm not sure for
> > Conal's file that I modified), is nested within along with
> > . There is no clear relationship between the and
> > elements except that they are within the same . We
> > recommend removing from and instead allowing several
> > tags which could point to the same image, but with different
> > coordinate values attached. So if I want to store coordinates for
> > every line on a manuscript page, I have a separate for each
> > line, each with different coordinates attached:
> >
> >
> >
> >
> >
> > coords="11,121,3,14"/>
> >
> > coords="15,352,388,124"/>
> >
> > coords="11,26,33,74"/>
> >
> >
> > We didn't discuss how this might work when mapping betwen different
> > image files.
> >
> > (Martin and Syd, I didn't take very good notes of this discussion so
> > please chime in if I've misrepresented our discussion.)
> >
> > Thanks,
> > Dot
> >
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes_at_uvic.ca)
> Half-Baked Software, Inc.
> (mholmes_at_halfbakedsoftware.com)
> martin_at_mholmes.com
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:21:57 EDT

From dporter at uky.edu Tue Jul 17 08:21:29 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:21:29 -0400 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <467BB479.4090409@uvic.ca> Message-ID: <96f3df640707170521r9823485m50d7fd996dbbd5a@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:21:29 -0400
Last message.
---------- Forwarded message ----------
From: Martin Holmes ca>
Date: Jun 22, 2007 7:37 AM
Subject: Re: Facsimile meeting, 6/20
To: Conal Tuohy com>
Cc: Dot Porter edu>, Syd Bauman edu>

Hi Conal,
I think our proposal does generalize yours a lot, but it still includes
everything you need, as far as I can see; you can associate any set of
coordinates on any image with any block of markup or milestone. Is that
not the case?
I think this might be easier to evaluate if we had a description of some
data which we could mark up under the two systems, to make sure that we
are fulfilling the needs of pg, as well as allowing more varied usage.
I'm pretty sure we were able to cover what's in Dot's example document;
do you have any others we could have a go at?
Cheers,
Martin
Conal Tuohy wrote:
> Hi Martin
>
> Following up on this discussion a bit late ... sorry for that.
>
> I think your suggestions are based on based on a misunderstanding of
> the intended role of the (page) element in the draft schema:
>
> It is emphatically NOT a representation of an image file (for which
> the tei:graphic should be used).
>
> Neither is intended to be used as a unit of analysis (i.e. to say -
> here is a region on the page). The element is intended to be
> used for that. So in your example below, the area on the page occupied
> by column 1 would be represented by an element within the
> appropriate page.
>
> I think if you consider the pg element in that light, and the
> element as your unit of graphical analysis, then you can see that you
> can associate arbitrary areas on a page with arbitrary bits of text.
> When you come to present a graphical view of a piece of text, you can
> pick from any of the graphic elements which are in the same pg as the
> area, so long as those graphic elements have bounding boxes which
> overlap the area's bounding box (i.e. so long as the area of the
> coverage of the graphic overlaps with the area of coverage of the
> ).
>
> Does that make sense?
>
> Cheers
>
> Con
>
> On 22/06/07, Martin Holmes ca> wrote:
>> Hi all,
>>
>> This is really clear -- thanks indeed. On reflection, I like the idea of
>> mapping FROM the element TO the document element (
>> etc.) best, because it would allow multiple images/media to be
>> associated with the same document element. So you might have this in the
>> header:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> with this in the text:
>>
>>
>>
>> so that the same page element can be associated with different
>> resolutions of graphic. Also, you could then have this:
>>
>>
>> >> 500" />
>>
>>
>> and in the text:
>>
>>
>>
>> where the column can be associated with a segment of the page image.
>> This seems to me to give us complete flexibility in associating any part
>> of any image with any element on the page, and letting the rendering
>> process determine the best image to use for a particular context based
>> on all the options available. We also discussed putting an optional
>> mimeType attribute on sourceMedia, so that if you want to make it clear
>> that the file is (say) a QuickTime movie, you can do so.
>>
>> I think it's important that this be a generally applicable system (any
>> appropriate element in the text, any type of media file) rather than
>> specific (images and codex pages) because lots of real-life projects are
>> not constrained to pages (e.g. the Graves diary, which has enclosures of
>> postcards, bullfight tickets, telegrams etc.).
>>
>> Cheers,
>> Martin
>>
>> Dot Porter wrote:
>> > Hi Syd, Martin, Conal,
>> >
>> > Here are the notes from yesterday's meeting between me, Syd and
>> > Martin. We took a look at the facsimile odd and came up with several
>> > recommended modifications:
>> >
>> > 1) The header element is very specific to a codex structure. We
>> > discussed changing this element to something more general such as
>> > or even (which leaves the door open to
>> > other media besides image files). This element would contain a pointer
>> > to class milestoneLike, so one could point not only to but to
>> > other milestones as well ( for example). Presumably once the
>> > physical bibliography work is incorporated into the TEI this kind of
>> > functionality would be directly available there as well.
>> > 2) We also discussed making a @sourceMedia or @sourceImage attribute
>> > available to milestoneLike elements (not only ) in the text. This
>> > could allow for two-way linking (so we could link from the text into
>> > the header), but would also serve the same purpose as @URL - to link
>> > to external files.
>> > 3) In the ODD file with my modifications (though I'm not sure for
>> > Conal's file that I modified), is nested within along with
>> > . There is no clear relationship between the and
>> > elements except that they are within the same . We
>> > recommend removing from and instead allowing several
>> > tags which could point to the same image, but with different
>> > coordinate values attached. So if I want to store coordinates for
>> > every line on a manuscript page, I have a separate for each
>> > line, each with different coordinates attached:
>> >
>> >
>> >
>> coords="1,2,3,4"/>
>> >
>> coords="5,6,7,8"/>
>> >
>> > coords="11,121,3,14"/>
>> >
>> > coords="15,352,388,124"/>
>> >
>> > coords="11,26,33,74"/>
>> >
>> >
>> > We didn't discuss how this might work when mapping betwen different
>> > image files.
>> >
>> > (Martin and Syd, I didn't take very good notes of this discussion so
>> > please chime in if I've misrepresented our discussion.)
>> >
>> > Thanks,
>> > Dot
>> >
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes_at_uvic.ca)
>> Half-Baked Software, Inc.
>> (mholmes_at_halfbakedsoftware.com)
>> martin_at_mholmes.com
>>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:22:15 EDT

From dporter at uky.edu Tue Jul 17 08:21:00 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 08:21:00 -0400 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <4ec2900f0706212310m264f933dob2991cefa7bedeb7@mail.gmail.com> Message-ID: <96f3df640707170521j22635d8cl7e827ba6a3d99d4d@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 08:21:00 -0400
---------- Forwarded message ----------
From: Conal Tuohy com>
Date: Jun 22, 2007 2:10 AM
Subject: Re: Facsimile meeting, 6/20
To: Dot Porter edu>
Cc: Syd Bauman edu>, Martin Holmes ca>

Hi Dot, Syd and Martin
Sorry i couldn't make this meeting, and I've been off work with a
cold, so I'm playing catch-up.
On 22/06/07, Dot Porter edu> wrote:
> Hi Syd, Martin, Conal,
>
> Here are the notes from yesterday's meeting between me, Syd and
> Martin. We took a look at the facsimile odd and came up with several
> recommended modifications:
>
> 1) The header element is very specific to a codex structure. We
> discussed changing this element to something more general such as
> or even (which leaves the door open to
> other media besides image files). This element would contain a pointer
> to class milestoneLike, so one could point not only to but to
> other milestones as well ( for example). Presumably once the
> physical bibliography work is incorporated into the TEI this kind of
> functionality would be directly available there as well.
I don't follow this at all. As I see it, the point of is to
model the flat surfaces on which texts are inscribed (call them pages
or not). Perhaps would be better.
I would be amenable to renaming to or or
something, but I think sourceMedia or sourceImage are open to
misinterpretation (i.e. that they represent electronic image files or
something). I think it's important that we keep the distinction clear
between the (or however it's named) which describes the physical
page, and the image media (e.g. TIF files).
I can see how you might want to extend this to handle other types of
media; audio for instance, but I don't think that's a great idea at
this stage. Audio recordings of a text might not be broken down into
pages (as images typically are), and they would have no graphical
projection, but only time markings. They would be quite different, in
short. The encoding is already complicated enough handling graphics.
> 2) We also discussed making a @sourceMedia or @sourceImage attribute
> available to milestoneLike elements (not only ) in the text. This
> could allow for two-way linking (so we could link from the text into
> the header), but would also serve the same purpose as @URL - to link
> to external files.
I don't see the use case for generalising to using or other
milestoneLike elements in place of just . Can you explain what
one might expect to gain by it? I don't think it's necessary to
achieve what you want (though I'm not exactly clear as to what this
might be), and it just seems like an extra complication to me.
> 3) In the ODD file with my modifications (though I'm not sure for
> Conal's file that I modified), is nested within along with
> . There is no clear relationship between the and
> elements except that they are within the same .
The relationship between the area and graphic elements is indeed
defined only through their relationships to the page which they belong
to. In the case of the area elements, they represent areas on the page
which have some analytic function, whereas in the case of the graphic
elements, they represent graphical facsimiles of the page, or a
specific part of the page.
> We
> recommend removing from and instead allowing several
> tags which could point to the same image, but with different
> coordinate values attached.
This is already allowed, so that's not an issue, but why remove ?
> So if I want to store coordinates for
> every line on a manuscript page, I have a separate for each
> line, each with different coordinates attached:
The problem with this (and the raison d'etre for ) is that you
may have multiple versions of those images. If you want to link each
line of the manuscript to a portion of a "visible-light" image, a
portion of a UV image, a portion of an "access" image, a portion of a
"master" image, etc, then you will need to duplicate a lot of
graphical data. The point of is to support this analysis - you
relate the lines of text to elements, and hence indirectly you
have related the lines of text to any elements which belong
to that page (and whose bounding box overlaps the bounding box of the
area).
>
>
>
>
>
>
>
>
> We didn't discuss how this might work when mapping betwen different image files.
Yes ... see above. :-)
> (Martin and Syd, I didn't take very good notes of this discussion so
> please chime in if I've misrepresented our discussion.)
Talk to you all again soon!
Con

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 08:21:37 EDT

From Conal.Tuohy at vuw.ac.nz Tue Jul 17 09:16:09 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 18 Jul 2007 01:16:09 +1200 Subject: [tei-council] tei stemma model In-Reply-To: <469C16D1.8010001@pitt.edu> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB5@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Wed, 18 Jul 2007 01:16:09 +1200
I like it, but I have a question about the use of @n for reference.
I'd have thought the standard practice here would be to have @target be a URI reference to the @xml:id of a node. The node/@n could still be used as a textual label.
Alternatively, instead of using URI reference, we could use @key and @ident, as someone I think mentioned on the teleconference.
C

-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of David J Birnbaum
Sent: Tue 17/07/07 13:09
To: TEI Council
Subject: [tei-council] tei stemma model

Dear Council,
At our last conference call, Council charged Matthew and me with coming
up with a proposal for modeling stemmata codicum (a specific type of
acyclic directed graph) within a TEI framework. In anticipation of
tomorrow's conference call, a proposal along those lines is now
available at:
http://clover.slavic.pitt.edu/~djb/private/article.html
This is a temporary URL, but it will be valid at least through the call.
I am still working on developing the XSLT needed to convert directly
from the descriptive model proposed in this article to SVG (an indirect
approach is already incorporated in the report), but that won't be ready
in time for tomorrow's call. Otherwise the report is more or less
complete, and, I hope, ready for discussion by Council.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:18:49 EDT

From Syd_Bauman at Brown.edu Tue Jul 17 09:22:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Jul 2007 09:22:09 -0400 Subject: [tei-council] next mtg Message-ID: <18076.49793.389997.5045@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 17 Jul 2007 09:22:09 -0400
Sorry, couldn't hear anything for the last minute or two. May I
suggest Thu 02 Aug as a our next conference call?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:22:13 EDT
From djbpitt+tei at pitt.edu Tue Jul 17 09:23:46 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 17 Jul 2007 09:23:46 -0400 Subject: [tei-council] audio quality of conference call Message-ID: <469CC2E2.6070208@pitt.edu>
From: David J Birnbaum
Date: Tue, 17 Jul 2007 09:23:46 -0400
Dear Council,
Is Skype the problem with the audio on our conference calls? Should we
try an alternative conference call system next time? I don't remember
our having problems of this type back when Perry was running the calls
out of Indiana.
In cany case, the quality was poor enough on today's call, especially
toward the end, that we were unable to conduct much of our business. If
we can avoid that problem by changing the way we configure our calls, we
probably should.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:23:53 EDT
From jawalsh at indiana.edu Tue Jul 17 09:28:07 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 17 Jul 2007 09:28:07 -0400 Subject: [tei-council] audio quality of conference call In-Reply-To: <469CC2E2.6070208@pitt.edu> Message-ID: <739CBFD9-BC03-412C-BD36-2B55DDC17D57@indiana.edu>
From: John A. Walsh
Date: Tue, 17 Jul 2007 09:28:07 -0400
Council,
I'm happy to resume running the calls through Indiana. It appears
our noble experiments at alternatives have failed miserably.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> On Jul 17, 2007, at 9:23 AM, David J Birnbaum wrote: > Dear Council, > > Is Skype the problem with the audio on our conference calls? Should > we try an alternative conference call system next time? I don't > remember our having problems of this type back when Perry was > running the calls out of Indiana. > > In cany case, the quality was poor enough on today's call, > especially toward the end, that we were unable to conduct much of > our business. If we can avoid that problem by changing the way we > configure our calls, we probably should. > > Best, > > David > > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 09:28:17 EDT
From dporter at uky.edu Tue Jul 17 09:34:13 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 17 Jul 2007 09:34:13 -0400 Subject: [tei-council] next mtg In-Reply-To: <18076.49793.389997.5045@emt.wwp.brown.edu> Message-ID: <96f3df640707170634x5406c58fx9f476411c8dae207@mail.gmail.com>
From: Dot Porter
Date: Tue, 17 Jul 2007 09:34:13 -0400
That works for me.
Dot
On 7/17/07, Syd Bauman edu> wrote:
> Sorry, couldn't hear anything for the last minute or two. May I
> suggest Thu 02 Aug as a our next conference call?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 09:34:17 EDT

From cwittern at gmail.com Tue Jul 17 09:39:31 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 17 Jul 2007 22:39:31 +0900 Subject: [tei-council] audio quality of conference call In-Reply-To: <739CBFD9-BC03-412C-BD36-2B55DDC17D57@indiana.edu> Message-ID: <469CC693.2030005@gmail.com>
From: Christian Wittern
Date: Tue, 17 Jul 2007 22:39:31 +0900
Thanks John.
I think it would be worth a try.
I tried to connect to Skype this time, but could not get through, so I
used the land line to call in. Unfortunately, after about 1 hr in the
call my battery went low so I had to spend the rest of the call standing
in the hallway next to the fixed phone without being able to look at my
computer screen. For me it was the worst call in recent memory...
All the best,
Christian
John A. Walsh wrote:
> Council,
>
> I'm happy to resume running the calls through Indiana. It appears our
> noble experiments at alternatives have failed miserably.
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> On Jul 17, 2007, at 9:23 AM, David J Birnbaum wrote:
>
>> Dear Council,
>>
>> Is Skype the problem with the audio on our conference calls? Should
>> we try an alternative conference call system next time? I don't
>> remember our having problems of this type back when Perry was running
>> the calls out of Indiana.
>>
>> In cany case, the quality was poor enough on today's call, especially
>> toward the end, that we were unable to conduct much of our business.
>> If we can avoid that problem by changing the way we configure our
>> calls, we probably should.
>>
>> Best,
>>
>> David
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 09:39:50 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 09:42:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 14:42:01 +0100 Subject: [tei-council] facsimile odd In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB3@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <469CC729.1090506@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 14:42:01 +0100
Conal Tuohy wrote:
> Lou wrote:
>
>> (5) alignment of image and text is done throughout using existing TEI
>> mechanisms -- i.e. we use @corresp to point from one to the other, or we
>> use a standoff alignment map.
>
> I think the problem with that is that people (also) desperately want to assign coordinates directly to textual elements such as p.
>
> Con
>
In what respect does the use of @corresp preclude doing precisely that?

This paragraph transcribes the area
with id pg123 defined in some or or whatever the thing with
the images in it is called

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:42:07 EDT

From daniel.odonnell at uleth.ca Tue Jul 17 09:41:49 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 17 Jul 2007 07:41:49 -0600 Subject: [tei-council] next mtg In-Reply-To: <96f3df640707170634x5406c58fx9f476411c8dae207@mail.gmail.com> Message-ID: <1184679710.15734.0.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 17 Jul 2007 07:41:49 -0600
I'll make it work for me.
On Tue, 2007-07-17 at 09:34 -0400, Dot Porter wrote:
> That works for me.
>
> Dot
>
> On 7/17/07, Syd Bauman edu> wrote:
> > Sorry, couldn't hear anything for the last minute or two. May I
> > suggest Thu 02 Aug as a our next conference call?
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 09:42:49 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 09:42:34 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 14:42:34 +0100 Subject: [tei-council] facsimile odd In-Reply-To: <96f3df640707170506o5cb61a4ao10b49076e039b06c@mail.gmail.com> Message-ID: <469CC74A.4040505@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 14:42:34 +0100
Dot Porter wrote:
> On 7/17/07, Conal Tuohy ac.nz> wrote:
>> Lou wrote:
>>
>> > (5) alignment of image and text is done throughout using existing TEI
>> > mechanisms -- i.e. we use @corresp to point from one to the other,
>> or we
>> > use a standoff alignment map.
>>
>> I think the problem with that is that people (also) desperately want
>> to assign coordinates directly to textual elements such as p.
>>
> Yes - and to scribal elements such as abbr, add, and to other
> descriptive elements such as damage and unclear.

Guys, @corresp is global.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:43:11 EDT

From cwittern at gmail.com Tue Jul 17 09:41:52 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 17 Jul 2007 22:41:52 +0900 Subject: [tei-council] next mtg In-Reply-To: <96f3df640707170634x5406c58fx9f476411c8dae207@mail.gmail.com> Message-ID: <469CC720.7040204@gmail.com>
From: Christian Wittern
Date: Tue, 17 Jul 2007 22:41:52 +0900
Dot Porter wrote:
> That works for me.
>
> Dot
>
> On 7/17/07, Syd Bauman edu> wrote:
>> Sorry, couldn't hear anything for the last minute or two. May I
>> suggest Thu 02 Aug as a our next conference call?
That would be fine with me too, as are all other dates Aug 1st through 7.
I will be offline starting tomorrow until Jul 29.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 09:42:44 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 09:48:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 14:48:01 +0100 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <96f3df640707170520q23b0e1fkc848af7fe1fe1aa4@mail.gmail.com> Message-ID: <469CC891.6090301@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 14:48:01 +0100
>
> 1) The header element is very specific to a codex structure. We
> discussed changing this element to something more general such as
> or even (which leaves the door open to
> other media besides image files).
I agree that is too specific. This is why I proposed a generic
element which simply identifies a 2-d space.

> 2) We also discussed making a @sourceMedia or @sourceImage attribute
> available to milestoneLike elements (not only ) in the text. This
> could allow for two-way linking (so we could link from the text into
> the header), but would also serve the same purpose as @URL - to link
> to external files.
I think all we need is the existing global @corresp attribute -- though
if you want to define a more specialised global attribute meaning "this
text transcribes this zone" that's OK by me... you could call it @facs
or @transcr or something
> 3) In the ODD file with my modifications (though I'm not sure for
> Conal's file that I modified), is nested within along with
> . There is no clear relationship between the and
> elements except that they are within the same . We
> recommend removing from and instead allowing several
> tags which could point to the same image, but with different
> coordinate values attached. So if I want to store coordinates for
> every line on a manuscript page, I have a separate for each
> line, each with different coordinates attached:
I think this is a mistake, because now I can't easily distinguish
graphics which identify the same zone but with different properties such
as scale or resolution from graphics which identify different zones.
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:48:05 EDT

From djbpitt+tei at pitt.edu Tue Jul 17 09:56:41 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 17 Jul 2007 09:56:41 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB5@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <469CCA99.2050005@pitt.edu>
From: David J Birnbaum
Date: Tue, 17 Jul 2007 09:56:41 -0400
Dear Conal (cc Council),
For what it's worth, my reasoning was:
1) Every needs an identifier, to which @target can point.
2) elements might also want to be able to point to
elements elsewhere, either in the same document or in a
different document.
3) Every needs a label that can be rendered, and that cannot be
subject to character restrictions.
4) One could use a different attribute in each of these functions, but
since they are all related (they are all essentially names of a
manuscript represented by a node), using three attributes where one
would do the job not only is inefficient, but also creates opportunities
for inconsistency (i.e., error).
5) In the schema I present, the one attribute that I use has all the
desired properties of IDs, IDREFs, and plain text names simultaneously.
There are no character restrictions on the name, it is guaranteed to be
unique, and @target is guaranteed to point to the name of a .
I'm not sure whether my reasoning was unclear or whether Council
understands it but disagrees. In the former case, I hope the preceding
elaboration is helpful (and if it is still unclear, please ask!). In the
latter, if Council understands the reasoning but nonetheless believes we
should use three attributes instead of one, so be it.
Best,
David
Conal Tuohy wrote:
> I like it, but I have a question about the use of @n for reference.
>
> I'd have thought the standard practice here would be to have @target be a URI reference to the @xml:id of a node. The node/@n could still be used as a textual label.
>
> Alternatively, instead of using URI reference, we could use @key and @ident, as someone I think mentioned on the teleconference.
>
> C
>
>
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of David J Birnbaum
> Sent: Tue 17/07/07 13:09
> To: TEI Council
> Subject: [tei-council] tei stemma model
>
> Dear Council,
>
> At our last conference call, Council charged Matthew and me with coming
> up with a proposal for modeling stemmata codicum (a specific type of
> acyclic directed graph) within a TEI framework. In anticipation of
> tomorrow's conference call, a proposal along those lines is now
> available at:
>
> http://clover.slavic.pitt.edu/~djb/private/article.html
>
> This is a temporary URL, but it will be valid at least through the call.
>
> I am still working on developing the XSLT needed to convert directly
> from the descriptive model proposed in this article to SVG (an indirect
> approach is already incorporated in the report), but that won't be ready
> in time for tomorrow's call. Otherwise the report is more or less
> complete, and, I hope, ready for discussion by Council.
>
> Best,
>
> David
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 09:56:48 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 10:18:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 15:18:53 +0100 Subject: [tei-council] Fwd: Facsimile meeting, 6/20 In-Reply-To: <96f3df640707170521j22635d8cl7e827ba6a3d99d4d@mail.gmail.com> Message-ID: <469CCFCD.3050601@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 15:18:53 +0100
Conal wrote:
>> 1) The header element is very specific to a codex structure. We
>> discussed changing this element to something more general such as
>> or even (which leaves the door open to
>> other media besides image files). This element would contain a pointer
>> to class milestoneLike, so one could point not only to but to
>> other milestones as well ( for example). Presumably once the
>> physical bibliography work is incorporated into the TEI this kind of
>> functionality would be directly available there as well.
>
> I don't follow this at all. As I see it, the point of is to
> model the flat surfaces on which texts are inscribed (call them pages
> or not). Perhaps would be better.
>
> I would be amenable to renaming to or or
> something, but I think sourceMedia or sourceImage are open to
> misinterpretation (i.e. that they represent electronic image files or
> something). I think it's important that we keep the distinction clear
> between the (or however it's named) which describes the physical
> page, and the image media (e.g. TIF files).
>
Let me reiterate that I agree with Conal on this one -- the purpose of
this element is to define the two-dimensional space within which
(potentially) writing occurs, and of which we have a non-textual
representation. That collection of non-textual representations
constitutes something that is like a text in that we can "read" it,
which is why I propose we should wrap them all in a like element.

> The relationship between the area and graphic elements is indeed
> defined only through their relationships to the page which they belong
> to. In the case of the area elements, they represent areas on the page
> which have some analytic function, whereas in the case of the graphic
> elements, they represent graphical facsimiles of the page, or a
> specific part of the page.
I agree with this too.
>
>> We
>> recommend removing from and instead allowing several
>> tags which could point to the same image, but with different
>> coordinate values attached.
>
> This is already allowed, so that's not an issue, but why remove ?
I would remove the need for area at all, by making (or whatevrer
we call the thing) self-nest.
>
> The problem with this (and the raison d'etre for ) is that you
> may have multiple versions of those images. If you want to link each
> line of the manuscript to a portion of a "visible-light" image, a
> portion of a UV image, a portion of an "access" image, a portion of a
> "master" image, etc, then you will need to duplicate a lot of
> graphical data.
I don't follow this argument, sorry. I would do this by saying










co-ords are always understood relative to their sibling graphic,
if there is one, or to that of their parent if there isn't

The point of is to support this analysis - you
> relate the lines of text to elements, and hence indirectly you
> have related the lines of text to any elements which belong
> to that page (and whose bounding box overlaps the bounding box of the
> area).
>
Could you give us an example?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 10:28:43 EDT

From arianna.ciula at kcl.ac.uk Tue Jul 17 10:32:33 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 17 Jul 2007 15:32:33 +0100 Subject: [tei-council] next mtg In-Reply-To: <469CC720.7040204@gmail.com> Message-ID: <469CD301.8000604@kcl.ac.uk>
From: Arianna Ciula
Date: Tue, 17 Jul 2007 15:32:33 +0100
As I said while a skype cascade of running water was flooding into my
ears, I won't be able to attend next conference call unless fixed after
the 11th of August. I realise that may be too late, so I will look
forward to going through minutes and notes.
Arianna
Christian Wittern wrote:
> Dot Porter wrote:
>> That works for me.
>>
>> Dot
>>
>> On 7/17/07, Syd Bauman edu> wrote:
>>> Sorry, couldn't hear anything for the last minute or two. May I
>>> suggest Thu 02 Aug as a our next conference call?
> That would be fine with me too, as are all other dates Aug 1st through 7.
>
> I will be offline starting tomorrow until Jul 29.
> All the best,
>
> Christian
>
>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 10:35:24 EDT
From daniel.odonnell at uleth.ca Tue Jul 17 10:34:47 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 17 Jul 2007 08:34:47 -0600 Subject: [tei-council] rdg and the phrase Message-ID: <1184682887.18648.21.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 17 Jul 2007 08:34:47 -0600
Just a quick follow up to our conversation re: rdg. Lous and I have had
a brief correspondence on it since:
> > Hi Lou,
> >
> > Following up: can you tell me again what it is I should be looking
> at
> > regarding rdg and chunks? Did you say rdgSpan (in which case
> what/where
> > is that?) or is it an attribute? I've quickly gone through the
> chapter
> > again but am not seeing anything that sounds like what I thought you
> > said.
> >
> > Thanks!
> >
> > -dan
>
> Sorry, I was misremembering something else. addSpan and delSpan are
> provided by the PH chapter to support additions and deletions of
> items
> that don't necessarily fit into the document hierarchy, for example
> an
> additiom that starts at the end of one chapter and continues into the
> next: I was proposing that something analogous might exist for rdgs
> and
> lems. But I see we already have it in the shape of the double end
> point
> attachment method.
>
The double-endpoint-attachment method is not quite sufficient, however.
It is good for overlapping variants and lemmas of the type in 117 of the
Wife of Bath's Tale (collation units indicated by [ and { respectively):
Hg
And [of so parfit {wys] a wight} ywroght
El
And for what profit {was a wight} ywroght
Ha4
And [in what wise] {was a wight} ywroght
And of so
parfit
wys
a wight
ywroght

of so parfit wys
in what wise was


wys a wight
was a wight


It won't solve the problem of extra, missing, or reordered chunks (as in
the case of lines of poetry or paragraphs) or divs (as in the case of
diary entries in something like the Diary of Anne Frank), since you
still can't reproduce chunks or divs marked up as such in lem or rdg.
This would work if app and/or lem|rdg was really something like
linkGroup and did not reproduce the actual text, since you could use the
milestones to mark off arbitrary sections of text regardless of their
encoding. But it breaks the moment you try to include the text you mean
with its structural markup in your lem or rdg if this markup is larger
than the phrase.
I'll propose concrete model and language changes this week as promised
at the meeting (in case you didn't hear during the meeting ;?? ).
-d
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 10:35:55 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 10:43:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 15:43:11 +0100 Subject: [tei-council] rdg and the phrase In-Reply-To: <1184682887.18648.21.camel@localhost> Message-ID: <469CD57F.9080508@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 15:43:11 +0100
But a traditional apparatus never *does* include whole chapters does it?
I think it's really distorting the meaning of "rdg" to say it can
contain a whole chapter!
You could perhaps more plausibly argue for allowing a pointer element of
some kind to stand in for a .

Daniel O'Donnell wrote:
> Just a quick follow up to our conversation re: rdg. Lous and I have had
> a brief correspondence on it since:
>
>>> Hi Lou,
>>>
>>> Following up: can you tell me again what it is I should be looking
>> at
>>> regarding rdg and chunks? Did you say rdgSpan (in which case
>> what/where
>>> is that?) or is it an attribute? I've quickly gone through the
>> chapter
>>> again but am not seeing anything that sounds like what I thought you
>>> said.
>>>
>>> Thanks!
>>>
>>> -dan
>> Sorry, I was misremembering something else. addSpan and delSpan are
>> provided by the PH chapter to support additions and deletions of
>> items
>> that don't necessarily fit into the document hierarchy, for example
>> an
>> additiom that starts at the end of one chapter and continues into the
>> next: I was proposing that something analogous might exist for rdgs
>> and
>> lems. But I see we already have it in the shape of the double end
>> point
>> attachment method.
>>
>
> The double-endpoint-attachment method is not quite sufficient, however.
> It is good for overlapping variants and lemmas of the type in 117 of the
> Wife of Bath's Tale (collation units indicated by [ and { respectively):
>
> Hg
> And [of so parfit {wys] a wight} ywroght
> El
> And for what profit {was a wight} ywroght
> Ha4
> And [in what wise] {was a wight} ywroght
>
> And of so
> parfit
> wys
> a wight
> ywroght
>
> of so parfit wys
> in what wise was
>
>
> wys a wight
> was a wight
>
>
>
> It won't solve the problem of extra, missing, or reordered chunks (as in
> the case of lines of poetry or paragraphs) or divs (as in the case of
> diary entries in something like the Diary of Anne Frank), since you
> still can't reproduce chunks or divs marked up as such in lem or rdg.
> This would work if app and/or lem|rdg was really something like
> linkGroup and did not reproduce the actual text, since you could use the
> milestones to mark off arbitrary sections of text regardless of their
> encoding. But it breaks the moment you try to include the text you mean
> with its structural markup in your lem or rdg if this markup is larger
> than the phrase.
>
> I'll propose concrete model and language changes this week as promised
> at the meeting (in case you didn't hear during the meeting ;?? ).
>
> -d
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 10:43:16 EDT

From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 12:00:24 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 17:00:24 +0100 Subject: [tei-council] next mtg In-Reply-To: <469CC720.7040204@gmail.com> Message-ID: <469CE798.6060407@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 17:00:24 +0100
Christian Wittern wrote:
> Dot Porter wrote:
>> That works for me.
>>
>> Dot
>>
>> On 7/17/07, Syd Bauman edu> wrote:
>>> Sorry, couldn't hear anything for the last minute or two. May I
>>> suggest Thu 02 Aug as a our next conference call?
> That would be fine with me too, as are all other dates Aug 1st through 7.
>
> I will be offline starting tomorrow until Jul 29.
> All the best,
>
> Christian
>
>
>
2 aug duly entered here.
next time we should use meetomatic!

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 12:00:28 EDT

From daniel.odonnell at uleth.ca Tue Jul 17 12:05:29 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 17 Jul 2007 10:05:29 -0600 Subject: [tei-council] rdg and the phrase In-Reply-To: <469CD57F.9080508@computing-services.oxford.ac.uk> Message-ID: <1184688329.18648.39.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 17 Jul 2007 10:05:29 -0600
On Tue, 2007-07-17 at 15:43 +0100, Lou Burnard wrote:
> But a traditional apparatus never *does* include whole chapters does it?
>
> I think it's really distorting the meaning of "rdg" to say it can
> contain a whole chapter!
First of all, let's deal with the simple intermediate problem rather
than the tough case: apparatus frequently include chunks and the TEI's
doesn't. I've given a number of use cases in the last months and they
are not at all hard to find. Print apparatus have always found this hard
to deal with, because of layout issues. The TEI's structural markup
allows us to be explicit about something print could not.
Secondly, the TEI apparatus is not a traditional apparatus, though it
can encode them. Parallel segmentation is not a traditional approach to
apparatus, though it is a brilliant electronic form (of course collation
lists are a kind of parallel segmentation, but they are not intended for
reading in the way a TEI parallel seg. apparatus is according to the
narrative description). So we can use the apparatus to encode existing
print apparatus, but we can also go much farther and deal with things
print has an extremely hard time dealing with.
And this leads us to the issue of divs. First of all, they actually do
show up in print apparatus: I don't have an example at my hand right
now, but I've seen them and I believe there are examples in Greetham's
textual scholarship. The normal print approach when a variant involves
the addition of an entire chapter or equivalent is to use an ellipsis
after the first couple of words and then close with an excipit. Often a
note or text in square brackets is use to indicate that the text in the
elipsis is a chapter. Other times, as in the Critical Edition of the
Diary of Anne Frank, they try to use pointers and codes to indicate what
they mean--the DAF critical ed has a normal textual apparatus that
collates at the chunk, phrase, and word level, and then a kind of
combination parallel-text/collation system that tries to compare
div-level elements. It is not very successful.
So div level elements do appear in print apparatus, but not very well.
In electronic form, once again, we can do much better. Apps are in my
view very much like dictionaries: something that print did but we can
improve on.
>
> You could perhaps more plausibly argue for allowing a pointer element of
> some kind to stand in for a .
This wouldn't solve the problem of the chunk and divs in rdg and lem,
since any attempt to use the pointers to extract an apparatus would
break rdg if the target was a chunk or div. So I could build a kind of
link group telling you where the collation units are, but I couldn't
perform one of the functions of a textual apparatus, which is extracting
the readings and placing them beside each other for comparison.
>
>
> Daniel O'Donnell wrote:
> > Just a quick follow up to our conversation re: rdg. Lous and I have had
> > a brief correspondence on it since:
> >
> >>> Hi Lou,
> >>>
> >>> Following up: can you tell me again what it is I should be looking
> >> at
> >>> regarding rdg and chunks? Did you say rdgSpan (in which case
> >> what/where
> >>> is that?) or is it an attribute? I've quickly gone through the
> >> chapter
> >>> again but am not seeing anything that sounds like what I thought you
> >>> said.
> >>>
> >>> Thanks!
> >>>
> >>> -dan
> >> Sorry, I was misremembering something else. addSpan and delSpan are
> >> provided by the PH chapter to support additions and deletions of
> >> items
> >> that don't necessarily fit into the document hierarchy, for example
> >> an
> >> additiom that starts at the end of one chapter and continues into the
> >> next: I was proposing that something analogous might exist for rdgs
> >> and
> >> lems. But I see we already have it in the shape of the double end
> >> point
> >> attachment method.
> >>
> >
> > The double-endpoint-attachment method is not quite sufficient, however.
> > It is good for overlapping variants and lemmas of the type in 117 of the
> > Wife of Bath's Tale (collation units indicated by [ and { respectively):
> >
> > Hg
> > And [of so parfit {wys] a wight} ywroght
> > El
> > And for what profit {was a wight} ywroght
> > Ha4
> > And [in what wise] {was a wight} ywroght
> >
> > And of so
> > parfit
> > wys
> > a wight
> > ywroght
> >
> > of so parfit wys
> > in what wise was
> >
> >
> > wys a wight
> > was a wight
> >
> >
> >
> > It won't solve the problem of extra, missing, or reordered chunks (as in
> > the case of lines of poetry or paragraphs) or divs (as in the case of
> > diary entries in something like the Diary of Anne Frank), since you
> > still can't reproduce chunks or divs marked up as such in lem or rdg.
> > This would work if app and/or lem|rdg was really something like
> > linkGroup and did not reproduce the actual text, since you could use the
> > milestones to mark off arbitrary sections of text regardless of their
> > encoding. But it breaks the moment you try to include the text you mean
> > with its structural markup in your lem or rdg if this markup is larger
> > than the phrase.
> >
> > I'll propose concrete model and language changes this week as promised
> > at the meeting (in case you didn't hear during the meeting ;?? ).
> >
> > -d
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 12:06:09 EDT
From Syd_Bauman at Brown.edu Tue Jul 17 14:19:03 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Jul 2007 14:19:03 -0400 (EDT) Subject: [tei-council] divWrapping: summary and question Message-ID: <200707171819.l6HIJ3S3002296@draco.services.brown.edu>
From: Syd Bauman
Date: Tue, 17 Jul 2007 14:19:03 -0400 (EDT)
For those of you for whom it is not obvious why divWrapping is
currently broken, and who do not remember why from the thread here
back in April or from the Berlin meeting, I will post a description
of the main problems "divWrapping: problem description" in a few
seconds.
This post is a summary of the divWrapping issue for
, ,
and (egregiously exempting and ), and a request
for input from Council and how to fix divWrapping.
Summary of Problems
------- -- --------
* In a
, things that should not be allowed in the div-bottom
area are (in particular and )
* has the reverse problem, that none of the divWrapper
elements are allowed near the bottom

Possible Solutions
-------- ---------
Back in April I outlined two possible fixes to the class system,
implicitly asking which was better. IIRC only 1 person even appeared
to express a preference either way, and it wasn't clear that he (CW)
was talking about a specific solution or the problem in general.
So, here is the question again in summary, and then in detail. Note
that for purposes of this discussion, I've used shorthand names in
the summary question.
Should we have
a) the common elements in divWrapper, divWrapper as part of divTop
and divBot, thus content models refer to divTop or divBot; or
b) the common elements in divWrapper, but divWrapper is not a member
of divTop and divBot, thus content models refer to both divTop and
divWrapper, or both divBot and divWrapper?

The following describes scenarios a & b more verbosely, and perhaps
more clearly.
--------- (a) ---------
model.divWrapper = argument byline dateline docAuthor docDate
model.divTop = model.divWrapper head opener salute epigraph
model.divBottom = model.divWrapper closed signed trailer ps
Content models have things like
model.divTop*
and
model.divBottom*
We have no way to refer to the set of elements head, opener, etc.
alone, without also referring to argument, byline, etc.
--------- (b) ---------
model.divWrapper = argument byline dateline docAuthor docDate
model.divTop = head opener salute epigraph
model.divBottom = closed signed trailer ps
Content models have things like
( model.divWrapper | model.divTop )*
and
( model.divWrapper | model.divBottom )*
If one ever wanted to refer to the class of elements that can go at
the top *but not the bottom* of a division, you'd say
model.divTop.

It would be very nice if I could get a sense of which of these two is
preferred ASAP.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 14:19:06 EDT

From Syd_Bauman at Brown.edu Tue Jul 17 14:19:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Jul 2007 14:19:09 -0400 Subject: [tei-council] divWrapping: problem description Message-ID: <18077.2077.87643.77534@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 17 Jul 2007 14:19:09 -0400
The major problem with the current content model of
[1] is that
anything that can go at the top of a division can also go at the
bottom. For a lot of elements this makes sense, e.g. ,
, and . Even for it may be OK, for
although most define as something that occurs at the
beginning[2], P4 goes both ways on the issue (defining as
"appearing at the start of a section or chapter, or on a title page",
but permitting it in %m.divbot;), and a few define it as something
either at the beginning or the end (the Comprehensive TeX Archive
Network, UK TeX FAQ); moreover, one could stretch the etymological
roots of the word to include both before and after.
However, for some elements, most notably and , it
makes no sense, and causes problems, to allow them at the bottom of a
division.
First off, semantically and just should not exist
after the main part of a division, much less after a or
. The following is valid against the current content
model[1]:







But what's worse, is the confusion this causes in those new to TEI,
particularly those who are used to XHTML.
Imagine such a person encoding what you and I know should be encoded
as


















Being familiar with XHTML, she tries the following:
01.

02.
03.


04.


05.
06.
07.


08.


09.
10.


11.


12.


and gets quite confused when her validator tells her that the


element on line 07 is invalid. (And then she asks "why isn't a


allowed after a ?" :-)
We would just be asking for trouble. Of course, the validator should
tell her that the at line 05 is invalid, because
shouldn't be allowed at the bottom of a division.

Note also that the content model for , which should be
essentially the same as that for

(except that it has to
accommodate both the numbered- and unnumbered- flavors of division)
does not have this problem. It has the reverse problem, that none of
the divWrapper elements are allowed near the bottom.

Lastly, the content model of

and its ilk is quite complicated,
with what initially appear to be extra levels of parentheses.
However, these are needed for DTD (and perhaps XSD) determinism. I
believe it is possible that we could make this model a bit simpler
and still be deterministic, but I am not sure, and as Sebastian has
pointed out, if it can be done it is awfully hard.
My recommendation (which I never got to on the conference call) is
not to bother trying for this simplification for 1.0.

Wrapping ones mind around the content models for and
and how they should be utilizing divWrapping stuff is another story.

Notes
-----
[1] See http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-div.html.
[2] Including wikipedia, Chicago Manual of Style, Random House
Unabridged Dictionary, Merriam-Webster, The American Heritage
Dictionary of the English Language, WordNet, DocBook, and the
Oxford English Dictionary.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 14:19:38 EDT

From jawalsh at indiana.edu Tue Jul 17 14:40:41 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 17 Jul 2007 14:40:41 -0400 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <200707171819.l6HIJ3S3002296@draco.services.brown.edu> Message-ID: <9AC29C3F-588E-4164-9221-655ED448D559@indiana.edu>
From: John A. Walsh
Date: Tue, 17 Jul 2007 14:40:41 -0400
Syd,
I understand the issue, and I prefer option A, which allows for
cleaner and more elegant content models. I don't see a compelling
need to refer to head, opener, salute, epigraph separately from the
other elements with which they would be grouped in divTop.
John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> On Jul 17, 2007, at 2:19 PM, Syd Bauman wrote: > For those of you for whom it is not obvious why divWrapping is > currently broken, and who do not remember why from the thread here > back in April or from the Berlin meeting, I will post a description > of the main problems "divWrapping: problem description" in a few > seconds. > > This post is a summary of the divWrapping issue for
, , > and (egregiously exempting and ), and a request > for input from Council and how to fix divWrapping. > > Summary of Problems > ------- -- -------- > > * In a
, things that should not be allowed in the div-bottom > area are (in particular and ) > > * has the reverse problem, that none of the divWrapper > elements are allowed near the bottom > > > Possible Solutions > -------- --------- > > Back in April I outlined two possible fixes to the class system, > implicitly asking which was better. IIRC only 1 person even appeared > to express a preference either way, and it wasn't clear that he (CW) > was talking about a specific solution or the problem in general. > > So, here is the question again in summary, and then in detail. Note > that for purposes of this discussion, I've used shorthand names in > the summary question. > > Should we have > > a) the common elements in divWrapper, divWrapper as part of divTop > and divBot, thus content models refer to divTop or divBot; or > > b) the common elements in divWrapper, but divWrapper is not a member > of divTop and divBot, thus content models refer to both divTop and > divWrapper, or both divBot and divWrapper? > > > The following describes scenarios a & b more verbosely, and perhaps > more clearly. > > --------- (a) --------- > model.divWrapper = argument byline dateline docAuthor docDate > model.divTop = model.divWrapper head opener salute epigraph > model.divBottom = model.divWrapper closed signed trailer ps > > Content models have things like > model.divTop* > and > model.divBottom* > > We have no way to refer to the set of elements head, opener, etc. > alone, without also referring to argument, byline, etc. > > --------- (b) --------- > model.divWrapper = argument byline dateline docAuthor docDate > model.divTop = head opener salute epigraph > model.divBottom = closed signed trailer ps > > Content models have things like > ( model.divWrapper | model.divTop )* > and > ( model.divWrapper | model.divBottom )* > > If one ever wanted to refer to the class of elements that can go at > the top *but not the bottom* of a division, you'd say > model.divTop. > > > It would be very nice if I could get a sense of which of these two is > preferred ASAP. > > _______________________________________________ > tei-council mailing list > tei-council_at_lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 14:40:55 EDT
From daniel.odonnell at uleth.ca Tue Jul 17 15:46:04 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 17 Jul 2007 13:46:04 -0600 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <9AC29C3F-588E-4164-9221-655ED448D559@indiana.edu> Message-ID: <1184701564.9646.5.camel@localhost>
From: Daniel O'Donnell
Date: Tue, 17 Jul 2007 13:46:04 -0600
Does option b have a particularly onerous cost? And under what
circumstances would we refer to top and bottom separately?
-dan
On Tue, 2007-07-17 at 14:40 -0400, John A. Walsh wrote:
> Syd,
>
> I understand the issue, and I prefer option A, which allows for
> cleaner and more elegant content models. I don't see a compelling
> need to refer to head, opener, salute, epigraph separately from the
> other elements with which they would be grouped in divTop.
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> On Jul 17, 2007, at 2:19 PM, Syd Bauman wrote:
>
> > For those of you for whom it is not obvious why divWrapping is
> > currently broken, and who do not remember why from the thread here
> > back in April or from the Berlin meeting, I will post a description
> > of the main problems "divWrapping: problem description" in a few
> > seconds.
> >
> > This post is a summary of the divWrapping issue for
, ,
> > and (egregiously exempting and ), and a request
> > for input from Council and how to fix divWrapping.
> >
> > Summary of Problems
> > ------- -- --------
> >
> > * In a
, things that should not be allowed in the div-bottom
> > area are (in particular and )
> >
> > * has the reverse problem, that none of the divWrapper
> > elements are allowed near the bottom
> >
> >
> > Possible Solutions
> > -------- ---------
> >
> > Back in April I outlined two possible fixes to the class system,
> > implicitly asking which was better. IIRC only 1 person even appeared
> > to express a preference either way, and it wasn't clear that he (CW)
> > was talking about a specific solution or the problem in general.
> >
> > So, here is the question again in summary, and then in detail. Note
> > that for purposes of this discussion, I've used shorthand names in
> > the summary question.
> >
> > Should we have
> >
> > a) the common elements in divWrapper, divWrapper as part of divTop
> > and divBot, thus content models refer to divTop or divBot; or
> >
> > b) the common elements in divWrapper, but divWrapper is not a member
> > of divTop and divBot, thus content models refer to both divTop and
> > divWrapper, or both divBot and divWrapper?
> >
> >
> > The following describes scenarios a & b more verbosely, and perhaps
> > more clearly.
> >
> > --------- (a) ---------
> > model.divWrapper = argument byline dateline docAuthor docDate
> > model.divTop = model.divWrapper head opener salute epigraph
> > model.divBottom = model.divWrapper closed signed trailer ps
> >
> > Content models have things like
> > model.divTop*
> > and
> > model.divBottom*
> >
> > We have no way to refer to the set of elements head, opener, etc.
> > alone, without also referring to argument, byline, etc.
> >
> > --------- (b) ---------
> > model.divWrapper = argument byline dateline docAuthor docDate
> > model.divTop = head opener salute epigraph
> > model.divBottom = closed signed trailer ps
> >
> > Content models have things like
> > ( model.divWrapper | model.divTop )*
> > and
> > ( model.divWrapper | model.divBottom )*
> >
> > If one ever wanted to refer to the class of elements that can go at
> > the top *but not the bottom* of a division, you'd say
> > model.divTop.
> >
> >
> > It would be very nice if I could get a sense of which of these two is
> > preferred ASAP.
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 17 2007 - 15:46:45 EDT
From Syd_Bauman at Brown.edu Tue Jul 17 15:59:16 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Jul 2007 15:59:16 -0400 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <1184701564.9646.5.camel@localhost> Message-ID: <18077.8084.902548.772522@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 17 Jul 2007 15:59:16 -0400
> Does option b have a particularly onerous cost? And under what
> circumstances would we refer to top and bottom separately?
No, the cost of option (b) is not particularly onerous. The cost is
really only that the content model (which is already quite a tangle)
is that much more complicated.
Honestly, I can't think of any reason we'd want to refer to the "top
only" elements without the "top or bottom" elements. But I guess
that, unlike John, I wasn't brave enough to commit to that :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 15:59:21 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 17 16:07:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Jul 2007 21:07:42 +0100 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <9AC29C3F-588E-4164-9221-655ED448D559@indiana.edu> Message-ID: <469D218E.8010007@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 17 Jul 2007 21:07:42 +0100
I agree with John.
(Apologies by the way for sounding so vehement about this being a
non-problem in the call this afternoon -- I thought that Syd was
referring to a different issue relating to the content model of divs. I
blame this misapprehension on the noisiness of the call...)

John A. Walsh wrote:
> Syd,
>
> I understand the issue, and I prefer option A, which allows for
> cleaner and more elegant content models. I don't see a compelling
> need to refer to head, opener, salute, epigraph separately from the
> other elements with which they would be grouped in divTop.
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 16:13:46 EDT

From conal.tuohy at vuw.ac.nz Tue Jul 17 19:31:18 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 18 Jul 2007 11:31:18 +1200 Subject: [tei-council] facsimile odd In-Reply-To: <469CC74A.4040505@computing-services.oxford.ac.uk> Message-ID: <1184715078.9326.162.camel@localhost>
From: Conal Tuohy
Date: Wed, 18 Jul 2007 11:31:18 +1200
On Tue, 2007-07-17 at 14:42 +0100, Lou Burnard wrote:
> Dot Porter wrote:
> > On 7/17/07, Conal Tuohy ac.nz> wrote:
> >> Lou wrote:
> >>
> >> > (5) alignment of image and text is done throughout using existing TEI
> >> > mechanisms -- i.e. we use @corresp to point from one to the other,
> >> or we
> >> > use a standoff alignment map.
> >>
> >> I think the problem with that is that people (also) desperately want
> >> to assign coordinates directly to textual elements such as p.
> >>
> > Yes - and to scribal elements such as abbr, add, and to other
> > descriptive elements such as damage and unclear.
>
>
> Guys, @corresp is global.
Yes @corresp is global, so people can use stand-off if they want, but
the issue is that what most encoders seem to actually WANT is to use a
more direct style of markup in which coords are attached directly to
elements within the text, rather than necessarily use a stand-off style
of markup, so our draft attempts to support that, as well as a stand-off
style in which textual (or scribal) elements are linked to a tei:area
which itself has the coordinates attached.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 19:40:44 EDT
From djbpitt+tei at pitt.edu Tue Jul 17 23:38:03 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 17 Jul 2007 23:38:03 -0400 Subject: [tei-council] stemma modeling Message-ID: <469D8B1B.9080308@pitt.edu>
From: David J Birnbaum
Date: Tue, 17 Jul 2007 23:38:03 -0400
Dear Council,
I've updated the stemma report and moved it to
http://clover.slavic.pitt.edu/~djb/2007_xml-stemma/2007_xml-stemma.html
. The new version includes an XSLT script for direct XML-to-SVG
transformation (bypassing Graphviz or comparable intermediaries), which
may be a useful proof of concept for potential users who might otherwise
think "yeah, it's a clever model, but how do I render it for my users?"
(which is not an unfair question).
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 17 2007 - 23:38:07 EDT
From conal.tuohy at vuw.ac.nz Tue Jul 17 23:52:06 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 18 Jul 2007 15:52:06 +1200 Subject: [tei-council] tei stemma model In-Reply-To: <469CCA99.2050005@pitt.edu> Message-ID: <1184730726.9326.195.camel@localhost>
From: Conal Tuohy
Date: Wed, 18 Jul 2007 15:52:06 +1200
On Tue, 2007-07-17 at 09:56 -0400, David J Birnbaum wrote:
> 1) Every needs an identifier, to which @target can point.
>
> 2) elements might also want to be able to point to
> elements elsewhere, either in the same document or in a
> different document.
>
> 3) Every needs a label that can be rendered, and that cannot be
> subject to character restrictions.
>
> 4) One could use a different attribute in each of these functions, but
> since they are all related (they are all essentially names of a
> manuscript represented by a node), using three attributes where one
> would do the job not only is inefficient, but also creates opportunities
> for inconsistency (i.e., error).
OK I figured it was this consideration (parsimony) that was the
motivation, and that makes sense. I think there's something to be said
for using a reference system that's more consistent with the others used
in TEI, and keeping the label function distinct from the reference
function.
What about pointing TO stemma nodes from elsewhere? Might that not be
needed? And if so, wouldn't that really require use of @xml:id? I think
the advantage of @xml:id as a reference point is that it is defined in a
broader context (i.e. as part of the XML spec rather than in a TEI
schema) and can be used by non-schema-aware processors.
> 5) In the schema I present, the one attribute that I use has all the
> desired properties of IDs, IDREFs, and plain text names simultaneously.
> There are no character restrictions on the name, it is guaranteed to be
> unique, and @target is guaranteed to point to the name of a .
>
> I'm not sure whether my reasoning was unclear or whether Council
> understands it but disagrees. In the former case, I hope the preceding
> elaboration is helpful (and if it is still unclear, please ask!). In the
> latter, if Council understands the reasoning but nonetheless believes we
> should use three attributes instead of one, so be it.
Well, yes, I guessed that was the justification (which does make sense),
but I think personally I would prefer the use of distinct @n and @xml:id
attributes, and tei:contaminates/@target having the type "URI". Is it
just me being picky?
Cheers
C
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 00:01:32 EDT
From conal.tuohy at vuw.ac.nz Tue Jul 17 23:56:45 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 18 Jul 2007 15:56:45 +1200 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <9AC29C3F-588E-4164-9221-655ED448D559@indiana.edu> Message-ID: <1184731005.9326.197.camel@localhost>
From: Conal Tuohy
Date: Wed, 18 Jul 2007 15:56:45 +1200
On Tue, 2007-07-17 at 14:40 -0400, John A. Walsh wrote:
> Syd,
>
> I understand the issue, and I prefer option A, which allows for
> cleaner and more elegant content models. I don't see a compelling
> need to refer to head, opener, salute, epigraph separately from the
> other elements with which they would be grouped in divTop.
>
> John
I agree with John.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 00:06:08 EDT
From djbpitt+tei at pitt.edu Wed Jul 18 00:19:14 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 18 Jul 2007 00:19:14 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <1184730726.9326.195.camel@localhost> Message-ID: <469D94C2.3030504@pitt.edu>
From: David J Birnbaum
Date: Wed, 18 Jul 2007 00:19:14 -0400
Dear Conal (cc Council),
I certainly appreciate the advantage of using consistent attributes
across the TEI spectrum, so using @xml:id to mark an element as a target
of pointing, @n as a name, and something else as a pointer to other
elements will strike a usefully familiar note with users of other parts
of P5. In my own projects, though, I try to be zealous about reducing
the opportunity for error, so I avoid markup like xml:id="blah" key="blah" ident="blah">blah, where the values of
all of the attributes should be the same, since that creates an
opportunity for an inattentive user to fail to keep them in sync, or to
write a pointer on another element to the wrong attribute.
For what it's worth, I do most of my schema development directly in
Relax NG, I like the added power of Schematron rules, and I tend to care
most about producing the most constrained schema possible. (Thus my
ongoing losing battle in Council against repeatable or groups!) Weighing
this worthwhile goal against the worthwhile goal of using global
attributes (such as @n or @xml:id) consistently throughout the TEI is
tricky, and my preferences may ultimately differ from those of the rest
of Council.
I have no objection to someone taking what I've developed and changing
the attribute usage before integrating it into P5. It isn't the way I'd
encode a stemma, since I think it invites error unnecessarily, but as
long as the primary functionality (nesting typed nodes and a mechanism
for encoding contamination through XML containment) is there, the rest
is just reference validation, and assuming the user is attentive, either
model will get job done.
Best,
David
Conal Tuohy wrote:
> On Tue, 2007-07-17 at 09:56 -0400, David J Birnbaum wrote:
>
>> 1) Every needs an identifier, to which @target can point.
>>
>> 2) elements might also want to be able to point to
>> elements elsewhere, either in the same document or in a
>> different document.
>>
>> 3) Every needs a label that can be rendered, and that cannot be
>> subject to character restrictions.
>>
>> 4) One could use a different attribute in each of these functions, but
>> since they are all related (they are all essentially names of a
>> manuscript represented by a node), using three attributes where one
>> would do the job not only is inefficient, but also creates opportunities
>> for inconsistency (i.e., error).
>>
>
> OK I figured it was this consideration (parsimony) that was the
> motivation, and that makes sense. I think there's something to be said
> for using a reference system that's more consistent with the others used
> in TEI, and keeping the label function distinct from the reference
> function.
>
> What about pointing TO stemma nodes from elsewhere? Might that not be
> needed? And if so, wouldn't that really require use of @xml:id? I think
> the advantage of @xml:id as a reference point is that it is defined in a
> broader context (i.e. as part of the XML spec rather than in a TEI
> schema) and can be used by non-schema-aware processors.
>
>
>> 5) In the schema I present, the one attribute that I use has all the
>> desired properties of IDs, IDREFs, and plain text names simultaneously.
>> There are no character restrictions on the name, it is guaranteed to be
>> unique, and @target is guaranteed to point to the name of a .
>>
>> I'm not sure whether my reasoning was unclear or whether Council
>> understands it but disagrees. In the former case, I hope the preceding
>> elaboration is helpful (and if it is still unclear, please ask!). In the
>> latter, if Council understands the reasoning but nonetheless believes we
>> should use three attributes instead of one, so be it.
>>
>
> Well, yes, I guessed that was the justification (which does make sense),
> but I think personally I would prefer the use of distinct @n and @xml:id
> attributes, and tei:contaminates/@target having the type "URI". Is it
> just me being picky?
>
> Cheers
>
> C
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 00:19:19 EDT
From djbpitt+tei at pitt.edu Wed Jul 18 00:30:50 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 18 Jul 2007 00:30:50 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <469D94C2.3030504@pitt.edu> Message-ID: <469D977A.5070908@pitt.edu>
From: David J Birnbaum
Date: Wed, 18 Jul 2007 00:30:50 -0400
Dear Conal (cc Council),
In my last message I neglected to respond directly to a possible
misunderstanding. You wrote:
> OK I figured it was this consideration (parsimony) that was the
> motivation, and that makes sense.
My proposed model is relatively parsimonious (one attribute instead of
three), but my primary consideration wasn't parsimony (I'm a fast
typist, so a few extra characters don't really affect my efficiency),
but accuracy. With three attributes instead of one, where the attribute
names may need to be similar or identical, one has three times as much
opportunity for error.
Cheers,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 00:30:54 EDT
From laurent.romary at loria.fr Wed Jul 18 01:56:51 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 18 Jul 2007 07:56:51 +0200 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <1184731005.9326.197.camel@localhost> Message-ID: <77AFC0D1-B491-4662-983A-2B05FB1DE7F3@loria.fr>
From: Laurent Romary
Date: Wed, 18 Jul 2007 07:56:51 +0200
And so do I! The more we can simplify the content models of divisions
the better...
Cheers,
Laurent
Le 18 juil. 07 ? 05:56, Conal Tuohy a ?crit :
> On Tue, 2007-07-17 at 14:40 -0400, John A. Walsh wrote:
>> Syd,
>>
>> I understand the issue, and I prefer option A, which allows for
>> cleaner and more elegant content models. I don't see a compelling
>> need to refer to head, opener, salute, epigraph separately from the
>> other elements with which they would be grouped in divTop.
>>
>> John
>
> I agree with John.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 01:58:43 EDT
From mjd at hum.ku.dk Wed Jul 18 03:22:23 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Wed, 18 Jul 2007 09:22:23 +0200 Subject: [tei-council] next mtg In-Reply-To: <[tei-council] next mtg> Message-ID: <5FA95E40EE2AD51190380090272724BB0FEC9EC2@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Wed, 18 Jul 2007 09:22:23 +0200
I can do 2 August as well. It would be nice if we could actually hear each
other.
Matthew
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU
[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of Daniel
O'Donnell
Sent: Tuesday, July 17, 2007 3:42 PM
To: Dot Porter
Cc: TEI Council
Subject: Re: [tei-council] next mtg
I'll make it work for me.
On Tue, 2007-07-17 at 09:34 -0400, Dot Porter wrote:
> That works for me.
>
> Dot
>
> On 7/17/07, Syd Bauman edu> wrote:
> > Sorry, couldn't hear anything for the last minute or two. May I
> > suggest Thu 02 Aug as a our next conference call?
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 03:22:37 EDT
From James.Cummings at oucs.ox.ac.uk Wed Jul 18 05:21:53 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 10:21:53 +0100 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <200707171819.l6HIJ3S3002296@draco.services.brown.edu> Message-ID: <469DDBB1.8080802@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 10:21:53 +0100
Syd Bauman wrote:
> Should we have
>
> a) the common elements in divWrapper, divWrapper as part of divTop
> and divBot, thus content models refer to divTop or divBot; or
>
> b) the common elements in divWrapper, but divWrapper is not a member
> of divTop and divBot, thus content models refer to both divTop and
> divWrapper, or both divBot and divWrapper?
I can see the attractiveness of solution b, but recognise that solution a
is a lot simpler. I have a solution-a-based extension I'd like to call
solution C. Couldn't one get around this lack of ability to refer to the
non-divWrapper members of divTop by adding a third class? i.e. divTopPart
So it becomes something like:
model.divWrapper = argument byline dateline docAuthor docDate
model.divTop = model.divWrapper model.divTopPart
model.divTopPart = head opener salute epigraph
model.divBottom = model.divWrapper model.divBottomPart
model.divBottomPart = closed signed trailer ps
So the content models remain model.divTop* and model.divBottom* but you are
still able to refer to model.divTopPart or model.divBottomPart individually
should you ever need to. I recognise that this bit of indirection is
messy, but it keeps the content model simple but allows you to refer to the
head/opener/etc. elements without referring to argument/byline/etc.
Or have I missed something in my wanton abuse of the class system?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 05:21:58 EDT
From James.Cummings at oucs.ox.ac.uk Wed Jul 18 07:26:09 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 12:26:09 +0100 Subject: [tei-council] tei stemma model In-Reply-To: <469CCA99.2050005@pitt.edu> Message-ID: <469DF8D1.2070803@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 12:26:09 +0100
Dear David and Council,
Apologies in advance for a long rambling and incoherent post. I sympathise
with many of the concerns that David expresses, especially those of the
character restrictions on @xml:id and the dangerous opportunities for
inconsistency.
The kind of proposal I'm sure could also be used for most stemmata I've
seen. See for example one of the typical Chaucerian ones,
http://computerphilologie.uni-muenchen.de/jg03/robinson-abb07.gif used to
display variant frequency.
However, I think the better solution has got to be the one which is more
consistent with the Guidelines as a whole. I'm also concerned that we are
just expressing the existing tree structure of the tree/root/iNode/leaf
elements in a different form. Would it be better if this were revised to
allow the nesting structure similar to that which David suggests? (But this
would push it to P5 1.1 I'm assuming.)
The proposal as it stands has several problems. As Conal has pointed out
the use of @n instead of @xml:id and @target(s). While I understand
David's desire for simplicity since that is less error prone, I have to
agree with Conal. I don't think that we should ever be using sigil as a
node identifier, to me it is a text-based label. Hence, any restrictions
on @xml:id don't really apply. Anyone wanting to construct manuscript
stemmata will be happy to have a witList somewhere. Thus I would be
recommending that any node being referred to have an @xml:id and use
@key/@corresp/or similar to itself refer to its own metadata (witList).
I think using
From James.Cummings at oucs.ox.ac.uk Wed Jul 18 07:37:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 12:37:52 +0100 Subject: [tei-council] Minutes from yesterday's meeting Message-ID: <469DFB90.8020406@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 12:37:52 +0100
Dear TEI Council,
The first initial draft of the minutes from yesterday's meeting. Please do
feel free to provide any corrections. They were hastily written so I'm
sure I've got some things wrong. Make sure to double check any action
items assigned to you and ALL, making sure that you understand the action,
and the due date is that which was agreed in the electronic blizzard which
was our teleconference.
See:
http://www.tei-c.org/Council/tcm32.xml?style=printable
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 07:37:57 EDT
From dporter at uky.edu Wed Jul 18 08:12:19 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 18 Jul 2007 08:12:19 -0400 Subject: [tei-council] Minutes from yesterday's meeting In-Reply-To: <469DFB90.8020406@oucs.ox.ac.uk> Message-ID: <96f3df640707180512v21f66344kb1fd2869d6b24eeb@mail.gmail.com>
From: Dot Porter
Date: Wed, 18 Jul 2007 08:12:19 -0400
Hi James,
Thanks for getting these up so quickly.
1) I didn't leave early (that was last meeting)
That's all.
Dot
On 7/18/07, James Cummings ox.ac.uk> wrote:
> Dear TEI Council,
>
> The first initial draft of the minutes from yesterday's meeting. Please do
> feel free to provide any corrections. They were hastily written so I'm
> sure I've got some things wrong. Make sure to double check any action
> items assigned to you and ALL, making sure that you understand the action,
> and the due date is that which was agreed in the electronic blizzard which
> was our teleconference.
>
> See:
>
> http://www.tei-c.org/Council/tcm32.xml?style=printable
>
> -James
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 08:12:24 EDT

From Syd_Bauman at Brown.edu Wed Jul 18 08:50:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 18 Jul 2007 08:50:11 -0400 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <469DDBB1.8080802@oucs.ox.ac.uk> Message-ID: <18078.3203.425357.33866@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 18 Jul 2007 08:50:11 -0400
JW> [a]
LB> [a]
CT> [a]
LR> [a]
JC> model.divWrapper = argument byline dateline docAuthor docDate
JC> model.divTop = model.divWrapper model.divTopPart
JC> model.divTopPart = head opener salute epigraph
JC> model.divBottom = model.divWrapper model.divBottomPart
JC> model.divBottomPart = closed signed trailer ps
Absolutely! I proposed this as a straw-man "overkill" solution last
time around, but since no one bit (including myself), didn't even
bother with it this time.
One of the reasons I'm kinda glad everyone is going for solution (a)
is that we can leave the classes as they are now, and if & when we
ever decide we do need to refer to 'em, we can create divTopPart w/o
having to muck with content models.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 08:50:15 EDT
From James.Cummings at computing-services.oxford.ac.uk Wed Jul 18 09:27:17 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 14:27:17 +0100 Subject: [tei-council] Minutes from yesterday's meeting In-Reply-To: <96f3df640707180512v21f66344kb1fd2869d6b24eeb@mail.gmail.com> Message-ID: <469E1535.4010607@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 14:27:17 +0100
Dot Porter wrote:
> Hi James,
>
> Thanks for getting these up so quickly.
>
> 1) I didn't leave early (that was last meeting)
*doh* that was mean just copying that section from last time and editing.
I do apologise. I've also changed where it said Laurent left early as well
and resubmitted to perforce.
-James
>
> That's all.
>
> Dot
>
> On 7/18/07, James Cummings ox.ac.uk> wrote:
>> Dear TEI Council,
>>
>> The first initial draft of the minutes from yesterday's meeting.
>> Please do
>> feel free to provide any corrections. They were hastily written so I'm
>> sure I've got some things wrong. Make sure to double check any action
>> items assigned to you and ALL, making sure that you understand the
>> action,
>> and the due date is that which was agreed in the electronic blizzard
>> which
>> was our teleconference.
>>
>> See:
>>
>> http://www.tei-c.org/Council/tcm32.xml?style=printable
>>
>> -James
>>
>> --
>> Dr James Cummings, Oxford Text Archive, University of Oxford
>> James dot Cummings at oucs dot ox dot ac dot uk
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 09:27:23 EDT

From James.Cummings at computing-services.oxford.ac.uk Wed Jul 18 09:30:38 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 14:30:38 +0100 Subject: [tei-council] divWrapping: summary and question In-Reply-To: <18078.3203.425357.33866@emt.wwp.brown.edu> Message-ID: <469E15FE.8040101@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 14:30:38 +0100
Syd Bauman wrote:
> JW> [a]
> LB> [a]
> CT> [a]
> LR> [a]
>
> JC> model.divWrapper = argument byline dateline docAuthor docDate
> JC> model.divTop = model.divWrapper model.divTopPart
> JC> model.divTopPart = head opener salute epigraph
> JC> model.divBottom = model.divWrapper model.divBottomPart
> JC> model.divBottomPart = closed signed trailer ps
>
> Absolutely! I proposed this as a straw-man "overkill" solution last
> time around, but since no one bit (including myself), didn't even
> bother with it this time.
Ah, maybe that is why it seemed fairly familiar to me.
> One of the reasons I'm kinda glad everyone is going for solution (a)
> is that we can leave the classes as they are now, and if & when we
> ever decide we do need to refer to 'em, we can create divTopPart w/o
> having to muck with content models.
Ok, I'm happy to go with solution a) then with the proviso that we should
re-examine it before P5 1.1. ;-)
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 18 2007 - 09:30:43 EDT
From djbpitt+tei at pitt.edu Wed Jul 18 09:47:51 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 18 Jul 2007 09:47:51 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <469DF8D1.2070803@oucs.ox.ac.uk> Message-ID: <469E1A07.6070403@pitt.edu>
From: David J Birnbaum
Date: Wed, 18 Jul 2007 09:47:51 -0400
Dear James (cc Council),
> However, I think the better solution has got to be the one which is more
> consistent with the Guidelines as a whole. I'm also concerned that we are
> just expressing the existing tree structure of the tree/root/iNode/leaf
> elements in a different form. Would it be better if this were revised to
> allow the nesting structure similar to that which David suggests? (But this
> would push it to P5 1.1 I'm assuming.)
>
I may have misunderstood, but since is already part of the Graph
chapter and already has the nesting structure I propose, I think we can
already allow that nesting structure if we use the existing to
do it. That is, a solution more consistent with the Guidelines as a
whole than my original version could use out of the box and make
the changes in attribute use that you and Conal have advocated. The only
substantial structural feature not currently present is a way of
representing contamination, but adding another element should not
inflict any damage on the existing graphing model (i.e., could be
undertaken easily and without substantial delay).
> I think using
> of nested eTree nodes might be useful.
>
This sounds like the best way to incorporate group labels, especially
because 1) it's already in place and 2) it doesn't conflict with labels
for individual nodes (retrievable from @n or by dereferencing
@key/@corresp/or something similar). In my own work I tend to refer to
groups by the label on their parent (so that, for example, I would refer
to the "beta branch of the tradition" to identify the subtree rooted at
beta), but if one wishes to assign a different name to the group as a
whole than to its root node in the stemma,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Aside from changing the @n attributes to references to spurious @xml:id
> attributes, an my labelling of groups, is much intellectual content lost?
>
In addition to the differences you note (changing @n to @xml:id, adding
group labels), you've also changed @target to @targets (presumably so
that it can contain more than one target, should a node contaminate more
than one other node) and you've divided between @xml:id and @corresp the
duties are shared by @n in my original model. Thus, the node that serves
as the target of pointing in your example has both of those attributes,
@corresp to point to a presumed elsewhere and @xml:id so
that @targets on another element can point to it. Other nodes have only
@corresp; they do not need an @xml:id since they are not the targets of
pointing from elements.
The only change to intellectual content is the addition of group labels,
which may be useful and which my original model did not support at all.
The change of @n to @xml:id and @corresp is, as you note, consistent
with TEI practice elsewhere. One possible additional cost (on top of
general parsimony and reduced opportunity for error with my model, which
I mentioned earlier) is that users may need to draw a stemma where they
do not have corresponding elements elsewhere. Since your
model doesn't record the sigla in the stemma itself, it requires that
users record them elsewhere, even when an (or witness
list or something similar) may otherwise not be needed, so that the
indirection and additional markup may be required not by the
informational goals of the author, but by the construction of the
schema. I appreciate that this additional cost may also seem worthwhile
if it buys greater consistency with general TEI practice. I don't
understand, though, how specifying multiple targets of contamination all
on one element is more TEI-like than specifying each
target in a separate element. There is no informational
difference between the two models, but, as noted above, using a separate
element for each instance of contamination models
iconically that each instance of contamination in the tradition is
independent of each other instance (which is true, or we would be
asserting that the contamination occurred at a different level in the
stemma).
> In having skimmed through some more of the trees and graphs section of the
> Guidelines, I'd like to suggest that anything significantly more
> complicated than David's proposal be held back until P5 1.1. Moreover,
> that when planning P5 1.1 that a significant re-examination of the current
> graph/tree provision be undertaken.
>
I read the Graphs chapter of the Guidelines for the first time (and the
second, and the third, etc.) when I was working on this proposal, and it
left me with the impression that, as in many other places, the TEI may
have decided to allow multiple ways of doing the same thing. I'm not
enough of a mathematician to be able to call this "impression" a
"conclusion" (in some cases the different models supported by the Graph
chapter clearly have different intellectual properties, and in other
cases they may have different properties that I do not understand), but
if we're going to revisit this chapter down the road, I think it's good
policy in general to provide multiple strategies only when they have
different informational content (that is, not when they are merely
notational variants of one another). Readers may find the following
useful when considering this issue, which arises frequently in TEI-land:
http://www.idealliance.org/papers/extreme/proceedings/html/2002/Usdin01/EML2002Usdin01.html
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 09:47:56 EDT
From James.Cummings at computing-services.oxford.ac.uk Wed Jul 18 10:15:24 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 18 Jul 2007 15:15:24 +0100 Subject: [tei-council] tei stemma model In-Reply-To: <469E1A07.6070403@pitt.edu> Message-ID: <469E207C.3080207@computing-services.oxford.ac.uk>
From: James Cummings
Date: Wed, 18 Jul 2007 15:15:24 +0100
David J Birnbaum wrote:
> Dear James (cc Council),
>
>> However, I think the better solution has got to be the one which is more
>> consistent with the Guidelines as a whole.
> I may have misunderstood, but since is already part of the Graph
> chapter and already has the nesting structure I propose, I think we can
> already allow that nesting structure if we use the existing to
> do it.
I was referring to the use of @xml:id instead of @n there.
> The only
> substantial structural feature not currently present is a way of
> representing contamination, but adding another element should not
> inflict any damage on the existing graphing model (i.e., could be
> undertaken easily and without substantial delay).
Yes, I have no problem with adding the element. (Though I
suppose the concept provided by the element name is a bit specialised to
this use, I have no better suggestions at the moment.)
> This sounds like the best way to incorporate group labels, especially
> because 1) it's already in place and 2) it doesn't conflict with labels
> for individual nodes (retrievable from @n or by dereferencing
> @key/@corresp/or something similar). In my own work I tend to refer to
> groups by the label on their parent (so that, for example, I would refer
> to the "beta branch of the tradition" to identify the subtree rooted at
> beta), but if one wishes to assign a different name to the group as a
> whole than to its root node in the stemma,
> place to record that name.
Should then eTree leaf nodes also have their own
From djbpitt+tei at pitt.edu Wed Jul 18 10:59:35 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 18 Jul 2007 10:59:35 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <469E207C.3080207@computing-services.oxford.ac.uk> Message-ID: <469E2AD7.8050301@pitt.edu>
From: David J Birnbaum
Date: Wed, 18 Jul 2007 10:59:35 -0400
Dear James (cc Council),
>> The only
>> substantial structural feature not currently present is a way of
>> representing contamination, but adding another element should not
>> inflict any damage on the existing graphing model (i.e., could be
>> undertaken easily and without substantial delay).
>>
>
> Yes, I have no problem with adding the element. (Though I
> suppose the concept provided by the element name is a bit specialised to
> this use, I have no better suggestions at the moment.)
>
For what it's worth, I chose "contaminates" (verb) rather than
"contamination" because I thought the former made the directionality
clear. That is, if a parent contains a element, it
suggests that the parent is the contaminator. If it contains a
element, it leaves open whether it is the contaminator
or the contaminatee. This isn't a major problem (the @target attribute
disambiguates in any case), but I tend to forget the names I assign to
objects, so I try to make them as mnemonic and self-explanatory as I can.
> Should then eTree leaf nodes also have their own
> user is not pointing back with @corresp to some msDescription (or similar)?
>
What I liked about your use of
From lou.burnard at computing-services.oxford.ac.uk Wed Jul 18 12:47:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 18 Jul 2007 17:47:03 +0100 Subject: [tei-council] tei stemma model In-Reply-To: <469E2AD7.8050301@pitt.edu> Message-ID: <469E4407.2040605@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 18 Jul 2007 17:47:03 +0100
Unless I'm mistaken, when this investigation of how to represent ms
stemma was first proposed, it was mostly as an exercise to see how
applicable the existing TEI model for trees and graphs is. I may be
inventing this, but my recollection is that the conversation went
something like
x: we've got this lovely way of representing graphs and networks and stuff
y: why would anyone ever want to use such a thing
x: well you could use it represent, err, airplane networks, or family
trees, or um,
y: or MANUSCRIPT TRADITIONS! wow that's really innerestink
So the exercise intended for David was really to test the capabilities
of the existing TEI model, which I think his work does rather well.
I don't have anything to add to what James has already said about
labels and the use of existing TEI styles for identification and
linkage. I do however wish to confess to a feeling of unease about
contamination.
As I understand it, this is a way of saying that a given node has one or
more parent-nodes *other* than the one it's actually attached to --
which of course means that you're not looking at a tree any more, but a
directed acyclic graph. So it cannot be represented using or
-- you need to use the more general .
I would be interested to see how David's example would play as a
Lou

the discussion about
z: David J Birnbaum wrote:
> Dear James (cc Council),
>
>>> The only
>>> substantial structural feature not currently present is a way of
>>> representing contamination, but adding another element should not
>>> inflict any damage on the existing graphing model (i.e., could be
>>> undertaken easily and without substantial delay).
>>>
>>
>> Yes, I have no problem with adding the element.
>> (Though I
>> suppose the concept provided by the element name is a bit specialised to
>> this use, I have no better suggestions at the moment.)
>>
>
> For what it's worth, I chose "contaminates" (verb) rather than
> "contamination" because I thought the former made the directionality
> clear. That is, if a parent contains a element, it
> suggests that the parent is the contaminator. If it contains a
> element, it leaves open whether it is the contaminator
> or the contaminatee. This isn't a major problem (the @target attribute
> disambiguates in any case), but I tend to forget the names I assign to
> objects, so I try to make them as mnemonic and self-explanatory as I can.
>
>> Should then eTree leaf nodes also have their own
>> user is not pointing back with @corresp to some msDescription (or
>> similar)?
>>
>
> What I liked about your use of
> node both individually and as a branch in the tradition. As I wrote
> earlier, I tend to use the same term for both, but one might reasonably
> want to refer to, say, beta as the "northern branch" of the tradition
> and gamma as the "southern branch," so that ones need to label a node
> both "beta" and "northern branch." In this case one could dereference a
> @corresp (or use an @n in just this limited function; it is, after all,
> a global TEI attribute, although its use in this textual function might
> represent an unacceptable retreat from the War on Attributes) to get the
> siglum but use
> descriptive. I don't see any particular need for
> leaf nodes as long as we can get their identifiers by dereferencing
> @corresp or through @n, but I see no reason to prohibit it. If I
> remember correctly, can always contain
> probably advise users on how they should distinguish among all these
> labeling mechanisms, though, so that we don't up leaving people
> uncertain about which strategy they should use to map a name to a node.
>
>>> One possible additional cost (on top of
>>> general parsimony and reduced opportunity for error with my model, which
>>> I mentioned earlier) is that users may need to draw a stemma where they
>>> do not have corresponding elements elsewhere. Since your
>>> model doesn't record the sigla in the stemma itself, it requires that
>>> users record them elsewhere, even when an (or witness
>>> list or something similar) may otherwise not be needed, so that the
>>> indirection and additional markup may be required not by the
>>> informational goals of the author, but by the construction of the
>>> schema.
>>>
>>
>> What if they nest
>>
>>
>> (...)
>>
>>
>>
>>
>> I
>>
>> X
>>
>>
>>
>> ?
>>
>>
>
> This should work, although it may cause confusion about how one labels
> an intermediary node that has both its own name and the name of a branch
> of the tradition. I've been advocating @n, but, of course, that means
> putting character data into an attribute value, which is something that
> we try not to do.
>
> Cheers,
>
> David
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 12:47:09 EDT

From djbpitt+tei at pitt.edu Wed Jul 18 13:26:20 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 18 Jul 2007 13:26:20 -0400 Subject: [tei-council] tei stemma model In-Reply-To: <469E4407.2040605@computing-services.oxford.ac.uk> Message-ID: <469E4D3C.6080203@pitt.edu>
From: David J Birnbaum
Date: Wed, 18 Jul 2007 13:26:20 -0400
Dear Lou (cc James, Council),
I may have translated the assignment from "describe a stemma using only
the limited set of tools you have in front of you" into "describe a
stemma in the best way possible, and then we'll see how to integrate
that into the TEI." In any case, I was inclined toward an -like
solution because contamination both is and isn't parentage, which led me
to conclude not that a contaminated stemma isn't a tree (although that's
a fair way to look at it), but that it's a tree with one other type of
relationship tacked on.
The existing TEI , with and , could describe a
stemma, since a stemma is a special type of graph and the existing model
is more than sufficiently powerful, but I think it's a clumsy tool for
the job. If we consider what we might want to do with a stemma other
than render it, one possibility is that we might want to use it for the
semi-automated evaluation of variation. I think this type of possibility
is the most exciting aspect of the whole enterprise, and the sort of
thing that makes humanities computing interesting even to philologists
who may not otherwise be interested in computing.
For example, suppose we have the stemma in my sample (you've all
memorized it by now, right? :-) ) and the following variation in an edition:

Chocolate
Peanut butter

According to stemmatic principles, the reading in alpha was "Peanut
butter," and "Chocolate" was introduced in delta. If, on the other hand,
we have:

Chocolate
Peanut butter

the "vote" is still two-to-four, but here we have a crux, since one
reading goes back to beta and the other to gamma, and the stemma doesn't
help us determine which goes back, in turn, to alpha.
If we've taken an approach, we can examine the text() nodes of
the elements for each element and for each element
find the youngest common parent (in the stemma) of the manuscripts cited
in the @wit attribute. If they are at the same depth in the stemma, we
have a crux, and the stemma cannot resolve which is primary. If,
however, the youngest common parent of one is deeper in the tree than
the lowest common parent of the other, the former is the error and the
latter can be projected back to alpha.
This is difficult but manageable XSLT/XPath programming with an
-like model. With the // model, on the other
hand, it becomes much more complicated. It isn't impossible (after all,
the // model can be transformed into the
model), but if we were going to try to build something like this for
production, I think we agree on which model has the greater engineering
advantages (by far). I'd like to see the TEI Guidelines say something
like "here's The Best Way to represent a stemma because in addition to
describing the graph [which one could do in a variety of ways], it also
lets one automate some of the analysis of variation, and that's part of
what humanities computing is all about."
With this in mind, I see no reason not to enhance the model with
a feature. It doesn't get in the way for those who are
modeling true trees, and it lets us use the structure for
modeling stemmata, which I think makes those models much more useful for
textual analysis than would be the case under the //
approach.
Cheers,
David
Lou Burnard wrote:
> Unless I'm mistaken, when this investigation of how to represent ms
> stemma was first proposed, it was mostly as an exercise to see how
> applicable the existing TEI model for trees and graphs is. I may be
> inventing this, but my recollection is that the conversation went
> something like
> x: we've got this lovely way of representing graphs and networks and
> stuff
> y: why would anyone ever want to use such a thing
> x: well you could use it represent, err, airplane networks, or family
> trees, or um,
> y: or MANUSCRIPT TRADITIONS! wow that's really innerestink
>
> So the exercise intended for David was really to test the capabilities
> of the existing TEI model, which I think his work does rather well.
>
> I don't have anything to add to what James has already said about
> labels and the use of existing TEI styles for identification and
> linkage. I do however wish to confess to a feeling of unease about
> contamination.
>
> As I understand it, this is a way of saying that a given node has one
> or more parent-nodes *other* than the one it's actually attached to --
> which of course means that you're not looking at a tree any more, but
> a directed acyclic graph. So it cannot be represented using or
> -- you need to use the more general .
>
> I would be interested to see how David's example would play as a
>
> Lou
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 18 2007 - 13:26:23 EDT
From Syd_Bauman at Brown.edu Thu Jul 19 20:35:48 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Jul 2007 20:35:48 -0400 (EDT) Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <46977D39.2000900@computing-services.oxford.ac.uk> Message-ID: <200707200035.l6K0ZmCM013186@draco.services.brown.edu>
From: Syd Bauman
Date: Thu, 19 Jul 2007 20:35:48 -0400 (EDT)
SB> In Berlin the TEI Council requested the creation of a new element,
SB> , which would replace the special-purpose
SB> element. Was part of the point of this exercise to eliminate the
SB> special-purpose , , and as well, using (e.g.)
SB> or some such instead?
LB> No, I don't think so.
Check. Anyone else have a useful recollection on this?

LB> The specific elements are permitted as children of
LB> as an alternation to text.
Yes, right, this is currently the case, but I do not think text
should be permissible in the content of . I cannot come
up with a good reason to use use an element that groups measurements
with anything other than elements from model.measureLike, let alone
plain text, as its content. Can you provide an example of how this is
useful? (But note that I am explicitly saying the in the simple case
of
7 x 12
it is not useful.)

LB> As I remember the discussion, we recognises that most
LB> institutions would always supply dimensions in their own specific
LB> sequence, and might not want therefore to tag the height etc.
LB> explicitly.
I don't remember any such conclusion, and don't think it is a good
reason to violate the principle of what a <*Grp> element is. Is it
really that tough to use
7 12
instead of
7x12
? Perhaps I'm being a holier-than-thou bigot here, but I don't see
anything wrong with telling those institutions who always do supply
dimensions in their own specific order "too bad, you have to
explicitly say which is which anyway" (at least, if you want to use
).

LB> Compare the element, which just knows that you give lat and
LB> long in that order.
Indeed. As far as I can tell, is underspecified[1], but even it
gives a default order: latitude then longitude. The imagined use of
here doesn't even specify a default order, so that if I
come across "7x12" I don't know which is height and which is width,
or if one of them is actually depth. In manuscript description these
terms are defined, and the difference matters, no?

SB> ... ... has traded in its quantity= attribute for an
SB> extent= attribute.
LB> I agree "extent" is a slightly strange name for this: how about
LB> @count?
Well, count= is certainly better than extent=. But it is really only
correct for measurements of countable things like "1 dozen roses"; it
still isn't quite right for uncountables, like "66.95 mL", or even
"12 in". I think the right attribute name is "quantity".
The Brown STG element upon which the P5 0.5
element was based used count= -- one of the few improvements we made
was to change the name of this attribute to quantity=. It was a good
idea then, and I still think it is.

SB> ... the "suggested values include" list for unit= has lost all
SB> the suggested values that don't make sense when measuring a page.
LB> The international standard is referenced, and I've certainly no
LB> objection to adding a few more examples taken from it
While I think a few more examples is far better than none, what I
don't understand is why not all of them? Why make a poor user go off
and read SI or NIST documentation, rather than just give her a nearly
comprehensive list of values? When she goes to enter a unit=, oXygen
would pop up the list with its glosses and descriptions, and she can
easily discover that she should use "kg", not "Kg" for kilograms, and
"in", not "inch" for inches.

SB> * move back to att.measurement
LB> Cant see anything to be gained by doing this, other than the
LB> confusion of now having two classes with the same meaning
But my point is that they don't have the same meaning. One is general
purpose for which commodity= and a long "semi" list of possible
values makes sense, but for which scope= is at least underspecified,
if it makes sense at all; the other is very special-purpose, for
which commodity= is always already known, scope= makes sense, and the
list of possible values should be quite limited.
This is a case where splitting is more helpful to the end user than
lumping.

SB> * remove text from content of ? (if it seems important,
SB> put model.pLike in?)
LB> Not a good idea in my view, for reasons given above
I disagree. I cannot see any reason why
136 folios:
280 x 190 .
Twenty-three quires of eight ...
is significantly superior to
136 folios: 280 x 190.
Twenty-three quires of eight ...
If one is going to bother putting a in, then why not
make it useful for processing:
136 folios:

280
190
.
Twenty-three quires of eight ...

Notes
-----
[1] Many, if not most, users will want to know what syntax to use for
expressing latitude and longitude. WGS 84, as far as I can tell,
provides no guidance here at all. Are they expressed as degrees,
minutes, and seconds, or as decimal degrees? With compass
direction, or using signed values? What symbols, if any, are used
to indicate the unit(s)? What separates the latitude from the
longitude? But for that matter, these TEI guys use "2" to mean
"female", maybe they want longitude expressed in radians (but if
so, signed values < pi or unsigned < 2*pi? :-)
While I'm at it, I noticed that is a member of
att.declarable, but that is not a member of att.declaring;
is the presumption that all of the s in a given

will
always use the same ?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 19 2007 - 20:35:52 EDT
From Syd_Bauman at Brown.edu Fri Jul 20 01:37:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Jul 2007 01:37:11 -0400 Subject: [tei-council] Minutes from yesterday's meeting In-Reply-To: <469DFB90.8020406@oucs.ox.ac.uk> Message-ID: <18080.18951.137124.832295@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 20 Jul 2007 01:37:11 -0400
Nice and fast job James, thanks.
I don't know for sure what was actually said during the con call, but
I have been acting up to now (and at this point, can't really change
course) as if the due dates for "move postscript to a free standing
ODD" and "make concrete proposal with regard to merging of Corpus
chapter into DS or teiCorpus/teiGroup" due dates are the reverse of
what you have posted. I expect to have the ODD ready
tomorrow. That will give Council a few days to check it and decide
whether or not they like it, and then will give me a few days to put
it back in and it can be completed well before 08-01.
As for moving teiCorpus into DS, I'll poke around at it on Monday ...
if we have a concrete proposal to discuss on 08-02, great. If not,
it'll have to wait until 1.1.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 01:37:16 EDT
From arianna.ciula at kcl.ac.uk Fri Jul 20 05:26:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Jul 2007 10:26:32 +0100 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <200707200035.l6K0ZmCM013186@draco.services.brown.edu> Message-ID: <46A07FC8.2010405@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 20 Jul 2007 10:26:32 +0100
Syd Bauman wrote:
> SB> In Berlin the TEI Council requested the creation of a new element,
> SB> , which would replace the special-purpose
> SB> element. Was part of the point of this exercise to eliminate the
> SB> special-purpose , , and as well, using (e.g.)
> SB> or some such instead?
>
> LB> No, I don't think so.
>
> Check. Anyone else have a useful recollection on this?
This is what I have in my notes from Berlin:
=============================
Manuscript Description.
DOD: use of extent/dimensions compared to measure (to be constrained
within this chapter); LB: chapter that lack integration with the class
model; redefinition of height and width (as special cases of measure)
and dimensions could be a grouped measure (all in measureLike class). We
would have particular constraints for the manuscript module (e.g. Always
height and width within the measurement group).
==============================
DOD: Dan
LB: Lou
not sure it helps...
Arianna
>
>
> LB> The specific elements are permitted as children of
> LB> as an alternation to text.
>
> Yes, right, this is currently the case, but I do not think text
> should be permissible in the content of . I cannot come
> up with a good reason to use use an element that groups measurements
> with anything other than elements from model.measureLike, let alone
> plain text, as its content. Can you provide an example of how this is
> useful? (But note that I am explicitly saying the in the simple case
> of
> 7 x 12
> it is not useful.)
>
>
> LB> As I remember the discussion, we recognises that most
> LB> institutions would always supply dimensions in their own specific
> LB> sequence, and might not want therefore to tag the height etc.
> LB> explicitly.
>
> I don't remember any such conclusion, and don't think it is a good
> reason to violate the principle of what a <*Grp> element is. Is it
> really that tough to use
> 7 12
> instead of
> 7x12
> ? Perhaps I'm being a holier-than-thou bigot here, but I don't see
> anything wrong with telling those institutions who always do supply
> dimensions in their own specific order "too bad, you have to
> explicitly say which is which anyway" (at least, if you want to use
> ).
>
>
> LB> Compare the element, which just knows that you give lat and
> LB> long in that order.
>
> Indeed. As far as I can tell, is underspecified[1], but even it
> gives a default order: latitude then longitude. The imagined use of
> here doesn't even specify a default order, so that if I
> come across "7x12" I don't know which is height and which is width,
> or if one of them is actually depth. In manuscript description these
> terms are defined, and the difference matters, no?
>
>
> SB> ... ... has traded in its quantity= attribute for an
> SB> extent= attribute.
>
> LB> I agree "extent" is a slightly strange name for this: how about
> LB> @count?
>
> Well, count= is certainly better than extent=. But it is really only
> correct for measurements of countable things like "1 dozen roses"; it
> still isn't quite right for uncountables, like "66.95 mL", or even
> "12 in". I think the right attribute name is "quantity".
>
> The Brown STG element upon which the P5 0.5
> element was based used count= -- one of the few improvements we made
> was to change the name of this attribute to quantity=. It was a good
> idea then, and I still think it is.
>
>
> SB> ... the "suggested values include" list for unit= has lost all
> SB> the suggested values that don't make sense when measuring a page.
>
> LB> The international standard is referenced, and I've certainly no
> LB> objection to adding a few more examples taken from it
>
> While I think a few more examples is far better than none, what I
> don't understand is why not all of them? Why make a poor user go off
> and read SI or NIST documentation, rather than just give her a nearly
> comprehensive list of values? When she goes to enter a unit=, oXygen
> would pop up the list with its glosses and descriptions, and she can
> easily discover that she should use "kg", not "Kg" for kilograms, and
> "in", not "inch" for inches.
>
>
> SB> * move back to att.measurement
>
> LB> Cant see anything to be gained by doing this, other than the
> LB> confusion of now having two classes with the same meaning
>
> But my point is that they don't have the same meaning. One is general
> purpose for which commodity= and a long "semi" list of possible
> values makes sense, but for which scope= is at least underspecified,
> if it makes sense at all; the other is very special-purpose, for
> which commodity= is always already known, scope= makes sense, and the
> list of possible values should be quite limited.
>
> This is a case where splitting is more helpful to the end user than
> lumping.
>
>
> SB> * remove text from content of ? (if it seems important,
> SB> put model.pLike in?)
>
> LB> Not a good idea in my view, for reasons given above
>
> I disagree. I cannot see any reason why
>
> 136 folios:
> 280 x 190 .
> Twenty-three quires of eight ...
>
> is significantly superior to
>
> 136 folios: 280 x 190.
> Twenty-three quires of eight ...
>
> If one is going to bother putting a in, then why not
> make it useful for processing:
>
> 136 folios:
>
> 280
> 190
> .
> Twenty-three quires of eight ...
>
>
> Notes
> -----
> [1] Many, if not most, users will want to know what syntax to use for
> expressing latitude and longitude. WGS 84, as far as I can tell,
> provides no guidance here at all. Are they expressed as degrees,
> minutes, and seconds, or as decimal degrees? With compass
> direction, or using signed values? What symbols, if any, are used
> to indicate the unit(s)? What separates the latitude from the
> longitude? But for that matter, these TEI guys use "2" to mean
> "female", maybe they want longitude expressed in radians (but if
> so, signed values < pi or unsigned < 2*pi? :-)
> While I'm at it, I noticed that is a member of
> att.declarable, but that is not a member of att.declaring;
> is the presumption that all of the s in a given
will
> always use the same ?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 05:26:44 EDT
From arianna.ciula at kcl.ac.uk Fri Jul 20 05:37:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Jul 2007 10:37:32 +0100 Subject: [tei-council] tei stemma model In-Reply-To: <469E2AD7.8050301@pitt.edu> Message-ID: <46A0825C.7030103@kcl.ac.uk>
From: Arianna Ciula
Date: Fri, 20 Jul 2007 10:37:32 +0100
David J Birnbaum wrote:
> For what it's worth, I chose "contaminates" (verb) rather than
> "contamination" because I thought the former made the directionality
> clear. That is, if a parent contains a element, it
> suggests that the parent is the contaminator. If it contains a
> element, it leaves open whether it is the contaminator
> or the contaminatee. This isn't a major problem (the @target attribute
> disambiguates in any case), but I tend to forget the names I assign to
> objects, so I try to make them as mnemonic and self-explanatory as I can.
This is like a special case of a element, isn't it - expect
it cannot have @mutual - ?
type="type of contamination"
name="contamination"
active="#??"
passive="#A"/>
By the way, I have enjoyed reading this proposal. It is elegant and has
a very well exemplified concrete application.
To be honest though I don't know enough about the chapter where it
should be integrated into...so I don't have very useful comments.
Arianna
>
>> Should then eTree leaf nodes also have their own
>> user is not pointing back with @corresp to some msDescription (or
>> similar)?
>>
>
> What I liked about your use of
> node both individually and as a branch in the tradition. As I wrote
> earlier, I tend to use the same term for both, but one might reasonably
> want to refer to, say, beta as the "northern branch" of the tradition
> and gamma as the "southern branch," so that ones need to label a node
> both "beta" and "northern branch." In this case one could dereference a
> @corresp (or use an @n in just this limited function; it is, after all,
> a global TEI attribute, although its use in this textual function might
> represent an unacceptable retreat from the War on Attributes) to get the
> siglum but use
> descriptive. I don't see any particular need for
> leaf nodes as long as we can get their identifiers by dereferencing
> @corresp or through @n, but I see no reason to prohibit it. If I
> remember correctly, can always contain
> probably advise users on how they should distinguish among all these
> labeling mechanisms, though, so that we don't up leaving people
> uncertain about which strategy they should use to map a name to a node.
>
>>> One possible additional cost (on top of
>>> general parsimony and reduced opportunity for error with my model, which
>>> I mentioned earlier) is that users may need to draw a stemma where they
>>> do not have corresponding elements elsewhere. Since your
>>> model doesn't record the sigla in the stemma itself, it requires that
>>> users record them elsewhere, even when an (or witness
>>> list or something similar) may otherwise not be needed, so that the
>>> indirection and additional markup may be required not by the
>>> informational goals of the author, but by the construction of the
>>> schema.
>>>
>>
>> What if they nest
>>
>>
>> (...)
>>
>>
>>
>>
>> I
>>
>> X
>>
>>
>>
>> ?
>>
>>
>
> This should work, although it may cause confusion about how one labels
> an intermediary node that has both its own name and the name of a branch
> of the tradition. I've been advocating @n, but, of course, that means
> putting character data into an attribute value, which is something that
> we try not to do.
>
> Cheers,
>
> David
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 05:37:52 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jul 20 07:40:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Jul 2007 12:40:48 +0100 Subject: [tei-council] datestamping guidelines Message-ID: <46A09F40.4010307@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 20 Jul 2007 12:40:48 +0100
while the guidelines are in flux, you
may appreciate the addition of the
datestamp at the bottom of (eg)
http://tei.oucs.ox.ac.uk/P5/Guidelines-web-beta/en/html/ref-unclear.html
the generation job checks every 10 minutes to see
if anything has changed.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 07:40:51 EDT
From Syd_Bauman at Brown.edu Fri Jul 20 10:57:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Jul 2007 10:57:56 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <46A07FC8.2010405@kcl.ac.uk> Message-ID: <18080.52596.252189.704754@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 20 Jul 2007 10:57:56 -0400
> This is what I have in my notes from Berlin:
> DOD: use of extent/dimensions compared to measure (to be
> constrained within this chapter); LB: chapter that lack integration
> with the class model; redefinition of height and width (as special
> cases of measure) and dimensions could be a grouped measure (all in
> measureLike class). We would have particular constraints for the
> manuscript module (e.g. Always height and width within the
> measurement group).
Thank you so much, Arianna! This does seem to imply we had not
planned to nuke , , and .
It does sound like we might have intended to use a Schematron rule to
enforce the ( height, width, depth? ) content model of
iff it is inside a manuscript description. But my over-imaginative
mind thinks that is not strict enough a condition for which to
enforce this: what if you have a manuscript that actually has a blood
pressure or a location in the sky (indicated with altitude and
azimuth) in its incipit? Would it be reasonable to say within a
?

In any case, the important issue here is that it is a bad idea to
hamstring the general purpose in order to make it better
fit in with the special purpose .
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 10:58:01 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jul 20 12:34:36 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Jul 2007 17:34:36 +0100 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <18080.52596.252189.704754@emt.wwp.brown.edu> Message-ID: <46A0E41C.2040000@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 20 Jul 2007 17:34:36 +0100
Syd Bauman wrote:
>
> But my over-imaginative
> mind thinks that is not strict enough a condition for which to
> enforce this: what if you have a manuscript that actually has a blood
> pressure or a location in the sky (indicated with altitude and
> azimuth) in its incipit? Would it be reasonable to say within a
> ?
Manuscripts do not have blood pressure, nor are they located in the sky
(or at least, if they are, we don't catalogue them.)
I am sorry, but none of your arguments convinces me Syd. You are trying
to complexify a very simple requirement quite needlessly.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 12:40:54 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Jul 20 12:46:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Jul 2007 17:46:13 +0100 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <46A0E41C.2040000@computing-services.oxford.ac.uk> Message-ID: <46A0E6D5.9060306@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 20 Jul 2007 17:46:13 +0100
Lou Burnard wrote:
>
> Manuscripts do not have blood pressure, nor are they located in the
> sky (or at least, if they are, we don't catalogue them.)
ooh, you manuscript people are *so* stick-in-the-mud.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 12:46:18 EDT
From dporter at uky.edu Fri Jul 20 12:52:43 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 20 Jul 2007 12:52:43 -0400 Subject: [tei-council] facsimile odd In-Reply-To: <469AB48E.2030304@computing-services.oxford.ac.uk> Message-ID: <96f3df640707200952m17a72ef2u4fb4f17b2dbf50c3@mail.gmail.com>
From: Dot Porter
Date: Fri, 20 Jul 2007 12:52:43 -0400
I'm returning to Lou's original commentary on the facsimile markup,
and I'll intersperse Conal's responses as well.
On 7/15/07, Lou Burnard oxford.ac.uk> wrote:
> Unless I've grossly misunderstood it, Conal's proposal may be summarized
> as follows:
>
> a) we define a new element , a member of model.sourceDescPart
> b) we define a new attribute class, att.projection and make a
> member of it, along with a small number of other existing "container"
> elements like

, , and . Dot also proposes an attribute @coords.
> c) we define a new element , a member of model.graphicLike
> d) is used as a wrapper for one or more s, each
> representing a page image; it can also contain s which define
> particular zones within the page.
> e) can point into text transcript by means of special attribute
> @start (indicates a ); s point to elements in the transcript
> using @corresp
>
Yes.
> And here, probably revealing the grossness of my understanding, are some
> comments on each of the above points:
>
> a) I don't think this element belongs in sourceDesc. If contains
> the images constituting a digital facsimile, then it isn't metadata
> about that facsimile, it *is* the facsimile. I might want to record in
> the sourceDesc other things (e.g. where I nicked the images from) which
> wouldn't form part of the facsimile proper.
CT>But to my mind, the tei:pg elements ARE descriptions of the source
CT>material. I could be misinterpreting this though, I admit.
I'm with Conal on this, I think. sourceDesc is a description of the
source material. "Source material" could be a manuscript, a scroll, a
gravestone, what have you. A facsimile of the source is not the same
thing as the source - a facsimile is metadata about the source. I'd
say that does belong in sourceDesc, however this doesn't mean it
doesn't also make sense to have it at the same level as .
Perhaps it should be allowed in both places? Similar to msDescription,
where you can have them both in the header and in the body.
> b) the class seems to combine two different kinds of attribute: ones
> like @top and @right which define where something else is within a
> graphic; and ones like @xscale and @rotate which define how a graphic is
> to be rendered in a given context. I really don't understand how these
> attributes are intended to be used though.
CT>You are right that this is perhaps overly complicated. The idea was to
CT>allow textual elements to be identified as being e.g. oriented vertically or
CT>diagonally on the page, etc.
CT>But a simplification would be to distribute the attributes
differently between
CT>the 2 attribute classes like so:
CT>att.projection should define scale factors and rotation. The members of this
CT>class should be the model.graphicLike elements which are children of the
CT>tei:pg elements. The projection attributes would define the mapping between
CT>the physical page and the various tei:graphic images of that page.
CT>att.coordinates would define the location of textual elements (or tei:area
CT>elements, which are the stand-off proxies of textual elements) within a page.
I have nothing to add to Conal's comments, this all makes sense to me.
I like his simplification.
> c) doesn't make much sense except with reference to a ;
> it can't therefore be a member of model.graphicLike, since this would
> allow it to stand in place of a
This is definitely an issue. I understand Conal's reply (see just
below) and my understanding is that the att.projection attributes, on
the s that are children of , will map from the s
(either children of or in the text) to the s in the
header [or wherever ends up]. This system should also work in the
simple case where there is only one image per source. though I would
prefer a recommendation for @url on when there is only one image
per source.
CT>I would say that an which was the child of a

, for instance,
CT>would make sense with reference to the images of the page,
CT>which are just the s which are children of the which points
CT>to the which precedes the

CT>e.g. schematically:
CT>
CT>
CT>
CT>...
CT>
CT>...
CT>

CT>
CT> A square picture of something
CT>

> d) seems rather restrictive (not to say unpronounceable) as a name:
> could I use it, for example, to wrap images of Sebastian's gravestones?
I really don't like the name for this element. Syd, Martin and I
suggested changing this to or but as Conal
replied to that suggestion:
CT>As I see it, the point of is to
CT>model the flat surfaces on which texts are inscribed (call them pages
CT>or not).
We need to make it clear that this element is not only for book or
manuscript pages but also for inscribed surfaces, scrolls, stone
crosses, graffiti on walls.... anything with text written on it.
Conal suggests or , both of which are fine with me
and much better than , though on first thought I prefer
> Is the only difference between a and an that one corresponds
> with a conventional visual unit -- the page -- and the other with any
> arbitrary subsection of it? suppose each of my images shows a 2-page
> spread: would each one be a with each page image being an ?
To which Conal replied
CT>No, you'd have 2 elements, each containing the same tei:graphic/@url
CT>value, but the graphics would have different graphical offsets with
respect to the
CT> which enclosed them. The right-hand page would have a big
negative @left
CT>offset to indicate that a vertical line down the centre of the
graphic corresponded
CT>to the left edge of the page.
Replacing with would mean that an editor would have to
make a decision on this point, I think. The "surface" of a 2-page
spread could be both pages, with used to differentiate between
them, or one could say that is each individual page and
proceed as Conal suggests above. It seems to me that this really is an
editorial decision and the approach would depend on the type of source
material - a "true" 2-page spread vs. one page of text leading to
another page of text.
> e) why two different attributes for pointing into the text? How do I
> point from text into image?
>
Here you are referring to @start (points from to ) and
@corresp (points from to text). I don't recall why we have
@start in addition to @corresp on , unless it was simply to make
clear the 1:1 relationship between and .
One of the limitations of the proposal as I see it is that the
pointing is in one direction - from the head/facsimile into the
encoded text. To point from the text to the image would require
@corresp and perhaps @coords on elements in the text that point to the
xml:id of (or whatever we call it) groupings of s in the
facsimile list. In cases where there is only one set of source images
with image files referenced directly on using @url this is even
simpler, and one only use @coords if one wishes to point to areas
within an image.

*****************
Now on to Lou's concrete suggestions
> I haven't got very far trying to answer these questions, but as far as I
> have I'd like to suggest that
> (1) we should be thinking of defining a different element to contain a
> collection of digital images, which would be analogous to the existing
> element: let's call it for the moment. A can appear
> where a (but not a ) can in the TEI model.
As stated above, I agree that is not a good element name and that
an equivalent grouping element should be available in place of ,
but it should also be available in the header (preferably in
) as a facsimile is metadata and not the source itself.
> (2) It contains one or more elements defining a two dimensional
> space which is represented in the facsimile
> (3) a contains one or more elements, each of which
> gives a visual representation of the zone in question, using differing
> scales, rotations etc.
> (4) a may also optionally contain other s, each of which
> contains a visual representation of some subset of the parent zone,
> again possibly using different scales or rotations.
I'm not sure how I feel about , especially nested s. If we
are talking about representing regions of a page (surface) I would
much rather talk about coordinate areas pointing to a (or a
group of s with some mapping system to ensure that the
coordinates point to the same regions of the different images) rather
than several different s. This is pretty much what METS does
and it is also how functions in this current proposal. Any
coordinate area one would want from a page could be identified as an
- there isn't a need to nest anything.
Another option - which Conal has mentioned in other posts and which I
will say more about below - is to allow a @coords attribute directly
on elements in the rather than having to rely on a separate
list of in the header/facsimile list.
> (5) alignment of image and text is done throughout using existing TEI
> mechanisms -- i.e. we use @corresp to point from one to the other, or we
> use a standoff alignment map.
>
I agree that we should use existing TEI mechanisms whenever possible,
and one way to do that is to use @corresp to link from elements up/out
to (or ) elements that define the locations of the
content of those elements on the (or ). But I do think
that we should have @coords allowed directly on elements in the
(such as , , , ). One, people are already
doing this (Edition Production Technology does this, and I know of
several projects that are using this tool. If people are using the
tool, they will use whatever markup it requires). Second, it's
relatively simple, especially if your project only has one set of
image files. No need for separate indexes or lists. Third, @coords as
an attribute is already defined in METS (and I believe they take it
from HTML 4). So we aren't just inventing something (though that never
stopped us before.

> Please tell me if this is far too simplistic an approach -- it doesn't
> seem to me a million miles away from the proposal we have though.
>
Well, I'm really sorry about the length of my post and I hope some of
you are still awake :-) I think we have the makings of a great
recommendation and I'm very sorry I haven't been more vocal as this is
something I think is vitally important to include in P5 1.0. I hope
my comments will be useful.
Dot

> Lou
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 12:52:46 EDT

From daniel.odonnell at uleth.ca Fri Jul 20 14:45:25 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Jul 2007 12:45:25 -0600 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <18080.52596.252189.704754@emt.wwp.brown.edu> Message-ID: <1184957125.7034.7.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 20 Jul 2007 12:45:25 -0600
Was not a point that there was a mix of text and children possible in
measure?
As I remember the discussion is was largely to try and make dimensions
machine-usable.
Did you not record the meeting Syd?
On Fri, 2007-07-20 at 10:57 -0400, Syd Bauman wrote:
> > This is what I have in my notes from Berlin:
> > DOD: use of extent/dimensions compared to measure (to be
> > constrained within this chapter); LB: chapter that lack integration
> > with the class model; redefinition of height and width (as special
> > cases of measure) and dimensions could be a grouped measure (all in
> > measureLike class). We would have particular constraints for the
> > manuscript module (e.g. Always height and width within the
> > measurement group).
>
> Thank you so much, Arianna! This does seem to imply we had not
> planned to nuke , , and .
>
> It does sound like we might have intended to use a Schematron rule to
> enforce the ( height, width, depth? ) content model of
> iff it is inside a manuscript description. But my over-imaginative
> mind thinks that is not strict enough a condition for which to
> enforce this: what if you have a manuscript that actually has a blood
> pressure or a location in the sky (indicated with altitude and
> azimuth) in its incipit? Would it be reasonable to say within a
> ?
>
>
> In any case, the important issue here is that it is a bad idea to
> hamstring the general purpose in order to make it better
> fit in with the special purpose .
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 14:45:30 EDT
From Syd_Bauman at Brown.edu Fri Jul 20 14:56:30 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Jul 2007 14:56:30 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <46A0E41C.2040000@computing-services.oxford.ac.uk> Message-ID: <18081.1374.7738.533975@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 20 Jul 2007 14:56:30 -0400
> I am sorry, but none of your arguments convinces me Syd. You are
> trying to complexify a very simple requirement quite needlessly.
So you would just have have its limited content model
anywhere in an ?
BTW, I consider this a tangent: I still think the important thing is
to restore the general-purpose to its previous more useful
state, regardless of what happens to the special-purpose uses in
.
(And, for the record, I was talking about MSs that talk about blood
pressures, not those that have them. I actually had the manuscripts
to Harvey's _Exercitatio Anatomica de Motu Cordis et Sanguinis in
Animalibus_ in mind, but (a) he measured blood quantity, not blood
pressure, and (b) I just checked, and according to Wikipeidia his
manuscripts were destroyed during the English Civil War.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 14:56:35 EDT
From Syd_Bauman at Brown.edu Fri Jul 20 15:00:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Jul 2007 15:00:44 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <1184957125.7034.7.camel@localhost> Message-ID: <18081.1628.704192.916624@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 20 Jul 2007 15:00:44 -0400
> Was not a point that there was a mix of text and children possible
> in measure?
I'm sorry, I don't understand what you're getting at, Dan.

> As I remember the discussion is was largely to try and make
> dimensions machine-usable.
Right, which is part of why I think allowing text inside
is a step in the wrong direction.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 15:00:48 EDT

From daniel.odonnell at uleth.ca Fri Jul 20 15:26:43 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Jul 2007 13:26:43 -0600 Subject: [tei-council] tei stemma model In-Reply-To: <469E4D3C.6080203@pitt.edu> Message-ID: <1184959603.9520.7.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 20 Jul 2007 13:26:43 -0600
Having followed this discussion, I'd say:
a) I think David has lived up to what we asked: shown how we could
represent a stemma within the existing TEI and some slight modifications
b) Despite the advantages enunciated for a heavily packed @n, I really
think Conal and James are right about the TEI and even XML-ness of using
ids for ids. David's issue with repetition of sigla-as-id in other
places can be addressed in other ways within the TEI if necessary. Even
a Linkgroup could keep track of them.
c) I like the ID label.
d) I would be less happy with a constraint on contaminates that
restricted the pointer to one idref: while it is true that
contaminations from the same tradition/manuscript can be different
impulses, they can also repeat themselves identically. I think we need
to be able to use both multiple idrefs or multiple contaminates.
This raises the interesting question of whether it is worthwhile trying
to capture information I know about each act of contamination: if I am
going to have multiple instances, presumably I am doing this for a
reason. Is there space for a note or something on this element?
e) For 5.0, I wonder if a basic version of David's proposal as modified
by Conal and James is not eminently doable. I think there may be
additional implications to contaminates that we won't see or solve in
the next week, but I think we definitely have the makings of an
extremely useful development.
On Wed, 2007-07-18 at 13:26 -0400, David J Birnbaum wrote:
> Dear Lou (cc James, Council),
>
> I may have translated the assignment from "describe a stemma using only
> the limited set of tools you have in front of you" into "describe a
> stemma in the best way possible, and then we'll see how to integrate
> that into the TEI." In any case, I was inclined toward an -like
> solution because contamination both is and isn't parentage, which led me
> to conclude not that a contaminated stemma isn't a tree (although that's
> a fair way to look at it), but that it's a tree with one other type of
> relationship tacked on.
>
> The existing TEI , with and , could describe a
> stemma, since a stemma is a special type of graph and the existing model
> is more than sufficiently powerful, but I think it's a clumsy tool for
> the job. If we consider what we might want to do with a stemma other
> than render it, one possibility is that we might want to use it for the
> semi-automated evaluation of variation. I think this type of possibility
> is the most exciting aspect of the whole enterprise, and the sort of
> thing that makes humanities computing interesting even to philologists
> who may not otherwise be interested in computing.
>
> For example, suppose we have the stemma in my sample (you've all
> memorized it by now, right? :-) ) and the following variation in an edition:
>
>
> Chocolate
> Peanut butter
>
>
> According to stemmatic principles, the reading in alpha was "Peanut
> butter," and "Chocolate" was introduced in delta. If, on the other hand,
> we have:
>
>
> Chocolate
> Peanut butter
>
>
> the "vote" is still two-to-four, but here we have a crux, since one
> reading goes back to beta and the other to gamma, and the stemma doesn't
> help us determine which goes back, in turn, to alpha.
>
> If we've taken an approach, we can examine the text() nodes of
> the elements for each element and for each element
> find the youngest common parent (in the stemma) of the manuscripts cited
> in the @wit attribute. If they are at the same depth in the stemma, we
> have a crux, and the stemma cannot resolve which is primary. If,
> however, the youngest common parent of one is deeper in the tree than
> the lowest common parent of the other, the former is the error and the
> latter can be projected back to alpha.
>
> This is difficult but manageable XSLT/XPath programming with an
> -like model. With the // model, on the other
> hand, it becomes much more complicated. It isn't impossible (after all,
> the // model can be transformed into the
> model), but if we were going to try to build something like this for
> production, I think we agree on which model has the greater engineering
> advantages (by far). I'd like to see the TEI Guidelines say something
> like "here's The Best Way to represent a stemma because in addition to
> describing the graph [which one could do in a variety of ways], it also
> lets one automate some of the analysis of variation, and that's part of
> what humanities computing is all about."
>
> With this in mind, I see no reason not to enhance the model with
> a feature. It doesn't get in the way for those who are
> modeling true trees, and it lets us use the structure for
> modeling stemmata, which I think makes those models much more useful for
> textual analysis than would be the case under the //
> approach.
>
> Cheers,
>
> David
>
> Lou Burnard wrote:
> > Unless I'm mistaken, when this investigation of how to represent ms
> > stemma was first proposed, it was mostly as an exercise to see how
> > applicable the existing TEI model for trees and graphs is. I may be
> > inventing this, but my recollection is that the conversation went
> > something like
> > x: we've got this lovely way of representing graphs and networks and
> > stuff
> > y: why would anyone ever want to use such a thing
> > x: well you could use it represent, err, airplane networks, or family
> > trees, or um,
> > y: or MANUSCRIPT TRADITIONS! wow that's really innerestink
> >
> > So the exercise intended for David was really to test the capabilities
> > of the existing TEI model, which I think his work does rather well.
> >
> > I don't have anything to add to what James has already said about
> > labels and the use of existing TEI styles for identification and
> > linkage. I do however wish to confess to a feeling of unease about
> > contamination.
> >
> > As I understand it, this is a way of saying that a given node has one
> > or more parent-nodes *other* than the one it's actually attached to --
> > which of course means that you're not looking at a tree any more, but
> > a directed acyclic graph. So it cannot be represented using or
> > -- you need to use the more general .
> >
> > I would be interested to see how David's example would play as a
> >
> > Lou
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 15:26:47 EDT
From daniel.odonnell at uleth.ca Fri Jul 20 15:32:32 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Jul 2007 13:32:32 -0600 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <18081.1628.704192.916624@emt.wwp.brown.edu> Message-ID: <1184959952.9520.18.camel@localhost>
From: Daniel O'Donnell
Date: Fri, 20 Jul 2007 13:32:32 -0600
This may be a slightly different issue, then: but I remember a
discussion about whether any of the following were a good idea:
>
> 2 pounds of flesh
> ??10-11-6d
> 2 merks of old extent
The reason was that the units are lost for all time as far as the
computer is concerned. I think this then led to the case of MS
dimensions and Lat and Long (didn't this actually start at the meeting
with our attempts to encode things like rivers)?
-d
On Fri, 2007-07-20 at 15:00 -0400, Syd Bauman wrote:
> > Was not a point that there was a mix of text and children possible
> > in measure?
>
> I'm sorry, I don't understand what you're getting at, Dan.
>
>
> > As I remember the discussion is was largely to try and make
> > dimensions machine-usable.
>
> Right, which is part of why I think allowing text inside
> is a step in the wrong direction.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 20 2007 - 15:32:35 EDT
From djbpitt+tei at pitt.edu Fri Jul 20 15:48:28 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 20 Jul 2007 15:48:28 -0400 Subject: [tei-council] xml table modeling Message-ID: <46A1118C.7090008@pitt.edu>
From: David J Birnbaum
Date: Fri, 20 Jul 2007 15:48:28 -0400
Dear TEI Council,
Some of you may remember that I woke up suddenly in the middle of one of
the Berlin meetings and blurted out, with characteristic understatement,
something about how the existing TEI table model is "all wrong" because
it is too preoccupied with presentation, contradicting the general TEI
(and XML) preference for descriptive markup. After the meetings I went
home and did a bit of research and development, the results of which are at:
http://clover.slavic.pitt.edu/~djb/2007_xml-tables/2007_xml-tables.html
I'll be presenting this at the Extreme Markup conference next month, but
because we discussed some of the ideas in the Council meeting, even if
only briefly, I thought some of you might be interested in seeing where
it has led. I think this report introduces a useful mechanism for the
descriptive modeling of tables, which is currently missing from the TEI
guidelines, but I don't have a strong opinion about whether such a model
should be incorporated into P5. In other words, this isn't a proposal
that requires an official response from Council; it's just a report
about an issue that arose in passing during our last meeting, which
Council may or may not consider constructive, either in general or in
the context of preparing P5 for release later this year.
For what it's worth, I think the impetus for both my proposed table
model and my proposed stemma model is the same. Tables and stemmata both
have conspicuous and distinctive graphic features that may distract us
from truly descriptive markup, by which I mean markup that is designed
with an eye toward encoding the semantics of the object being modeled,
irrespective of its physical appearance during rendering. Both the table
model and the stemma model attempt to concentrate on descriptive markup
in this sense.
Best,
David

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 15:48:33 EDT

From lou.burnard at computing-services.oxford.ac.uk Fri Jul 20 16:34:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Jul 2007 21:34:11 +0100 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <18081.1374.7738.533975@emt.wwp.brown.edu> Message-ID: <46A11C43.8090406@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Fri, 20 Jul 2007 21:34:11 +0100
Syd Bauman wrote:
>> I am sorry, but none of your arguments convinces me Syd. You are
>> trying to complexify a very simple requirement quite needlessly.
>>
>
> So you would just have have its limited content model
> anywhere in an ?
>
>
I don't know what you mean by "limited content model". At present the
content model for measureGrp is (text|model.measureLike)*
It would be better if it were (text | (model.measureLike)+) but as you
know we're not allowed to do that in XML
> BTW, I consider this a tangent: I still think the important thing is
> to restore the general-purpose to its previous more useful
> state, regardless of what happens to the special-purpose uses in
> .
>
>
These are not special purpose uses. For every one hypothetical person
who might conceivably want to encode a measurement of blood pressure *as
a measurement* (rather than just leave it in the text) there are
countless others who want to record the dimensions of a manuscript. Why
make life miserable for those users we know we have for the sake of the
few you might like to imagine we might have?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 16:40:31 EDT
From Syd_Bauman at Brown.edu Fri Jul 20 22:35:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Jul 2007 22:35:02 -0400 Subject: [tei-council] oversimplification: isn't measured In-Reply-To: <46A11C43.8090406@computing-services.oxford.ac.uk> Message-ID: <18081.28886.227195.627031@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 20 Jul 2007 22:35:02 -0400
I have a very strong feeling we are talking at cross purposes, here.
So let me reiterate the important points:
* The element should have a quantity= attribute, not
extent= (and preferably not count=, although that's a lot better
than extent=).
* Either someone should do some work deciding what scope= means for a
generic , or it shouldn't have a scope= attribute.
* The "suggested values include" list for unit= of should
be pretty much as all-encompassing as we can get it.
I do not see how to reconcile these needs with the attribute needs of
the three special purpose measurements, , , and
,
* which should not have commodity=
* which should have scope=
* for which extent= is as good as quantity=
* for which the "suggested values include" list should be very
limited
without having separate attribute classes.

Perhaps I'll post later about the less important bits
later.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Jul 20 2007 - 22:35:07 EDT

From Syd_Bauman at Brown.edu Sat Jul 21 13:07:30 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 21 Jul 2007 13:07:30 -0400 Subject: [tei-council] fre-standing ODD for (postscript) now up Message-ID: <18082.15698.660504.829837@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 21 Jul 2007 13:07:30 -0400
The free-standing ODD for the proposed element is now available
in http://www.tei-c.org/Drafts/ps/. Once again, the schemas provided
include
among the possible root elements in order to make
testing easy.
It would be nice if we could make a decision about incorporating this
into the Guidelines reasonably soon.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jul 21 2007 - 13:07:35 EDT
From Syd_Bauman at Brown.edu Sun Jul 22 13:20:32 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 22 Jul 2007 13:20:32 -0400 Subject: [tei-council] appInfo In-Reply-To: <46934398.1080100@oucs.ox.ac.uk> Message-ID: <18083.37344.212779.726666@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 22 Jul 2007 13:20:32 -0400
An excerpt from the ODD at
http://tei.oucs.ox.ac.uk/P5/Test/testappinfo.odd:
|
|
|
|
|
|
|
|
|
|
|

This example shows an appInfo tag describing an application
| called the Image Markup Tool, which has declared an interest in
| two sections of the file, and which last saved the file on June 6
| 2006.


|
I gather the idea is that IMT 1.5 would have only one
element, rather than one element for every time it
mucked with the file. Is that right?
In either case, is that date on notAfter= supposed to match the date
in the prose?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 22 2007 - 13:20:36 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 22 14:02:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 22 Jul 2007 19:02:34 +0100 Subject: [tei-council] appInfo In-Reply-To: <18083.37344.212779.726666@emt.wwp.brown.edu> Message-ID: <46A39BBA.7050309@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 22 Jul 2007 19:02:34 +0100
Syd Bauman wrote:
> I gather the idea is that IMT 1.5 would have only one
> element, rather than one element for every time it
> mucked with the file. Is that right?
>
that is my assumption, yes. its a snapshot, not
an incremental set of s.
> In either case, is that date on notAfter= supposed to match the date
> in the prose?
>
yes. a typo....

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 22 2007 - 14:02:38 EDT
From daniel.odonnell at uleth.ca Sun Jul 22 20:46:29 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 22 Jul 2007 18:46:29 -0600 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart Message-ID: <1185151589.6627.4.camel@localhost>
From: Daniel O'Donnell
Date: Sun, 22 Jul 2007 18:46:29 -0600
Hi all,
Here is the first of two proposals relating to my concerns around choice
and app/rdg:
http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
I'm still working on the app/rdg one but hope to have it up soon.
In summary, the proposal linked to above suggests:
1. removing restore from model.pPartTranscriptional and placing it
in the parent model.pPartEdit
2. creating a new class model.restorePart to contain the relatively
limited number of elements from macro.paraContent that restore
can logically affect
3. removing app from model.pPartTranscriptional and placing it in
model.listLike
4. removing choice from model.pPartEditorial and placing it in the
parent model.pPartEdit
5. getting rid of model.pPartEditorial and
model.pPartTranscriptional (all of the contents of which after
the revisions 1-4 are now also found in model.choicePart
6. redefining the membership of model.pPartEdit to contain: choice,
restore, and model.choicePart
The reasoning and advantages of these changes are discussed in the
document. There are also some other suggestions for changes in language,
etc.
I had almost proposed removing seg from model.choicePart and replacing
it with a new phrase level element named something like option or
alternative as the generic case (this is because a series of segs are
not obviously alternatives normally), but decided against it for the
time being because this may be of broader application.
-dan
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Jul 22 2007 - 20:48:06 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 23 06:27:02 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 23 Jul 2007 11:27:02 +0100 Subject: [tei–council] facsimile odd –– what is a facsimile? In-Reply-To: <96f3df640707200952m17a72ef2u4fb4f17b2dbf50c3@mail.gmail.com> Message-ID: <46A48276.9080308@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 23 Jul 2007 11:27:02 +0100
Thanks Dot for your comments. If I may, I'd like to address what seem to
be the chief issues in separate messages. I will start with the one I
feel more strongly about than the others.
Dot Porter wrote:
>
LB >> a) I don't think this element belongs in sourceDesc. If contains
>> the images constituting a digital facsimile, then it isn't metadata
>> about that facsimile, it *is* the facsimile. I might want to record in
>> the sourceDesc other things (e.g. where I nicked the images from) which
>> wouldn't form part of the facsimile proper.
>
> CT>But to my mind, the tei:pg elements ARE descriptions of the source
> CT>material. I could be misinterpreting this though, I admit.
>
> I'm with Conal on this, I think. sourceDesc is a description of the
> source material. "Source material" could be a manuscript, a scroll, a
> gravestone, what have you. A facsimile of the source is not the same
> thing as the source - a facsimile is metadata about the source.

The syllogism seems to be:
* A facsimile is not the same thing as the source.
* Metadata is not the same thing as the source.
* Therefore A facsimile is metadata.
But of course this is a fine example of an "undistributed middle"!
One of my most prized books is the Hinman facsimile edition of the First
Folio. This hefty volume consists of page images of the 1623 folio, with
modern metadata (line numbering) added, modern (well, early 20th c.)
introductory matter, title page, back matter etc. It also has its own
metadata -- who printed it, when and where -- quite distinct from the
information about Isaac Iaggard and others responsible for the 1623
volume which it reproduces. For example, like other facsimile editions,
this one makes a fairly eclectic selection from the available surviving
first folio sources -- it doesn't claim to reproduce any specific copy,
but tells you which copies have been used for which pages. Even in the
case where there is a unique original, as Andrew Prescott tells us,
facsimiles can vary greatly in their relationship to it, and thus there
is always some degree of description needed about the facsimile itself,
distinct from the source it purports to represent.
In fact, it seems to me the relationship between a transcription of a
source and the original is almost identical to the relationship between
a facsimile of it and the original. One translates a reading letter by
letter, and the other translates a reading dot by dot, but they are both
readings and as such I would like to give them the same ontological
standing in my encoding.
In addition to this philosophical argument, let us not forget that for
every one TEI-encoded digital text out there, there are probably a
thousand digital facsimiles. Surely the TEI ought to be offering a way
of encoding digital facsimile editions as well as digital
transcriptions? There are quite a few places where the TEI Header is
used to stock metadata about both kinds of digital object. Wouldn't it
be nice to offer a way of growing one kind into the other without doing
violence to the basic TEI model?
If we are going to have markup which describes the page images
themselves, as digital objects, then the set of page images constituting
a work isa kind of "text" itself and should be treated as such. In
short: my proposal is
a) add a new element (or better word if we can think of one)
b) change the content model of and of to permit
(text|facsimile) where they currently permit
Note that I am not proposing a class model.textLike because I cannot
think of any other kind of thing that might go in there -- I'd suggest
that talking books, if we want to digitize them, are another form of
facsimile.

DP: I'd
> say that does belong in sourceDesc, however this doesn't mean it
> doesn't also make sense to have it at the same level as .
> Perhaps it should be allowed in both places? Similar to msDescription,
> where you can have them both in the header and in the body.
>
I can see why the "bung em in the header" policy is convenient, for
example in the case where you just have a few page images to illustrate
particularly vexing parts of your manuscript, so I am ready to concede
this as a possibility. But I still think it's Wrong with a capital R.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 23 2007 - 06:27:06 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon Jul 23 07:11:42 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 23 Jul 2007 12:11:42 +0100 Subject: [tei–council] facsimile odd –– what is a facsimile? In-Reply-To: <46A48276.9080308@computing-services.oxford.ac.uk> Message-ID: <46A48CEE.7000407@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 23 Jul 2007 12:11:42 +0100
Lou Burnard wrote:

> If we are going to have markup which describes the page images
> themselves, as digital objects, then the set of page images constituting
> a work isa kind of "text" itself and should be treated as such. In
> short: my proposal is
> a) add a new element (or better word if we can think of one)
> b) change the content model of and of to permit
> (text|facsimile) where they currently permit
>
> Note that I am not proposing a class model.textLike because I cannot
> think of any other kind of thing that might go in there -- I'd suggest
> that talking books, if we want to digitize them, are another form of
> facsimile.
For the record I have no strong objections to this method. I've been
thinking of facsimile images as a form of tei:surrogates, and we should
document how tei:surrogates (which is a metadata element) relates to the
content of your proposed tei:facsimile
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 07:11:46 EDT

From dporter at uky.edu Mon Jul 23 07:50:30 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 23 Jul 2007 07:50:30 -0400 Subject: [tei–council] facsimile odd –– what is a facsimile? In-Reply-To: <46A48CEE.7000407@computing-services.oxford.ac.uk> Message-ID: <96f3df640707230450u58cc1aa5y16ef404e83d1217e@mail.gmail.com>
From: Dot Porter
Date: Mon, 23 Jul 2007 07:50:30 -0400
Lou, I have no objection either. In fact, following a brief phone
conversation with Syd over the weekend, I would like to publicly
acknowledge the error of my ways and support the proposal to add a new
(or whatever we call it) element that is roughly parallel
to text.
If you have a look at the Draft Recommendations for TEI Facsimiles
(authored by Richard Gartner and Lou back in the Dark Age of 2001, and
summarized on the Legacy Facsimile Markup wiki page:
http://www.tei-c.org.uk/wiki/index.php/LegacyFacsimileMarkup#Draft_Recommendations_for_TEI_Digital_Facsimiles),
the proposal is roughly equivalent to part of that
previous recommendation (which proposes using separate TEI elements
instead of creating a new element).
Dot
On 7/23/07, James Cummings
oxford.ac.uk> wrote:
> Lou Burnard wrote:
>
>
> > If we are going to have markup which describes the page images
> > themselves, as digital objects, then the set of page images constituting
> > a work isa kind of "text" itself and should be treated as such. In
> > short: my proposal is
> > a) add a new element (or better word if we can think of one)
> > b) change the content model of and of to permit
> > (text|facsimile) where they currently permit
> >
> > Note that I am not proposing a class model.textLike because I cannot
> > think of any other kind of thing that might go in there -- I'd suggest
> > that talking books, if we want to digitize them, are another form of
> > facsimile.
>
> For the record I have no strong objections to this method. I've been
> thinking of facsimile images as a form of tei:surrogates, and we should
> document how tei:surrogates (which is a metadata element) relates to the
> content of your proposed tei:facsimile
>
> -James
>
> --
> Dr James Cummings, Oxford Text Archive, University of Oxford
> James dot Cummings at oucs dot ox dot ac dot uk
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 07:50:35 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 23 09:51:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 23 Jul 2007 14:51:01 +0100 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <1185151589.6627.4.camel@localhost> Message-ID: <46A4B245.70003@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 23 Jul 2007 14:51:01 +0100
These proposals look interesting, but since they overlap in subject
matter at least with proposals from Matthew Driscoll, which first
appeared at our Berlin meeting, I think we should probably review the
latter first. I've put Matthew's note up at
http://www.tei-c.org/Drafts/edInt.xml
Briefly (and they are very brief), he proposes
a) a new grouping element for the special case where an
and a are to be understood as one action
b) use of to indicate the supplied part of an expanded
abbreviation
c) a new element to mark specifically editorial (i.e. not
physically visible in the source) interventions. If the intervention is
an addition or deletion, should be used in preference to
or ; if a substitution, then the element contains a and
pair like
Comments?

> Hi all,
>
> Here is the first of two proposals relating to my concerns around choice
> and app/rdg:
> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
>
> I'
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 23 2007 - 09:51:07 EDT

From James.Cummings at computing-services.oxford.ac.uk Mon Jul 23 10:30:57 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 23 Jul 2007 15:30:57 +0100 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <46A4B245.70003@computing-services.oxford.ac.uk> Message-ID: <46A4BBA1.8050206@computing-services.oxford.ac.uk>
From: James Cummings
Date: Mon, 23 Jul 2007 15:30:57 +0100
>I've put Matthew's note up at
> http://www.tei-c.org/Drafts/edInt.xml
>
> Briefly (and they are very brief), he proposes
>
> a) a new grouping element for the special case where an
> and a are to be understood as one action
Seems reasonable as a way of grouping these two actions.
> b) use of to indicate the supplied part of an expanded
> abbreviation
>
> c) a new element to mark specifically editorial (i.e. not
> physically visible in the source) interventions. If the intervention is
> an addition or deletion, should be used in preference to
> or ; if a substitution, then the element contains a and
> pair like
So where an editor had supplied the word 'foo' that would be:

I wrote the word: foo

instead of:

I wrote the word: foo

?
The difference from choice when doing
foobar will certainly need more
explanation. (If I'm understanding it, the difference is with choice you
are meant to make that choice and choose one, whereas with edInt you have
equal access to one/both/none depending on your need?)
I suppose is out of the question instead of ?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 10:31:03 EDT
From arianna.ciula at kcl.ac.uk Mon Jul 23 11:04:48 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 23 Jul 2007 16:04:48 +0100 Subject: [tei–council] facsimile odd –– what is a facsimile? In-Reply-To: <46A48276.9080308@computing-services.oxford.ac.uk> Message-ID: <46A4C390.5070408@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 23 Jul 2007 16:04:48 +0100
Lou Burnard wrote:
> In fact, it seems to me the relationship between a transcription of a
> source and the original is almost identical to the relationship between
> a facsimile of it and the original. One translates a reading letter by
> letter, and the other translates a reading dot by dot, but they are both
> readings and as such I would like to give them the same ontological
> standing in my encoding.
I fully agree with this and therefore with the proposal of having a
no-mainly-textual representation encoded as the equivalent of
rather than metadata, since the tei header will be useful to encode the
description of this image-based representation instead.
I am not sure is the best term, but can't suggest anything
better to represent a more general 'material' alternative to a textual
edition.
Arianna
>
> In addition to this philosophical argument, let us not forget that for
> every one TEI-encoded digital text out there, there are probably a
> thousand digital facsimiles. Surely the TEI ought to be offering a way
> of encoding digital facsimile editions as well as digital
> transcriptions? There are quite a few places where the TEI Header is
> used to stock metadata about both kinds of digital object. Wouldn't it
> be nice to offer a way of growing one kind into the other without doing
> violence to the basic TEI model?
>
> If we are going to have markup which describes the page images
> themselves, as digital objects, then the set of page images constituting
> a work isa kind of "text" itself and should be treated as such. In
> short: my proposal is
> a) add a new element (or better word if we can think of one)
> b) change the content model of and of to permit
> (text|facsimile) where they currently permit
>
> Note that I am not proposing a class model.textLike because I cannot
> think of any other kind of thing that might go in there -- I'd suggest
> that talking books, if we want to digitize them, are another form of
> facsimile.
>
>
>
> DP: I'd
>> say that does belong in sourceDesc, however this doesn't mean it
>> doesn't also make sense to have it at the same level as .
>> Perhaps it should be allowed in both places? Similar to msDescription,
>> where you can have them both in the header and in the body.
>>
>
> I can see why the "bung em in the header" policy is convenient, for
> example in the case where you just have a few page images to illustrate
> particularly vexing parts of your manuscript, so I am ready to concede
> this as a possibility. But I still think it's Wrong with a capital R.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 11:05:01 EDT
From arianna.ciula at kcl.ac.uk Mon Jul 23 11:06:19 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 23 Jul 2007 16:06:19 +0100 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <46A4B245.70003@computing-services.oxford.ac.uk> Message-ID: <46A4C3EB.10206@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 23 Jul 2007 16:06:19 +0100
Lou Burnard wrote:
> c) a new element to mark specifically editorial (i.e. not
> physically visible in the source) interventions. If the intervention is
> an addition or deletion, should be used in preference to
> or ; if a substitution, then the element contains a and
> pair like
I think lots of people (especially modernists) will be happy to see a
proposed differentiation between authorial and editorial interventions.
Arianna
>
> Comments?
>
>
>> Hi all,
>>
>> Here is the first of two proposals relating to my concerns around choice
>> and app/rdg:
>> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
>>
>>
>> I'
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 11:06:19 EDT
From dporter at uky.edu Mon Jul 23 11:08:34 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 23 Jul 2007 11:08:34 -0400 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <46A4C3EB.10206@kcl.ac.uk> Message-ID: <96f3df640707230808q683b8d91t4b02bec84248130f@mail.gmail.com>
From: Dot Porter
Date: Mon, 23 Jul 2007 11:08:34 -0400
On 7/23/07, Arianna Ciula ac.uk> wrote:
> I think lots of people (especially modernists) will be happy to see a
> proposed differentiation between authorial and editorial interventions.
>
> Arianna
I agree that differentiating between authorial and editorial
interventions would be a valuable addition to the Guidelines.
Dot
> >
> > Comments?
> >
> >
> >> Hi all,
> >>
> >> Here is the first of two proposals relating to my concerns around choice
> >> and app/rdg:
> >> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
> >>
> >>
> >> I'
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> --
> Dr Arianna Ciula
> Research Associate
> Centre for Computing in the Humanities
> King's College London
> Strand
> London WC2R 2LS (UK)
> Tel: +44 (0)20 78481945
> http://www.kcl.ac.uk/cch
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 11:08:38 EDT

From laurent.romary at loria.fr Mon Jul 23 11:11:20 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 23 Jul 2007 17:11:20 +0200 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <96f3df640707230808q683b8d91t4b02bec84248130f@mail.gmail.com> Message-ID: <19608CB7-5E66-429C-9D8C-8E0EB5ED9EF9@loria.fr>
From: Laurent Romary
Date: Mon, 23 Jul 2007 17:11:20 +0200
But in the long run, arn't yesterday's editorial tomorrow's
authorial? (remember: yesterday's information tomorrow...)
Laurent
Le 23 juil. 07 ? 17:08, Dot Porter a ?crit :
> On 7/23/07, Arianna Ciula ac.uk> wrote:
>
>> I think lots of people (especially modernists) will be happy to see a
>> proposed differentiation between authorial and editorial
>> interventions.
>>
>> Arianna
>
> I agree that differentiating between authorial and editorial
> interventions would be a valuable addition to the Guidelines.
>
> Dot
>
>> >
>> > Comments?
>> >
>> >
>> >> Hi all,
>> >>
>> >> Here is the first of two proposals relating to my concerns
>> around choice
>> >> and app/rdg:
>> >> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-
>> revisions-to-choice-app-and-modelppartedit
>> >>
>> >>
>> >> I'
>> > _______________________________________________
>> > tei-council mailing list
>> > tei-council_at_lists.village.Virginia.EDU
>> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> --
>> Dr Arianna Ciula
>> Research Associate
>> Centre for Computing in the Humanities
>> King's College London
>> Strand
>> London WC2R 2LS (UK)
>> Tel: +44 (0)20 78481945
>> http://www.kcl.ac.uk/cch
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
> --
> ***************************************
> Dot Porter, University of Kentucky
> #####
> Program Coordinator
> Collaboratory for Research in Computing for Humanities
> dporter_at_uky.edu 859-257-9549
> #####
> Editorial Assistant, REVEAL Project
> Center for Visualization and Virtual Environments
> porter_at_vis.uky.edu
> ***************************************
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 23 2007 - 11:13:32 EDT
From daniel.odonnell at uleth.ca Mon Jul 23 15:03:08 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 13:03:08 -0600 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <96f3df640707230808q683b8d91t4b02bec84248130f@mail.gmail.com> Message-ID: <1185217388.25461.35.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 13:03:08 -0600
I think we need to be a little careful with Matthew's proposals: I've
long wanted some kind of emend element (i.e. something similar to edInt,
but I'm not convinced that edInt is actually different from a relatively
clear existing distinction in some of the use cases proposed:

> 1. Scribal and editorial emendations
> The elements and should be retained and used as they are
> currently, i.e for additions and deletions physically present in the
> manuscript, whether the actions of the scribe at the time of writing
> or of a later hand. A element should be added for indicating
> cases where and constitute a substitution:
>
>

my brain
> rend="overstrike">burns
> place="margin">hurts.


I like this, but I think we should see it for what it is: a
specialisation of choice (in this case, choice_at_type="substitution").
I'll deal with the claim that it is not choice below. The reason I like
this as a proposal is that semantically substitution is a recognised
example of (let's call it authorial for the moment) alterity in the
proposal. In terms of my proposal, it helps address the issue of the
janus-y pair del : add, since it provides a specific "authorial" axis
for a specialised form of choice to work along. This may also help
clarify restore, which can also be seen as a semantically specific form
of choice--albeit one that for reasons of parsimony we don't have the
"other" state explicitly mentioned.
So yup. I'd add "subst" to model.pPartEdit alongside choice and restore,
and model.choicePart. I wouldn't change model.choicePart, but you could
either just add add and del to the content model of "subst" or we could
create a class model.pPartSubstitution parallel to model.pPartRestore.
>
> The element should be retained for text now illegible or
> lost through damage but assumed originally to have been in the
> manuscript (what used to be supplied reason="illegible|damage"), and
> for the expansion of abbreviations -- these are both arguably things
> which are present in the manuscript, but where a degree of
> interpretation is required on the part of the editor.
I like this. It is a little bit more narrow than the current use of
substitution (which can also be used with gap, where the point is that
the text might NOT have been in the original), but the new semantics are
easy to explain and very clear ("This element is used to supply text
that arguably once existed in the physical witness").
It does raise the question (which also came up in Berlin), if we should
not consider whether gap is doing to much, when it represents both
physically missing material (i.e. due to a hole in the MS) and
intellectually missing material, due to editorial sampling decisions,
for example, or saute meme a meme. We could end up in a situation where
the constraint on whether supplied is used with gap is purely semantic:
if you are using gap because the text that was there is now physically
missing, use supplied to restore the text; if you are using gap to
describe text missing due to an error or a sampling decision, do not
restore with supplied.
How about if we split these two functions: for material that
once was in the text but is now lost (for which would be an
appropriate indicated of the alternate state) and for material
that was never present in the physical witness or has been omitted from
the transcription for sampling reasons. In this case, "supplied" would
be inappropriate for indicating the alternate state and "edInt" should
be used instead.
>
> Add an element, for "editorial intervention", where an editor,
> believing the manuscript to be incorrect or corrupt, supplies,
> suppresses or otherwise alters the text (note the specific means of
> indicating each of these three cases in traditional printed
> editions).
I like this (though not the name) if we consider this as basically an
"editorial" parallel to "supplied." What we are talking about here is
basically emendation. Rather than edInt what if we called it emend or
edit?
Now come the problems:
> In the first case, the editor supplies text assumed to have been
> inadvertently omitted by the scribe:
>
>

my brain hur
> cert="high">ts.


Sure. But since we also think it is an error (hurs is clearly understood
here as sic for hurts), what is wrong with and ?
>
> In the second, the editor suppresses superfluous text in the
> manuscript, for example arising through a dittography:
>
>

my brain hur
> cert="high">urts.


I suppose: but again, what about sic and corr? Again, hururts is also a
misspelling of hurts.
>
> In the third the editor corrects a misspelt word, substitutes one word
> for another, or rearranges the order of the words in the text of the
> manuscript. In this case the existing and should be used:
>
>

my
> cert="high">brianbrain hurts.


This I really disagree with. First of all, apparent we are privileging
dittography and simple omission of letters over alteration in order. In
my view all three are spelling mistakes, something we already have an
editorial tag set for describing, sic and corr. Secondly, this specific
use of edInt is quite different from the previous two: here edInt is
being used as a special kind of choice, parallel to subst (pace to
below); in the other two it is a special kind/alternate editorial form
of supplied. I think this distinction needs to be cleaned up.
>
> The resp and cert attributes may be used to indicate the person
> responsible for the addition, suppression or emendation and the degree
> of certainty. Where the reading of another witness supports the
> reconstruction the source attribute may also be used, providing for
> example the sigil of the other witness.
>
> Note: I don't think this makes or sub-types of
> , since one would frequently want both the added and deleted
> or original and emended forms to appear, whereas implies that
> only one of the two options can be used at any one time.)
Only the name "choice" suggests this. Both actual usage and the
description (narrative and the slightly erroneous version in the
Appendix indicate that choice describes alterity. A use case showing
that both options of choice can be showing is choice/abbr|expan. We
commonly print both options the first time a name that will subsequently
be abbreviated is used; after that we tend to use either abbr or expan
(without choice). So something you might very easily encode thus

> This proposal is intended for the
>
> Text Encoding Initiative
> TEI
>
Will very commonly be rendered

> This proposal is intended for the Text Encoding Initiative (TEI).

I would strongly argue that choice is to subst (and this use of edInt)
as ab is to p, and seg to any phrase element: a generic case that is
semantically and syntactically narrowed by the other options in order to
cover specific cases.
Secondly, I would strongly argue that the basic pattern of all
choiceLike elements is choice/option|option where option can be either a
child of choice or used on its own when alterity is not required--but
that options should not also be able to substitute for choice. So we
should allow this (option is a currently non-existent generic element
intended to stand for elements like abbr and expan):


or


But neither

nor





In other words, we should consider very carefully whether an element is
*either* the choiceLike container, or the optionLike option; but the
same element should not be capable of both expressing an alternate state
and directly containing options expressing alternate states.
>

On Mon, 2007-07-23 at 11:08 -0400, Dot Porter wrote:
> On 7/23/07, Arianna Ciula ac.uk> wrote:
>
> > I think lots of people (especially modernists) will be happy to see a
> > proposed differentiation between authorial and editorial interventions.
> >
> > Arianna
>
> I agree that differentiating between authorial and editorial
> interventions would be a valuable addition to the Guidelines.
>
> Dot
>
> > >
> > > Comments?
> > >
> > >
> > >> Hi all,
> > >>
> > >> Here is the first of two proposals relating to my concerns around choice
> > >> and app/rdg:
> > >> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
> > >>
> > >>
> > >> I'
> > > _______________________________________________
> > > tei-council mailing list
> > > tei-council_at_lists.village.Virginia.EDU
> > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
> > --
> > Dr Arianna Ciula
> > Research Associate
> > Centre for Computing in the Humanities
> > King's College London
> > Strand
> > London WC2R 2LS (UK)
> > Tel: +44 (0)20 78481945
> > http://www.kcl.ac.uk/cch
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 15:04:28 EDT

From daniel.odonnell at uleth.ca Mon Jul 23 15:07:32 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 13:07:32 -0600 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <1185217388.25461.35.camel@localhost> Message-ID: <1185217652.25461.38.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 13:07:32 -0600
On Mon, 2007-07-23 at 13:03 -0600, Daniel O'Donnell wrote:
> >
> > The element should be retained for text now illegible or
> > lost through damage but assumed originally to have been in the
> > manuscript (what used to be supplied reason="illegible|damage"), and
> > for the expansion of abbreviations -- these are both arguably things
> > which are present in the manuscript, but where a degree of
> > interpretation is required on the part of the editor.
>
> I like this. It is a little bit more narrow than the current use of
> substitution
Sorry: substitutionsupplied (or should that be
corr?)
> >
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 15:08:52 EDT
From daniel.odonnell at uleth.ca Mon Jul 23 16:24:56 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 14:24:56 -0600 Subject: [tei-council] Are model.inter and model.common in the wrong section of Chapter 1? Message-ID: <1185222296.9462.3.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 14:24:56 -0600
I was just looking at ????1.6.3 and 1.6.4. I wonder if model.common and
model.inter are not in the wrong place. Currently they are found in
??1.6.3: low level classes. I'm sure they should be in ??1.6.4, High-level
classes, especially since the first sentence of that section says "The
following element classes are used to implement the threefold structural
distinction among phrases, chunks, and intermediate elements discussed
above in section 1.6.2 Model Classes." In actual fact, however, the
section only contains two classes: model.phrase and model.limitedPhrase.
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 16:25:01 EDT
From daniel.odonnell at uleth.ca Mon Jul 23 16:29:31 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 14:29:31 -0600 Subject: [tei-council] REFTAG is down Message-ID: <1185222571.9462.6.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 14:29:31 -0600
Appendix B from the current development guidelines
(/P5/Guidelines-web/en/html/REFTAG.html) is unavailable--other sections
seems to be working.
-d
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 16:29:35 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 23 16:39:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 23 Jul 2007 21:39:52 +0100 Subject: [tei-council] REFTAG is down In-Reply-To: <1185222571.9462.6.camel@localhost> Message-ID: <46A51218.7060600@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 23 Jul 2007 21:39:52 +0100
Daniel O'Donnell wrote:
> Appendix B from the current development guidelines
> (/P5/Guidelines-web/en/html/REFTAG.html) is unavailable--other sections
> seems to be working.
>
you'll see a outage occasionally while it rebuilds
(it tests every 15 mins). Seems OK now though
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 23 2007 - 16:39:56 EDT
From daniel.odonnell at uleth.ca Mon Jul 23 18:20:18 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 16:20:18 -0600 Subject: [tei-council] rdg content model Message-ID: <1185229218.14934.4.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 16:20:18 -0600
Here is a link to my proposal for expanding the content model for
rdg/lem:
http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-including-chunk-inter-and-div-level-children-of-teirdg-and-tei-lemma
The proposal is very straightforward: add the ability for chunk, div,
and text level elements to appear as children of rdg. I've provided
examples of each from the apparatus to the Riverside Chaucer, since
there was some doubt that such collations actually existed.
Given that we allowed inter-level children of rdg already, I don't see
how chunk-level elements could be controversial. div and floatingText
might seem more so, but use cases are simply not hard to find.
Finally I make a smaller suggestion that since, as has been pointed out
here, lem and rdg are extremely similar, we should put lem in
model.rdgLike. It is not at all clear to me why we so emphatically
exclude it (we mention this exclusion in the narrative).
-dan
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 18:20:24 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 23 18:42:00 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 23 Jul 2007 23:42:00 +0100 Subject: [tei-council] Are model.inter and model.common in the wrong section of Chapter 1? In-Reply-To: <1185222296.9462.3.camel@localhost> Message-ID: <46A52EB8.9030006@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 23 Jul 2007 23:42:00 +0100
Daniel O'Donnell wrote:
> I was just looking at ????1.6.3 and 1.6.4. I wonder if model.common and
> model.inter are not in the wrong place. Currently they are found in
> ??1.6.3: low level classes. I'm sure they should be in ??1.6.4, High-level
> classes, especially since the first sentence of that section says "The
> following element classes are used to implement the threefold structural
> distinction among phrases, chunks, and intermediate elements discussed
> above in section 1.6.2 Model Classes." In actual fact, however, the
> section only contains two classes: model.phrase and model.limitedPhrase.
>
These two sections still contain some misleading wording... there has
been a lot of heavy surgery in order to get DTD specifics moved out
whilst still ensuring that things get declared in the right order (this
is one of the few places where order of declaration actually matters)
and I think there is some residual scar tissue.
I will take a closer look and try to clean it up as soon as I can. But I
don't think the declarations are in the wrong place: just that the place
they're in is wrongly described.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 23 2007 - 18:48:40 EDT
From daniel.odonnell at uleth.ca Mon Jul 23 19:38:34 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 23 Jul 2007 17:38:34 -0600 Subject: [tei-council] Are model.inter and model.common in the wrong section of Chapter 1? In-Reply-To: <46A52EB8.9030006@computing-services.oxford.ac.uk> Message-ID: <1185233914.18471.1.camel@localhost>
From: Daniel O'Donnell
Date: Mon, 23 Jul 2007 17:38:34 -0600
On Mon, 2007-07-23 at 23:42 +0100, Lou Burnard wrote:
> Daniel O'Donnell wrote:
> > I was just looking at ????1.6.3 and 1.6.4. I wonder if model.common and
> > model.inter are not in the wrong place. Currently they are found in
> > ??1.6.3: low level classes. I'm sure they should be in ??1.6.4, High-level
> > classes, especially since the first sentence of that section says "The
> > following element classes are used to implement the threefold structural
> > distinction among phrases, chunks, and intermediate elements discussed
> > above in section 1.6.2 Model Classes." In actual fact, however, the
> > section only contains two classes: model.phrase and model.limitedPhrase.
> >
> These two sections still contain some misleading wording... there has
> been a lot of heavy surgery in order to get DTD specifics moved out
> whilst still ensuring that things get declared in the right order (this
> is one of the few places where order of declaration actually matters)
> and I think there is some residual scar tissue.
>
> I will take a closer look and try to clean it up as soon as I can. But I
> don't think the declarations are in the wrong place: just that the place
> they're in is wrongly described.
Wow that must have been pretty significant surgery if it demoted
model.common and model.inter to low level classes and restricted
high-level classes to model.phrase and model.limitedPhrase. We'll have
to rewrite chapter 1 throughout.
-- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 23 2007 - 19:38:39 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 24 06:18:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 24 Jul 2007 11:18:10 +0100 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <46A4B245.70003@computing-services.oxford.ac.uk> Message-ID: <46A5D1E2.7000206@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 24 Jul 2007 11:18:10 +0100
Here, fwiw, are my thought's on Matthew's proposals as posted yetsreday:
>
> a) a new grouping element for the special case where an
> and a are to be understood as one action
>
fine by me, if people want to do that kind of thing. can it also appear
within an though?
> b) use of to indicate the supplied part of an expanded
> abbreviation
a shorter name would be nice. and i still don't see why abbbrv. deserves
this special treatment. why isnt expansion of abbrevn just a kind of
normalization?
>
> c) a new element to mark specifically editorial (i.e. not
> physically visible in the source) interventions. If the intervention is
> an addition or deletion, should be used in preference to
> or ; if a substitution, then the element contains a and
> pair like
i dont relish explaining why this is not just
i also think that is a much nicer name than
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 24 2007 - 06:18:19 EDT
From lou.burnard at computing-services.oxford.ac.uk Tue Jul 24 06:18:38 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 24 Jul 2007 11:18:38 +0100 Subject: [tei-council] subst and edInt In-Reply-To: <46A4B245.70003@computing-services.oxford.ac.uk> Message-ID: <46A5D1FE.5060604@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Tue, 24 Jul 2007 11:18:38 +0100
Here, fwiw, are my thought's on Matthew's proposals as posted yetsreday:
>
> a) a new grouping element for the special case where an
> and a are to be understood as one action
>
fine by me, if people want to do that kind of thing. can it also appear
within an though?
> b) use of to indicate the supplied part of an expanded
> abbreviation
a shorter name would be nice. and i still don't see why abbbrv. deserves
this special treatment. why isnt expansion of abbrevn just a kind of
normalization?
>
> c) a new element to mark specifically editorial (i.e. not
> physically visible in the source) interventions. If the intervention is
> an addition or deletion, should be used in preference to
> or ; if a substitution, then the element contains a and
> pair like
i dont relish explaining why this is not just
i also think that is a much nicer name than
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 24 2007 - 06:18:49 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Jul 25 05:25:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 25 Jul 2007 10:25:30 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <18086.44328.471188.684278@emt.wwp.brown.edu> Message-ID: <46A7170A.7030004@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 25 Jul 2007 10:25:30 +0100
Syd sent me and Christian the following musings about
which I
am forwarding to the list for discussion, along with my immediate reactions:
Syd Bauman wrote:
> In P4, the content model of figure (ignoring globals) was
> ( head?, p*, figDesc?, text? )
>
> In P5 it has become
> ( model.pLike | model.global | figure | figDesc | model.graphicLike
> | model.headLike )*
>
> So first off, it seems that either or needs to
> be permitted somewhere in there. I'd vote for the latter.
>
certainly not in any case
> But I am also a bit uncomfortable with the content model permitting
> anywhere other than as the first textual element (other than
> globals). The Guidelines explicitly say that the transcription of the
> caption or descriptive paragraph should occur after the . Do
> you want to defend permitting
>

>


>
>
>
>


> ?
>
I think this is preferable to complicating the model.
> I also thought it might be prudent to take advantage of the use of
> classes, and use where the semantics of

aren't really right.
> However, I can't really tell *what* the

in one of our examples
> is: "

Thou shalt labor till thou returne to duste

" in the
> tagdoc for . Can you shed some light?
>
I agree that might be more appropriate than

for random biyts of
texts floating about inside an image.
> In any case, I think both in the prose and in an example we should
> recommend using for a caption. After all,
> depending on your defintion of "paragraph", a caption isn't one.
> (Might think of using
>
Not sure what the difference between a caption and a head is within a figure
> Lastly, if we permit

to self-nest, we should probably say
> somewhere what that is for, and perhaps give an example of its use.
> Is there a good use case for permitting it to self-nest anywhere, or
> would it be OK to stick it in at the end?
I thought there was an example of this: it's for things like complex
figures with subfigures in them.
>
> If the latter, then how about this for a content model:
> (
> model.global*,
> ( model.headLike, model.global* )*,
> ( model.graphic, model.global* )*,
> ( figDesc, model.global* )*,
> ( model.pLike, model.global* )*,
> ( floatingText, model.global* )?,
> ( figure, model.global* )*
> )
>
I don't think the added complication of this model is worth the effort,
frankly.
> If the latter (
needs to be able to self-nest anywhere) then
> we'd want to change every "model.global*" to "( figure | model.global
> )*", I guess. That gets kinda complicated, though.
>
I don't think the added complication of this model is worth the effort,
frankly.
>
> I also don't wonder whether
should permit model.egLike in
> addition to model.graphicLike. One can imagine wanting to associate a
> heading or a coption with an example.
>
This could work. Or could make model.egLike a subclass of model.graphicLike

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 05:25:35 EDT

From arianna.ciula at kcl.ac.uk Wed Jul 25 05:58:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 25 Jul 2007 10:58:56 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A7170A.7030004@computing-services.oxford.ac.uk> Message-ID: <46A71EE0.4020303@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 25 Jul 2007 10:58:56 +0100
Lou Burnard wrote:
>> I also thought it might be prudent to take advantage of the use of
>> classes, and use where the semantics of

aren't really right.
>> However, I can't really tell *what* the

in one of our examples
>> is: "

Thou shalt labor till thou returne to duste

" in the
>> tagdoc for . Can you shed some light?
>>
>
> I agree that might be more appropriate than

for random biyts of
> texts floating about inside an image.
Agree
>
>> In any case, I think both in the prose and in an example we should
>> recommend using for a caption. After all,
>> depending on your defintion of "paragraph", a caption isn't one.
>> (Might think of using
>>
>
> Not sure what the difference between a caption and a head is within a
> figure
An image may have its own in the source that doesn't necessarily
correspond with what we call a caption (more descriptive). However, do
we need an >
>> Lastly, if we permit

to self-nest, we should probably say
>> somewhere what that is for, and perhaps give an example of its use.
>> Is there a good use case for permitting it to self-nest anywhere, or
>> would it be OK to stick it in at the end?
>
> I thought there was an example of this: it's for things like complex
> figures with subfigures in them.
I think I had given a very abstract example in TEI L long time ago, but
I suspect we need something more concrete.
Arianna
>
>>
>> If the latter, then how about this for a content model:
>> ( model.global*,
>> ( model.headLike, model.global* )*,
>> ( model.graphic, model.global* )*,
>> ( figDesc, model.global* )*,
>> ( model.pLike, model.global* )*,
>> ( floatingText, model.global* )?,
>> ( figure, model.global* )*
>> )
>>
>
> I don't think the added complication of this model is worth the effort,
> frankly.
>
>> If the latter (
needs to be able to self-nest anywhere) then
>> we'd want to change every "model.global*" to "( figure | model.global
>> )*", I guess. That gets kinda complicated, though.
>>
> I don't think the added complication of this model is worth the effort,
> frankly.
>
>>
>> I also don't wonder whether
should permit model.egLike in
>> addition to model.graphicLike. One can imagine wanting to associate a
>> heading or a coption with an example.
>>
>
> This could work. Or could make model.egLike a subclass of model.graphicLike
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 05:58:48 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 06:27:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 11:27:17 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A7170A.7030004@computing-services.oxford.ac.uk> Message-ID: <46A72585.8090808@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 11:27:17 +0100
Lou Burnard wrote:
>
>> But I am also a bit uncomfortable with the content model permitting
>> anywhere other than as the first textual element (other than
>> globals). The Guidelines explicitly say that the transcription of the
>> caption or descriptive paragraph should occur after the .
I'd say change the Guidelines
>
>> In any case, I think both in the prose and in an example we should
>> recommend using for a caption. After all,
>> depending on your defintion of "paragraph", a caption isn't one.
>> (Might think of using
>>
>
> Not sure what the difference between a caption and a head is within a
> figure
indeed. if isnt a , I am gobsmacked. seems like
angels on a pin to me.
>
>>
>> I also don't wonder whether
should permit model.egLike in
>> addition to model.graphicLike. One can imagine wanting to associate a
>> heading or a coption with an example.
>>
>
> This could work. Or could make model.egLike a subclass of
> model.graphicLike
>
or add to
frankly, I feel that that this sort of discussion should have
taken place at chapter review time, not now....

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 06:27:21 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 11:37:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 11:37:38 -0400 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A72585.8090808@oucs.ox.ac.uk> Message-ID: <18087.28226.862187.662499@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 11:37:38 -0400
SB> [need or in
]
LB> certainly not in any case
OK, then it is.

SB> Do you want to defend permitting
SB>


SB>


SB>
SB>
SB>
SB>


SB> ?
LB> I think this is preferable to complicating the model.
As always, I ask for whom is it preferable? I don't think that making
it easier on us to maintain the content model is a reason for having
bad content models.

SB> ... use where the semantics of

aren't really right
LB> I agree that might be more appropriate than

for random
LB> biyts of texts floating about inside an image.
AC> Agree
I think I'm glad to hear that, but I want to double-check that we're
on the same page. I wasn't talking about text *inside* the image,
which heretofore has been encoded inside a , and it seems
hereafter will be encoded inside a . Rather, I was
talking about bits of text that orbit the image, as it were.

LB> Not sure what the difference between a caption and a head is
LB> within a figure
SR> indeed. if isnt a , I am gobsmacked. seems like
SR> angels on a pin to me.
AC> An image may have its own in the source that doesn't
AC> necessarily correspond with what we call a caption (more
AC> descriptive).
I think Arianna's got it right, here. While I agree that there are
many cases where only one or the other is present, and I am sure that
there are cases where it is hard to distinguish, I think that it is
very often quite clear which is which.
I just opened Knuth _The Art of Computer Programming_ volume 3
_Sorting and Searching_, and thumbed through a bit, stopping at a
figure that intrigued me because it looked a bit like a typical tree
representation of XML. Associated with the image in bold typeface is
"Fig. 24.", and then, in roman typeface, "RANK fields, used for
searching by position".
I think most of us would be inclined to encode
Fig. 24.

RANK fields, used for searching by position


in P4. I think very few encoders would want to call them both
s. I do think some folks would think of "Fig. 24." as a label,
not a heading, though.

AC> However, do we need an ; we may conclude that
captions are a flavor of

LB> I thought there was an example of this: it's for things like
LB> complex figures with subfigures in them.
I didn't find any case of //teix:figure//teix:figure in the
Guidelines.
AC> I think I had given a very abstract example in TEI L long time
AC> ago, but I suspect we need something more concrete.
Do you mean the one at
http://listserv.brown.edu/?A2=ind0606&L=TEI-L&P=R7213?
That looks like you were interested in dealing with a whole image and
some fragments thereof. Lou, does that match what you're talking
about?

LB> I don't think the added complication of this model is worth the
LB> effort, frankly.
Well, in the "nested

s go at the end" case, it's a pretty
simple content model, so I actually think it is worth the effort,
because it isn't much effort.
In the "nested
s can go anywhere" case, I still prefer
the structure over repeated OR groups, but I'm less convinced it is
worth the effort at this point.

SB> I also don't wonder whether

should permit model.egLike
SB> in addition to model.graphicLike. One can imagine wanting to
SB> associate a heading or a coption with an example.
LB> This could work. Or could make model.egLike a subclass of
LB> model.graphicLike
You mean make model.egLike a member of model.graphicLike? This would
have the consequence that and could have or
instead of , , or . Is that
OK?
We'd have to remove model.egLike from model.phrase, of course.

SR> or add to
My gut instinct is that we should do this whether or not we add
model.egLike to

somehow.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 11:37:44 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 11:45:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 16:45:42 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <18087.28226.862187.662499@emt.wwp.brown.edu> Message-ID: <46A77026.80103@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 16:45:42 +0100
Syd Bauman wrote:
> I just opened Knuth _The Art of Computer Programming_ volume 3
> _Sorting and Searching_, and thumbed through a bit, stopping at a
> figure that intrigued me because it looked a bit like a typical tree
> representation of XML. Associated with the image in bold typeface is
> "Fig. 24.", and then, in roman typeface, "RANK fields, used for
> searching by position".
>
> I think most of us would be inclined to encode
> Fig. 24.
>

RANK fields, used for searching by position


> in P4. I think very few encoders would want to call them both
> s. I do think some folks would think of "Fig. 24." as a label,
> not a heading, though.
>
Gosh. I'd encode that as RANK fields, used for
searching by position
without a shadow of doubt (with a rend or @n if you want).
It is, semantically, the figure caption; it would be
replicated in a list of figures.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 11:45:46 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 11:49:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 11:49:53 -0400 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A77026.80103@oucs.ox.ac.uk> Message-ID: <18087.28961.789333.511267@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 11:49:53 -0400
> Gosh. I'd encode that as RANK fields, used for searching
> by position without a shadow of doubt (with a rend or @n
> if you want). It is, semantically, the figure caption; it would be
> replicated in a list of figures.
Right. But the Guidelines do not have a element, but rather
currently recommend

for this purpose. (Although we are in the
process of agreeing that we should recommend instead.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 11:49:58 EDT

From lou.burnard at oucs.ox.ac.uk Wed Jul 25 11:55:53 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 25 Jul 2007 16:55:53 +0100 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <[tei-council] Re: figurin' about
(fwd)> Message-ID: <20070725155554.0417394047@webmail220.herald.ox.ac.uk>
From: Lou Burnard
Date: Wed, 25 Jul 2007 16:55:53 +0100
----- Forwarded message from Lou Burnard ox.ac.uk> -----
From: Lou Burnard ox.ac.uk>
To: Syd_Bauman_at_Brown.edu
Subject: Re: [tei-council] Re: figurin' about

Date: Wed, 25 Jul 2007 16:55:01 +0100

In message <18087.28961.789333.511267_at_emt.wwp.brown.edu> Syd_Bauman_at_Brown.edu
writes:
> > Gosh. I'd encode that as RANK fields, used for searching
> > by position without a shadow of doubt (with a rend or @n
> > if you want). It is, semantically, the figure caption; it would be
> > replicated in a list of figures.
>
> Right. But the Guidelines do not have a element, but rather
> currently recommend

for this purpose. (Although we are in the
> process of agreeing that we should recommend instead.)
>
>
I *think* Sebastian meant , not . That's what I would do anyway.
And I wouldnt hesitate to have multiple s if nessa.
If you can find a place in the Guidelines where we recommend coding a heading or
caption with a

I will be very surprised.

----- End of forwarded message from Lou Burnard ox.ac.uk> -----
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 11:55:57 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 12:01:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 17:01:46 +0100 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <20070725155554.0417394047@webmail220.herald.ox.ac.uk> Message-ID: <46A773EA.7080608@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 17:01:46 +0100
Lou Burnard wrote:
> I *think* Sebastian meant , not . That's what I would do anyway.
> And I wouldnt hesitate to have multiple s if nessa.
>
er yeah, I meant , sorry. was thinking of \caption{}, which
is probably what Knuth typed....

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 12:01:51 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 12:11:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 17:11:15 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <18087.28226.862187.662499@emt.wwp.brown.edu> Message-ID: <46A77623.9080106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 17:11:15 +0100
Syd Bauman wrote:
>
> Do you mean the one at
> http://listserv.brown.edu/?A2=ind0606&L=TEI-L&P=R7213?
> That looks like you were interested in dealing with a whole image and
> some fragments thereof. Lou, does that match what you're talking
> about?
>
>
the markup matches what *I* think nested figures are for,
but your words don't. The use is to describe a figure
which contains (eg) two graphs captioned "(a) Before Harry
Potter" and "(b) After Harry Potter", and an overall
caption saying "Instances of black magic games amongst pre-teens".
that model is very common indeed in scientific journals etc.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 12:11:20 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Jul 25 12:18:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 25 Jul 2007 17:18:40 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A77623.9080106@oucs.ox.ac.uk> Message-ID: <46A777E0.1020005@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 25 Jul 2007 17:18:40 +0100
Sebastian Rahtz wrote:
> Syd Bauman wrote:
>>
>> Do you mean the one at
>> http://listserv.brown.edu/?A2=ind0606&L=TEI-L&P=R7213?
>> That looks like you were interested in dealing with a whole image and
>> some fragments thereof. Lou, does that match what you're talking
>> about?
>>
> the markup matches what *I* think nested figures are for,
> but your words don't. The use is to describe a figure
> which contains (eg) two graphs captioned "(a) Before Harry
> Potter" and "(b) After Harry Potter", and an overall
> caption saying "Instances of black magic games amongst pre-teens".
>
> that model is very common indeed in scientific journals etc.
>
Exactly. That's what I had in mind, and we should put an example into
the Guidelines along those lines (though preferably a real one,
unrelated to any Potterish nonsense)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 12:18:44 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 12:19:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 17:19:16 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <18087.28961.789333.511267@emt.wwp.brown.edu> Message-ID: <46A77804.8040106@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 17:19:16 +0100
Syd Bauman wrote:
> Right. But the Guidelines do not have a element, but rather
> currently recommend

for this purpose.
am in a parallel universe? this is what
is for, surely? the example in *Spec for


seems clear to me
> (Although we are in the
> process of agreeing that we should recommend instead.)
>
gracious. I'll burn myself at the stake rather than go
down this madness......
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Jul 25 2007 - 12:19:19 EDT
From Syd_Bauman at Brown.edu Wed Jul 25 12:21:33 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 12:21:33 -0400 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <20070725155554.0417394047@webmail220.herald.ox.ac.uk> Message-ID: <18087.30861.628678.746940@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 12:21:33 -0400
> I *think* Sebastian meant , not . That's what I
> would do anyway. And I wouldnt hesitate to have multiple s if
> nessa.
I wouldn't hesitate to have multiple elements (perhaps
differentiated by type=), either, *if* the text in question seemed to
be heading-like. But I think some of these things are not
heading-like, but are longer winded descriptive things.

> If you can find a place in the Guidelines where we recommend coding
> a heading or caption with a

I will be very surprised.
>From #FTGRA:

Figures are often accompanied not only by a title or heading,
but by a paragraph or so of commentary or caption. One or more
p elements following the head may be used to
transcribe any caption or discussion of the figure in the
source:
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 12:21:37 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 12:23:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 12:23:52 -0400 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A77623.9080106@oucs.ox.ac.uk> Message-ID: <18087.31000.740834.893017@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 12:23:52 -0400
> the markup matches what *I* think nested figures are for, but your
> words don't. The use is to describe a figure which contains (eg)
> two graphs captioned "(a) Before Harry Potter" and "(b) After Harry
> Potter", and an overall caption saying "Instances of black magic
> games amongst pre-teens".
Right, thanks.

> that model is very common indeed in scientific journals etc.
Yes, there are several in that Knuth book, even.

So unless someone else wants the task, I can try to come up with an
example. (Although I have to say, I like Sebastian's a lot :-)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 12:24:21 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Jul 25 12:35:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 25 Jul 2007 17:35:37 +0100 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <18087.30861.628678.746940@emt.wwp.brown.edu> Message-ID: <46A77BD9.6010401@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 25 Jul 2007 17:35:37 +0100
Syd Bauman wrote:
>
>> If you can find a place in the Guidelines where we recommend coding
>> a heading or caption with a

I will be very surprised.
>
>>From #FTGRA:
>
>

Figures are often accompanied not only by a title or heading,
> but by a paragraph or so of commentary or caption. One or more
> p elements following the head may be used to
> transcribe any caption or discussion of the figure in the
> source:
>
Oh *that* sort of caption. Well, at a pinch, maybe. Well, maybe that bit
of text in the Guidelines (a recent addition I think) needs
clarification. Pity that this wasn't noticed when we were actually
reviewing this particular chapter.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 12:35:43 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 12:49:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 12:49:05 -0400 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <46A77BD9.6010401@computing-services.oxford.ac.uk> Message-ID: <18087.32513.957215.529921@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 12:49:05 -0400
> Oh *that* sort of caption. Well, at a pinch, maybe. Well, maybe
> that bit of text in the Guidelines (a recent addition I think)
> needs clarification.
Well, it has been around since P3. And clearly users have been using
it for over a decade. I know we have been doing so here at the WWP,
but also see http://listserv.brown.edu/?A2=ind9701&L=TEI-L&P=R682.
Other than change

to , what clarification would you propose?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 12:49:14 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Jul 25 13:46:27 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 25 Jul 2007 18:46:27 +0100 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <18087.32513.957215.529921@emt.wwp.brown.edu> Message-ID: <46A78C73.2030804@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 25 Jul 2007 18:46:27 +0100
Syd Bauman wrote:
>> Oh *that* sort of caption. Well, at a pinch, maybe. Well, maybe
>> that bit of text in the Guidelines (a recent addition I think)
>> needs clarification.
>
> Well, it has been around since P3. And clearly users have been using
> it for over a decade. I know we have been doing so here at the WWP,
> but also see http://listserv.brown.edu/?A2=ind9701&L=TEI-L&P=R682.
I don't see what Peter Gorman's comment has to do with this issue. His
examples are about linking, which is a completely different matter
>
> Other than change

to , what clarification would you propose?
>
I'm not so sure about changing to now. I think we should leaving
well alone, and getting back to our scheduled business: reviewing the
material from Dot and Conal.

> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 13:46:32 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 14:47:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 14:47:18 -0400 Subject: [tei-council] Re: figurin' about
In-Reply-To: <46A77804.8040106@oucs.ox.ac.uk> Message-ID: <18087.39606.30772.288471@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 14:47:18 -0400
> am in a parallel universe? this is what is for, surely? the
> example in *Spec for
seems clear to me
Yes, when they're short and heading-like, one could encode them as
. But not all are like that.

Transition Network

Transition network for DetHi behaviour on
indeterminate ques­
tions. Nodes represent rules, and their areas represent the
frequency at
which that rule was invoked. Links represent the
probability of transition
from one rule to another; transitions at 10% probability and
below are not shown




> > (Although we are in the process of agreeing that we should
> > recommend instead.)
> gracious. I'll burn myself at the stake rather than go
> down this madness......
Feel free to bow out of the discussion -- wouldn't want you all
burned up. (Although from the sound of it, you could just hop in the
street to douse the flames.)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 14:47:22 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 14:47:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 14:47:36 -0400 Subject: [tei-council] Re: figurin' about
(fwd) In-Reply-To: <46A78C73.2030804@computing-services.oxford.ac.uk> Message-ID: <18087.39624.401883.342803@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 14:47:36 -0400
> I don't see what Peter Gorman's comment has to do with this issue.
> His examples are about linking, which is a completely different
> matter
Not his comment, his encoding -- he uses

for a caption.

> I'm not so sure about changing to now. I think we should
> leaving well alone, and getting back to our scheduled business:
> reviewing the material from Dot and Conal.
While I agree we need to get moving on the linking-to-images stuff
(about which I hope to post a bit tonight), it seems to me changing
from

to is pretty darn trivial. (After all, both are already
permitted in the content, there is only 1 occurence in the prose to
change, and only 2 examples that have

inside

to change.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 14:47:53 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Jul 25 15:51:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jul 2007 20:51:21 +0100 Subject: [tei-council] Re: figurin' about
In-Reply-To: <18087.39606.30772.288471@emt.wwp.brown.edu> Message-ID: <46A7A9B9.4030606@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 25 Jul 2007 20:51:21 +0100
Syd Bauman wrote:
>
>

> Transition Network
>
> Transition network for DetHi behaviour on
> indeterminate ques­
> tions. Nodes represent rules, and their areas represent the
> frequency at
> which that rule was invoked. Links represent the
> probability of transition
> from one rule to another; transitions at 10% probability and
> below are not shown
>

>
oh sure. I just would not call that a caption. I'd just
have put that in a normal

. its
explanatory text which could in another
universe be in the graphic.

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 14:51:21 EDT

From Syd_Bauman at Brown.edu Wed Jul 25 23:39:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Jul 2007 23:39:40 -0400 Subject: [tei–council] linking text to image, facsimiles –– what to do? Message-ID: <18088.6012.747606.924046@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 25 Jul 2007 23:39:40 -0400
First, some thoughts on specifics:
Whatever we end up doing, we should not be using corresp= as part of
a system for linking text to images. In fact, I don't think we should
make any specific recommendations that rely on the use of corresp=.
(Examples of it being used are fine, of course.) It is a general-
purpose attribute whose specific semantics should generally be left
to the user. In any case where it would be useful to suggest it as a
mechanism in the Guidelines, we should probably be coming up with a
specific-purpose attribute, instead.

various> [facsimiles should be in ]
LB> [No, it should not]
LB> The syllogism seems to be: ... distinct from the source it
LB> purports to represent.
I agree with everything Lou has said up to this point in his posting
pretty emphatically. A facsimile is not metadata about the source,
and even if it were, it isn't a *description* of the source in any
way, shape, or form, and thus does not belong in .

LB> In fact, it seems to me the relationship between a transcription
LB> of a source and the original is almost identical to the
LB> relationship between a facsimile of it and the original.
I am not nearly as convinced of this statement. I am convinced that a
transcription requires interpretation. While I am open to discussion
on the subject, my gut instinct is that a scanned page image does
not. However, I'm not sure we need to agree on this philosophical
issue to move forward.

LB> One translates a reading letter by letter, and the other
LB> translates a reading dot by dot, but they are both readings and
LB> as such I would like to give them the same ontological standing
LB> in my encoding.
Perhaps I am misunderstanding what you mean here, Lou, or not
understanding some nuance, but this seems at least wrong, if not
blasphemous. I don't think of a facsimile (i.e., a page image) as a
reading at all -- it is read, but it is not a reading. An encoded
transcription is one or more readings.

LB> Surely the TEI ought to be offering a way of encoding digital
LB> facsimile editions as well as digital transcriptions?
No, this does not seem like a given at all. It may be something we
want to do in the end, but it is not obvious. The "T" in "TEI" stands
for *text*. Do we want to become the Text and Images of Thereof Encoding
Initiative? I dunno.

LB> Wouldn't it be nice to offer a way of growing one kind into the
LB> other without doing violence to the basic TEI model?
Maybe.

LB> If we are going to have markup which describes the page images
LB> themselves, as digital objects, then the set of page images
LB> constituting a work isa kind of "text" itself and should be
LB> treated as such.
With this we would end up with TEI files that look like








But a is explicitly, and mostly carefully, crafted to
contain metadata about *text*. There is lots of metadata about
*images* for which it is currently ill-suited.

I know that this has been brought up before, but I'm afraid I need to
be reminded ... what is it that METS doesn't do that makes us want to
reinvent this wheel? I am (very) far from an expert in METS, but it
is worth noting that METS is designed not only to describe the
relationships between (e.g.) TEI elements and facsimile images, but
to be a mechanism for storing metadata about the images.

The suggestion of developing a complete mechanism for describing
facsimiles and providing linkages, and to have it replace is
not a small invisible-to-the-user change like fixing the name of a
class; this also doesn't seem like an obvious improvement right up
the TEI's alley like mechanisms for encoding postscripts, manuscript
descriptions, or physical bibliographic information. I'm worried that
this is even more than a small addition that "pushes the envelope"
like personagraphy does.
I'm not saying that the TEI should not do this. I am suggesting that
we should not rush into it without more care than can be applied in
the remaining week. I think this is a 1.1 or 1.2 issue.

That said, I think having a *simple* mechanism that correlates page
breaks (and perhaps other milestone elements) to a single scanned
image of the page (that follows the ) is pretty much a
requirement for 1.0. Quite a few users have mentioned their desire
for this to me, one of whom is Martin Mueller; thus I think of this
as a solution for "the Martin Mueller's of the world".
Again, it is not ideal for us to recommend "use corresp=" (although
even that is better than nothing), as there may well be other
correspondences that apply to s which a user would want to
encode.
This mechanism should NOT:
* permit linking to multiple images (thumbnails, high-res, Xray,
etc.)
* permit linking to a portion of an image above and beyond what one
can do in a standard URL (i.e., w/ XPointer)
* require indirection to get to the image (beyond perhaps resolving a
URN to a URL)
* require table-lookup, decoding, or use of NOTATIONs (except of
course resolution of entity references as required by XML, and of %
escaped characters as per URLs)
* use more than one attribute
This mechanism SHOULD:
* be expandable -- if we decide to go with a system like Conal's, it
would be nice if we could make use of this simple mechanism and
build upon it, if it seemed like the right thing to do; if we
decide to add cRef= like shortcuts later, we should be able to
Personally, I think it should just be an attribute that is declared
as a single data.pointer that points to the image. No MIME type, no
indirection, no regular expression to resolve to get the URI. Just a
pointer -- a simple URI. We just have to name the attribute such that
its semantics could be expanded in the future, if we want.

I hope this post makes sense. G'night.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Jul 25 2007 - 23:39:44 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Jul 26 05:09:25 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 26 Jul 2007 10:09:25 +0100 Subject: [tei–council] linking text to image, facsimiles –– what to do? In-Reply-To: <18088.6012.747606.924046@emt.wwp.brown.edu> Message-ID: <46A864C5.9070609@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 26 Jul 2007 10:09:25 +0100
I am short of time today (have to write a paper for a conference this
weekend) so I am just going to respond very quickly to what I see as the
major points of Syd's posting.
1. an image does not have multiple readings
In my sense of the word "reading" it does. For example, a black and
white image is a different "reading" from a colour one. You can also
talk about a reading such as "woman holding baby" as distinct from
"madonna and child". These two different kinds of difference nicely
parallel the sorts of difference we are well used to in encoding text
e.g. "this is a placename" vs "this is a reference to Botswana"
2. Why are we the TEI doing this?
Because two members of the Council have put a lot of work into it,
reflecting their perceptions of the needs of the Community. Because
there is ample evidence that users of the TEI want to produce facsimile
editions within one single encoding framework. Because one of the great
things about digitization/encoding is breaking down media-specific
barriers.
3. image information in the header?
Here at least we seem to be in agreement: it doesn't belong in the
header. It doesnt belong in the body either though, since an image *in*
the text is not the same as an image *of* the text. So we do need some
kind of type element, analogous to .
4. what's wrong with mets?
Nothing, (except that I dont know much about it). But nowhere has anyone
proposed anything about re-inventing a place for special metadata about
images have they? The idea is to invent a home for the images. If it's
outside the header (vide sup) then you can put your image metadata
inside the header if you want to, or have it wherever mets puts it.
Unless I'm mistaken, part of the original charge for Conal and Dot was
to consider whether or not we should hand over the entire problem to
METS, and their conclusion, which the Council agreed to lo these many
many months ago was that we shouldn't. If you want to reverse that
decision you need to come up with a rather more convincing case, and
some specific alternatives.
5. don't use corresp
I dont feel very strongly on this one. seems to me @corresp has exactly
the right semantics, but it's not inconceivable that you might also want
to use it for say a translation, in which case you'd be stuck. So let's
invent another attribute -- how about @facs -- for this specific kind of
correspondence.
6. don't do clever image mapping stuff
I am open minded on this. I'm willing to trust to C&D's expertise to get
this right eventually; they've thought about it more than I have
certainly, and it's not their fault that the TEI editors have been too
slow in reacting to their ideas and helping them develop them further.
I stand by the oft repeated assertion that we *must* have something in
P5 1.0 on this topic. We won't be crucified for failing to include a
special tag for postscripts. We will be for not recognising that people
want to produce digital objects containing page images as well as
transcriptions.
Must dash...
Lou
Syd Bauman wrote:
> First, some thoughts on specifics:
>
> Whatever we end up doing, we should not be using corresp= as part of
> a system for linking text to images. In fact, I don't think we should
> make any specific recommendations that rely on the use of corresp=.
> (Examples of it being used are fine, of course.) It is a general-
> purpose attribute whose specific semantics should generally be left
> to the user. In any case where it would be useful to suggest it as a
> mechanism in the Guidelines, we should probably be coming up with a
> specific-purpose attribute, instead.
>
>
> various> [facsimiles should be in ]
> LB> [No, it should not]
> LB> The syllogism seems to be: ... distinct from the source it
> LB> purports to represent.
>
> I agree with everything Lou has said up to this point in his posting
> pretty emphatically. A facsimile is not metadata about the source,
> and even if it were, it isn't a *description* of the source in any
> way, shape, or form, and thus does not belong in .
>
>
> LB> In fact, it seems to me the relationship between a transcription
> LB> of a source and the original is almost identical to the
> LB> relationship between a facsimile of it and the original.
>
> I am not nearly as convinced of this statement. I am convinced that a
> transcription requires interpretation. While I am open to discussion
> on the subject, my gut instinct is that a scanned page image does
> not. However, I'm not sure we need to agree on this philosophical
> issue to move forward.
>
>
> LB> One translates a reading letter by letter, and the other
> LB> translates a reading dot by dot, but they are both readings and
> LB> as such I would like to give them the same ontological standing
> LB> in my encoding.
>
> Perhaps I am misunderstanding what you mean here, Lou, or not
> understanding some nuance, but this seems at least wrong, if not
> blasphemous. I don't think of a facsimile (i.e., a page image) as a
> reading at all -- it is read, but it is not a reading. An encoded
> transcription is one or more readings.
>
>
> LB> Surely the TEI ought to be offering a way of encoding digital
> LB> facsimile editions as well as digital transcriptions?
>
> No, this does not seem like a given at all. It may be something we
> want to do in the end, but it is not obvious. The "T" in "TEI" stands
> for *text*. Do we want to become the Text and Images of Thereof Encoding
> Initiative? I dunno.
>
>
> LB> Wouldn't it be nice to offer a way of growing one kind into the
> LB> other without doing violence to the basic TEI model?
>
> Maybe.
>
>
> LB> If we are going to have markup which describes the page images
> LB> themselves, as digital objects, then the set of page images
> LB> constituting a work isa kind of "text" itself and should be
> LB> treated as such.
>
> With this we would end up with TEI files that look like
>
>
>
>
>
>
>
>
>
>
> But a is explicitly, and mostly carefully, crafted to
> contain metadata about *text*. There is lots of metadata about
> *images* for which it is currently ill-suited.
>
>
>
>
> I know that this has been brought up before, but I'm afraid I need to
> be reminded ... what is it that METS doesn't do that makes us want to
> reinvent this wheel? I am (very) far from an expert in METS, but it
> is worth noting that METS is designed not only to describe the
> relationships between (e.g.) TEI elements and facsimile images, but
> to be a mechanism for storing metadata about the images.
>
>
> The suggestion of developing a complete mechanism for describing
> facsimiles and providing linkages, and to have it replace is
> not a small invisible-to-the-user change like fixing the name of a
> class; this also doesn't seem like an obvious improvement right up
> the TEI's alley like mechanisms for encoding postscripts, manuscript
> descriptions, or physical bibliographic information. I'm worried that
> this is even more than a small addition that "pushes the envelope"
> like personagraphy does.
>
> I'm not saying that the TEI should not do this. I am suggesting that
> we should not rush into it without more care than can be applied in
> the remaining week. I think this is a 1.1 or 1.2 issue.
>
>
> That said, I think having a *simple* mechanism that correlates page
> breaks (and perhaps other milestone elements) to a single scanned
> image of the page (that follows the ) is pretty much a
> requirement for 1.0. Quite a few users have mentioned their desire
> for this to me, one of whom is Martin Mueller; thus I think of this
> as a solution for "the Martin Mueller's of the world".
>
> Again, it is not ideal for us to recommend "use corresp=" (although
> even that is better than nothing), as there may well be other
> correspondences that apply to s which a user would want to
> encode.
>
> This mechanism should NOT:
> * permit linking to multiple images (thumbnails, high-res, Xray,
> etc.)
> * permit linking to a portion of an image above and beyond what one
> can do in a standard URL (i.e., w/ XPointer)
> * require indirection to get to the image (beyond perhaps resolving a
> URN to a URL)
> * require table-lookup, decoding, or use of NOTATIONs (except of
> course resolution of entity references as required by XML, and of %
> escaped characters as per URLs)
> * use more than one attribute
>
> This mechanism SHOULD:
> * be expandable -- if we decide to go with a system like Conal's, it
> would be nice if we could make use of this simple mechanism and
> build upon it, if it seemed like the right thing to do; if we
> decide to add cRef= like shortcuts later, we should be able to
>
> Personally, I think it should just be an attribute that is declared
> as a single data.pointer that points to the image. No MIME type, no
> indirection, no regular expression to resolve to get the URI. Just a
> pointer -- a simple URI. We just have to name the attribute such that
> its semantics could be expanded in the future, if we want.
>
>
> I hope this post makes sense. G'night.
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 05:09:33 EDT
From Conal.Tuohy at vuw.ac.nz Thu Jul 26 09:05:43 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 01:05:43 +1200 Subject: [tei-council] facsimile - where to encode pages and facsimile graphics? Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB7@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 01:05:43 +1200
I want to address several aspects of the facsimile proposal, starting with this question about where the facsimile graphics should be encoded.
I am convinced by Lou that they should not be encoded in the teiHeader. I think he's right that they deserve to be treated more like a text, and I think facsimile is a good name for the element.
So, if have it correctly, it would be possible to have (as at present):
TEI
teiHeader
text
(for a normal transcript)
or:
TEI
teiHeader
facsimile
text
(for an edition in which the transcript is aligned with facsimile graphics. This is the main use case which Dot and I have had in mind all along)
and, finally:
TEI
teiHeader
facsimile
(for a "purely graphical" facsimile, without any transcript at all).
This last is an odd case, but I have seen something very like it in the wild. The now obsolete digital library software ENCompass (aka Curator) from Endeavour InfoSystems came with TEI support, but it turned out to be a highly customised variant in which a teiHeader was combined with a text consisting of a bunch of page breaks, each with a URL attribute pointing to an image. So there is a case for this already.
I'm not sure how useful it would be to have multiple "facsimile" elements within the same TEI document. It need not require more than one such element, e.g.
element TEI
{
att.global.attributes,
attribute version { xsd:decimal }?,
( teiHeader, facsimile?, text )
}
On the other hand, I'm open-minded about this, and I would be happy with any alternative. Obviously it has to be decided one way or another, but the other parts of the facsimile model are more crucial to the actual functionality of the encoding.
Con

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 09:06:08 EDT

From Conal.Tuohy at vuw.ac.nz Thu Jul 26 09:19:49 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 01:19:49 +1200 Subject: [tei-council] facsimile - low-end markup Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB8@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 01:19:49 +1200
There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
This needs to support the case of a transcript with a single set of page images (i.e. each page would have an optional image file associated with it). The simplest way would be to extend to add a URL attribute pointing to the facsimile graphic. e.g.

I believe this is as far as Syd thinks we should go at this point, but I think there is also a strongly felt need for a mechanism to assign graphical coordinates to pieces of text, which we should address. This is most easily done by adding an optional @coords attribute to elements which can appear inside . e.g.

This paragraph is 500x10 pixels.


This is about as far as many "facsimile" customisations of TEI have gone, and I think this is also a sensible minimum. NB this minimum would not use elements to encode the facsimile images, hence it does not require a element.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 09:20:11 EDT
From dporter at uky.edu Thu Jul 26 09:28:23 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 26 Jul 2007 09:28:23 -0400 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB8@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <96f3df640707260628p25f00891mca9f026d24614756@mail.gmail.com>
From: Dot Porter
Date: Thu, 26 Jul 2007 09:28:23 -0400
Yes, yes, yes. Conal's minimum recommendation is exactly what, at
minimum, I would like to see. It would work for projects with only one
set of image files, which would be (I expect) most projects.
For projects with multiple sets of images, we might simply point to
METS (for now) rather than trying to put in something of our own.
Dot
On 7/26/07, Conal Tuohy ac.nz> wrote:
> There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
>
> This needs to support the case of a transcript with a single set of page images (i.e. each page would have an optional image file associated with it). The simplest way would be to extend to add a URL attribute pointing to the facsimile graphic. e.g.
>
>
>
> I believe this is as far as Syd thinks we should go at this point, but I think there is also a strongly felt need for a mechanism to assign graphical coordinates to pieces of text, which we should address. This is most easily done by adding an optional @coords attribute to elements which can appear inside . e.g.
>
>

This paragraph is 500x10 pixels.


>
> This is about as far as many "facsimile" customisations of TEI have gone, and I think this is also a sensible minimum. NB this minimum would not use elements to encode the facsimile images, hence it does not require a element.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 26 2007 - 09:28:28 EDT

From laurent.romary at loria.fr Thu Jul 26 09:43:27 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 26 Jul 2007 15:43:27 +0200 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <96f3df640707260628p25f00891mca9f026d24614756@mail.gmail.com> Message-ID: <13F8E7C1-D135-426C-A541-21F409A6E135@loria.fr>
From: Laurent Romary
Date: Thu, 26 Jul 2007 15:43:27 +0200
Triple yes also for me. We urgently need some basic principles
concerning such projects and be able to point to METS when something
more ellaborated comes along.
Laurent
Le 26 juil. 07 ? 15:28, Dot Porter a ?crit :
> Yes, yes, yes. Conal's minimum recommendation is exactly what, at
> minimum, I would like to see. It would work for projects with only one
> set of image files, which would be (I expect) most projects.
>
> For projects with multiple sets of images, we might simply point to
> METS (for now) rather than trying to put in something of our own.
>
> Dot
>
> On 7/26/07, Conal Tuohy ac.nz> wrote:
>> There seems to be a consensus that at least a minimal facsimile
>> markup is really needed in P5 version 1.0.
>>
>> This needs to support the case of a transcript with a single set
>> of page images (i.e. each page would have an optional image file
>> associated with it). The simplest way would be to extend to
>> add a URL attribute pointing to the facsimile graphic. e.g.
>>
>>
>>
>> I believe this is as far as Syd thinks we should go at this point,
>> but I think there is also a strongly felt need for a mechanism to
>> assign graphical coordinates to pieces of text, which we should
>> address. This is most easily done by adding an optional @coords
>> attribute to elements which can appear inside . e.g.
>>
>>

This paragraph is 500x10 pixels.


>>
>> This is about as far as many "facsimile" customisations of TEI
>> have gone, and I think this is also a sensible minimum. NB this
>> minimum would not use elements to encode the facsimile
>> images, hence it does not require a element.
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>
>
> --
> ***************************************
> Dot Porter, University of Kentucky
> #####
> Program Coordinator
> Collaboratory for Research in Computing for Humanities
> dporter_at_uky.edu 859-257-9549
> #####
> Editorial Assistant, REVEAL Project
> Center for Visualization and Virtual Environments
> porter_at_vis.uky.edu
> ***************************************
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 09:45:14 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 26 09:48:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 26 Jul 2007 14:48:57 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB8@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46A8A649.1020604@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 26 Jul 2007 14:48:57 +0100
Conal Tuohy wrote:
> There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
>
> This needs to support the case of a transcript with a single set of page images (i.e. each page would have an optional image file associated with it). The simplest way would be to extend to add a URL attribute pointing to the facsimile graphic. e.g.
>
>
>
> I believe this is as far as Syd thinks we should go at this point, but I think there is also a strongly felt need for a mechanism to assign graphical coordinates to pieces of text, which we should address. This is most easily done by adding an optional @coords attribute to elements which can appear inside . e.g.
>
>

This paragraph is 500x10 pixels.


>
> This is about as far as many "facsimile" customisations of TEI have gone, and I think this is also a sensible minimum. NB this minimum would not use elements to encode the facsimile images, hence it does not require a element.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 09:49:05 EDT
From Conal.Tuohy at vuw.ac.nz Thu Jul 26 10:13:14 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 02:13:14 +1200 Subject: [tei-council] facsimile - how to do encode multiple facsimile images per page? Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABB9@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 02:13:14 +1200
Our original proposal recognised that an important use case is where there are multiple facsimile images of each page.
Since these images may have different margins and different resolutions, they will not necessarily share the same coordinate space, so it will not be possible to assign an unambiguous set of coordinates to pieces of text, using coords.
Some of the images for a given page may even be detail images, showing only a particularly interesting portion of the page at high resolution, so the images for a page may constitute a patchwork.
So to provide a single coordinate space for each page, in which locations can be expressed, but still being able to use graphics of different resolutions, it's necessary to explicitly define the relationship between the coordinate spaces of those graphics. The simplest way to do this is to relate the coordinate spaces of each graphic to a single common coordinate space, which is defined independently of any of the graphics.
This is the reason why our proposal included a new element called (hereinafter known as which is a much nicer name). If you had multiple images per page, you would have to use the element instead of just adding a url to the elements. Each element would isntead be linked with a pointer to the corresponding , and would contain the elements which are facsimiles of that page. The would provide a coordinate space indendepent of the coordinate spaces of the facsimile images. Each would have @coords to show the region of the page covered by the , and a @scale factor to adjust for different resolution images, i.e. if image A had 2x the resolution of image B then it would have a scale factor of 0.5, to normalise the 2 coordinate spaces.
This allows for a paragraph (for instance) to be encoded with @coords which can be mapped easily onto regions of any of the graphical facsimiles of that page, by some simple arithmetic. The calcluation of which part of which graphics correspond with which pieces of text could be done in XSLT with XPath and maybe using the key() function, but would not require the use of recursive templates to calculate the graphical transformations, which I think is very important. It ought to be simple to process this to produce e.g. SVG or HTML+CSS or XSL-FO versions in wich text and image are aligned.
That brings me finally to comment on Lou's proposal of a element which can self-nest, allowing for a series of graphical transformations. While this could certainly work, I think it is overly complex. I don't believe that the recursive markup (i.e. zones within zones) provides anything that couldn't be done without it fairly easily. Whereas the downside is it would be considerably more difficult to process. Not impossible by any means, but in XSLT for instance I am sure it would require the use of recursive templates, because there's no telling how far the elements nest.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 10:13:38 EDT
From Conal.Tuohy at vuw.ac.nz Thu Jul 26 10:36:38 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 02:36:38 +1200 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABBA@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 02:36:38 +1200
The other requirement we've tried to cover in our proposal is the ability to add facsimile markup to an existing transcript in a stand-off way. Rather than adding @coords to each

, , or whatever, the coordinates would be attached to another element, representing the area on the page, and that area would be linked with @corresp (or some other pointer mechanism) to the textual elements which fall within that area.
This is the function of the element in our proposal. I would be happy to rename this , which actually accords with the technical term used by people who are using OCR to produce this kind of facsimile edition, I believe.
For example:
A single-page document with 2 facsimile images, one of which is 10x the resolution of the other.
-----------------------------------






...

...

...

Foo
...

-----------------------------------
This could be equivalently encoded in a stand-off style like so:
-----------------------------------








...

...

...
Foo
...

-----------------------------------
I think that Martin Holmes also wanted to be able to link such elements to milestoneLike elements in the text, in order to be able to more easily handle cases where paragraphs were split over columns or pages. I was thinking that could have @start and @end attributes pointing at milestones, to be used as an alternative to @corresp. But it's late and I'll leave this until tomorrow.
Finally, I'm open-minded regarding the need for a different attribute to @corresp - I suggested @fax earlier and Lou suggested @facs, and I think Syd also preferred using an attribute with distinctly "facsimilar" semantics, rather than the multi-purpose @corresp.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 10:37:01 EDT

From daniel.odonnell at uleth.ca Thu Jul 26 11:09:49 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 26 Jul 2007 09:09:49 -0600 Subject: [tei-council] facsimile - where to encode pages and facsimile graphics? In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB7@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <1185462589.6786.2.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 26 Jul 2007 09:09:49 -0600
I like this.
On Fri, 2007-07-27 at 01:05 +1200, Conal Tuohy wrote:
> I want to address several aspects of the facsimile proposal, starting with this question about where the facsimile graphics should be encoded.
>
> I am convinced by Lou that they should not be encoded in the teiHeader. I think he's right that they deserve to be treated more like a text, and I think facsimile is a good name for the element.
>
> So, if have it correctly, it would be possible to have (as at present):
>
> TEI
> teiHeader
> text
>
> (for a normal transcript)
>
> or:
>
> TEI
> teiHeader
> facsimile
> text
>
> (for an edition in which the transcript is aligned with facsimile graphics. This is the main use case which Dot and I have had in mind all along)
>
> and, finally:
>
> TEI
> teiHeader
> facsimile
>
> (for a "purely graphical" facsimile, without any transcript at all).
>
> This last is an odd case, but I have seen something very like it in the wild. The now obsolete digital library software ENCompass (aka Curator) from Endeavour InfoSystems came with TEI support, but it turned out to be a highly customised variant in which a teiHeader was combined with a text consisting of a bunch of page breaks, each with a URL attribute pointing to an image. So there is a case for this already.
>
> I'm not sure how useful it would be to have multiple "facsimile" elements within the same TEI document. It need not require more than one such element, e.g.
>
> element TEI
> {
> att.global.attributes,
> attribute version { xsd:decimal }?,
> ( teiHeader, facsimile?, text )
> }
>
> On the other hand, I'm open-minded about this, and I would be happy with any alternative. Obviously it has to be decided one way or another, but the other parts of the facsimile model are more crucial to the actual functionality of the encoding.
>
> Con
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 26 2007 - 11:11:28 EDT
From daniel.odonnell at uleth.ca Thu Jul 26 11:10:23 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 26 Jul 2007 09:10:23 -0600 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <96f3df640707260628p25f00891mca9f026d24614756@mail.gmail.com> Message-ID: <1185462623.6786.4.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 26 Jul 2007 09:10:23 -0600
On Thu, 2007-07-26 at 09:28 -0400, Dot Porter wrote:
> Yes, yes, yes. Conal's minimum recommendation is exactly what, at
> minimum, I would like to see. It would work for projects with only one
> set of image files, which would be (I expect) most projects.
>
> For projects with multiple sets of images, we might simply point to
> METS (for now) rather than trying to put in something of our own.
I agree it is the minimum for P5 and easily doable. Is there more that
can be incorporated, however?
>
> Dot
>
> On 7/26/07, Conal Tuohy ac.nz> wrote:
> > There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
> >
> > This needs to support the case of a transcript with a single set of page images (i.e. each page would have an optional image file associated with it). The simplest way would be to extend to add a URL attribute pointing to the facsimile graphic. e.g.
> >
> >
> >
> > I believe this is as far as Syd thinks we should go at this point, but I think there is also a strongly felt need for a mechanism to assign graphical coordinates to pieces of text, which we should address. This is most easily done by adding an optional @coords attribute to elements which can appear inside . e.g.
> >
> >

This paragraph is 500x10 pixels.


> >
> > This is about as far as many "facsimile" customisations of TEI have gone, and I think this is also a sensible minimum. NB this minimum would not use elements to encode the facsimile images, hence it does not require a element.
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 26 2007 - 11:12:04 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 26 13:47:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 26 Jul 2007 18:47:43 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABB8@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <20070726174743.GC7248@crow.linux.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 26 Jul 2007 18:47:43 +0100
On Fri, Jul 27, 2007 at 01:19:49AM +1200, Conal Tuohy wrote:
> There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
well, I'd remove the word "minimal". I want facsimile markup
in P5. I want something better than the flawed
hack. I want to explicitly model facsimiles, and discuss
portions of them; and I want to link those to portions
of my text in various ways.
Simple example from my world: gravestones. The stone
has several surfaces ("pages" if you like), for which
I have pictures of various kinds, rubbings etc. There
are several inscriptions on each face, and maybe a graffito.
There are no page breaks in the here to link to,
I use some other structure to represent the surfaces
and the portions of text. Yes, I know a gravestone
isn't a book or a manuscript, but its close.
So please, don't tie us down to page breaks!
Not sure why we are having the philosophical discussion again -
council agreed ages back, strongly, that we want the standoff
facsimile markup in P5. Its just a matter of agreeing
details of the tags, isn't it?

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 13:47:46 EDT

From Conal.Tuohy at vuw.ac.nz Thu Jul 26 17:11:58 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 09:11:58 +1200 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <20070726174743.GC7248@crow.linux.ox.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABBB@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 09:11:58 +1200
Sebastian, can you give a quick outline about you encode the multiple "surfaces" of your gravestones?
I don't see why you could't delimit them in your transcription with and treat them as a kind of page for the purpose of linking the intervening transcriptions with a corresponding . But I'm not familiar with the gravestone markup language.
If it's the mismatch of "page breaks" on a gravestone that irks, we would need some mechanism to link pieces of text with their .
Con

-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Sebastian Rahtz
Sent: Fri 27/07/07 5:47
To: Conal Tuohy
Cc: TEI Council
Subject: Re: [tei-council] facsimile - low-end markup

On Fri, Jul 27, 2007 at 01:19:49AM +1200, Conal Tuohy wrote:
> There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
well, I'd remove the word "minimal". I want facsimile markup
in P5. I want something better than the flawed
hack. I want to explicitly model facsimiles, and discuss
portions of them; and I want to link those to portions
of my text in various ways.
Simple example from my world: gravestones. The stone
has several surfaces ("pages" if you like), for which
I have pictures of various kinds, rubbings etc. There
are several inscriptions on each face, and maybe a graffito.
There are no page breaks in the here to link to,
I use some other structure to represent the surfaces
and the portions of text. Yes, I know a gravestone
isn't a book or a manuscript, but its close.
So please, don't tie us down to page breaks!
Not sure why we are having the philosophical discussion again -
council agreed ages back, strongly, that we want the standoff
facsimile markup in P5. Its just a matter of agreeing
details of the tags, isn't it?

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 17:12:22 EDT

From dporter at uky.edu Thu Jul 26 17:16:23 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 26 Jul 2007 17:16:23 -0400 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABBB@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <96f3df640707261416j47062c60i18eafa2d29368d47@mail.gmail.com>
From: Dot Porter
Date: Thu, 26 Jul 2007 17:16:23 -0400
Would it make a difference if we allowed @url on and
in addition to ? I was going to say milestoneLike but having @url
on and doesn't make quite as much sense.
I would also like to see a separate structure for those
cases when there is more than one set of image files, but I also think
that the proposed pb_at_url = @coords will be useful for a lot of
projects.
Dot
On 7/26/07, Conal Tuohy ac.nz> wrote:
> Sebastian, can you give a quick outline about you encode the multiple "surfaces" of your gravestones?
>
> I don't see why you could't delimit them in your transcription with and treat them as a kind of page for the purpose of linking the intervening transcriptions with a corresponding . But I'm not familiar with the gravestone markup language.
>
> If it's the mismatch of "page breaks" on a gravestone that irks, we would need some mechanism to link pieces of text with their .
>
> Con
>
>
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Sebastian Rahtz
> Sent: Fri 27/07/07 5:47
> To: Conal Tuohy
> Cc: TEI Council
> Subject: Re: [tei-council] facsimile - low-end markup
>
> On Fri, Jul 27, 2007 at 01:19:49AM +1200, Conal Tuohy wrote:
> > There seems to be a consensus that at least a minimal facsimile markup is really needed in P5 version 1.0.
>
> well, I'd remove the word "minimal". I want facsimile markup
> in P5. I want something better than the flawed
> hack. I want to explicitly model facsimiles, and discuss
> portions of them; and I want to link those to portions
> of my text in various ways.
>
> Simple example from my world: gravestones. The stone
> has several surfaces ("pages" if you like), for which
> I have pictures of various kinds, rubbings etc. There
> are several inscriptions on each face, and maybe a graffito.
> There are no page breaks in the here to link to,
> I use some other structure to represent the surfaces
> and the portions of text. Yes, I know a gravestone
> isn't a book or a manuscript, but its close.
>
> So please, don't tie us down to page breaks!
>
> Not sure why we are having the philosophical discussion again -
> council agreed ages back, strongly, that we want the standoff
> facsimile markup in P5. Its just a matter of agreeing
> details of the tags, isn't it?
>
>
> Sebastian
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Jul 26 2007 - 17:16:28 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 26 17:54:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 26 Jul 2007 22:54:27 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABBB@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <20070726215426.GB31253@raven.linux.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 26 Jul 2007 22:54:27 +0100
On Fri, Jul 27, 2007 at 09:11:58AM +1200, Conal Tuohy wrote:
> Sebastian, can you give a quick outline about you encode the multiple "surfaces" of your gravestones?
just multiple
elements with @decls to classify them;
and elements for the lines of text.
> I don't see why you could't delimit them in your transcription with
I could, but it look well odd. And how would I reference
my multiple photos of each surface?
> But I'm not familiar with the gravestone markup language.
plain 'ole TEI....
> If it's the mismatch of "page breaks" on a gravestone that irks,
> we would need some mechanism to link pieces of text with their .
right. back to the ?
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 17:54:31 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Jul 26 17:56:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 26 Jul 2007 22:56:54 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <96f3df640707261416j47062c60i18eafa2d29368d47@mail.gmail.com> Message-ID: <20070726215654.GC31253@raven.linux.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 26 Jul 2007 22:56:54 +0100
On Thu, Jul 26, 2007 at 05:16:23PM -0400, Dot Porter wrote:
> Would it make a difference if we allowed @url on and
> in addition to ? I was going to say milestoneLike but having @url
> on and doesn't make quite as much sense.
till seems very weird to link from a " point of change"
to an image which corresponds to a structural unit.
> I would also like to see a separate structure for those
> cases when there is more than one set of image files, but I also think
> that the proposed pb_at_url = @coords will be useful for a lot of
> projects.
just seems to cut down the concept to a level
of simplicity which is at odds with the rest of the TEI....
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 17:56:58 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Jul 26 18:20:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 26 Jul 2007 23:20:43 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <96f3df640707261416j47062c60i18eafa2d29368d47@mail.gmail.com> Message-ID: <46A91E3B.9000506@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 26 Jul 2007 23:20:43 +0100
Dot Porter wrote:
> Would it make a difference if we allowed @url on and
> in addition to ? I was going to say milestoneLike but having @url
> on and doesn't make quite as much sense.
Rather than sticking a magic attribute on various elements (and
therefore having to decide which ones), wouldn't it be better to use a
special kind of empty element? for example.
The problems with this allegedly simple solution are legion though:
1. It doesn't scale. When I want to enhance my image collection or add
more complex linking I have to throw away what I've done.
2. It depends on special rules that are not explicit in the markup (the
bit of text corresponding with this image starts here and ends ...er...
where exactly? the next in sequence? what if I don't have an
image of the next page, but do have one of the next page but one?
3. The @coords thing is strange. According to the spec I looked at, in
order to do the job properly you actually need two other bits of
information in addition to the magic numbers in the coords. You need to
know what *shape* you are pointing at -- three numbers could mean a
triangle or could mean a circle. And you need to know what is the "base
image" relative to which the co-ords are calculated. (Trivia like units
we leave aside because of course there's only one kind of unit in the
world). To make this work, you have to simplify things by saying "only
rectangular shapes can be defined", and "all coords are relative to the
last mentioned page image".
4. I don't see how this naive solution is going to interoperate with the
way.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 18:27:42 EDT

From conal.tuohy at vuw.ac.nz Thu Jul 26 21:10:01 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 13:10:01 +1200 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <20070726215426.GB31253@raven.linux.ox.ac.uk> Message-ID: <1185498601.19820.149.camel@localhost>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 13:10:01 +1200
On Thu, 2007-07-26 at 22:54 +0100, Sebastian Rahtz wrote:
> On Fri, Jul 27, 2007 at 09:11:58AM +1200, Conal Tuohy wrote:
> > Sebastian, can you give a quick outline about you encode the multiple "surfaces" of your gravestones?
>
> just multiple
elements with @decls to classify them;
> and elements for the lines of text.
o e.g. you could add a before each of these divs:


Kilroy was here





> > I don't see why you could't delimit them in your transcription with
> I could, but it look well odd.
Because pb = page break and gravestones are not really pages?
> And how would I reference
> my multiple photos of each surface?
You would have elements corresponding to those
elements, each of which would contain the graphics which are facsimiles
of that surface, with attributes specifying how the coordinates of those
graphics map onto the coordinates of the surface, like so:

coords="0 0 1000 1000"
scale="1"/>
coords="220 450 100 105"
scale="1.1"/>
coords="220 450 100 105"
scale="0.5"/>
coords="0 0 100 100"
scale="0.1"/>
coords="0 0 1000 1000"
scale="2"/>

> > If it's the mismatch of "page breaks" on a gravestone that irks,
> > we would need some mechanism to link pieces of text with their .
>
> right. back to the ?
Ah yes I think I see what you mean now about not being tied down to page
breaks - do you want to get away from attaching a url directly to a page
break? Or do you want to be able to not use elements at all in
your transcription?
Certainly if you want to have multiple graphics per surface then you do
need a element in order to be able to align the coordinate
spaces of the different graphics, and if you have elements
then you need to put them somewhere, hence the need for a
element or equivalent.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 21:10:08 EDT
From conal.tuohy at vuw.ac.nz Thu Jul 26 23:56:51 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 27 Jul 2007 15:56:51 +1200 Subject: [tei-council] Re: TEI P5 0.8 - the Noah release In-Reply-To: <20070726173253.GB7248@crow.linux.ox.ac.uk> Message-ID: <1185508611.15113.17.camel@localhost>
From: Conal Tuohy
Date: Fri, 27 Jul 2007 15:56:51 +1200
On Thu, 2007-07-26 at 18:32 +0100, Sebastian Rahtz wrote:
> On Thu, Jul 26, 2007 at 12:14:59PM -0400, Syd Bauman wrote:
> >
> > If I had my druthers, actually, in both cases the user would be able
> > to toggle whether model classes are expanded or not, and the default
> > for the Guidelines would be not, and the default for customized would
> > be to list 'em all.
>
> sure, that's probably doable. just some Javascript required.
>
> > Oh. This seems pretty important to me, and so much of it is the same
> > as the Guidelines style ... I certainly hope it is finished by launch
> > date.
>
> well, its all sitting there on Sourceforge for anyone
> who wants to add the functionality :-}
>
> I should note for observers that the design and layout
> of the Guidelines is being coordinated by James C and Dot P.
> You should lobby them, not me! They shall make these
> weighty decisions.
OK - for Dot and Jamies, then: how about listing the class membership in
the @title of each class hyperlink?
e.g. for floatingText we'd have:



Parents




href="ref-model.divPart.html"
title="ab eTree floatingText forest forestGrp graph l lg p
schemaSpec sp tree">
model.divPart




That way you can discover individual elements, and at the same time learn the TEI class structure.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Jul 26 2007 - 23:56:58 EDT
From James.Cummings at computing-services.oxford.ac.uk Fri Jul 27 03:29:55 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 27 Jul 2007 08:29:55 +0100 Subject: [tei-council] Re: TEI P5 0.8 - the Noah release In-Reply-To: <1185508611.15113.17.camel@localhost> Message-ID: <46A99EF3.6090003@computing-services.oxford.ac.uk>
From: James Cummings
Date: Fri, 27 Jul 2007 08:29:55 +0100
Conal Tuohy wrote:
> On Thu, 2007-07-26 at 18:32 +0100, Sebastian Rahtz wrote:
>> On Thu, Jul 26, 2007 at 12:14:59PM -0400, Syd Bauman wrote:
>>> If I had my druthers, actually, in both cases the user would be able
>>> to toggle whether model classes are expanded or not, and the default
>>> for the Guidelines would be not, and the default for customized would
>>> be to list 'em all.
>> sure, that's probably doable. just some Javascript required.
>>
>>> Oh. This seems pretty important to me, and so much of it is the same
>>> as the Guidelines style ... I certainly hope it is finished by launch
>>> date.
>> well, its all sitting there on Sourceforge for anyone
>> who wants to add the functionality :-}
>>
>> I should note for observers that the design and layout
>> of the Guidelines is being coordinated by James C and Dot P.
>> You should lobby them, not me! They shall make these
>> weighty decisions.
>
> OK - for Dot and Jamies, then: how about listing the class membership in
> the @title of each class hyperlink?
That's easy enough I suppose -- I'll add it to the wiki list. My only worry is
that in the case of long lists of members certain browsers clip contents of
title attribute popups at a fixed character list.

-James
>
> e.g. for floatingText we'd have:
>
>
>
>
> Parents
>
>
>
>
>
> href="ref-model.divPart.html"
> title="ab eTree floatingText forest forestGrp graph l lg p
> schemaSpec sp tree">
> model.divPart
>
>
>
>
>
> That way you can discover individual elements, and at the same time learn the TEI class structure.
>
> Con
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 27 2007 - 03:30:00 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Jul 27 04:28:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Jul 2007 09:28:44 +0100 Subject: [tei-council] facsimile - low-end markup In-Reply-To: <1185498601.19820.149.camel@localhost> Message-ID: <46A9ACBC.7020509@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 27 Jul 2007 09:28:44 +0100
Conal Tuohy wrote:
> so e.g. you could add a before each of these divs:
>
>
>
> Kilroy was here
>

>
well, I could, but that seems like tag abuse to me.
"marks the boundary between one page of a
text and the next". there only *is* one page.
>
> You would have elements corresponding to those
> elements, each of which would contain the graphics which are facsimiles
> of that surface, with attributes specifying how the coordinates of those
> graphics map onto the coordinates of the surface,
>
I'm happy with that sort of structure, but in that case
I could link to anything with has an xml:id, and we don't
need to special case
>
> Ah yes I think I see what you mean now about not being tied down to page
> breaks - do you want to get away from attaching a url directly to a page
> break? Or do you want to be able to not use elements at all in
> your transcription?
>
both. I have no to encode; and I want to attach an image to
a container, not a break point.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Jul 27 2007 - 04:28:47 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sat Jul 28 07:37:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 28 Jul 2007 12:37:51 +0100 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABBA@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46AB2A8F.8020406@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 28 Jul 2007 12:37:51 +0100
Sorry for coming late to this, I took my eye off the ball for a week
while panicking about something else.
Conal wrote:
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> Foo
> ...
>
>
This fills me with mild horror. The bit, but
that floating @coords on ? with no specific idea
which image it is, or what the units are?
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
> Foo
> ...
>
>
I can relate to that much better (though I still don't get what units
the coords are in), or which image they relate to.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jul 28 2007 - 06:37:41 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sat Jul 28 07:43:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 28 Jul 2007 12:43:56 +0100 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABBA@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46AB2BFC.8030702@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sat, 28 Jul 2007 12:43:56 +0100
PS I note that HTML image maps link from the
image to the image map (with @usemap). Some
link from to a particular image is need?
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Jul 28 2007 - 06:43:46 EDT
From Syd_Bauman at Brown.edu Sun Jul 29 00:40:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 29 Jul 2007 00:40:05 -0400 Subject: [tei-council] non-enumerated type= attributes (was "Re: type= of ") In-Reply-To: <18091.21756.292131.730442@emt.wwp.brown.edu> Message-ID: <18092.6693.268515.181420@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 29 Jul 2007 00:40:05 -0400
I found that there are 8 definitions of type= that are not
data.enumerated:
* att.typed -- fixed (also subtype=)
* -- was 1 to infinite occurences of data.word; changed
to 1 occurence of data.enumerated. I'm not sure, but some may think
this should stay (rather than become att.typed) because of useful
info in , so left it in tagdoc for now.
* att.pointing -- changed to data.enumerated, but did not make it a
member of att.typed because is helpful
* -- changed to data.enumerated. Some possible values are given
in the . Either should become a member of att.typed, or those
values should be moved to a .
* -- added to att.typed, deleted type= attribute
* -- same as with , except sample values are in ;
also one of the values had a space, changed to underscore
* -- added to att.typed, deleted type= attribute
* -- changed to data.enumerated. provides useful
information.
//tei:attDef[@ident='type']/tei:datatype[not(child::rng:ref[@name='data.enumerated'])]
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 00:40:11 EDT
From Conal.Tuohy at vuw.ac.nz Sun Jul 29 08:46:16 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 30 Jul 2007 00:46:16 +1200 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <46AB2A8F.8020406@oucs.ox.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABBE@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Mon, 30 Jul 2007 00:46:16 +1200
Conal wrote:
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> Foo
> ...
>
>
Sebastian wrote:
> This fills me with mild horror. The bit, but
?

> that floating @coords on ? with no specific idea
> which image it is,
The coords don't relate to a specific image; they are relative to the which represents the current page (i.e. the one linked to the preceding ). The element in the example belongs to that surface because its preceding page break is linked to it. Perhaps you are thinking that the element would include the or other textual elements, in a divLike way? In general I don't think it would be workable to have the element directly contain the textual elements because they have a logical hierarchy of paragraphs, divs, etc, so instead we use elements to link the pages of the transcript with the pages of the facsimile.
> or what the units are?
The units are implicitly pixels I suppose. In the demo I did at Berlin, I made the units explicit. In this current draft under discussion, we are using @coords borrowed from METS, which doesn't seem to have units. I don't know if this is actually an issue, since I think that facsimile images will be bitmaps and hence px is a reasonable unit. WDYT?
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
> Foo
> ...
>
>
Sebastian wrote:
> I can relate to that much better (though I still don't get what units
> the coords are in), or which image they relate to.
Similar to the above.
In this case, the is relative to the which has graphics p1.jpg and p1-thumbnail.jpg. Since the @scale of the first graphic = "1", therefore the coordinates can be interpreted to be equivalent to px in that graphic, whereas the second graphic has px which are 0.1 x that size.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 08:46:42 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 29 13:26:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 29 Jul 2007 18:26:46 +0100 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABBE@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46ACCDD6.5010907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 29 Jul 2007 18:26:46 +0100
Conal Tuohy wrote:
> The coords don't relate to a specific image; they are relative to the which represents the current page (i.e. the one linked to the preceding ). The element in the example belongs to that surface because its preceding page break is linked to it.
hmm. "the preceding " seems like a loose sort of way to work.
>> or what the units are?
>>
>
> The units are implicitly pixels I suppose. In the demo I did at Berlin, I made the units explicit. In this current draft under discussion, we are using @coords borrowed from METS, which doesn't seem to have units. I don't know if this is actually an issue, since I think that facsimile images will be bitmaps and hence px is a reasonable unit. WDYT?
>
If there are several images of a page, at different resolutions, then
the @coords is going to mean different things in different images.
That seems impossibly imprecise. No idea how METS deals with
this problem. And of course it assume bitmap images; do we
rule out ever dealing with vector graphics?
> In this case, the is relative to the which has graphics p1.jpg and p1-thumbnail.jpg. Since the @scale of the first graphic = "1", therefore the coordinates can be interpreted to be equivalent to px in that graphic, whereas the second graphic has px which are 0.1 x that size.
>
gurk. "the second graphic has px which are 0.1 x that size" is not
quite how I would express this. the @coords apply _after_ the scaling???
have I missed somewhere an ODD customization which encapsulate
the current proposal so that I can try it in the wild?
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 12:26:33 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 29 16:44:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 29 Jul 2007 21:44:44 +0100 Subject: [tei-council] fre-standing ODD for (postscript) now up In-Reply-To: <18082.15698.660504.829837@emt.wwp.brown.edu> Message-ID: <46ACFC3C.6060907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 29 Jul 2007 21:44:44 +0100
Syd Bauman wrote:
> The free-standing ODD for the proposed element is now available
> in http://www.tei-c.org/Drafts/ps/. Once again, the schemas provided
> include
among the possible root elements in order to make
> testing easy.
>
> It would be nice if we could make a decision about incorporating this
> into the Guidelines reasonably soon.
>
>
I say we should put it in. I am willing to believe
someone will use it.
It will need to be added to new model.pLike.back, Syd?
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 16:44:49 EDT
From conal.tuohy at vuw.ac.nz Sun Jul 29 18:09:42 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 30 Jul 2007 10:09:42 +1200 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <46ACCDD6.5010907@oucs.ox.ac.uk> Message-ID: <1185746982.24064.3.camel@localhost>
From: Conal Tuohy
Date: Mon, 30 Jul 2007 10:09:42 +1200
> Conal Tuohy wrote:
> > The coords don't relate to a specific image; they are relative to the which represents the current page (i.e. the one linked to the preceding ). The element in the example belongs to that surface because its preceding page break is linked to it.
On Sun, 2007-07-29 at 18:26 +0100, Sebastian Rahtz wrote:
> hmm. "the preceding " seems like a loose sort of way to work.
In what sense "loose"? It seems perfectly clear to me - and of course
you well know that a marks the start of a page - so I'm rather
struggling to see, and address, your point.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 18:13:15 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Jul 29 18:24:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 29 Jul 2007 23:24:08 +0100 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <1185746982.24064.3.camel@localhost> Message-ID: <46AD1388.4050201@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 29 Jul 2007 23:24:08 +0100
Conal Tuohy wrote
> In what sense "loose"? It seems perfectly clear to me - and of course
> you well know that a marks the start of a page
Only "By convention". It's not mandated. I continue to find it
simply odd to attach things to a page break. It just seems the
wrong container.
I may be beating my head on a brick wall [1]
I suppose my problem is that its unusual in the TEI
for element A to be bound to element B simply
by proximity. The normal methods are by explicit link
or by hierarchy.

[1] on the other hand, went to a wedding yesterday,
so the beating head _may_ be due to strong drink.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Jul 29 2007 - 18:24:12 EDT

From cwittern at gmail.com Mon Jul 30 02:56:25 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 30 Jul 2007 15:56:25 +0900 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <46AD1388.4050201@oucs.ox.ac.uk> Message-ID: <46AD8B99.6070808@gmail.com>
From: Christian Wittern
Date: Mon, 30 Jul 2007 15:56:25 +0900
Sebastian Rahtz wrote:
> Conal Tuohy wrote
>> In what sense "loose"? It seems perfectly clear to me - and of course
>> you well know that a marks the start of a page
> Only "By convention". It's not mandated. I continue to find it
> simply odd to attach things to a page break. It just seems the
> wrong container.
The point is that it is not a container and can not be, since the images
and the transcribed text are in different hierarchies and could not be
-- with your gravestones, you do not have the problem, but you will have
heard of it anyway... I also do not find the convention strange to look
for the previous or for certain kinds of processing, something
that is all over the place in my xsl scripts; this simply takes
advantage of the first O in OHCO.

This reminds me that we might want to consider changing the "break" in
the gloss of the elements pb, cb and lb to "begin" to reinforce the
notion that it now is general practice in the text encoding community to
put these things where they start.
All the best,
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 02:56:33 EDT

From cwittern at gmail.com Mon Jul 30 03:02:40 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 30 Jul 2007 16:02:40 +0900 Subject: [tei-council] facsimile - where to encode pages and facsimile graphics? In-Reply-To: <1185462589.6786.2.camel@localhost> Message-ID: <46AD8D10.5060801@gmail.com>
From: Christian Wittern
Date: Mon, 30 Jul 2007 16:02:40 +0900
Daniel O'Donnell wrote:
> I like this.
>
Me too. This looks like a pretty balanced middle road between the
re-implement-METS and hang-it-all-on-pb proposals. And it reflects
accurately the fact that both the and the reflect
different views of the same text. For that reason, I would prefer to
have only one , BTW.
All the best,
Christian
> On Fri, 2007-07-27 at 01:05 +1200, Conal Tuohy wrote:
>
>> I want to address several aspects of the facsimile proposal, starting with this question about where the facsimile graphics should be encoded.
>>
>> I am convinced by Lou that they should not be encoded in the teiHeader. I think he's right that they deserve to be treated more like a text, and I think facsimile is a good name for the element.
>>
>> So, if have it correctly, it would be possible to have (as at present):
>>
>> TEI
>> teiHeader
>> text
>>
>> (for a normal transcript)
>>
>> or:
>>
>> TEI
>> teiHeader
>> facsimile
>> text
>>
>> (for an edition in which the transcript is aligned with facsimile graphics. This is the main use case which Dot and I have had in mind all along)
>>
>> and, finally:
>>
>> TEI
>> teiHeader
>> facsimile
>>
>> (for a "purely graphical" facsimile, without any transcript at all).
>>
>> This last is an odd case, but I have seen something very like it in the wild. The now obsolete digital library software ENCompass (aka Curator) from Endeavour InfoSystems came with TEI support, but it turned out to be a highly customised variant in which a teiHeader was combined with a text consisting of a bunch of page breaks, each with a URL attribute pointing to an image. So there is a case for this already.
>>
>> I'm not sure how useful it would be to have multiple "facsimile" elements within the same TEI document. It need not require more than one such element, e.g.
>>
>> element TEI
>> {
>> att.global.attributes,
>> attribute version { xsd:decimal }?,
>> ( teiHeader, facsimile?, text )
>> }
>>
>> On the other hand, I'm open-minded about this, and I would be happy with any alternative. Obviously it has to be decided one way or another, but the other parts of the facsimile model are more crucial to the actual functionality of the encoding.
>>
>> Con
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 03:02:54 EDT

From cwittern at gmail.com Mon Jul 30 03:20:42 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 30 Jul 2007 16:20:42 +0900 Subject: [tei-council] next telecon 2007-08-02 at 1200 UTC Message-ID: <46AD914A.6040003@gmail.com>
From: Christian Wittern
Date: Mon, 30 Jul 2007 16:20:42 +0900
Dear Council members,
As you might have noticed, I am back in circulation and just spend a few
hours filing through the 109 messages from the Council list and the 88
messages on TEI-L that had accumulated in my absence. It looks like a lot
of ground got covered. Great! We are only a few steps away from
integrating the last minute changes in to the Guidelines, or so it seems to me.
After the acoustical thunderstorm of the last telecon, I would like to
switch back to the Indiana system for this call. John, could you please set
up things and post a message here how to connect?
Please look again at the minutes at
http://www.tei-c.org/Council/tcm32.xml?style=printable and report here on
progress as far as possible.
I would like to keep this as short as possible, but if there are issues that
would not come up in the list of active work items, please drop me a line so
that I can put it on the agenda.

All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 03:20:48 EDT

From cwittern at gmail.com Mon Jul 30 03:31:56 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 30 Jul 2007 16:31:56 +0900 Subject: [tei-council] Proposal for choice, model.pPartEdit, and model.choicePart In-Reply-To: <1185217388.25461.35.camel@localhost> Message-ID: <46AD93EC.7050008@gmail.com>
From: Christian Wittern
Date: Mon, 30 Jul 2007 16:31:56 +0900
I wonder where we stand on this now? Dan, did you integrate Matthews
suggestions as far as they seem reasonable to you? It would be good to
have one aggregated proposal to consider.
All the best,
Christian
Daniel O'Donnell wrote:
> I think we need to be a little careful with Matthew's proposals: I've
> long wanted some kind of emend element (i.e. something similar to edInt,
> but I'm not convinced that edInt is actually different from a relatively
> clear existing distinction in some of the use cases proposed:
>
>
>
>> 1. Scribal and editorial emendations
>> The elements and should be retained and used as they are
>> currently, i.e for additions and deletions physically present in the
>> manuscript, whether the actions of the scribe at the time of writing
>> or of a later hand. A element should be added for indicating
>> cases where and constitute a substitution:
>>
>>

my brain
>> rend="overstrike">burns
>> place="margin">hurts.


>>
>
> I like this, but I think we should see it for what it is: a
> specialisation of choice (in this case, choice_at_type="substitution").
> I'll deal with the claim that it is not choice below. The reason I like
> this as a proposal is that semantically substitution is a recognised
> example of (let's call it authorial for the moment) alterity in the
> proposal. In terms of my proposal, it helps address the issue of the
> janus-y pair del : add, since it provides a specific "authorial" axis
> for a specialised form of choice to work along. This may also help
> clarify restore, which can also be seen as a semantically specific form
> of choice--albeit one that for reasons of parsimony we don't have the
> "other" state explicitly mentioned.
>
> So yup. I'd add "subst" to model.pPartEdit alongside choice and restore,
> and model.choicePart. I wouldn't change model.choicePart, but you could
> either just add add and del to the content model of "subst" or we could
> create a class model.pPartSubstitution parallel to model.pPartRestore.
>
>
>> The element should be retained for text now illegible or
>> lost through damage but assumed originally to have been in the
>> manuscript (what used to be supplied reason="illegible|damage"), and
>> for the expansion of abbreviations -- these are both arguably things
>> which are present in the manuscript, but where a degree of
>> interpretation is required on the part of the editor.
>>
>
> I like this. It is a little bit more narrow than the current use of
> substitution (which can also be used with gap, where the point is that
> the text might NOT have been in the original), but the new semantics are
> easy to explain and very clear ("This element is used to supply text
> that arguably once existed in the physical witness").
>
> It does raise the question (which also came up in Berlin), if we should
> not consider whether gap is doing to much, when it represents both
> physically missing material (i.e. due to a hole in the MS) and
> intellectually missing material, due to editorial sampling decisions,
> for example, or saute meme a meme. We could end up in a situation where
> the constraint on whether supplied is used with gap is purely semantic:
> if you are using gap because the text that was there is now physically
> missing, use supplied to restore the text; if you are using gap to
> describe text missing due to an error or a sampling decision, do not
> restore with supplied.
>
> How about if we split these two functions: for material that
> once was in the text but is now lost (for which would be an
> appropriate indicated of the alternate state) and for material
> that was never present in the physical witness or has been omitted from
> the transcription for sampling reasons. In this case, "supplied" would
> be inappropriate for indicating the alternate state and "edInt" should
> be used instead.
>
>
>> Add an element, for "editorial intervention", where an editor,
>> believing the manuscript to be incorrect or corrupt, supplies,
>> suppresses or otherwise alters the text (note the specific means of
>> indicating each of these three cases in traditional printed
>> editions).
>>
>
> I like this (though not the name) if we consider this as basically an
> "editorial" parallel to "supplied." What we are talking about here is
> basically emendation. Rather than edInt what if we called it emend or
> edit?
>
> Now come the problems:
>
>> In the first case, the editor supplies text assumed to have been
>> inadvertently omitted by the scribe:
>>
>>

my brain hur
>> cert="high">ts.


>>
>
> Sure. But since we also think it is an error (hurs is clearly understood
> here as sic for hurts), what is wrong with and ?
>
>
>> In the second, the editor suppresses superfluous text in the
>> manuscript, for example arising through a dittography:
>>
>>

my brain hur
>> cert="high">urts.


>>
>
> I suppose: but again, what about sic and corr? Again, hururts is also a
> misspelling of hurts.
>
>
>> In the third the editor corrects a misspelt word, substitutes one word
>> for another, or rearranges the order of the words in the text of the
>> manuscript. In this case the existing and should be used:
>>
>>

my
>> cert="high">brianbrain hurts.


>>
>
> This I really disagree with. First of all, apparent we are privileging
> dittography and simple omission of letters over alteration in order. In
> my view all three are spelling mistakes, something we already have an
> editorial tag set for describing, sic and corr. Secondly, this specific
> use of edInt is quite different from the previous two: here edInt is
> being used as a special kind of choice, parallel to subst (pace to
> below); in the other two it is a special kind/alternate editorial form
> of supplied. I think this distinction needs to be cleaned up.
>
>> The resp and cert attributes may be used to indicate the person
>> responsible for the addition, suppression or emendation and the degree
>> of certainty. Where the reading of another witness supports the
>> reconstruction the source attribute may also be used, providing for
>> example the sigil of the other witness.
>>
>> Note: I don't think this makes or sub-types of
>> , since one would frequently want both the added and deleted
>> or original and emended forms to appear, whereas implies that
>> only one of the two options can be used at any one time.)
>>
>
> Only the name "choice" suggests this. Both actual usage and the
> description (narrative and the slightly erroneous version in the
> Appendix indicate that choice describes alterity. A use case showing
> that both options of choice can be showing is choice/abbr|expan. We
> commonly print both options the first time a name that will subsequently
> be abbreviated is used; after that we tend to use either abbr or expan
> (without choice). So something you might very easily encode thus
>
>
>
>> This proposal is intended for the
>>
>> Text Encoding Initiative
>> TEI
>>
>>
>
> Will very commonly be rendered
>
>
>
>> This proposal is intended for the Text Encoding Initiative (TEI).
>>
>
>
> I would strongly argue that choice is to subst (and this use of edInt)
> as ab is to p, and seg to any phrase element: a generic case that is
> semantically and syntactically narrowed by the other options in order to
> cover specific cases.
>
> Secondly, I would strongly argue that the basic pattern of all
> choiceLike elements is choice/option|option where option can be either a
> child of choice or used on its own when alterity is not required--but
> that options should not also be able to substitute for choice. So we
> should allow this (option is a currently non-existent generic element
> intended to stand for elements like abbr and expan):
>
>
>
>
>
>
> or
>
>
>
>
>
>
>
>
>
>
> But neither
>
>
>
>
>
>
> nor
>
>
>
>
>
>
>
>
>
>
> In other words, we should consider very carefully whether an element is
> *either* the choiceLike container, or the optionLike option; but the
> same element should not be capable of both expressing an alternate state
> and directly containing options expressing alternate states.
>
>
>
> On Mon, 2007-07-23 at 11:08 -0400, Dot Porter wrote:
>
>> On 7/23/07, Arianna Ciula ac.uk> wrote:
>>
>>
>>> I think lots of people (especially modernists) will be happy to see a
>>> proposed differentiation between authorial and editorial interventions.
>>>
>>> Arianna
>>>
>> I agree that differentiating between authorial and editorial
>> interventions would be a valuable addition to the Guidelines.
>>
>> Dot
>>
>>
>>>> Comments?
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> Here is the first of two proposals relating to my concerns around choice
>>>>> and app/rdg:
>>>>> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-revisions-to-choice-app-and-modelppartedit
>>>>>
>>>>>
>>>>> I'
>>>>>
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council_at_lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>> --
>>> Dr Arianna Ciula
>>> Research Associate
>>> Centre for Computing in the Humanities
>>> King's College London
>>> Strand
>>> London WC2R 2LS (UK)
>>> Tel: +44 (0)20 78481945
>>> http://www.kcl.ac.uk/cch
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council_at_lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>>
>>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 03:32:04 EDT

From cwittern at gmail.com Mon Jul 30 03:38:52 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 30 Jul 2007 16:38:52 +0900 Subject: [tei-council] rdg content model In-Reply-To: <1185229218.14934.4.camel@localhost> Message-ID: <46AD958C.6080007@gmail.com>
From: Christian Wittern
Date: Mon, 30 Jul 2007 16:38:52 +0900
Daniel O'Donnell wrote:
> Here is a link to my proposal for expanding the content model for
> rdg/lem:
> http://people.uleth.ca/~daniel.odonnell/Research/a-proposal-for-including-chunk-inter-and-div-level-children-of-teirdg-and-tei-lemma
>
> The proposal is very straightforward: add the ability for chunk, div,
> and text level elements to appear as children of rdg. I've provided
> examples of each from the apparatus to the Riverside Chaucer, since
> there was some doubt that such collations actually existed.
>
I like this a lot, since I have banging my head at this very problem a
couple of times. Purist might wince that this gives you much more
changes to shoot yourself in the foot, but we have to take some risks in
life. I was wondering though, if you would allow parts of the
apparatus nest, for example

Here is some stuff in witness
one
We have some other stuff

> Finally I make a smaller suggestion that since, as has been pointed out
> here, lem and rdg are extremely similar, we should put lem in
> model.rdgLike. It is not at all clear to me why we so emphatically
> exclude it (we mention this exclusion in the narrative).
>
>
+1
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 03:39:00 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 30 04:31:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Jul 2007 09:31:27 +0100 Subject: [tei-council] facsimile - how to do stand-off facsimile markup? In-Reply-To: <46AD8B99.6070808@gmail.com> Message-ID: <46ADA1DF.8020009@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 30 Jul 2007 09:31:27 +0100
Christian Wittern wrote:
>
> This reminds me that we might want to consider changing the "break" in
> the gloss of the elements pb, cb and lb to "begin" to reinforce the
> notion that it now is general practice in the text encoding community
> to put these things where they start.
it may be obvious to the TEI community, but others (I note minor systems
like HTML, Word, TeX)
think that line breaks come at the end of lines. Show me any other
system which starts a document with a
page break and a line break!
but I agree, changing "break to begin" would at least make it unambiguous.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 04:31:32 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 30 11:55:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 30 Jul 2007 16:55:52 +0100 Subject: [tei-council] next telecon 2007-08-02 at 1200 UTC In-Reply-To: <46AD914A.6040003@gmail.com> Message-ID: <46AE0A08.1000705@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 30 Jul 2007 16:55:52 +0100
Could we discuss the issue Elena Pierazzo has just raised on the Council
list about the overlap between and ?
I think it would be a shame to remove : my tentative proposal
would be to add it as an optional element within , removing it
from model.profileDescPart. This would mean you couldnt do it without
including msDesc module but as Elena suggests this may not be such an
imposition.
(Incidentally, I just noticed that handShift is also a member of
model.profileDescPart: this is definitely bonkers, so I am removing it)

Christian Wittern wrote:
> Dear Council members,
>
> As you might have noticed, I am back in circulation and just spend a few
> hours filing through the 109 messages from the Council list and the 88
> messages on TEI-L that had accumulated in my absence. It looks like a lot
> of ground got covered. Great! We are only a few steps away from
> integrating the last minute changes in to the Guidelines, or so it seems to me.
>
> After the acoustical thunderstorm of the last telecon, I would like to
> switch back to the Indiana system for this call. John, could you please set
> up things and post a message here how to connect?
>
> Please look again at the minutes at
> http://www.tei-c.org/Council/tcm32.xml?style=printable and report here on
> progress as far as possible.
>
> I would like to keep this as short as possible, but if there are issues that
> would not come up in the list of active work items, please drop me a line so
> that I can put it on the agenda.
>
>
> All the best,
>
> Christian
>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 12:03:10 EDT

From Syd_Bauman at Brown.edu Mon Jul 30 13:53:03 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 30 Jul 2007 13:53:03 -0400 Subject: [tei-council] time is running out ... and Message-ID: <18094.9599.159461.557796@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 30 Jul 2007 13:53:03 -0400
Christian (and all) --
We need to decide what we are going to do, if anything, with
and pretty fast.

On
-- ----
As per council's request in Berlin, rather than checking into
P5, I ripped it out and made a stand-alone ODD of it
(http://www.tei-c.org/Drafts/ps/). The ostensible point of this
exercise was that having an element to encode postscripts is
controversial enough that it was too scary for me to check it
directly into P5. This means, IMHO, that we need an explicit vote to
include this element in P5 or not. I think we need to make this
decision ASAP.
So far Sebastian has said he thinks it should go in, and Lou has
tangentially implied that he doesn't. I am in favor of including it.

On et al.
-- --------- -- ---
I think the current situation is broken. I am quite confident, e.g.,
that at least 2 of the projects I work with at Brown would re-define
(to be roughly what it used to be) rather than use it as it
is now.
* The element should have a quantity= attribute, not
extent= (and preferably not count=, although that's a lot better
than extent=).
* should not have a scope= attribute (unless someone wants
to put in some work figuring out what a scope= might usefully mean
for a generic ).
* The "suggested values include" list for unit= of should
be pretty much as all-encompassing as we can get it.
* The , , and elements should not have a
commodity= attribute.
* The , , and elements should have a scope=
attribute (they currently do; the point of my saying this is to
contrast it with ).
* The "suggested values include" list for unit= of , ,
and should be very limited (the list that is currently
there looks good to me; again the point of mentioning this is that
it is very different from unit= of , for which the current
list seems inappropriate to me).
* The amount attribute on , , and could be
named quantity= or extent=, or for that matter, value=.
In tabular form, what I think we should do could be summarized as
follows.
,
, and

---------------- ---------------------
name of
amount
attribute: quantity= extent=
cope= no yes
uggested extensive very short
values for semi-closed closed or semi-closed
unit=: list list

In addition, I think that should not have text content.
If Council is persuaded by Lou's arguments as to why it should have
textual content ("As I remember the discussion, we recognises that
most institutions would always supply dimensions in their own
specific sequence, and might not want therefore to tag the height
etc. explicitly. Compare the element, which just knows that you
give lat and long in that order.") rather than my counter argument
(which boils down to "for consistency grouping elements should not
have textual content, and is a poor model, as it is poorly
defined"), then we should come up with a different name, like
or .
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 13:53:27 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 30 14:36:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 30 Jul 2007 19:36:29 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.9599.159461.557796@emt.wwp.brown.edu> Message-ID: <46AE2FAD.1040702@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 30 Jul 2007 19:36:29 +0100
Syd Bauman wrote:
> Christian (and all) --
>
> We need to decide what we are going to do, if anything, with
> and pretty fast.
>
>
> On
> -- ----
> As per council's request in Berlin, rather than checking into
> P5, I ripped it out and made a stand-alone ODD of it
> (http://www.tei-c.org/Drafts/ps/). The ostensible point of this
> exercise was that having an element to encode postscripts is
> controversial enough that it was too scary for me to check it
> directly into P5. This means, IMHO, that we need an explicit vote to
> include this element in P5 or not. I think we need to make this
> decision ASAP.
>
> So far Sebastian has said he thinks it should go in, and Lou has
> tangentially implied that he doesn't. I am in favor of including it.
>
I didn't tangentially or otherwise imply any opinion on the
proposal because I havent had time to read it yet. What I did say was
that I thought getting such a feature into P5 1.0 was of less urgency
or importance than progressing the work on digital facsimile editions to
the point that it is usable in P5 1.0, and I still do!
>
> On et al.
> -- --------- -- ---
> I think the current situation is broken. I am quite confident, e.g.,
> that at least 2 of the projects I work with at Brown would re-define
> (to be roughly what it used to be) rather than use it as it
> is now.
>
This issue seems to me to be even further down the scale of importance
than
Does anyone know of any project (other than at Brown) which wants to use
in the way that Syd seems to wish? However, not to appear
churlish, here are some quick comments on this issue.
> * The element should have a quantity= attribute, not
> extent= (and preferably not count=, although that's a lot better
> than extent=).
>
>
As already indicated, I have no problem with changing the name of the
attribute (in fact I think I proposed it)
However all of Syd's subsequent points really boil down the fact that
his view of what a generic element should be like turns out
not to be able to support what people want to do when recording the
measurements of manuscript page/s.
The Berlin Council meeting made the suggestion that we should try to use
generic for this purpose, and I implemented what I understood
was wanted, despite some misgivings about the fact that measurements of
pages are rather different from quantities of stuff. This was done quite
some time ago and till now no-one has complained about it.
> * should not have a scope= attribute (unless someone wants
> to put in some work figuring out what a scope= might usefully mean
> for a generic ).
>
It makes no difference whether the is generic or not. If I was
obsessive enough to mark up as a measure sentences such as "The cart
contained five six-gallon jugs" as
"five six gallon jugs" I could use @scope to
indicate whether all five were exactly 6 gallon jugs, or most of them
were, or some of them were only 5.7 gallons. I freely concede that to
do this you'd have to completely mad, but that doesn't affect the issue
of what the @scope attribute means.
> * The "suggested values include" list for unit= of should
> be pretty much as all-encompassing as we can get it.
>
>
I think this is a silly idea. We don't supply exhaustive lists of
language identifiers, but refer to places where people can find them.
Same applies to standard names for units.
> * The , , and elements should not have a
> commodity= attribute.
>
>
Indeed not.
> * The , , and elements should have a scope=
> attribute (they currently do; the point of my saying this is to
> contrast it with ).
>
>
ee above.
> * The "suggested values include" list for unit= of , ,
> and should be very limited (the list that is currently
> there looks good to me; again the point of mentioning this is that
> it is very different from unit= of , for which the current
> list seems inappropriate to me).
>
>
if you want etc. to exist as specialisations of
clearly you can suppress whatever attributes you like in them,
> * The amount attribute on , , and could be
> named quantity= or extent=, or for that matter, value=.
>
> In tabular form, what I think we should do could be summarized as
> follows.
> ,
> , and
>
> ---------------- ---------------------
> name of
> amount
> attribute: quantity= extent=
>
> scope= no yes
>
> suggested extensive very short
> values for semi-closed closed or semi-closed
> unit=: list list
>
>
> In addition, I think that should not have text content.
> If Council is persuaded by Lou's arguments as to why it should have
>
> textual content ("As I remember the discussion, we recognises that
> most institutions would always supply dimensions in their own
> specific sequence, and might not want therefore to tag the height
> etc. explicitly. Compare the element, which just knows that you
> give lat and long in that order.") rather than my counter argument
> (which boils down to "for consistency grouping elements should not
> have textual content, and is a poor model, as it is poorly
> defined"), then we should come up with a different name, like
> or .
>
>
We used to have but Council told us to take it away. I'm
perfectly happy to bring it back.

> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 14:43:46 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 30 16:31:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Jul 2007 21:31:10 +0100 Subject: [tei-council] reminder re actions Message-ID: <46AE4A8E.5060105@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 30 Jul 2007 21:31:10 +0100
Looking at the list of actions from last minute, I believe the status is
as follows.
You all may wish to look for your names :-}
Sebastian

TODO
1. Eds Implement Board decision with regard to title page. 2007-07-20
IN PROGRESS
2. CW Draft list of workgroups and their members for editors. 2007-08-01
DONE
3. SB move postscript to a free standing ODD. 2007-08-01
DONE
4. SB Post reminder of the current

problems to council list.
2007-07-20
TODO
5. JW Rewrite rendition recommendations and evaluate whether possible
for P5 1.0 2007-08-01
6. LB Prepare the ground for changes to rendition/@rend/@rendRef in P5
1.1 if JW's recommendations are unable to be included in P5 1.0 2007-08-01
IN PROGRESS
7. LB, CT, DP (and ALL) Discuss work on facsimile markup on council
list.2007-07-24
8. LB, CT, DP Hammer out final P5 1.0 draft of facsimile markup. 2007-08-01
TODO
9. SB Make concrete proposal with regard to merging of Corpus chapter
into DS or teiCorpus/teiGroup. 2007-07-20
10. LB Implement any council-approved recommendations concerning the
merging of Corpus into DS.2007-08-01
TODO
11. DB, TMB, SB, LB Review prose of NH and discuss on council list
from 1 August, providing rewritten chapter by mid August. 2007-08-15
TODO
12. LR Provide any further changes to Dictionary chapter in light of
discussion and submit to Eds.2007-08-1
13. Eds Editors to integrate final Dictionary revisions into
Guidelines.2007-08-15
DONE
14. LB To continue to encourage community feedback until 2007-07-27
TODO
15. LB Revise person/places draft with regard to TEI Community
comment, announce final draft version on mailing list. 2007-08-01
TODO
16. LB Report back to council on any changes to FSD/FS and if
necessary rationalise the TEI version. 2007-08-15
IN PROGRESS
17. LB Revise add/del/supplied issues (e.g.trac 301, 331) 2007-08-01
IN PROGRESS
18. JC, DP Report back to council on progress of formatting of the
Guidelines so far and any outstanding issues 2007-08-03
19. JC, DP All issues should be resolved and/or reported to Sebastian
and/or Council 2007-09-07
IN PROGRESS
20. DO Report back to Council with proposal for any changes to app/rdg
2007-07-20
DONE
21. SB SB to finalise new || element and add to guidelines.
2007-08-01
TODO?
22. ALL Provide comments on DB's proposals for modelling stemmata.
2007-07-20
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 16:30:51 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 30 17:05:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Jul 2007 22:05:26 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE2FAD.1040702@computing-services.oxford.ac.uk> Message-ID: <46AE5296.8030501@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 30 Jul 2007 22:05:26 +0100
I tried to review this discussion in order to contribute something,
but I just cannot get a handle on it.
My tiny votes are
- I think the issue of whether to give a list of suggested types of units
is pure administrivia. Lou and Syd should sort that out on their own.

- @extent looks weird. @quantity better.

- @scope I simply dont grok at all, and cannot imagine ever using. You
bother to supply a measurement, but then cross your fingers behind
your back and say "well, maybe not". I'd leave it out :-}
- @commodity similarly. If you cant agree, throw it out
- plain text in . can someone remind me the use case
for this? at first sight (looking at the examples) I don't see it.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:05:06 EDT
From lou.burnard at computing-services.oxford.ac.uk Mon Jul 30 17:08:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 30 Jul 2007 22:08:17 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE5296.8030501@oucs.ox.ac.uk> Message-ID: <46AE5341.4010406@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 30 Jul 2007 22:08:17 +0100
Sebastian Rahtz wrote:
> I tried to review this discussion in order to contribute something,
> but I just cannot get a handle on it.
>
>
> - @scope I simply dont grok at all, and cannot imagine ever using. You
> bother to supply a measurement, but then cross your fingers behind
> your back and say "well, maybe not". I'd leave it out :-}
It's intended for uses where you want to say "the measurements of most
pages in this book are x y z; but it's not guaranteed that all of them
are (some have been gnawed by moths)". It was present in the
element in ms description.
>
> - @commodity similarly. If you cant agree, throw it out
this is needed for normalising historical data (because e.g. 1 imperial
flarg of hops is different from 1 imperial flarg of treacle)
>
> - plain text in . can someone remind me the use case
> for this? at first sight (looking at the examples) I don't see it.
12 x 11 x 4
(i.e. what used to be inside )
Really, I think the best solution is to bring back !

>
> Sebastian
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:15:36 EDT

From Syd_Bauman at Brown.edu Mon Jul 30 17:16:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 30 Jul 2007 17:16:14 -0400 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE5296.8030501@oucs.ox.ac.uk> Message-ID: <18094.21790.743549.626199@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 30 Jul 2007 17:16:14 -0400
> - @commodity similarly. If you cant agree, throw it out
Quoting P3 (so no one can accuse me of having changed the definition
to suit my needs):
| : contains a word or phrase referring to some quantity of
| an object or commodity, usually comprising a number, a unit
| and a commodity name.
| In its fullest form, a measure consists of a number, a phrase
| expressing units of measure and a phrase expressing the commodity
| being measured. Not all of these components need be present in
| every case.
Seems to me since there are 3 components to a measure, there should
be three attributes for regularizing 'em.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:16:19 EDT
From Syd_Bauman at Brown.edu Mon Jul 30 17:18:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 30 Jul 2007 17:18:09 -0400 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE5341.4010406@computing-services.oxford.ac.uk> Message-ID: <18094.21905.891655.794820@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 30 Jul 2007 17:18:09 -0400
> Really, I think the best solution is to bring back !
I don't know that it's *best*, because I haven't really thought
through all the various possibilities, but I agree that it would be a
good solution, and better than what we have now.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:18:13 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 30 17:40:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Jul 2007 22:40:08 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE5341.4010406@computing-services.oxford.ac.uk> Message-ID: <46AE5AB8.1050302@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 30 Jul 2007 22:40:08 +0100
Lou Burnard wrote:
> It's intended for uses where you want to say "the measurements of most
> pages in this book are x y z; but it's not guaranteed that all of them
> are (some have been gnawed by moths)".
you MS guys are weird....
>
>>
>> - plain text in . can someone remind me the use case
>> for this? at first sight (looking at the examples) I don't see it.
>
> 12 x 11 x 4
I have to agree with Syd that this seems at odds with the rest of
.
Using notation like "12 x 11 x 4" is on a level of evil with
Becket, Samuel (1921-1996)
>
> Really, I think the best solution is to bring back !
yes. it would seem much more honest to have as a container
for text.
but all this is small beer compared to and friends.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:39:49 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Jul 30 17:42:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Jul 2007 22:42:37 +0100 Subject: [tei-council] next telecon 2007-08-02 at 1200 UTC In-Reply-To: <46AE0A08.1000705@computing-services.oxford.ac.uk> Message-ID: <46AE5B4D.9020000@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 30 Jul 2007 22:42:37 +0100
Lou Burnard wrote:
> Could we discuss the issue Elena Pierazzo has just raised on the Council
> list about the overlap between and ?
>
>
you could raise the relationship betweem and
if you feel strong.... :-{
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 17:42:17 EDT
From Syd_Bauman at Brown.edu Mon Jul 30 18:04:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 30 Jul 2007 18:04:59 -0400 Subject: [tei-council] time is running out ... and In-Reply-To: <46AE2FAD.1040702@computing-services.oxford.ac.uk> Message-ID: <18094.24715.429153.641359@emt.wwp.brown.edu>
From: Syd Bauman
Date: Mon, 30 Jul 2007 18:04:59 -0400
> > * The "suggested values include" list for unit= of should
> > be pretty much as all-encompassing as we can get it.
> >
> I think this is a silly idea. We don't supply exhaustive lists of
> language identifiers, but refer to places where people can find them.
> Same applies to standard names for units.
But we don't supply a list of language identifiers because we can't,
they're combinatorial. Just including language, script, and region
subtags (i.e. not including variant, extension, and of course not
private use subtags), there are over 17 million possibilities.[1]
If we all put our heads together and tried I doubt we'd come up with
100 units.

Notes
-----
[1] Yes, probably a good portion of those are non-sensical
combinations, like English written in Cyrillic in Latin America.
Doesn't matter. Even if only 1% of the combinations are sensible,
that's still over 170,000 of 'em.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 18:05:03 EDT

From lou.burnard at computing-services.oxford.ac.uk Mon Jul 30 18:16:27 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 30 Jul 2007 23:16:27 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.24715.429153.641359@emt.wwp.brown.edu> Message-ID: <46AE633B.3030806@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Mon, 30 Jul 2007 23:16:27 +0100
Syd Bauman wrote:
>>> * The "suggested values include" list for unit= of should
>>> be pretty much as all-encompassing as we can get it.
>>>
>>>
>> I think this is a silly idea. We don't supply exhaustive lists of
>> language identifiers, but refer to places where people can find them.
>> Same applies to standard names for units.
>>
>
> But we don't supply a list of language identifiers because we can't,
> they're combinatorial. Just including language, script, and region
> subtags (i.e. not including variant, extension, and of course not
> private use subtags), there are over 17 million possibilities.[1]
>
> If we all put our heads together and tried I doubt we'd come up with
> 100 units.
>
>
There are quite a few SI units too if you take into account the prefixes!
But I stand by the assertion that it just makes the TEI look silly to
tell people what unit to use for e.g. electrical resistivity.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 18:23:45 EDT

From Conal.Tuohy at vuw.ac.nz Mon Jul 30 18:59:35 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 31 Jul 2007 10:59:35 +1200 Subject: [tei-council] next telecon 2007-08-02 at 1200 UTC In-Reply-To: <46AE5B4D.9020000@oucs.ox.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABC8@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Tue, 31 Jul 2007 10:59:35 +1200
I meant to reply to this point when James brought it up.
I think it's an easy one, actually.
The surrogates element is a container for information about digital or photographic surrogates of the manuscript.
The example at http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-surrogates.html uses elements to describe the different sets of surrogates, but really this information is not required to have any particular structure, unlike the proposed facsimile markup. I don't think needs to change.



diapositive
AM 74 a, fol.
May 1984


b/w prints
AM 75 a, fol.
1972



Clearly, if the the hypothetical document (from which the above example is drawn) also used the facsimile markup to record the graphics, then the 2 elements in this example would correspond to 2 distinct sets of elements. Each such could use @corresp to point to the that describes it, or perhaps more meaningfully, if graphic were added to the att.declaring class, it could use @decls to point to a bibl that describes it.
http://tei.oucs.ox.ac.uk/Query/tag.xq?name=att.declaring
Cheers
Con
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Sebastian Rahtz
Sent: Tue 31/07/07 9:42
To: Lou Burnard
Cc: TEI Council
Subject: Re: [tei-council] next telecon 2007-08-02 at 1200 UTC

Lou Burnard wrote:
> Could we discuss the issue Elena Pierazzo has just raised on the Council
> list about the overlap between and ?
>
>
you could raise the relationship betweem and
if you feel strong.... :-{
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 19:00:27 EDT
From conal.tuohy at vuw.ac.nz Mon Jul 30 19:38:51 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 31 Jul 2007 11:38:51 +1200 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.9599.159461.557796@emt.wwp.brown.edu> Message-ID: <1185838731.14375.17.camel@localhost>
From: Conal Tuohy
Date: Tue, 31 Jul 2007 11:38:51 +1200
On Mon, 2007-07-30 at 13:53 -0400, Syd Bauman wrote:
> On
> -- ----
> As per council's request in Berlin, rather than checking into
> P5, I ripped it out and made a stand-alone ODD of it
> (http://www.tei-c.org/Drafts/ps/). The ostensible point of this
> exercise was that having an element to encode postscripts is
> controversial enough that it was too scary for me to check it
> directly into P5. This means, IMHO, that we need an explicit vote to
> include this element in P5 or not. I think we need to make this
> decision ASAP.
>
> So far Sebastian has said he thinks it should go in, and Lou has
> tangentially implied that he doesn't. I am in favor of including it.
I am all in favour of . Let's have it, please!
> On et al.
> -- --------- -- ---
> I think the current situation is broken. I am quite confident, e.g.,
> that at least 2 of the projects I work with at Brown would re-define
> (to be roughly what it used to be) rather than use it as it
> is now.
>
> * The element should have a quantity= attribute, not
> extent= (and preferably not count=, although that's a lot better
> than extent=).
I agree "quantity" is a more suitable word.
> * should not have a scope= attribute (unless someone wants
> to put in some work figuring out what a scope= might usefully mean
> for a generic ).
I don't understand the issue here. Why is @scope out of scope? :-)
> * The "suggested values include" list for unit= of should
> be pretty much as all-encompassing as we can get it.
As others have mentioned, this list would be prohibitively large. I
suggest we give a few examples of SI units, and perhaps 1 or 2 ISO 4217
currency codes, and leave it at that. IMHO it would be good to include
an example in which obsolete units are re-expressed in modern units,
e.g.
1 foot-pound
> * The , , and elements should not have a
> commodity= attribute.
agree
> * The , , and elements should have a scope=
> attribute (they currently do; the point of my saying this is to
> contrast it with ).
why?
It seems to me that @scope is in no way tied to the concept of distance,
but perhaps I'm missing something?
> * The "suggested values include" list for unit= of , ,
> and should be very limited (the list that is currently
> there looks good to me; again the point of mentioning this is that
> it is very different from unit= of , for which the current
> list seems inappropriate to me).
>
> * The amount attribute on , , and could be
> named quantity= or extent=, or for that matter, value=.
I like @extent but I'm not fussed
> In addition, I think that should not have text content.
> If Council is persuaded by Lou's arguments as to why it should have
> textual content ("As I remember the discussion, we recognises that
> most institutions would always supply dimensions in their own
> specific sequence, and might not want therefore to tag the height
> etc. explicitly. Compare the element, which just knows that you
> give lat and long in that order.") rather than my counter argument
> (which boils down to "for consistency grouping elements should not
> have textual content, and is a poor model, as it is poorly
> defined"), then we should come up with a different name, like
> or .
ure
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Jul 30 2007 - 19:39:04 EDT
From cwittern at gmail.com Mon Jul 30 19:58:52 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 31 Jul 2007 08:58:52 +0900 Subject: [tei-council] next telecon 2007-08-02 at 1200 UTC In-Reply-To: <46AE0A08.1000705@computing-services.oxford.ac.uk> Message-ID: <46AE7B3C.2080604@gmail.com>
From: Christian Wittern
Date: Tue, 31 Jul 2007 08:58:52 +0900
Lou Burnard wrote:
> Could we discuss the issue Elena Pierazzo has just raised on the Council
> list about the overlap between and ?
>
On TEI-L in fact, since she is not a member of the Council. Yes, I will
add this to the agenda, but would prefer if arguments pro and con could
be brought forward here and now, so that we can flesh out what needs to
be done right away.
> I think it would be a shame to remove : my tentative proposal
> would be to add it as an optional element within , removing it
> from model.profileDescPart. This would mean you couldnt do it without
> including msDesc module but as Elena suggests this may not be such an
> imposition.
>
This sounds reasonable to me, although I don't do manuscripts and have
no actual experience with it.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 19:59:14 EDT
From cwittern at gmail.com Mon Jul 30 20:52:42 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 31 Jul 2007 09:52:42 +0900 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.9599.159461.557796@emt.wwp.brown.edu> Message-ID: <46AE87DA.6040306@gmail.com>
From: Christian Wittern
Date: Tue, 31 Jul 2007 09:52:42 +0900
Syd Bauman wrote:
> Christian (and all) --
>
> We need to decide what we are going to do, if anything, with
> and pretty fast.
>
>
> On
> -- ----
> As per council's request in Berlin, rather than checking into
> P5, I ripped it out and made a stand-alone ODD of it
> (http://www.tei-c.org/Drafts/ps/). The ostensible point of this
> exercise was that having an element to encode postscripts is
> controversial enough that it was too scary for me to check it
> directly into P5. This means, IMHO, that we need an explicit vote to
> include this element in P5 or not. I think we need to make this
> decision ASAP.
>
To me it looks like it could go into P5 now.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 20:53:12 EDT
From cwittern at gmail.com Mon Jul 30 20:55:52 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 31 Jul 2007 09:55:52 +0900 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.21905.891655.794820@emt.wwp.brown.edu> Message-ID: <46AE8898.5060403@gmail.com>
From: Christian Wittern
Date: Tue, 31 Jul 2007 09:55:52 +0900
Syd Bauman wrote:
>> Really, I think the best solution is to bring back !
>>
>
> I don't know that it's *best*, because I haven't really thought
> through all the various possibilities, but I agree that it would be a
> good solution, and better than what we have now.
>
>
Then let the MS people have their dimensions. Seems like a good compromise.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Jul 30 2007 - 20:57:09 EDT
From James.Cummings at oucs.ox.ac.uk Tue Jul 31 05:05:28 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 31 Jul 2007 10:05:28 +0100 Subject: [tei-council] time is running out ... and In-Reply-To: <18094.9599.159461.557796@emt.wwp.brown.edu> Message-ID: <46AEFB58.9090702@oucs.ox.ac.uk>
From: James Cummings
Date: Tue, 31 Jul 2007 10:05:28 +0100
Syd Bauman wrote:
> On
> -- ----
> As per council's request in Berlin, rather than checking into
> P5, I ripped it out and made a stand-alone ODD of it
> (http://www.tei-c.org/Drafts/ps/). The ostensible point of this
> exercise was that having an element to encode postscripts is
> controversial enough that it was too scary for me to check it
> directly into P5. This means, IMHO, that we need an explicit vote to
> include this element in P5 or not. I think we need to make this
> decision ASAP.
For the record, the ps draft looks fine to me.
> * The element should have a quantity= attribute, not
> extent= (and preferably not count=, although that's a lot better
> than extent=).
@quantity is certainly better than @extent (@extent just makes me think of
@scope below).
> * should not have a scope= attribute (unless someone wants
> to put in some work figuring out what a scope= might usefully mean
> for a generic ).
I'm not sure I know anyone who would really want to use the @scope attribute.
> * The "suggested values include" list for unit= of should
> be pretty much as all-encompassing as we can get it.
Provide a list that includes examples from all major divisions of units,
you know one that refers to distance, area, volume, weight, resistance,
etc. But I'd say no more than 10 total but with prose recommending how to
indicate things like converted units, precision, etc.
> * The , , and elements should not have a
> commodity= attribute.
agreed,
> * The , , and elements should have a scope=
> attribute (they currently do; the point of my saying this is to
> contrast it with ).
How used?
> * The "suggested values include" list for unit= of , ,
> and should be very limited (the list that is currently
ure,
> * The amount attribute on , , and could be
> named quantity= or extent=, or for that matter, value=.
I'd go for quantity for consistency.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 05:05:33 EDT
From daniel.odonnell at uleth.ca Tue Jul 31 07:04:00 2007 From: daniel.odonnell at uleth.ca (daniel.odonnell_at_uleth.ca) Date: Tue, 31 Jul 2007 12:04:00 +0100 Subject: [tei-council] Choice, app, rdg, and edit-y thingies Message-ID: <20070731110945.IOFW1171.to5email2.gprs.rogers.com@COM>
From:
Date: Tue, 31 Jul 2007 12:04:00 +0100
I'll try to write up a proposal that combines Matthew and my proposals this pm (UK time). That'll give some though not much time for consideration before the call.
-d
Daniel Paul O'Donnell, PhD.
Department of English
University of Lethbridge
+1 (403) 381-2539
+1 (403) 329-2378
@treo
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 31 2007 - 07:09:53 EDT
From jawalsh at indiana.edu Tue Jul 31 13:30:32 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 31 Jul 2007 13:30:32 -0400 Subject: [tei-council] teleconference details Message-ID: <96DC4720-F7FE-42F0-BF94-E6E6F86223B0@indiana.edu>
From: John A. Walsh
Date: Tue, 31 Jul 2007 13:30:32 -0400
You have been invited to participate in a Conference Call on 8/2/2007
from 8:00:00 AM to 10:00:00 AM Eastern Time (US & Canada) / 12:00:00
- 14:00:00 UTC.
The Conference Access Information is listed below:
Date: 8/2/2007
Begin Time: 7:00:00 AM Eastern Time (US & Canada) / 12:00:00 UTC
End Time: 10:00:00 AM Eastern Time (US & Canada) / 14:00:00 UTC
Phone Number: (812) 856-3600
PIN: 000920#
For conferencing assistance please call 812-855-4848.
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 13:30:46 EDT
From Syd_Bauman at Brown.edu Tue Jul 31 18:01:15 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 31 Jul 2007 18:01:15 -0400 Subject: [tei-council] or not , that is the question In-Reply-To: <46AEFB58.9090702@oucs.ox.ac.uk> Message-ID: <18095.45355.753967.860198@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 31 Jul 2007 18:01:15 -0400
On the question as to whether for postscript should go into the
Guidelines for P5 1.0, it seems we have the following votes:
DB
TMB
AC
JC - yes
MD
DOD
DP
SR - yes
LR
CT - yes
JW
CW - yes
Any chance we can get 3 more in favor (or 7 against) in the next few
hours?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 31 2007 - 18:01:20 EDT
From Syd_Bauman at Brown.edu Tue Jul 31 18:11:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 31 Jul 2007 18:11:22 -0400 Subject: [tei-council] figure fixed Message-ID: <18095.45962.945434.874893@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 31 Jul 2007 18:11:22 -0400
I have added both and model.egLike to the content
model of
. I have added to FT-TablesFormulaeGraphics.xml a
new paragraph with an example of nested
s which use
instead of

for the captions. As no one but me seems to be in
favor limiting elements to near the beginning of a

[1], I did not restrict the content model. It's still just
one big bag of repeatable optional elements.
Note
---- [1] And also because, although I am not convinced by it, I think there is a quite reasonable argument in favor of allowing s at the bottom: the idea that semantically a is really just a special-purpose label -- it happens to usually appear at the top, thus it's name, but that's not a requirement. _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 18:11:28 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Jul 31 18:34:07 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 31 Jul 2007 23:34:07 +0100 Subject: [tei-council] figure fixed In-Reply-To: <18095.45962.945434.874893@emt.wwp.brown.edu> Message-ID: <46AFB8DF.20408@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 31 Jul 2007 23:34:07 +0100
Syd Bauman wrote:
> I have added both and model.egLike to the content
> model of
. I have added to FT-TablesFormulaeGraphics.xml a
> new paragraph with an example of nested
s which use
> instead of

for the captions.
I am not sure if I am in a minority here, but I think the example
is simply not right. It reads:




Parallel



Perspective

The two canonical view volumes, for the (a) parallel
and (b) perspective projections. Note that -z is to the right.

I just can't see why those elements are not .
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 31 2007 - 18:33:43 EDT
From cwittern at gmail.com Tue Jul 31 21:58:10 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 01 Aug 2007 10:58:10 +0900 Subject: [tei-council] List of contributors to P5 Message-ID: <46AFE8B2.7040005@gmail.com>
From: Christian Wittern
Date: Wed, 01 Aug 2007 10:58:10 +0900
Council members,
Below is my list of contributors to P5. Please compare it to your memory or
notes and alert me of any mistakes or omissions.

* Council
Chair:
John Unsworth (Jan 2002 - Jun 2003)
Christian Wittern (Jul 2003 - )
Members
non-elected
John Unsworth 2002 - Jul 2003
Julia Flanders 2004 - 2005
Matthew Zimmerman 2006
Daniel O'Donnell 2007 -
Sebastian Rahtz 2002 -
Lou Burnard 2002 -
Syd Baumann 2002 -
elected
Christian Wittern 2002 -
Perry Willett 2002 - 2005
Geoffrey Rockwell 2002
Merrilee Proffitt 2002 - 2003
Matthew Driscoll 2002 -
Arnamagn??an Institute, University of Copenhagen, Denmark
David Durand 2002 - 2004
Laurent Romary 2002 -
David Birnbaum 2002 - 2004, 2006 -
University of Pittsburgh djbpitt+@pitt.edu
Toma?? Erjavec 2002 - 2004
Fotis Jannidis 2002
Martin Mueller 2002
Peter Robinson 2002
Alejandro Bia 2003 - Apr 2006
Amit Kumar May 2006 - Dec 2006
Susan Schreibman 2003 -
Natasha Smith 2004 - 2005
Edward Vanhoutte 2004 - 2005
John Walsh 2005 -
Indiana University
James Cummings 2005 -
Dot Porter 2006 -
University of Kentucky dporter_at_uky.edu
Conal Tuohy 2006 -
New Zealand Electronic Text Centre Conal.Tuohy_at_vuw.ac.nz
Tone Merete Bruvik 2007 -
University of Bergen
Ariana Ciula 2007 -
King's College London
* WGs
** TEI character set WG
Active July 2001 to Jan. 2005
Members
* Christian Wittern, Kyoto University : chair
* Deborah Anderson, Berkeley
* Michael Beddow, Independent Scholar
* David Birnbaum, Pittsburgh University
* Robin Cover, OASIS/Isogen
* Martin Duerst, W3C/Keio University
* Patrick Durusau,Society of Biblical Literature
* Tony McEnery, Lancaster University
* Tomohiko Morioka, Kyoto University
* Espen Ore, National Library of Norway
** TEI Meta task force
Active Feb 2003 to Feb 2005
Members:
# Sebastian Rahtz (Chair)
# Syd Bauman (editor, ex-officio)
# Lou Burnard (editor, ex-officio)
# Laurent Romary
# David Durand
# Alejandro Bia
# Michael Sperberg-McQueen
# Norman Walsh
# Christian Wittern
** TEI Workgroup on Stand-Off Markup, XLink and XPointer
Active Feb 2002 to Jan 2006
Members:
# DD David G. Durand (chair)
# SB Syd Bauman
# JC Jean Carletta
# JH Jessica Hekman
# NI Nancy M. Ide
# FV Fabio Vitali
** MS Description Task Force
Active Feb 2003 - December 2005
Members:
S. Bauman,
D. Birnbaum,
L. Burnard,
M. Driscoll,
M. Proffitt
** TEI Personography Activity
Active Jan. 2006 - May 2007
Members:
Matthew Driscoll (Chair)
Lou Burnard, Oxford University
Sebastian Rahtz, Oxford University
Syd Bauman, Brown University
James Cummings, Oxford Text Archive
Ariana Ciula, Kings College
Tom Elliott, University of North Carolina at Chapel Hill

** Project on Internationalization and Localization
Active Oct. 2005 -
Sebastian Rahtz (Chair)
Chinese Marcus Bingenheimer, Chung-hwa Institute of Buddhist Studies,
Taipei
French Jean-Luc Bemoit, ATILF
German Werner Wegstein, Wuerzburg University
Japanese Ohya Kazushi, Tsurumi University, Yokohama
Spanish Carmen Arronis Llopis, University of Alicante

* Hosts for Council Meetings
2002: Kings College, London
2003: Oxford University, Oxford
2004: Koninklijke Academie voor Nederlandse Taal- en Letterkunde, Ghent
2005: association fran??aise de normalisation, Paris
2006: Kyoto University, Institute for Research in Humanities, Kyoto
2007: Berlin-Brandenburgische Akademie der Wissenschaften, Berlin
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 21:58:44 EDT

From cwittern at gmail.com Tue Jul 31 22:06:47 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 01 Aug 2007 11:06:47 +0900 Subject: [tei-council] Contributors to P5 (revised) Message-ID: <46AFEAB7.9080403@gmail.com>
From: Christian Wittern
Date: Wed, 01 Aug 2007 11:06:47 +0900
Council members,
the moment I sent out the list, I noticed a few glitches, here is a revised
version:
;-*- coding: utf-8 -*-
* Council
Chair:
John Unsworth (Jan 2002 - Jun 2003)
Christian Wittern (Jul 2003 - )
Members
non-elected
John Unsworth 2002 - Jul 2003
Julia Flanders 2004 - 2005
Matthew Zimmerman 2006
Daniel O'Donnell 2007 -
Sebastian Rahtz 2002 -
Lou Burnard 2002 -
Syd Baumann 2002 -
elected
Christian Wittern 2002 -
Perry Willett 2002 - 2005
Geoffrey Rockwell 2002
Merrilee Proffitt 2002 - 2003
Matthew Driscoll 2002 -
Arnamagn??an Institute, University of Copenhagen, Denmark
David Durand 2002 - 2004
Laurent Romary 2002 -
David Birnbaum 2002 - 2004, 2006 -
University of Pittsburgh
Toma?? Erjavec 2002 - 2004
Fotis Jannidis 2002
Martin Mueller 2002
Peter Robinson 2002
Alejandro Bia 2003 - Apr 2006
Amit Kumar May 2006 - Dec 2006
Susan Schreibman 2003 -
Natasha Smith 2004 - 2005
Edward Vanhoutte 2004 - 2005
James Cummings 2005 -
Dot Porter 2006 -
University of Kentucky
Conal Tuohy 2006 -
New Zealand Electronic Text Centre
Tone Merete Bruvik 2007 -
University of Bergen
Ariana Ciula 2007 -
King's College London
John Walsh 2005 -
Indiana University
* WGs
** TEI character set WG
Active July 2001 to Jan. 2005
Members
* Christian Wittern, Kyoto University : chair
* Deborah Anderson, Berkeley
* Michael Beddow, Independent Scholar
* David Birnbaum, Pittsburgh University
* Robin Cover, OASIS/Isogen
* Martin Duerst, W3C/Keio University
* Patrick Durusau,Society of Biblical Literature
* Tony McEnery, Lancaster University
* Tomohiko Morioka, Kyoto University
* Espen Ore, National Library of Norway
** TEI Meta task force
Active Feb 2003 to Feb 2005
Members:
# Sebastian Rahtz (Chair)
# Syd Bauman (editor, ex-officio)
# Lou Burnard (editor, ex-officio)
# Laurent Romary
# David Durand
# Alejandro Bia
# Michael Sperberg-McQueen
# Norman Walsh
# Christian Wittern
** TEI Workgroup on Stand-Off Markup, XLink and XPointer
Active Feb 2002 to Jan 2006
Members:
# DD David G. Durand (chair)
# SB Syd Bauman
# JC Jean Carletta
# JH Jessica Hekman
# NI Nancy M. Ide
# FV Fabio Vitali
** MS Description Task Force
Active Feb 2003 - December 2005
Members:
S. Bauman,
D. Birnbaum,
L. Burnard,
M. Driscoll,
M. Proffitt
** TEI Personography Activity
Active Jan. 2006 - May 2007
Members:
Matthew Driscoll (Chair)
Lou Burnard, Oxford University
Sebastian Rahtz, Oxford University
Syd Bauman, Brown University
James Cummings, Oxford Text Archive
Ariana Ciula, King's College
Gabriel Bodard, King's College
Tom Elliott, University of North Carolina at Chapel Hill

** Project on Internationalization and Localization
Active Oct. 2005 -
Sebastian Rahtz (Chair)
Chinese Marcus Bingenheimer, Chung-hwa Institute of Buddhist Studies,
Taipei
French Jean-Luc Bemoit, ATILF
German Werner Wegstein, Wuerzburg University
Japanese Ohya Kazushi, Tsurumi University, Yokohama
Spanish Carmen Arronis Llopis, University of Alicante
* Hosts for Council Meetings
2002: Kings College
2003: Oxford University
2004: Koninklijke Academie voor Nederlandse Taal- en Letterkunde, Ghent
2005: association fran??aise de normalisation
2006: Kyoto University, Institute for Research in Humanities
2007: Berlin Brandenburgische Akademie der Wissenschaften

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 22:06:55 EDT

From cwittern at gmail.com Tue Jul 31 22:40:37 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 01 Aug 2007 11:40:37 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on Aug 2, 2007 at 1200 UTC Message-ID: <46AFF2A5.205@gmail.com>
From: Christian Wittern
Date: Wed, 01 Aug 2007 11:40:37 +0900
DRAFT Agenda for the TEI Council teleconference on Aug 2, 2007 at 1200 UTC
Expected to participate:
Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, James
Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian
Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern
ent apologies:
Arianna Ciula

============================================================
How to connect:
Date: 8/2/2007
Begin Time: 7:00:00 AM Eastern Time (US & Canada) / 12:00:00 UTC
End Time: 10:00:00 AM Eastern Time (US & Canada) / 14:00:00 UTC
Phone Number: (812) 856-3600
PIN: 000920#
For conferencing assistance please call 812-855-4848.
============================================================
The main purpose of this telecon is to decide which of the still open
issues will go into P5 and agree on a timetable for further work.
============================================================
1) Open action items
* We will look at the open action items from the last meeting
(http://www.tei-c.org/Council/tcm32.xml?style=printable) first, here is the
view from trac on the open issues:
http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=%21closed&group=status&milestone=Remaining+technical+problems

2) Items for Discussion
* sorting out vs. (LB)
3) Timetable
(still working on the plan here, will post separate message)
4) next meeting

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Jul 31 2007 - 22:40:46 EDT

From Syd_Bauman at Brown.edu Tue Jul 31 23:10:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 31 Jul 2007 23:10:10 -0400 Subject: [tei-council] Contributors to P5 (revised) In-Reply-To: <46AFEAB7.9080403@gmail.com> Message-ID: <18095.63890.808097.986532@emt.wwp.brown.edu>
From: Syd Bauman
Date: Tue, 31 Jul 2007 23:10:10 -0400
Morning Christian! Thanks for putting this together. Some quick
thoughts, as it is way past my bedtime ... :-)
Do we mention physical bibliography? I'm inclined to say no, as none
of their work got into P5, right?
I am not sure whether the editors should be mentioned in workgroups
or not, but in either case I was not part of personography (sorry to
say). (Lou & I should be mentioned for the MS task force though.)
Do we want to list the members of the ISO FS group?
There were two others who participated in SO: Chris Catton and Hamish
Cunningham. Chris actually even wrote a draft that Council didn't
like very much. But AFAIK Hamish only attended the first conference
call. There is no mention of him saying or doing anything after that.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Jul 31 2007 - 23:10:16 EDT
From cwittern at gmail.com Wed Aug 1 01:28:04 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 01 Aug 2007 14:28:04 +0900 Subject: [tei-council] Contributors to P5 (revised) In-Reply-To: <18095.63890.808097.986532@emt.wwp.brown.edu> Message-ID: <46B019E4.8010107@gmail.com>
From: Christian Wittern
Date: Wed, 01 Aug 2007 14:28:04 +0900
Syd Bauman wrote:
> Morning Christian! Thanks for putting this together. Some quick
> thoughts, as it is way past my bedtime ... :-)
>
> Do we mention physical bibliography? I'm inclined to say no, as none
> of their work got into P5, right?
>
That's why I did not mention them, same as the migration WG.
> I am not sure whether the editors should be mentioned in workgroups
> or not, but in either case I was not part of personography (sorry to
> say). (Lou & I should be mentioned for the MS task force though.)
>
OK, there was some mixup on my side here. The document should probably
go into SF anyway, but I have no rights to put it there and am also not
clear where.
> Do we want to list the members of the ISO FS group?
>
Good question. Since it was not a TEI activity, I left them out.
> There were two others who participated in SO: Chris Catton and Hamish
> Cunningham. Chris actually even wrote a draft that Council didn't
> like very much. But AFAIK Hamish only attended the first conference
> call. There is no mention of him saying or doing anything after that.
>
OK, so that means we should include Chris Catton, right?
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 01 2007 - 01:28:11 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Aug 1 04:18:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 01 Aug 2007 09:18:30 +0100 Subject: [tei-council] List of contributors to P5 In-Reply-To: <46AFE8B2.7040005@gmail.com> Message-ID: <46B041D6.4070706@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 01 Aug 2007 09:18:30 +0100
>
> * Council
>
> Chair:
> John Unsworth (Jan 2002 - Jun 2003)
> Christian Wittern (Jul 2003 - )
>
> Members
> non-elected
(worth saying explicitly that these were Board
nominations to the Council).
>
> ** TEI Personography Activity
> Active Jan. 2006 - May 2007
> Members:
> Matthew Driscoll (Chair)
> Lou Burnard, Oxford University
> Sebastian Rahtz, Oxford University
> Syd Bauman, Brown University
> James Cummings, Oxford Text Archive
> Ariana Ciula, Kings College
> Tom Elliott, University of North Carolina at Chapel Hill
Matthew D has a longer list. Of these, only MD, SR and LB
attended all meetings, so it would be sensible to list
all attendees at any meeting? Certainly G Bodard
should be there.
>
>
> ** Project on Internationalization and Localization
> Active Oct. 2005 -
> Sebastian Rahtz (Chair)
> Chinese Marcus Bingenheimer, Chung-hwa Institute of Buddhist Studies,
> Taipei
> French Jean-Luc Bemoit, ATILF
Benoit
> German Werner Wegstein, Wuerzburg University
> Japanese Ohya Kazushi, Tsurumi University, Yokohama
> Spanish Carmen Arronis Llopis, University of Alicante
very important to also list Pierre-Yves Duchesmin for French (deceased
2007).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 01 2007 - 04:18:34 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Aug 1 05:02:00 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 01 Aug 2007 10:02:00 +0100 Subject: [tei-council] List of contributors to P5 In-Reply-To: <46B041D6.4070706@oucs.ox.ac.uk> Message-ID: <46B04C08.1030200@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 01 Aug 2007 10:02:00 +0100
Sebastian Rahtz wrote:
>
> very important to also list Pierre-Yves Duchesmin for French (deceased
> 2007).
>
Yes: but make that "Duchemin"
I will supply list of the ISO group later -- have to go to a meeting
this morning.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 05:09:26 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Aug 1 05:53:20 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 01 Aug 2007 10:53:20 +0100 Subject: [tei-council] Contributors to P5 (revised) In-Reply-To: <18095.63890.808097.986532@emt.wwp.brown.edu> Message-ID: <46B05810.5060801@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 01 Aug 2007 10:53:20 +0100
Syd Bauman wrote:
> M
> Do we mention physical bibliography? I'm inclined to say no, as none
> of their work got into P5, right?
>
I agree
> I am not sure whether the editors should be mentioned in workgroups
> or not, but in either case I was not part of personography (sorry to
> say). (Lou & I should be mentioned for the MS task force though.)
>
The editors shouldnt appear in any of the lists since they are
ex-officio members of all of them.
> Do we want to list the members of the ISO FS group?
>
Yes. Their work resulted in changes which are reflected in P5
> There were two others who participated in SO: Chris Catton and Hamish
> Cunningham. Chris actually even wrote a draft that Council didn't
> like very much. But AFAIK Hamish only attended the first conference
> call. There is no mention of him saying or doing anything after that.
>
Catton should be added then, if the idea is to list all people who
contributed, even negatively.
The list needs affiliations, and regrouping to put it into the same
style as the other wg lists. I'll work on that later today and post to
the website asap.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 05:53:24 EDT
From tone.bruvik at aksis.uib.no Wed Aug 1 07:19:26 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Wed, 1 Aug 2007 13:19:26 +0200 Subject: [tei-council] or not , that is the question In-Reply-To: <18095.45355.753967.860198@emt.wwp.brown.edu> Message-ID: <195B09E2-0102-4715-BE66-4C9B7B6C4800@aksis.uib.no>
From: Tone Merete Bruvik
Date: Wed, 1 Aug 2007 13:19:26 +0200
I vote yes to include in P5 1.0
Tone Merete Bruvik (TMB)
Den 1. aug. 2007 kl. 00.01 skrev Syd Bauman:
> On the question as to whether for postscript should go into the
> Guidelines for P5 1.0, it seems we have the following votes:
>
> DB
> TMB
> AC
> JC - yes
> MD
> DOD
> DP
> SR - yes
> LR
> CT - yes
> JW
> CW - yes
>
> Any chance we can get 3 more in favor (or 7 against) in the next few
> hours?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 07:19:36 EDT
From mjd at hum.ku.dk Wed Aug 1 08:38:35 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Wed, 1 Aug 2007 14:38:35 +0200 Subject: [tei-council] handDesc and handList Message-ID: <5FA95E40EE2AD51190380090272724BB1002FBBD@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Wed, 1 Aug 2007 14:38:35 +0200
I may be wrong (or indulging in wishful thinking), but I recall (albeit
vaguely, as one does) that we had already decided that there was no longer
any real justification for using and , since they didn't do
anything that couldn't be done with and . Does anyone
else remember this?
Matthew
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU
[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of Lou
Burnard
Sent: Monday, July 30, 2007 5:56 PM
To: Christian Wittern
Cc: TEI Council
Subject: Re: [tei-council] next telecon 2007-08-02 at 1200 UTC
Could we discuss the issue Elena Pierazzo has just raised on the Council
list about the overlap between and ?
I think it would be a shame to remove : my tentative proposal
would be to add it as an optional element within , removing it
from model.profileDescPart. This would mean you couldnt do it without
including msDesc module but as Elena suggests this may not be such an
imposition.
(Incidentally, I just noticed that handShift is also a member of
model.profileDescPart: this is definitely bonkers, so I am removing it)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-counci
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 08:38:42 EDT

From lou.burnard at computing-services.oxford.ac.uk Wed Aug 1 10:11:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 01 Aug 2007 15:11:39 +0100 Subject: [tei-council] Re: handDesc and handList In-Reply-To: <5FA95E40EE2AD51190380090272724BB1002FBBD@humxsrv1.hum.ku.dk> Message-ID: <46B0949B.8040103@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Wed, 01 Aug 2007 15:11:39 +0100
We certainly had a conversation about the duplication between handList
and handDesc, which is why I wished to put them on the agenda.
At first glance, it's true that you could use in place of
, and in place of . However, as currently
written, the spec for the handDesc/Note combination permits you to do
all sorts of vague things that you can't do with the handList/hand pair.
For example, the handDesc could just say "there are six hands in this
ms, and I can only read one of them" (without saying which or supplying
anything further). And there's no requirement that a handNote relate to
a single hand, as I read the definition: it could summarise your
thoughts on all the different varieties of say secretary hand you've
detected in the ms.
So my suggestion would be that we change the content model of
to permit (a single) as a child in addition to (or in place
of)

or

This means that those wishing to indulge in computational codicology
(you know who you are) can do so, while permitting those who just want
to witter on (ditto) to do that too. :-)

. Matthew James Driscoll wrote:
> I may be wrong (or indulging in wishful thinking), but I recall (albeit
> vaguely, as one does) that we had already decided that there was no longer
> any real justification for using and , since they didn't do
> anything that couldn't be done with and . Does anyone
> else remember this?
>
> Matthew
>
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU
> [mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of Lou
> Burnard
> Sent: Monday, July 30, 2007 5:56 PM
> To: Christian Wittern
> Cc: TEI Council
> Subject: Re: [tei-council] next telecon 2007-08-02 at 1200 UTC
>
> Could we discuss the issue Elena Pierazzo has just raised on the Council
> list about the overlap between and ?
>
> I think it would be a shame to remove : my tentative proposal
> would be to add it as an optional element within , removing it
> from model.profileDescPart. This would mean you couldnt do it without
> including msDesc module but as Elena suggests this may not be such an
> imposition.
>
> (Incidentally, I just noticed that handShift is also a member of
> model.profileDescPart: this is definitely bonkers, so I am removing it)
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-counci
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 10:11:47 EDT

From djbpitt+tei at pitt.edu Wed Aug 1 10:34:10 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 01 Aug 2007 10:34:10 -0400 Subject: [tei-council] and Message-ID: <46B099E2.6020009@pitt.edu>
From: David J Birnbaum
Date: Wed, 01 Aug 2007 10:34:10 -0400
Dear Council,
This sounds consistent with the general strategy in our manuscript
description resources of providing structured and unstructured (or, more
accurately, loosely constrained) alternatives.
Best,
David
Lou Burnard wrote:
> We certainly had a conversation about the duplication between handList
> and handDesc, which is why I wished to put them on the agenda.
>
> At first glance, it's true that you could use in place of
> , and in place of . However, as currently
> written, the spec for the handDesc/Note combination permits you to do
> all sorts of vague things that you can't do with the handList/hand
> pair. For example, the handDesc could just say "there are six hands in
> this ms, and I can only read one of them" (without saying which or
> supplying anything further). And there's no requirement that a
> handNote relate to a single hand, as I read the definition: it could
> summarise your thoughts on all the different varieties of say
> secretary hand you've detected in the ms.
>
> So my suggestion would be that we change the content model of
> to permit (a single) as a child in addition to
> (or in place of)

or
>
>
> This means that those wishing to indulge in computational codicology
> (you know who you are) can do so, while permitting those who just want
> to witter on (ditto) to do that too. :-)
>
>
>
> . Matthew James Driscoll wrote:
>> I may be wrong (or indulging in wishful thinking), but I recall (albeit
>> vaguely, as one does) that we had already decided that there was no
>> longer
>> any real justification for using and , since they
>> didn't do
>> anything that couldn't be done with and . Does
>> anyone
>> else remember this?
>>
>> Matthew
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 10:34:23 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Aug 1 10:57:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 01 Aug 2007 15:57:37 +0100 Subject: [tei-council] TEI Oxford outage August 11th Message-ID: <46B09F61.5030207@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 01 Aug 2007 15:57:37 +0100
Note that this means that the trac, Roma and dynamic Guidelines
services will be out of action for a day. Plus all email
from us at Oxford will be out, though incoming
will be queued up.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 01 2007 - 10:57:41 EDT
From lou.burnard at oucs.ox.ac.uk Wed Aug 1 11:45:21 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 01 Aug 2007 16:45:21 +0100 Subject: [tei-council] postscript draft Message-ID: <20070801154521.49B4E9A001@webmail223.herald.ox.ac.uk>
From: Lou Burnard
Date: Wed, 01 Aug 2007 16:45:21 +0100
I love the examples, and have no objection to including this new element.
I have a question though: suppose I'd decided to treat the letter as a
rather than a
(not on the face of it a completely daft idea), would the
postscript then become a
or would it be inside ?
Why not use as the name of the tag? We generally do use fullnames
for these divTop/bot things (e.g. not )
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 11:45:24 EDT
From Syd_Bauman at Brown.edu Wed Aug 1 11:55:39 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 1 Aug 2007 11:55:39 -0400 Subject: [tei-council] reduex In-Reply-To: <46AE8898.5060403@gmail.com> Message-ID: <18096.44283.156958.762802@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 1 Aug 2007 11:55:39 -0400
LB> Really, I think the best solution is to bring back !
SB> [Maybe not best, but a good idea.]
SR> yes. it would seem much more honest to have as a
SR> container for text.
CW> Then let the MS people have their dimensions. Seems like a good
CW> compromise.
OK, as I'm still waiting for votes for or agin (about which I
see Lou just posted) or more discussion on facsimile markup, I'll get
going on this presently.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 11:55:43 EDT

From Syd_Bauman at Brown.edu Wed Aug 1 12:05:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 1 Aug 2007 12:05:29 -0400 Subject: [tei-council] postscript draft In-Reply-To: <20070801154521.49B4E9A001@webmail223.herald.ox.ac.uk> Message-ID: <18096.44873.155477.498526@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 1 Aug 2007 12:05:29 -0400
> I love the examples, and have no objection to including this new
> element.
Excellent, glad to hear it.

> I have a question though: suppose I'd decided to treat the letter
> as a rather than a

(not on the face of it a completely
> daft idea), would the postscript then become a
or
> would it be inside ?
Good question ... since you can't encode it directly in , I
don't think, I think it would be in a
, whether it was
a child of or of . I'm not sure whether we should make a
recommendation of one over the other, though.

> Why not use as the name of the tag? We generally do
> use fullnames for these divTop/bot things (e.g. not
> )
For reasons stated in the prose, but I am not at all opposed to
. I don't think it matters (remember, the gloss does say
"postscript" :-) and think that the only issue that should be driving
this decision is "what do the users want?"; but we haven't time to
poll the membership, so we need to take our best guess.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 12:05:53 EDT

From Syd_Bauman at Brown.edu Wed Aug 1 18:32:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 1 Aug 2007 18:32:22 -0400 Subject: [tei-council] postscript draft In-Reply-To: <03AF7903F10BB64CA22CDF89EE5D80BA9B6050@EXCHCL2.uleth.ca> Message-ID: <18097.2550.793953.724282@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 1 Aug 2007 18:32:22 -0400
> Actually, this seems quite important to me. All sorts of similar
> chunks can go directly in front or back, for example: epigraph,
> byline, etc. (the contents of model.pLikeFront). It seems to me
> that (my preferred name) should be parallel and able
> to be a direct child of back.
Oh, good point Dan. I was mis- (or actually over-) recalling the
content of . Back in P4 you couldn't do that sort of thing --
but then again, there was no in P4!
So yes, it would probably be reasonable to have

Right, Dan!

in P5.

But of course, unless you and 1 outher Council member vote "yes"
awfully fast, it's a moot point. (Although I suppose given that the
editors are in favor, six is enough, eh? So just you would do it,
then.)
DB
TMB - yes
AC
JC - yes
MD
DOD
DP
SR - yes
LR
CT - yes
JW
CW - yes

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 18:32:28 EDT

From sebastian.rahtz at oucs.ox.ac.uk Wed Aug 1 19:38:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 00:38:18 +0100 Subject: [tei-council] postscript draft In-Reply-To: <18097.2550.793953.724282@emt.wwp.brown.edu> Message-ID: <46B1196A.2020506@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 00:38:18 +0100
Syd Bauman wrote:
> But of course, unless you and 1 outher Council member vote "yes"
> awfully fast, it's a moot point. (Although I suppose given that the
> editors are in favor, six is enough, eh? So just you would do it,
> then.)
>
I don't think a vote was formally called - only the chair
can do that. So I don't think you need to worry....
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 18:37:52 EDT
From Syd_Bauman at Brown.edu Wed Aug 1 19:56:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 1 Aug 2007 19:56:18 -0400 Subject: [tei-council] postscript draft In-Reply-To: <46B1196A.2020506@oucs.ox.ac.uk> Message-ID: <18097.7586.108019.97531@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 1 Aug 2007 19:56:18 -0400
SR> I don't think a vote was formally called - only the chair can do
SR> that.
While I think you're right, only the Chair can formally call for a
vote, I addressed the chair when I stated that "IMHO ... we need an
explicit vote to include this element in P5 or not.", and Christian
responded with what I take to be a vote in the affirmative.
I really can't imagine why we deferred checking a postscript element
into P5 in Berlin unless it was to subject the issue to an up-or-down
vote.

SR> So I don't think you need to worry....
Well, "confused" is more the term I'd use than "worried" to describe
my state. Are you claiming that in the absence of an explicit vote on
it, I should go ahead and stick a postscript elment in anyway, after
Council has explicitly told me not to do so? I can't really wrap my
mind around that. Admittedly there was no vote about it in Berlin,
just murmur about the table, but still ...
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 01 2007 - 19:56:22 EDT

From cwittern at gmail.com Wed Aug 1 21:30:15 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 02 Aug 2007 10:30:15 +0900 Subject: [tei-council] postscript draft In-Reply-To: <18097.2550.793953.724282@emt.wwp.brown.edu> Message-ID: <46B133A7.2040007@gmail.com>
From: Christian Wittern
Date: Thu, 02 Aug 2007 10:30:15 +0900
Syd Bauman wrote:
>
> But of course, unless you and 1 outher Council member vote "yes"
> awfully fast, it's a moot point. (Although I suppose given that the
> editors are in favor, six is enough, eh? So just you would do it,
> then.)
>
Since we haven't heard a single voice of disapproval, I think it fair
for you to go ahead now. This is the way we have been conducting
business so far.
As we will need to come to decide on quite a few things in the weeks to
come, I will make formal calls where necessary, including a cut-off time
for the ballot, after which we count.
All the best,
Christian
> DB
> TMB - yes
> AC
> JC - yes
> MD
> DOD
> DP
> SR - yes
> LR
> CT - yes
> JW
> CW - yes
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 01 2007 - 21:30:23 EDT

From cwittern at gmail.com Wed Aug 1 23:58:56 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 02 Aug 2007 12:58:56 +0900 Subject: [tei-council] workplan Message-ID: <46B15680.10503@gmail.com>
From: Christian Wittern
Date: Thu, 02 Aug 2007 12:58:56 +0900
Dear Council members,
As promised yesterday and after discussion in the planning subcommittee
(Daniel, Sebastian, Christian), here is the proposed work plan for the weeks
to come:

Overall timetable:
Aug 4th: feature freeze (more or less)
Aug 4th - September 7th: integration of proposed items (e.g. facsimile)
in chapters and review (see below)
September 11th - September 16th: final council review sessions
we will put the chapters to vote 1 by 1
September 15th - October 19th: all text locked for single master edit,
assigned to Lou
(at this point, I think it would be counter - productive to try
to do cross-atlantic editing)
September 15th - October 19th: final decisions about layout, publication,
web site, assigned to Syd
October 20th - October 30th: implementation of publication, assigned to
Sebastian

The details for the chapter triage are at
http://tei.oucs.ox.ac.uk/trac/TEIP5/wiki/Review [1]
one of the ideas behind this being that those who still carry stuff not
integrated stuff (eg facsimile) will take ownership of that chapter for the
month Aug 4 to Sep 7.
The task assigned with the chapter review is as follows:
Read thechapter again and fix anything which looks wrong. You can do this in
one of two ways:
- writing replacement lines/paragraphs/sections and sending them to Lou
- editing the source ODD file in situ, if you are sure you know what
they are doing
Saying "this section looks wrong, it needs a rewrite" is only acceptable
_in extremis_. If you edit the ODD, you will have to be extremely
careful to work in a way which allows someone else to see
the differences. Proposals for changes to the schema
can be made, and recorded in trac for P5 1.1.
All the best,
Christian

[1] The last column has more ? if the chapter is deemed to have more
work to do, and a * if its vitally important that it be edited

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 01 2007 - 23:59:08 EDT

From jawalsh at indiana.edu Thu Aug 2 01:46:36 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 2 Aug 2007 01:46:36 -0400 Subject: [tei-council] rendition/rend proposal Message-ID: <71752389-E62B-46C6-B3A8-A9375402DD42@indiana.edu>
From: John A. Walsh
Date: Thu, 2 Aug 2007 01:46:36 -0400
Hi all,
Here is a summary of the rend/rendition proposal. If we choose to
adopt something along these lines, I can work with Lou and Syd to
flesh it out.

John
-- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 edu> _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 01:46:42 EDT
From conal.tuohy at vuw.ac.nz Thu Aug 2 01:57:19 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 02 Aug 2007 17:57:19 +1200 Subject: [tei-council] rendition/rend proposal In-Reply-To: <71752389-E62B-46C6-B3A8-A9375402DD42@indiana.edu> Message-ID: <1186034239.22202.43.camel@localhost>
From: Conal Tuohy
Date: Thu, 02 Aug 2007 17:57:19 +1200
Cheers John
BTW - in your final example shouldn't you have used
These
rather than
These
?
Con

On Thu, 2007-08-02 at 01:46 -0400, John A. Walsh wrote:
> Hi all,
>
> Here is a summary of the rend/rendition proposal. If we choose to
> adopt something along these lines, I can work with Lou and Syd to
> flesh it out.
>
>
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 01:57:29 EDT

From Conal.Tuohy at vuw.ac.nz Thu Aug 2 04:57:52 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 2 Aug 2007 20:57:52 +1200 Subject: [tei-council] facsimile diagram Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABCE@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 2 Aug 2007 20:57:52 +1200
I have uploaded a simple diagram showing the (graphical) relationships between the , , and elements as used in the latest "facsimile" draft.
http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg
Please take a look at it to make sure we are all on the same page (pun intended) regarding the meaning of the proposed terms, since the proposed element names have changed as a result of last week's discussion.
The diagram shows 1 page with 1 associated graphic, and 4 zones:
A represents a physical page itself, and may contain and elements. The example represents a recto page from a manuscript.
A represents a digital image of that page. In the example the graphic covers an area slightly larger than the page itself (represented by the element).
A represents a rectangular area on a page. In the example the zones show 4 areas of interest, which would be linked to pieces of transcript.
I will upload some other updated material after dinner (shortly)
Conal

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 04:58:16 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 05:18:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 10:18:03 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABCE@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46B1A14B.50304@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 10:18:03 +0100
I still prefer the idea of recursive surfaces
TEI -> header, facsimile? , text?
facsimile -> front?, (surface+ | model.graphicLike+), back?)
urface -> (model.graphicLike*, surface*)
This allows for the possibility that you might have additional images
for particularly interesting bits of the page ("zone"s in your terminologuy)
However if you're really unhappy with the recursion, I can live with
urface -> (model.graphicLike*, zone*)
zone -> (model.graphicLike*)
The big headache for me is the attributes. The draft I am working on
proposes a new global attribute @facs to point from any element to a
corresponding surface (or zone) but we need more than that.
James reminded me that there is work in the MPEG/ISO/W3C communities on
defining new Xpointer schemes to point into assorted kinds of multimedia
which we should at least acknowledge somewhere.

Conal Tuohy wrote:
> I have uploaded a simple diagram showing the (graphical) relationships between the , , and elements as used in the latest "facsimile" draft.
>
> http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg
>
> Please take a look at it to make sure we are all on the same page (pun intended) regarding the meaning of the proposed terms, since the proposed element names have changed as a result of last week's discussion.
>
> The diagram shows 1 page with 1 associated graphic, and 4 zones:
>
> A represents a physical page itself, and may contain and elements. The example represents a recto page from a manuscript.
>
> A represents a digital image of that page. In the example the graphic covers an area slightly larger than the page itself (represented by the element).
>
> A represents a rectangular area on a page. In the example the zones show 4 areas of interest, which would be linked to pieces of transcript.
>
> I will upload some other updated material after dinner (shortly)
>
> Conal
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 05:18:10 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 05:53:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 10:53:18 +0100 Subject: [tei-council] reduex In-Reply-To: <18096.44283.156958.762802@emt.wwp.brown.edu> Message-ID: <46B1A98E.2010808@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 10:53:18 +0100
My understanding of this issue may be summarised as follows.
1. MsDesc had an element which allowed either just text or
some number the specialised elements
2. There was a consensus in favour of generalising these three rather
specific not to say obsessive elements. A very early draft version of
MsDesc had am element rather cutely named for this purpose
3. It was observed that was pretty close to the existing
so maybe we should use the latter instead
I'd like us to agree on one of the following strategies
a. do nothing i.e. try to make function satisfactorily both as
a measurement of quantity and as a statement of dimensions; live with
the oddity of a which doesnt just contain s
b. do some cosmetics i.e. rename @extent as @quantity, as
etc as already discussed
c. revert i.e. leave more or less as is, reintroduce
, abolish
If you choose (c) then you need to decide between the following content
models for
c-1 : text
c-2 : text | model.dimLike+
c-3 : text | model.dimLike.sequence
and you also need to decide whether the members of model.dimLike are --
d. height, width, depth
e. dim
f. dim, height, width, depth
g. dim, height, width, depth, measure
Assuming that we don't do (a), my recommendations are
c, c-2, f

Syd Bauman wrote:
> LB> Really, I think the best solution is to bring back !
> SB> [Maybe not best, but a good idea.]
> SR> yes. it would seem much more honest to have as a
> SR> container for text.
> CW> Then let the MS people have their dimensions. Seems like a good
> CW> compromise.
>
> OK, as I'm still waiting for votes for or agin (about which I
> see Lou just posted) or more discussion on facsimile markup, I'll get
> going on this presently.
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 05:53:22 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 06:02:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 11:02:06 +0100 Subject: [tei-council] rendition/rend proposal In-Reply-To: <71752389-E62B-46C6-B3A8-A9375402DD42@indiana.edu> Message-ID: <46B1AB9E.9090001@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 11:02:06 +0100
I think this is essentially a lovely proposal,which I see no difficulty
in integrating into P5 1.0. I have the following minor reservations:
a) when I print it on A4 paper the right hand edge of each page
disappears. Tsk tsk.
b) @rendition is not such a nice name. Would @style be better (OK I know
it's exactly not what HTML @style is but @class would be really
confusing)? @rendPtr ? @render ?
@render has the implied semantics that this is how you should render the
document, not how it was originally rendered. On the other hand I am not
sure that maintaining this distinction is sustainable anyway: most
production systems that I know of will take what the TEI document says
about source rendition and use it to determine the output rendition anyway.

John A. Walsh wrote:
> Hi all,
>
> Here is a summary of the rend/rendition proposal. If we choose to adopt
> something along these lines, I can work with Lou and Syd to flesh it out.
>
>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 06:02:10 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 06:05:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 11:05:17 +0100 Subject: [tei-council] postscript draft In-Reply-To: <18097.7586.108019.97531@emt.wwp.brown.edu> Message-ID: <46B1AC5D.2030600@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 11:05:17 +0100
Syd Bauman wrote:
> Are you claiming that in the absence of an explicit vote on
> it, I should go ahead and stick a postscript elment in anyway, after
> Council has explicitly told me not to do so?
er um. I was just thinking that offering it
up for discusson for a week and having
no "nay" votes is as good as 10 "yeah" votes.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 06:05:21 EDT
From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 06:07:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 11:07:40 +0100 Subject: [tei-council] Choice, app, rdg, and edit-y thingies In-Reply-To: <20070731110945.IOFW1171.to5email2.gprs.rogers.com@COM> Message-ID: <46B1ACEC.7070808@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 11:07:40 +0100
daniel.odonnell_at_uleth.ca wrote:
> I'll try to write up a proposal that combines Matthew and my proposals this pm (UK time). That'll give some though not much time for consideration before the call.
>
I haven't seen this. Did it materialise?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 06:07:50 EDT
From Conal.Tuohy at vuw.ac.nz Thu Aug 2 06:33:26 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 2 Aug 2007 22:33:26 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <46B1A14B.50304@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABCF@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 2 Aug 2007 22:33:26 +1200
G'day Lou!
I don't think we need recursion in order to have graphics that represent particularly interesting bits of the page, and I think that the extra complexity involved in processing recursive markup should therefore rule it out, to be frank.
To represent a detail image using the markup I'm proposing, you would simply add a (as a child of a particular ) whose coordinates would indicate that it covered just a small region.
In short, each graphic can be declared to cover any area of the surface it depicts, just as each zone can be declared to represent a region any particular region on that surface.
I also don't think that elements should contain elements. I think the value of the original proposal is precisely in that it defines the graphics independently of the zones: the graphics and zones relate only via the surfaces (i.e. the physical pages) which those graphics and zones depict, and analyse, respectively. Hence both zones and graphics would be empty elements.
I think this makes sense if you consider that the function of the graphic elements is to depict the pages, while the function of the zone elements is to analyse the pages. A particular area of the page is of interest to a particular analysis independently of the graphics which depict that area of the page, and a particular graphic is a depiction of the page (or part of the page), independently of whether any part of that graphic is of analytical interest.
As far as linking textual elements (such as tei:p) to the stand-off analytical elements (tei:zone), I can see a few ways to do this, and I'll post something about this shortly. But to my mind it's important that we can reach a consensus on surfaces, graphics, and zones, too, so we are clear on what is being linked.
Con

-----Original Message-----
From: Lou Burnard [mailto:lou.burnard_at_computing-services.oxford.ac.uk]
Sent: Thu 02/08/07 21:18
To: Conal Tuohy
Cc: TEI Council
Subject: Re: [tei-council] facsimile diagram

I still prefer the idea of recursive surfaces
TEI -> header, facsimile? , text?
facsimile -> front?, (surface+ | model.graphicLike+), back?)
urface -> (model.graphicLike*, surface*)
This allows for the possibility that you might have additional images
for particularly interesting bits of the page ("zone"s in your terminologuy)
However if you're really unhappy with the recursion, I can live with
urface -> (model.graphicLike*, zone*)
zone -> (model.graphicLike*)
The big headache for me is the attributes. The draft I am working on
proposes a new global attribute @facs to point from any element to a
corresponding surface (or zone) but we need more than that.
James reminded me that there is work in the MPEG/ISO/W3C communities on
defining new Xpointer schemes to point into assorted kinds of multimedia
which we should at least acknowledge somewhere.

Conal Tuohy wrote:
> I have uploaded a simple diagram showing the (graphical) relationships between the , , and elements as used in the latest "facsimile" draft.
>
> http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg
>
> Please take a look at it to make sure we are all on the same page (pun intended) regarding the meaning of the proposed terms, since the proposed element names have changed as a result of last week's discussion.
>
> The diagram shows 1 page with 1 associated graphic, and 4 zones:
>
> A represents a physical page itself, and may contain and elements. The example represents a recto page from a manuscript.
>
> A represents a digital image of that page. In the example the graphic covers an area slightly larger than the page itself (represented by the element).
>
> A represents a rectangular area on a page. In the example the zones show 4 areas of interest, which would be linked to pieces of transcript.
>
> I will upload some other updated material after dinner (shortly)
>
> Conal
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 06:33:50 EDT

From dporter at uky.edu Thu Aug 2 06:34:14 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 2 Aug 2007 06:34:14 -0400 Subject: [tei-council] facsimile diagram In-Reply-To: <46B1A14B.50304@computing-services.oxford.ac.uk> Message-ID: <96f3df640708020334l76c3510dl96fc251731380871@mail.gmail.com>
From: Dot Porter
Date: Thu, 2 Aug 2007 06:34:14 -0400
Hello Everyone,
On 8/2/07, Lou Burnard oxford.ac.uk> wrote:
> I still prefer the idea of recursive surfaces
>
> TEI -> header, facsimile? , text?
>
> facsimile -> front?, (surface+ | model.graphicLike+), back?)
>
> surface -> (model.graphicLike*, surface*)
>
> This allows for the possibility that you might have additional images
> for particularly interesting bits of the page ("zone"s in your terminologuy)
>
It is important to allow for both coordinates pointing into image
files and for separate "zone" images, however it's done.

> The big headache for me is the attributes. The draft I am working on
> proposes a new global attribute @facs to point from any element to a
> corresponding surface (or zone) but we need more than that.
>
Please, not global. I don't think @facs would make sense on any
element in the header (except maybe for some in msDesc). Perhaps on
children of ?
> James reminded me that there is work in the MPEG/ISO/W3C communities on
> defining new Xpointer schemes to point into assorted kinds of multimedia
> which we should at least acknowledge somewhere.
>
Conal had looked into this several months ago and had I believe
included it in a very early draft of the plan, but at that time the
multimedia Xpointer scheme was only for pointing into audio/video
files and not into still images (which would have made our work much
easier). This may have changed.
>
>
> Conal Tuohy wrote:
> > I have uploaded a simple diagram showing the (graphical) relationships between the , , and elements as used in the latest "facsimile" draft.
> >
> > http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg
> >
> > Please take a look at it to make sure we are all on the same page (pun intended) regarding the meaning of the proposed terms, since the proposed element names have changed as a result of last week's discussion.
> >
> > The diagram shows 1 page with 1 associated graphic, and 4 zones:
> >
> > A represents a physical page itself, and may contain and elements. The example represents a recto page from a manuscript.
> >
> > A represents a digital image of that page. In the example the graphic covers an area slightly larger than the page itself (represented by the element).
> >
> > A represents a rectangular area on a page. In the example the zones show 4 areas of interest, which would be linked to pieces of transcript.
> >
> > I will upload some other updated material after dinner (shortly)
> >
> > Conal
> >
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council_at_lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter_at_uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter_at_vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 06:34:25 EDT

From Conal.Tuohy at vuw.ac.nz Thu Aug 2 06:42:28 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 2 Aug 2007 22:42:28 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <96f3df640708020334l76c3510dl96fc251731380871@mail.gmail.com> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABD1@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 2 Aug 2007 22:42:28 +1200
Dot wrote:
>> James reminded me that there is work in the MPEG/ISO/W3C communities on
>> defining new Xpointer schemes to point into assorted kinds of multimedia
>> which we should at least acknowledge somewhere.
>>
> Conal had looked into this several months ago and had I believe
> included it in a very early draft of the plan, but at that time the
> multimedia Xpointer scheme was only for pointing into audio/video
> files and not into still images (which would have made our work much
> easier). This may have changed.
I think that's right, and I still believe that using URI fragment identifiers for pointing into images is not an useful approach.
A particular URI fragment identifier syntax is defined only for a particular set of internet media types.
So HTML has a fragment identifier syntax in which the identifier is a pointer to either an @id attribute, or the @name attribute of an element. XML has a complex syntax in which the identifier refers to an element with a matching @xml:id attribute, or it can use XPointer. SVG has that, too, and also has an "svgview" alternative.
But these different syntaxes apply only to HTML, XML, and SVG respectively; other media types need to have registered their own fragment identifier syntax, and neither JPEG, TIFF, GIF nor PNG images (I am pretty sure) have such a syntax defined. The MPEG group's pointer syntax applies only to MPEG video (or did, when I looked into it).
I believe that the facsimile markup should therefore not rely on fragment identifiers, since at best they will be too varied to be helpful, and at worst, they will simply not be defined for many useful image types.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 06:42:51 EDT
From cwittern at gmail.com Thu Aug 2 07:05:04 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 02 Aug 2007 20:05:04 +0900 Subject: [tei-council] facsimile diagram In-Reply-To: <96f3df640708020334l76c3510dl96fc251731380871@mail.gmail.com> Message-ID: <46B1BA60.7000505@gmail.com>
From: Christian Wittern
Date: Thu, 02 Aug 2007 20:05:04 +0900
For what its worth, as far as I understand the proposal I like what I see.
Dot Porter wrote:
> Hello Everyone,
>
> On 8/2/07, Lou Burnard oxford.ac.uk> wrote:
>
>> I still prefer the idea of recursive surfaces
>>
>> TEI -> header, facsimile? , text?
>>
>> facsimile -> front?, (surface+ | model.graphicLike+), back?)
>>
>> surface -> (model.graphicLike*, surface*)
>>
>> This allows for the possibility that you might have additional images
>> for particularly interesting bits of the page ("zone"s in your terminologuy)
>>
>>
> It is important to allow for both coordinates pointing into image
> files and for separate "zone" images, however it's done.
>
The way I understand Conal's proposal this is exactly the same set of
coordinates, since they relate to the same physical page.
>
>
>> The big headache for me is the attributes. The draft I am working on
>> proposes a new global attribute @facs to point from any element to a
>> corresponding surface (or zone) but we need more than that.
>>
>>
> Please, not global. I don't think @facs would make sense on any
> element in the header (except maybe for some in msDesc). Perhaps on
> children of ?
>
>
I think it will probably make sense to go even further and try to
determine on what elements it does make sense.
Christian
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 07:05:32 EDT

From Syd_Bauman at Brown.edu Thu Aug 2 07:07:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 2 Aug 2007 07:07:02 -0400 Subject: [tei-council] reduex In-Reply-To: <18096.44283.156958.762802@emt.wwp.brown.edu> Message-ID: <18097.47830.397258.606012@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 2 Aug 2007 07:07:02 -0400
OK, I've reinstated the element, making it and its
children members of the class att.dimensions (previously
att.measured), which has unit=, quantity=, and scope=.
Correspondingly I've put back into att.measurement, which
has unit=, quantity=, and commodity=. Since the two unit= attributes
are described quite differently, I don't think it is worth factoring
things out further, here. (Except perhaps for scope=, more in a
moment.)
I found that the previous content model for was
( height?, width?, depth? )+
which is equivalent to
( height | width | depth )*
There was some prose in the Guidelines that attempted explained the
utility of multiple occurences of the children elements, but the
example that purported to demonstrate this actually used multiple
elements, each with at most 1 child of each type. So I
changed the content model to
( height?, width?, depth? )
and tweaked the prose accordingly.
On scope=
-- ------
Since the unit= for is closer to that of than that of
, I made it a member of att.dimensions. This gives it a
scope= attribute, which we may think is so bizarre as to be worth
doing something about.
At the moment I am not sure what to do about this for P5 1.0. So I am
leaving it is, realizing that we may decide this is in error, and fix
it somehow within the next few days.
One idea would be to factor out the scope= attribute to a new
att.scoped, and make , , , and
members of att.scoped, but not .
I find the use of scope= in the examples in the tagdoc
confsuing. The example uses the value "range", which indicates that
the it is specified on only applies to a certain range of
the leaves in the entire manuscript. But the content also indicates a
range ("157-160") -- ostensibly the height of each leaf is from 157
to 160 mm (inclusive) within the range of leaves to which this
applies. And, AFAIK, there is no way to indicate what range
of leaves this height applies to. The example would be clearer, I
think, if the element with scope="range" had a single value as its
content (or value of quantity=), and some other element had a range
as its content. Or am I missing something?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:07:05 EDT
From djbpitt+tei at pitt.edu Thu Aug 2 07:14:50 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 02 Aug 2007 07:14:50 -0400 Subject: [tei-council] teleconference details In-Reply-To: <96DC4720-F7FE-42F0-BF94-E6E6F86223B0@indiana.edu> Message-ID: <46B1BCAA.70204@pitt.edu>
From: David J Birnbaum
Date: Thu, 02 Aug 2007 07:14:50 -0400
Dear Council,
The instructions below list the US Eastern time for the start of the
call as both 8:00 a.m. (first sentence) and 7:00 a.m. (more detailed
Access Information, below). If we go by 12:00 UTC, it should be 8:00
a.m. in the US Eastern time zone (see
http://www.timeanddate.com/worldclock/meetingtime.html?month=8&day=2&year=2007&p1=0&p2=179&p3=-1&p4=-1
). "See" you all then.
Best,
David
John A. Walsh wrote:
> You have been invited to participate in a Conference Call on 8/2/2007
> from 8:00:00 AM to 10:00:00 AM Eastern Time (US & Canada) / 12:00:00 -
> 14:00:00 UTC.
>
> The Conference Access Information is listed below:
>
> Date: 8/2/2007
> Begin Time: 7:00:00 AM Eastern Time (US & Canada) / 12:00:00 UTC
> End Time: 10:00:00 AM Eastern Time (US & Canada) / 14:00:00 UTC
> Phone Number: (812) 856-3600
> PIN: 000920#
>
> For conferencing assistance please call 812-855-4848.
>
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:15:03 EDT
From Syd_Bauman at Brown.edu Thu Aug 2 07:21:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 2 Aug 2007 07:21:59 -0400 Subject: [tei-council] rendition/rend proposal In-Reply-To: <46B1AB9E.9090001@computing-services.oxford.ac.uk> Message-ID: <18097.48727.384177.614235@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 2 Aug 2007 07:21:59 -0400
Overall I agree with Lou: good idea, fine proposal, we could get it
into P5 1.0 if we really wanted to (could also wait for P5 1.1), name
"rendition" could be improved upon. (I am presently leaning towards
"rendRef", as it is pronouncable.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:22:02 EDT
From Syd_Bauman at Brown.edu Thu Aug 2 07:29:26 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 2 Aug 2007 07:29:26 -0400 Subject: [tei-council] facsimile diagram In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABD1@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <18097.49174.993548.191473@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 2 Aug 2007 07:29:26 -0400
FWIW, the mechanism for using URIs to point into a graphic is to wrap
the image file in SVG. This permits pointing in very powerful ways
(e.g., to multiple subareas at once, to shapes other than rectangles;
even perhaps to multiple images at once, but I'm not sure of that),
but has the disadvantage that you need to go about using an SVG
wrapper. IIRC Council pretty much nixed this idea at or shortly after
our Kyoto meeting.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:29:31 EDT
From Conal.Tuohy at vuw.ac.nz Thu Aug 2 07:38:07 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 2 Aug 2007 23:38:07 +1200 Subject: [tei-council] updated facsimile odd Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABD2@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 2 Aug 2007 23:38:07 +1200
I have uploaded an updated ODD to match the diagram I uploaded earlier.
http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-for-august-teleconference.odd
Also, there is a little bit of documentation in the ODD, which I reproduce below:
1 Graphical facsimiles
1.1 Overview
This section deals with recording the planar co-ordinates of textual elements on the page; and linking those pages with digital facsimile images.
There are several applications for encoding the relationship between pages and facsimile images, and between pages and text. It can be used as the basis for full text search in ‘digital facsimle editions’, as well as for annotating figures and graphics, such as identifying individuals appearing in group portraits.
1.2 The , , and elements
1.2.1 The element
The element represents a physical page of the source material. This may be a sheet of paper, a billboard, a papyrus scroll, or indeed any 2-dimensional surface which forms part of the source material.
Each element may contain any number of elements, which represent facsimiles of the page, and any number of elements which represent rectangular areas of the page used as units of analysis.
1.2.2 The element
The element represents a rectangular region on the page represented by its parent element.
An is a unit of analysis, used to define a region of the page in order to say, typically, that some particular text appears there.
The element's function is as a graphical stand-off markup; that is, it is linked to a fragment of text using a pointer, and represents that fragment of text graphically, defining the area of the page on which that fragment of text appears. By using an , the graphical aspect of the text is encoded separately from the textual aspects, with the correspondences between the two aspects encoded using pointers.
An alternative to using the element is to encode the coordinates of pieces of text directly, as attributes of the elements containing the text.
1.2.3 The element
Within a element describing a particular page, each element represents one digital facsimile image of that page. Any number of elements may appear within a , in order that the page may be represented by images taken under multiple lighting conditions, with different resolutions or file formats, or by detail images covering only certain areas of the page.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:38:31 EDT
From Syd_Bauman at Brown.edu Thu Aug 2 07:41:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 2 Aug 2007 07:41:11 -0400 Subject: [tei-council] reduex In-Reply-To: <46B1A98E.2010808@computing-services.oxford.ac.uk> Message-ID: <18097.49879.905830.601067@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 2 Aug 2007 07:41:11 -0400
Well, I thought we had already agreed to (c) at least with respect to
, and so have implemented it. However, this does leave us
with the question of what to do with (which currently is
declared, but not used anywhere.)
Possibilities:
1. Abolish it.
2. Keep it (w/o text content) as a measure-like thing. May be useful
for things like
My neighbor has a
18 foot
7,600 gallon
pool
3. Keep it with a different name and w/ text content as a
measure-like thing. May be useful for things like
My neighbor has a
18
by
4,
7,600 gallon
pool

> If you choose (c) then you need to decide between the following content
> models for
>
> c-1 : text
> c-2 : text | model.dimLike+
> c-3 : text | model.dimLike.sequence
I pretty much just reverted to what we had previously -- but will our
ODD to DTD transformation make legal DTDs out of c-2 and c-3?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:41:14 EDT

From James.Cummings at computing-services.oxford.ac.uk Thu Aug 2 07:44:16 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 02 Aug 2007 12:44:16 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABD1@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46B1C390.70502@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 02 Aug 2007 12:44:16 +0100
Yup, I agree with what Conal says below. I think it a shame that a set of
xpointer schemes to point into all different sorts of media hasn't been
done. The ISO standard in question is 21000-17, I believe and only covers
MPEG. I think it would be great if the TEI had a single similar xpointer
scheme method for pointing into multiple types of non-XML media. However,
I don't think this is realistic or really advisable for P5 1.0. If ISO/W3C
do more in this area, it would be changes which are backwards compatible
and no problem to include in P5 1.x sometime in the future.
-James
Conal Tuohy wrote:
> Dot wrote:
>>> James reminded me that there is work in the MPEG/ISO/W3C communities
>>> on defining new Xpointer schemes to point into assorted kinds of
>>> multimedia which we should at least acknowledge somewhere.
>>>
>> Conal had looked into this several months ago and had I believe
>> included it in a very early draft of the plan, but at that time the
>> multimedia Xpointer scheme was only for pointing into audio/video
>> files and not into still images (which would have made our work much
>> easier). This may have changed.
>
> I think that's right, and I still believe that using URI fragment
> identifiers for pointing into images is not an useful approach.
>
> A particular URI fragment identifier syntax is defined only for a
> particular set of internet media types.
>
> So HTML has a fragment identifier syntax in which the identifier is a
> pointer to either an @id attribute, or the @name attribute of an
> element. XML has a complex syntax in which the identifier refers to an
> element with a matching @xml:id attribute, or it can use XPointer. SVG
> has that, too, and also has an "svgview" alternative.
>
> But these different syntaxes apply only to HTML, XML, and SVG
> respectively; other media types need to have registered their own
> fragment identifier syntax, and neither JPEG, TIFF, GIF nor PNG images
> (I am pretty sure) have such a syntax defined. The MPEG group's pointer
> syntax applies only to MPEG video (or did, when I looked into it).
>
> I believe that the facsimile markup should therefore not rely on
> fragment identifiers, since at best they will be too varied to be
> helpful, and at worst, they will simply not be defined for many useful
> image types. _______________________________________________ tei-council
> mailing list tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 07:44:21 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 07:44:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 12:44:54 +0100 Subject: [tei-council] reduex In-Reply-To: <18097.49879.905830.601067@emt.wwp.brown.edu> Message-ID: <46B1C3B6.6@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 12:44:54 +0100
Syd Bauman wrote:
> Well, I thought we had already agreed to (c) at least with respect to
> , and so have implemented it. However, this does leave us
> with the question of what to do with (which currently is
> declared, but not used anywhere.)
>
> Possibilities:
>
> 1. Abolish it.
+1
>
>> If you choose (c) then you need to decide between the following content
>> models for
>>
>> c-1 : text
>> c-2 : text | model.dimLike+
>> c-3 : text | model.dimLike.sequence
>
> I pretty much just reverted to what we had previously -- but will our
> ODD to DTD transformation make legal DTDs out of c-2 and c-3?
>
ah yes, actually you can't have either of c-2 or c-3. Bother.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:45:01 EDT
From Conal.Tuohy at vuw.ac.nz Thu Aug 2 07:54:25 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 2 Aug 2007 23:54:25 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <46B1A14B.50304@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABD3@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 2 Aug 2007 23:54:25 +1200
Lou Burnard wrote:
> The big headache for me is the attributes. The draft I am working on
> proposes a new global attribute @facs to point from any element to a
> corresponding surface (or zone) but we need more than that.
Yes, I think we certainly need to be able to point from a zone to a range of text, delimited by milestone elements.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 07:58:48 EDT
From djbpitt+tei at pitt.edu Thu Aug 2 09:35:29 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 02 Aug 2007 09:35:29 -0400 Subject: [tei-council] stemma modeling Message-ID: <46B1DDA1.6010303@pitt.edu>
From: David J Birnbaum
Date: Thu, 02 Aug 2007 09:35:29 -0400
Dear Council,
To adapt the markup used in my stemma report to current TEI practice:
1) Use TEI where I use .
2) Change the attributes for identification and pointing as James proposed.
3) Change my to TEI , as Arianna proposed.
Problem: is not currently permitted inside , and it
would need to be for this to work. I think the question for Council,
then, is whether we want to permit inside . If so, the
adaptation is easy, and we can fold my (modified) stemma example into
the graphing chapter as an example of using to model a
contaminated tree. If not, we should proceed without the proposed stemma
model.
Argument for: A stemma is not a tree, but it can be understood as a tree
with something else (and not simply as a non-tree). Accordingly,
modeling it as a tree (with ) but adding something to reflect the
contamination () conforms to what's really going on.
Argument against: A contaminated tree is by definition a non-tree, and
tree-oriented markup (such as ) is therefore inappropriate.
For what it's worth, I find the argument in favor more useful for those
who might want to model stemmata.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 09:35:43 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 10:18:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 15:18:18 +0100 Subject: [tei-council] stemma modeling In-Reply-To: <46B1DDA1.6010303@pitt.edu> Message-ID: <46B1E7AA.1010107@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 15:18:18 +0100
David J Birnbaum wrote:
>
> Problem: is not currently permitted inside , and it
> would need to be for this to work. I think the question for Council,
> then, is whether we want to permit inside .
note that is in namesdates, so cant be directly used in
. You'd
have to make a class model.relationLike, or move to the core.

would you be happy with a model which only permitted is another
module were loaded?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 10:18:22 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 10:23:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 15:23:10 +0100 Subject: [tei-council] reduex In-Reply-To: <18097.49879.905830.601067@emt.wwp.brown.edu> Message-ID: <46B1E8CE.50509@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 15:23:10 +0100
Syd Bauman wrote:
> 1. Abolish it.
>
>
+1
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 10:23:14 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 10:28:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 15:28:27 +0100 Subject: [tei-council] rendition/rend proposal In-Reply-To: <46B1AB9E.9090001@computing-services.oxford.ac.uk> Message-ID: <46B1EA0B.5090508@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 15:28:27 +0100
Lou Burnard wrote:
> b) @rendition is not such a nice name. Would @style be better (OK I
> know it's exactly not what HTML @style is but @class would be really
> confusing)? @rendPtr ? @render ?
@style or @class would remind one of the HTML attributes which are NOT
the same
semantically or syntactically. Bad....
@rendered would be better, as it makes clear that this is how it _was_
rendered,
not how it _will_ be.
> most production systems that I know of will take what the TEI document
> says about source rendition and use it to determine the output
> rendition anyway.
quite....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 10:28:29 EDT
From James.Cummings at computing-services.oxford.ac.uk Thu Aug 2 10:43:18 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 02 Aug 2007 15:43:18 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABD3@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46B1ED86.8040608@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 02 Aug 2007 15:43:18 +0100
Conal Tuohy wrote:
> Lou Burnard wrote:
>
>> The big headache for me is the attributes. The draft I am working on
>> proposes a new global attribute @facs to point from any element to a
>> corresponding surface (or zone) but we need more than that.
>
> Yes, I think we certainly need to be able to point from a zone to a
> range of text, delimited by milestone elements.
Conal,
In the call you said something like that in the surface/graphic/zone
hierarchy the graphic could be a full page/wall/whatever or could equally
be a small detail of that surface. I just want to make sure I'm
understanding this right, it isn't that graphic can act as a zone, but that
you could have two graphics, one full page, one same resolution but
close-up-macro-shot-of-detail? If the first graphic had a zone that was
the same as the amount-of-surface covered by the second graphic that would
be ok. (The use-case in my mind being highlighting a section of the first
graphic somehow to then have someone click on to see the full-sized detail
(i.e. second graphic).)
I just wanted to make sure I had that clear in my mind or I wasn't
misunderstanding?
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 10:43:23 EDT
From djbpitt+tei at pitt.edu Thu Aug 2 11:03:11 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 02 Aug 2007 11:03:11 -0400 Subject: [tei-council] stemma modeling In-Reply-To: <46B1E7AA.1010107@oucs.ox.ac.uk> Message-ID: <46B1F22F.4080404@pitt.edu>
From: David J Birnbaum
Date: Thu, 02 Aug 2007 11:03:11 -0400
Dear Council,
> note that is in namesdates, so cant be directly used in
> . You'd
> have to make a class model.relationLike, or move to the core.
>
> would you be happy with a model which only permitted if
> another
> module were loaded?
Doesn't sound like a problem.
Best,
David
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 11:03:25 EDT
From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 13:00:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 18:00:29 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABD2@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46B20DAD.7090706@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 18:00:29 +0100
Musings....
If I have the surface/graphic/zone setup, then I can see that
zone/@coords of 20,20,100,100 represents one rectangle,
measured in pixels, of the parent graphic.
I can also see that my

or whatever links to
a by ID.
I can also see that one links to X of Y in
Z (though I see not how).
What I do NOT see is how one can link to
coords 20,20,100,100 in the _surface_. Can it?
It can only relate to a particular graphic?
If I have a hi-res image and a lo-res image,
and describe the same are within each,
the coords of each will be different. Correct?
When I have one , with three ,
each with a pointing at the original of my ,
then the points at all three?

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 13:00:33 EDT

From James.Cummings at computing-services.oxford.ac.uk Thu Aug 2 17:03:22 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 02 Aug 2007 22:03:22 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <46B20DAD.7090706@oucs.ox.ac.uk> Message-ID: <46B2469A.7020606@computing-services.oxford.ac.uk>
From: James Cummings
Date: Thu, 02 Aug 2007 22:03:22 +0100
Sebastian Rahtz wrote:
> What I do NOT see is how one can link to
> coords 20,20,100,100 in the _surface_. Can it?
> It can only relate to a particular graphic?
I'm not entirely sure of the relationship in coordinates between the graphic and
the surface. Unless the unit of measurement is determined on the surface and
then all the coords are defaultly in that unit of measurement (and in that case
it must be a real-world physical unit, i.e. not pixels).
> If I have a hi-res image and a lo-res image,
> and describe the same are within each,
> the coords of each will be different. Correct?
I'm not sure. If the coords is on graphic, in units of measurement referring to
the surface, then they both cover the same distance. (One simply does it with
greater resolution in its reproduction of that surface.) If coords is on a zone,
then it makes sense that it is in relation to whatever unit of measurement is
use for the graphic (presumably pixels).
> When I have one , with three ,
> each with a pointing at the original of my ,
> then the points at all three?
I think then the l/@corresp (or specialised attribute) could point to all three
zones, and that these zones would have different coords in relationship to the
graphic which contains them. However, it is equally possible for there just to
be a l/@xml:id which then each of the zones point to. (And in fact, that way
round of zones pointing to lines stand-offishly rather than the reverse would
naturally be my preference, I believe.)
I'm still a bit fuzzy on the details of the relationship between surface and
graphic and would like more clarification from Conal and others how they see
that working. Maybe the examples being reworked as Conal suggested would help.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 17:03:26 EDT
From James.Cummings at oucs.ox.ac.uk Thu Aug 2 17:10:06 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Aug 2007 22:10:06 +0100 Subject: [tei-council] stemma modeling In-Reply-To: <46B1F22F.4080404@pitt.edu> Message-ID: <46B2482E.80503@oucs.ox.ac.uk>
From: James Cummings
Date: Thu, 02 Aug 2007 22:10:06 +0100
David J Birnbaum wrote:
> Dear Council,
>
>> note that is in namesdates, so cant be directly used in
>> . You'd
>> have to make a class model.relationLike, or move to the core.
>>
>> would you be happy with a model which only permitted if
>> another
>> module were loaded?
>
> Doesn't sound like a problem.
I'd concur, that wouldn't be a problem. If you didn't need to mark
contamination, then you don't need to load namesdates(etc.) ... but then again
the type of person doing manuscript stemmata is probably already going to have
loaded this. ;-)
-James
>
> Best,
>
> David
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 02 2007 - 17:10:10 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 18:58:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 02 Aug 2007 23:58:59 +0100 Subject: [tei-council] contribs from me during August Message-ID: <46B261B3.8070504@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Thu, 02 Aug 2007 23:58:59 +0100
Just a note to say that I'll be doing my P5 tasks
only after August 23rd, as I am on family holiday from
this weekend.
If anything like Roma breaks, and James or Lou
are around, they may be able to fix it.
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 17:58:29 EDT
From Conal.Tuohy at vuw.ac.nz Thu Aug 2 18:34:55 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 3 Aug 2007 10:34:55 +1200 Subject: [tei-council] rendition/rend proposal In-Reply-To: <46B1EA0B.5090508@oucs.ox.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABD4@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 3 Aug 2007 10:34:55 +1200
Lou Burnard wrote:
> b) @rendition is not such a nice name. Would @style be better (OK I
> know it's exactly not what HTML @style is but @class would be really
> confusing)? @rendPtr ? @render ?
Sebastian Rahtz wrote:
> @rendered would be better, as it makes clear that this is how it _was_
> rendered, not how it _will_ be.
I like @rendered, too
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 02 2007 - 18:36:43 EDT
From Syd_Bauman at brown.edu Fri Aug 3 14:34:58 2007 From: Syd_Bauman at brown.edu (Syd Bauman) Date: Fri, 3 Aug 2007 14:34:58 -0400 Subject: [tei-council] Roma over the weekend Message-ID: <18099.30034.424108.929858@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 3 Aug 2007 14:34:58 -0400
I have temporarily moved my TEI Ubuntu machine to outside of my office's
firewall. Thus another Roma is available to Council members at
http://tei.wwp.brown.edu/Roma/. This is likely to be temporary,
perhaps even short-lived, but should take us through this Oxford-free
weekend.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 08:45:03 EDT
From conal.tuohy at vuw.ac.nz Fri Aug 3 03:00:06 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 03 Aug 2007 19:00:06 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <46B2CA7B.3090506@oucs.ox.ac.uk> Message-ID: <1186124406.22202.121.camel@localhost>
From: Conal Tuohy
Date: Fri, 03 Aug 2007 19:00:06 +1200
On Fri, 2007-08-03 at 07:26 +0100, James Cummings wrote:
> Conal Tuohy wrote:
> > It's true I didn't mean to imply that a graphic could act as a zone - I
> > don't think people should in general be linking bits of text to those
> > graphics.
>
> So really people should only be linking to and from zones generally.
yes
> > Within the same as the stamp's , there would be some
> > elements, and if those graphics had @coords which overlapped
> > the @coords of the stamp's zone, then those graphics would actually
> > depict the stamp itself. Any of those associated graphics might be used
> > to present a view of that zone. Obviously a graphic whose coords
> > entirely enclosed the coords of the zone would be best (because it will
> > show the full stamp), and a graphic whose resolution is higher will be
> > better (if zooming), etc.
>
> Ok, and if those graphic/@coords are relative to the surface, how do we on the
> surface indicate what unit of measurement they are using? Surely a surface may
> be measured in all sorts of units (millimetres, inches, metres,
> kilometres,etc.)?
Well, it's not really needed in order to align the graphics and the
zones (all that's needed is that the units are consistent). But for
documentary purposes, perhaps a surface's dimensions could be given
using a element?
> How do I know that one graphic is higher resolution than the
> other? i.e. they both cover the same area of the surface "0 0 100 100" but one
> was taken with a hi-res camera, and one was taken quite awhile ago with some
> low-res camera. How is that resolution indicated?
The 2 graphics may use @height and @width to indicate their intrinsic
dimensions. The hi-res image should be higher and wider, despite having
the same @coords as the equivalent lo-res image. The resolution of a
graphic could be calculated by dividing the @width by the width as
specified in the @coords (which says how much of the surface the graphic
covers).
But to be honest, rereading the documentation for @height, @width and
@scale, I'm not entirely sure that I understand how @height and @width
are supposed to work together with @scale.
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
If I have an image which is 200px wide, I would expect to mark it up as
a graphic with @width="200px", but what do I do with @scale? And what is
the "desired display size" anyway? If I give @scale="2", I'd be saying
that I wanted the image to be displayed as 400 pixels wide, which sounds
like an odd thing to want to do.
I'd be interested in seeing any examples of the use of @scale.
As an alternative to calculations involving graphic/@height, etc,
presentation software could choose among graphics on the basis of
metadata encoded in a linked element. Could that be a
useful approach?
Con

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 08:48:46 EDT

From lou.burnard at computing-services.oxford.ac.uk Sat Aug 4 06:27:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 04 Aug 2007 11:27:17 +0100 Subject: [tei-council] test Message-ID: <46B45485.8020008@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 04 Aug 2007 11:27:17 +0100
There seems to be a problem with this list again.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 08:55:18 EDT
From conal.tuohy at vuw.ac.nz Thu Aug 2 20:19:07 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 03 Aug 2007 12:19:07 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <46B1ED86.8040608@computing-services.oxford.ac.uk> Message-ID: <1186100347.22202.77.camel@localhost>
From: Conal Tuohy
Date: Fri, 03 Aug 2007 12:19:07 +1200
On Thu, 2007-08-02 at 15:43 +0100, James Cummings wrote:
> In the call you said something like that in the surface/graphic/zone
> hierarchy
Let me just stop you there to note that the hierarchy is really:
surface/(graphic|zone) - i.e. the graphics and zones are siblings.
> the graphic could be a full page/wall/whatever or could equally
> be a small detail of that surface. I just want to make sure I'm
> understanding this right, it isn't that graphic can act as a zone,
It's true I didn't mean to imply that a graphic could act as a zone - I
don't think people should in general be linking bits of text to those
graphics.
> ... but that
> you could have two graphics, one full page, one same resolution but
> close-up-macro-shot-of-detail?
I think a detail shot would typically have a higher resolution wouldn't
it? There wouldn't be much point if the detail shot were just a cropped
version of the full page.

> If the first graphic had a zone ...

Here I think you've gone astray. In the proposed model, the graphics do
not "have" zones, nor do the zones "have" graphics. The graphics and
zones are siblings, and relate to each other only in that the occupy
regions in the same 2-dimensional space (represented by their common
parent element, a ).
Let's go through an example:
Say you have a manuscript with an interesting stamp on it, which you
want to be able to highlight in some presentation system.
Somewhere within the you would represent that stamp in your
transcript with (a "semantic" representation of the stamp).
Somewhere within the (specifically, within a particular
representing the page the stamp appeared on), you'd
represent the stamp as a (with a @corresp or similar link to the
). This would be a purely "cartesian" representation of the
stamp.
Within the same as the stamp's , there would be some
elements, and if those graphics had @coords which overlapped
the @coords of the stamp's zone, then those graphics would actually
depict the stamp itself. Any of those associated graphics might be used
to present a view of that zone. Obviously a graphic whose coords
entirely enclosed the coords of the zone would be best (because it will
show the full stamp), and a graphic whose resolution is higher will be
better (if zooming), etc.
Does that help?
Cheers
Con
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 09:17:03 EDT

From James.Cummings at oucs.ox.ac.uk Sat Aug 4 06:05:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 04 Aug 2007 11:05:52 +0100 Subject: [tei-council] Minutes Message-ID: <46B44F80.3010109@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 04 Aug 2007 11:05:52 +0100
The minutes from the last meeting are available now. Both editors have had a
chance to glance at them, so I thought I should announce them to Council:
http://www.tei-c.org/Council/tcm33.xml?style=printable
Please double check that I've not forgotten any actions, and that you understand
and agree with the due dates for the actions assigned to you. And as always,
feel free to point out the many typos and grammatical mistakes.
Best,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 09:28:41 EDT
From cwittern at gmail.com Thu Aug 2 19:40:36 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 03 Aug 2007 08:40:36 +0900 Subject: [tei-council] updated facsimile odd In-Reply-To: <46B2469A.7020606@computing-services.oxford.ac.uk> Message-ID: <46B26B74.9020001@gmail.com>
From: Christian Wittern
Date: Fri, 03 Aug 2007 08:40:36 +0900
James Cummings wrote:
> Sebastian Rahtz wrote:
>> What I do NOT see is how one can link to
>> coords 20,20,100,100 in the _surface_. Can it?
>> It can only relate to a particular graphic?
As I understand it you link to the surface coordinates and then go and
see which graphic covers the area you are interested in. That seems to
be the whole point of this indirection.
>
> I'm not entirely sure of the relationship in coordinates between the
> graphic and the surface. Unless the unit of measurement is determined
> on the surface and then all the coords are defaultly in that unit of
> measurement (and in that case it must be a real-world physical unit,
> i.e. not pixels).
>
>> If I have a hi-res image and a lo-res image,
>> and describe the same are within each,
>> the coords of each will be different. Correct?
My understanding is that they will be exactly the same, since the coords
are expressed relative to the .
>
> I'm not sure. If the coords is on graphic, in units of measurement
> referring to the surface, then they both cover the same distance.
> (One simply does it with greater resolution in its reproduction of
> that surface.) If coords is on a zone, then it makes sense that it is
> in relation to whatever unit of measurement is use for the graphic
> (presumably pixels).
>
>> When I have one , with three ,
>> each with a pointing at the original of my ,
>> then the points at all three?
>
> I think then the l/@corresp (or specialised attribute) could point to
> all three zones, and that these zones would have different coords in
> relationship to the graphic which contains them.
As I understand it, the pointing goes through the indirection of the
surface: You express the location of in terms of the
coords, using the same reference system as is used for the zones. You
will then discover from these coords in which of the zones (in this case
all three) your is located.

Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 09:42:31 EDT

From lou.burnard at computing-services.oxford.ac.uk Thu Aug 2 18:47:27 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 02 Aug 2007 23:47:27 +0100 Subject: [tei-council] rendition/rend proposal In-Reply-To: <46B26C44.6020701@oucs.ox.ac.uk> Message-ID: <46B25EFF.2090606@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Thu, 02 Aug 2007 23:47:27 +0100
Sebastian Rahtz wrote:
> @rendPtr would meet James' criticism, as it makes
> it clear that its doing the same job as @rend, but using a
> different method.
>
> or @rendTarget
>
> Sebastian
>
or @rendRef (syd's suggestion, I believe)
but i still dont like any of em much

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 11:34:17 EDT

From James.Cummings at oucs.ox.ac.uk Fri Aug 3 02:26:03 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 03 Aug 2007 07:26:03 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <1186100347.22202.77.camel@localhost> Message-ID: <46B2CA7B.3090506@oucs.ox.ac.uk>
From: James Cummings
Date: Fri, 03 Aug 2007 07:26:03 +0100
Conal Tuohy wrote:
> Let me just stop you there to note that the hierarchy is really:
> surface/(graphic|zone) - i.e. the graphics and zones are siblings.
Yes, I was confused about this. Mea culpa.
> It's true I didn't mean to imply that a graphic could act as a zone - I
> don't think people should in general be linking bits of text to those
> graphics.
So really people should only be linking to and from zones generally.
> I think a detail shot would typically have a higher resolution wouldn't
> it? There wouldn't be much point if the detail shot were just a cropped
> version of the full page.
I've known ppl to do stranger things.
> Here I think you've gone astray. In the proposed model, the graphics do
> not "have" zones, nor do the zones "have" graphics. The graphics and
> zones are siblings, and relate to each other only in that the occupy
> regions in the same 2-dimensional space (represented by their common
> parent element, a ).
Yup I was confused.
> Within the same as the stamp's , there would be some
> elements, and if those graphics had @coords which overlapped
> the @coords of the stamp's zone, then those graphics would actually
> depict the stamp itself. Any of those associated graphics might be used
> to present a view of that zone. Obviously a graphic whose coords
> entirely enclosed the coords of the zone would be best (because it will
> show the full stamp), and a graphic whose resolution is higher will be
> better (if zooming), etc.
Ok, and if those graphic/@coords are relative to the surface, how do we on the
surface indicate what unit of measurement they are using? Surely a surface may
be measured in all sorts of units (millimetres, inches, metres,
kilometres,etc.)? How do I know that one graphic is higher resolution than the
other? i.e. they both cover the same area of the surface "0 0 100 100" but one
was taken with a hi-res camera, and one was taken quite awhile ago with some
low-res camera. How is that resolution indicated?
> Does that help?
Yes, greatly. Don't think I've got it entirely.
Best,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 11:44:22 EDT
From cwittern at gmail.com Fri Aug 3 01:50:05 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 03 Aug 2007 14:50:05 +0900 Subject: [tei-council] date for next telco Message-ID: <46B2C20D.3000607@gmail.com>
From: Christian Wittern
Date: Fri, 03 Aug 2007 14:50:05 +0900
Dear Council members,
As promised, I have asked meetomatic.com to find a suitable day for us. The
meeting will take place as usual at 1200 UTC.
I've proposed a meeting for the dates below.
Please visit the following web page to fill in your own
constraints:
http://www.meetomatic.com/respond.php?id=2J30GB
PROPOSED MEETING DATES:
Monday 20th August 2007
Tuesday 21st August 2007
Wednesday 22nd August 2007
Thursday 23rd August 2007
Friday 24th August 2007
Monday 27th August 2007
Tuesday 28th August 2007
Wednesday 29th August 2007
Thursday 30th August 2007
Friday 31st August 2007
Monday 3rd September 2007
Tuesday 4th September 2007
Wednesday 5th September 2007
Thursday 6th September 2007
Friday 7th September 2007
-------------------------
Meet-O-Matic - The World's Simplest Meeting Scheduler
Copyright (c) Meetomatic Ltd., 2003-2007. All Rights Reserved.

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 13:00:13 EDT

From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 2 19:44:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 03 Aug 2007 00:44:04 +0100 Subject: [tei-council] rendition/rend proposal In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABD4@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46B26C44.6020701@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 03 Aug 2007 00:44:04 +0100
@rendPtr would meet James' criticism, as it makes
it clear that its doing the same job as @rend, but using a
different method.
or @rendTarget
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 13:01:55 EDT
From Syd_Bauman at Brown.edu Sat Aug 4 14:16:49 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 4 Aug 2007 14:16:49 -0400 Subject: [tei-council] postscript scripted Message-ID: <18100.49809.914174.678339@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 4 Aug 2007 14:16:49 -0400
I have put the new element for encoding postscripts into the
Guidelines. Since no one spoke up preferring to , I
have used the name .
I'm afraid there were two egregious errors in the free-standing ODD I
created which no one noticed:
* examples used value= (instead of when=) on
* content model of was the no-longer existing macro.componentSeq
(I didn't even notice this myself until validation of P5 failed!)
Both have been fixed.
Note: for now is a member of model.divBottom, as I
couldn't bring myself to put it into the mis-named model.pLike.back
until that is fixed. I'm off to have lunch first, but then plan to
get to that this afternoon.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 14:16:53 EDT
From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 3 04:13:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 03 Aug 2007 09:13:23 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <46B26B74.9020001@gmail.com> Message-ID: <46B2E3A3.3030407@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 03 Aug 2007 09:13:23 +0100
Christian Wittern wrote:
> As I understand it you link to the surface coordinates and then go and
> see which graphic covers the area you are interested in. That seems
> to be the whole point of this indirection.
umm. expand on "the surface coordinates" for me. if they are unitless
and unbounded,
they cannot mean anything.
>>
>
> My understanding is that they will be exactly the same, since the
> coords are expressed relative to the .
relative is good, but you must either have units, or proportions of a
bounding box. just units
won't cut it.
> As I understand it, the pointing goes through the indirection of the
> surface: You express the location of in terms of the
> coords, using the same reference system as is used for the zones. You
> will then discover from these coords in which of the zones (in this
> case all three) your is located.
we really really need worked examples of this to understand it....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Aug 04 2007 - 14:40:04 EDT
From lou.burnard at computing-services.oxford.ac.uk Sat Aug 4 18:19:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 04 Aug 2007 23:19:10 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <1186124406.22202.121.camel@localhost> Message-ID: <46B4FB5E.4030309@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sat, 04 Aug 2007 23:19:10 +0100
Conal Tuohy wrote:
> But to be honest, rereading the documentation for @height, @width and
> @scale, I'm not entirely sure that I understand how @height and @width
> are supposed to work together with @scale.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
>
> If I have an image which is 200px wide, I would expect to mark it up as
> a graphic with @width="200px", but what do I do with @scale? And what is
> the "desired display size" anyway? If I give @scale="2", I'd be saying
> that I wanted the image to be displayed as 400 pixels wide, which sounds
> like an odd thing to want to do.
>
My understanding of these attributes on is that they relate to
the desired display size -- i.e. how the image is to be rendered. If
@scale=2,. it means I want it rendered twice as big as it actually is.
If @width=50 it means I want it rendered 50 px wide (and presumably with
the height scaled accordingly). You can't supply @scale along with the
others, clearly -- or if you do I am not sure which wins. The
documentation (like the schema) is vague on this point.
They do NOT describe the actual size of the image.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 04 2007 - 18:26:56 EDT
From Syd_Bauman at Brown.edu Sun Aug 5 00:00:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 5 Aug 2007 00:00:10 -0400 Subject: [tei-council] divWrapper classes changed Message-ID: <18101.19274.945045.438169@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sun, 5 Aug 2007 00:00:10 -0400
Due to an error in the content model that Sebastian
discovered, we did indeed need to create the extra divTopPart and
divBottomPart classes as per discussion here of 07-18.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 00:00:15 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 5 08:12:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 05 Aug 2007 13:12:20 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <1186100347.22202.77.camel@localhost> Message-ID: <46B5BEA4.5070408@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 05 Aug 2007 13:12:20 +0100
Conal wrote
"Within the same as the stamp's , there would be some
elements, and if those graphics had @coords which overlapped
the @coords of the stamp's zone, then those graphics would actually
depict the stamp itself."
which simply cannot work with unitless coordinates! either you
must have a unit, or coordinates must be proportions of an overall
width and height limit.
If said " width=400 height=800", then a @coords value
of "10,20" makes sense. But not otherwise.
Though how I would work out that a was 400 x 800, I know not.....

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 07:12:18 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 5 08:14:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 05 Aug 2007 13:14:13 +0100 Subject: [tei-council] Roma over the weekend In-Reply-To: <18099.30034.424108.929858@emt.wwp.brown.edu> Message-ID: <46B5BF15.7080801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 05 Aug 2007 13:14:13 +0100
Syd Bauman wrote:
> I have temporarily moved my TEI Ubuntu machine to outside of my office's
> firewall. Thus another Roma is available to Council members at
> http://tei.wwp.brown.edu/Roma/. This is likely to be temporary,
> perhaps even short-lived, but should take us through this Oxford-free
> weekend.
>
hmm, its _next_ weekend that Oxford is off...
but i am delighted to see your Roma is working!
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 07:14:12 EDT
From lou.burnard at computing-services.oxford.ac.uk Sun Aug 5 17:07:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 05 Aug 2007 22:07:12 +0100 Subject: [tei-council] facsimile draft Message-ID: <46B63C00.4080903@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 05 Aug 2007 22:07:12 +0100
As mentioned in the call, I've been working on trying to produce a
section about facsimile markup which could be plugged into the current
chapter on physical transcription, using as many as possible of the
ideas discussed here by Conal and others over the last few weeks.
Time is running out, and we need to get closure on this, so I hope Conal
and Dot will excuse me for steaming ahead on this without consulting
with them privately first. I've used the documents circulated and
followed (as far as I can) the discussion so far to produce a
straw-person kind of a draft which is now posted for your (particularly
their) urgent attention at http://www.tei-c.org/Drafts/facs.odd
I've deliberately restricted the scope of what this draft makes possible
to what I hope we can all agree on as a bare minimum of functionality.
It supports linking from text to image and image to text with a minimum
of fuss ; it also supports linking between text and image fragments, but
only provides one way to do it. It tries to fit in with existing TEI
idiom and practice.
It is however in desperate need of help on the following counts:
-- I haven't the faintest idea how to transcribe the Old English ms
we're using as an example. (The one Conal circulated earlier). Either
someone needs to transcribe it for me, or I need to find another example
which I can transcribe. (Actually, as this one claims to be copyright of
the Bodleian, the second is probably the wiser course)
-- in defining how the co-ordinate system works, I have had to rely on
my vague recollections of O level maths. Someone who actually knows
about this stuff should read it carefully to see how plausible this is.
Also how feasible it is to implement it!
-- I've also made a wild guess about how to specify the datatype of my
@box attribute (formerly known as @coords -- I renamed it because it is
considerably more restricted than the synonymous XHTML attribute)
All comments, bouquets, and brickbats gratefully received
Lou

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 17:15:03 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 5 18:24:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 05 Aug 2007 23:24:35 +0100 Subject: [tei-council] facsimile draft In-Reply-To: <46B63C00.4080903@computing-services.oxford.ac.uk> Message-ID: <46B64E23.8090104@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 05 Aug 2007 23:24:35 +0100
I wonder how to gracefully extend the scheme
to allow for non-rectangular shapes. the name
@box is a bit restrictive. I'd prefer @shape,
possibly.
I am fairly sure I believe in the internal integrity of this
setup; and, more or less, in its implementability.
I'd hesitate to sign off on it until I had tried it
with real data, though, and made some
output....
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 17:24:32 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 5 18:26:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 05 Aug 2007 23:26:26 +0100 Subject: [tei-council] facsimile draft In-Reply-To: <46B63C00.4080903@computing-services.oxford.ac.uk> Message-ID: <46B64E92.8050008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 05 Aug 2007 23:26:26 +0100
PS you may wish to be prepared to change
0,0 to be at top-left. Strangely, computer folks prefer
it this way for reasons I wot not of. Perhaps related
to their need to think 0 is the first number in
a sequence..
Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 17:26:27 EDT
From lou.burnard at computing-services.oxford.ac.uk Sun Aug 5 17:55:44 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 05 Aug 2007 22:55:44 +0100 Subject: [tei–council] facsimile draft –– only boxes? In-Reply-To: <46B64E23.8090104@oucs.ox.ac.uk> Message-ID: <46B64760.3000504@computing-services.oxford.ac.uk>
From: Lou Burnard
Date: Sun, 05 Aug 2007 22:55:44 +0100
Sebastian Rahtz wrote:
> I wonder how to gracefully extend the scheme
> to allow for non-rectangular shapes. the name
> @box is a bit restrictive. I'd prefer @shape,
> possibly.
I chose the name precisely because it makes explicit the limitation that
we only do this for rectangular shapes. If you want other shapes, you
have to define them in SVG. Might be worth mentioning that method here,
or cross-referring to where it's discussed (in SA if I remember aright)
his notation represents two pairs of h,v coordinates, the first pair
giving the coordinates of the top-left corner of the rectangle and the
second pair giving the coordinates of the bottom-right corner (8,13,130,1
I'm not sure whether @coords in HTML requires you to specify the shape
(using @shape attribute): it seems instead that you can rely on some
rather odd rules about how the coordinates are specified:
* When shape="rect" (rectangle), the coords are specified by
four numbers separated by commas. This notation represents two pairs of
h,v coordinates, the first pair giving the coordinates of the top-left
corner of the rectangle and the second pair giving the coordinates of
the bottom-right corner (8,13,130,123).
* When shape="circle", the coords are specified by three
numbers separated by commas. The first two numbers represent the h,v
coodinates of the center point of the circle and the last number is the
pixel width of the radius (228,123,62).
* When shape="poly" (polygon), the coords are specified by as
many pairs of h,v coordinates as there are points on the polygon. Number
pairs can be listed clockwise or counter-clockwise around the polygon;
they are separated by blank spaces (100,144 175,200 155,255 50,250 45,175).

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 18:03:37 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 5 19:09:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 06 Aug 2007 00:09:16 +0100 Subject: [tei–council] facsimile draft –– only boxes? In-Reply-To: <46B64760.3000504@computing-services.oxford.ac.uk> Message-ID: <46B6589C.4050506@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 06 Aug 2007 00:09:16 +0100
Lou Burnard wrote:
>
> I chose the name precisely because it makes explicit the limitation
> that we only do this for rectangular shapes.
ok, fair point.
> If you want other shapes, you have to define them in SVG. Might be
> worth mentioning that method here,
it would be good to work up an example of it
to record somewhere. one of these days..
ebasyian

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 05 2007 - 18:09:12 EDT

From cwittern at gmail.com Tue Aug 7 01:59:28 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 07 Aug 2007 14:59:28 +0900 Subject: [tei-council] facsimile draft In-Reply-To: <46B63C00.4080903@computing-services.oxford.ac.uk> Message-ID: <46B80A40.2070202@gmail.com>
From: Christian Wittern
Date: Tue, 07 Aug 2007 14:59:28 +0900
Lou Burnard wrote:
> As mentioned in the call, I've been working on trying to produce a
> section about facsimile markup which could be plugged into the current
> chapter on physical transcription, using as many as possible of the
> ideas discussed here by Conal and others over the last few weeks.
>
> Time is running out, and we need to get closure on this, so I hope
> Conal and Dot will excuse me for steaming ahead on this without
> consulting with them privately first. I've used the documents
> circulated and followed (as far as I can) the discussion so far to
> produce a straw-person kind of a draft which is now posted for your
> (particularly their) urgent attention at
> http://www.tei-c.org/Drafts/facs.odd
>
Thanks for getting it this far. It seems pretty well worked through, at
least as far as I can see by just reading through it.
I wonder if it would be worthwhile to show this to Martin Holmes to see
what he thinks -- if we get ever an implementation of this, he is among
the likely implementers.

> I've deliberately restricted the scope of what this draft makes
> possible to what I hope we can all agree on as a bare minimum of
> functionality. It supports linking from text to image and image to
> text with a minimum of fuss ; it also supports linking between text
> and image fragments, but only provides one way to do it. It tries to
> fit in with existing TEI idiom and practice.
I feel a bit uneasy about @facs doubling as a direct and indirect link
-- are there other cases where we do something similar?
One tiny piece of nit-picking: in this list, you probably dont want the
word "element" after facsimile?
legal TEI document may thus comprise any of the following:-

a TEI Header and a text
a TEI Header and a facsimile element
a TEI Header, a facsimile, and a text

>
> -- I've also made a wild guess about how to specify the datatype of my
> @box attribute (formerly known as @coords -- I renamed it because it
> is considerably more restricted than the synonymous XHTML attribute)
>
As Sebastian said, I would use the same type of arrangement for the
coordinates as in HTML, SVG, CSS and who knows what, that is starting
from the upper left corner.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Aug 07 2007 - 01:59:51 EDT

From cwittern at gmail.com Tue Aug 7 06:19:10 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 07 Aug 2007 19:19:10 +0900 Subject: [tei-council] Minutes In-Reply-To: <46B44F80.3010109@oucs.ox.ac.uk> Message-ID: <46B8471E.3040606@gmail.com>
From: Christian Wittern
Date: Tue, 07 Aug 2007 19:19:10 +0900
James Cummings wrote:
>
> The minutes from the last meeting are available now. Both editors
> have had a chance to glance at them, so I thought I should announce
> them to Council:
>
> http://www.tei-c.org/Council/tcm33.xml?style=printable
Thank you. The minutes look fine to me, I also did not find uncovered
actions.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Aug 07 2007 - 06:19:31 EDT

From cwittern at gmail.com Tue Aug 7 06:22:24 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 07 Aug 2007 19:22:24 +0900 Subject: [tei-council] Lock-editing period Sep 15 - Oct 19 Message-ID: <46B847E0.9000700@gmail.com>
From: Christian Wittern
Date: Tue, 07 Aug 2007 19:22:24 +0900
Council members,

At the last conference call, we deferred the final decision on this item for
a few days. I have in the mean time talked with Syd over this and neither
then, nor on this list have been new arguments or new suggestions come
foreword. I would therefore like to settle this issue in the way it was
proposed in the time table. If there are dissenters, please speak up now!
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Aug 07 2007 - 06:22:43 EDT

From James.Cummings at oucs.ox.ac.uk Tue Aug 7 11:47:37 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 07 Aug 2007 16:47:37 +0100 Subject: [tei-council] Formatting of the Guidelines: Update Message-ID: <46B89419.5040607@oucs.ox.ac.uk>
From: James Cummings
Date: Tue, 07 Aug 2007 16:47:37 +0100
A bit late, but here is my report on the formatting of the Guidelines work.
I've been progressing through the list of suggested improvement on the
wiki. The beta (well not really, but whatever) version where formatting is
slowly changing is filed in SVN alongside the normal P5 formatting. That
is instead of guidelines.css there is a guidelines-beta.css instead of
Utilities/guidelines.xsl there is a Utilities/guidelines-beta.xsl These
are used with a separate Makefile target (make html-web-beta) to produce a
version of the Guidelines with any XSLT/CSS changes we've made. This is
automatically produced alongside the version on tei.oucs.ox.ac.uk in a
separate folder so that none of the changes we make end up breaking the
current tei.oucs Guidelines.
Some of the things done recently include:
- Changing Sebastian's red-bordered black and white link from 'RNG' or
'RNC' to an actual xhtml button.
- Adding of discrete permanent links following division headings. (Still
currently has some problems).
- Changed the 'edited by' to 'Edited by' as requested.
etc.
As ever, if things occur to you, then add them to the wiki in an
appropriate area.
Best,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Aug 07 2007 - 11:47:41 EDT
From James.Cummings at oucs.ox.ac.uk Wed Aug 8 07:09:27 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 08 Aug 2007 12:09:27 +0100 Subject: [tei-council] Re: Facsimile Draft Message-ID: <46B9A467.8050402@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 08 Aug 2007 12:09:27 +0100
Dear Lou/Conal/Dot/et alia,
Apologies for my delay in looking over the most recent facsimile draft.
I've read the ODD and the following little niggles are what occur to me. I
am basically happy with it as it is, and think it should be integrated with
P5 (but because of its importance expanded with more examples).
Niggles:
a TEI Header and a text
a TEI Header and a facsimile element
a TEI Header, a facsimile, and a text
- 'text' vs 'facsimile element' vs 'facsimile'. Confusing. Use the same
mode of expression throughout. Why no use of ?
- I like the potential use of binaryObject ... could we have an example?
(And I suppose you don't want to know that it potentially is a patent
conflict with microsoft ... them suing us would be good publicity I suppose.)
- I like being able to just have a list of graphics without
surfaces/zones/etc, that is a good simple case. I don't like so much the
just putting facs="page1.png" on pb elements... but since it is a pointer I
don't think we can really control that, and obviously some others here
think that is better.
- Is surface a form of choice? Should the fact that it isn't be
highlighted somewhere. (i.e. that you might want to point to more than one
of these simultaneously somewhere?)
- I still don't like @box as a name, but I have no better suggestions.
"blah blah I cant help they only taught me old english in print form"
- Which image is it again that you're reading, as council happens to have a
few medievalists on it at the moment, I'm sure we can transcribe it more
accurately. Perhaps we should also include some other manuscript and even
print sources as examples? (Maybe a Wilfred Owen Postcard or some such?
with recto and verso images.)
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 07:09:32 EDT
From lou.burnard at oucs.ox.ac.uk Wed Aug 8 07:55:59 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 08 Aug 2007 12:55:59 +0100 Subject: [tei-council] Re: Facsimile Draft In-Reply-To: <46B9A467.8050402@oucs.ox.ac.uk> Message-ID: <20070808115559.A5B686C001@webmail219.herald.ox.ac.uk>
From: Lou Burnard
Date: Wed, 08 Aug 2007 12:55:59 +0100
Thanks for the comments James.
In message <46B9A467.8050402_at_oucs.ox.ac.uk> James.Cummings_at_oucs.ox.ac.uk writes:
> Niggles:
>
> a TEI Header and a text
> a TEI Header and a facsimile element
> a TEI Header, a facsimile, and a text
>
> - 'text' vs 'facsimile element' vs 'facsimile'. Confusing. Use the same
> mode of expression throughout. Why no use of ?

Christian picked this one up too. No gi because the intention was to use the
refer to the thing the tags denote (i.e. TEI Header rather than )
but the word "element" confuses things somewhat
> - I like the potential use of binaryObject ... could we have an example?
> (And I suppose you don't want to know that it potentially is a patent
> conflict with microsoft ... them suing us would be good publicity I suppose.)

+1
>
> - Is surface a form of choice? Should the fact that it isn't be
> highlighted somewhere. (i.e. that you might want to point to more than one
> of these simultaneously somewhere?)
>
the rule of thumb is that if you have more than one directly inside a
then they are NOT alternatives ; if however they are inside a
or an then they always are. So if you have multiple
(non-altermnationg) images, each one has to be within its own or
. There's a sense then in which it is a special kind of but I
don't want to get Daniel started.
Other suggestions welcomed!
> - I still don't like @box as a name, but I have no better suggestions.
the floor is open... but please dont suggest @coords (too general). I preferred
it to @rect because it's a complete word and shorter and doesnt sound faintly rude
> "blah blah I cant help they only taught me old english in print form"
>
> - Which image is it again that you're reading, as council happens to have a
> few medievalists on it at the moment, I'm sure we can transcribe it more
> accurately.
It's the same image as the one Conal uploaded to the wiki and I thought I'd
copied it into the Drafts website at the URL given in the ODD, but I now see I
haven't. Will fix later this afternoon. But note that this image is copyright
(as well as hard to read), so I would rather find an out of copyright and more
legible casae for P5.

Perhaps we should also include some other manuscript and even
> print sources as examples? (Maybe a Wilfred Owen Postcard or some such?
> with recto and verso images.)
>
ooh yes yes please.

So how many council members are (a) on the beach (b) in Montreal this week?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 08 2007 - 07:56:03 EDT

From James.Cummings at oucs.ox.ac.uk Wed Aug 8 08:57:10 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 08 Aug 2007 13:57:10 +0100 Subject: [tei-council] Re: Facsimile Draft In-Reply-To: <20070808115559.A5B686C001@webmail219.herald.ox.ac.uk> Message-ID: <46B9BDA6.80803@oucs.ox.ac.uk>
From: James Cummings
Date: Wed, 08 Aug 2007 13:57:10 +0100
Lou Burnard wrote:
> Christian picked this one up too. No gi because the intention was to use the
> refer to the thing the tags denote (i.e. TEI Header rather than )
> but the word "element" confuses things somewhat
I think if you remove the word element, then it is fine.
> the rule of thumb is that if you have more than one directly inside a
> then they are NOT alternatives ; if however they are inside a
> or an then they always are. So if you have multiple
> (non-altermnationg) images, each one has to be within its own or
> . There's a sense then in which it is a special kind of but I
> don't want to get Daniel started.
So:
!= choice but
choice. I suppose that makes sense. But surely I might want to (in the
same output) use one of these graphics in one place, and another in another
place.
>> - I still don't like @box as a name, but I have no better suggestions.
> the floor is open... but please dont suggest @coords (too general). I preferred
> it to @rect because it's a complete word and shorter and doesnt sound faintly rude
I wasn't going to suggest @coords. I suppose it isn't politic to point out
that 'box' in much international english slang is certainly a rude word
rather than faintly rude. I'm sure I can think of some dodgy (to some)
sounding poster proposals.
> It's the same image as the one Conal uploaded to the wiki and I thought I'd
> copied it into the Drafts website at the URL given in the ODD, but I now see I
> haven't. Will fix later this afternoon. But note that this image is copyright
> (as well as hard to read), so I would rather find an out of copyright and more
> legible casae for P5.
It is a Bodley image if memory serves. They have been quite good about
giving gratis permission to use their images for teaching purposes when I
have used bits of MS Digby 133. But you are right, overall, maybe we
should find some nice images which have more useful licenses. I'm sure
that I have some of some monuments which have writing on somewhere that I'd
happily place in the public domain.
> ooh yes yes please.
Well, you know who to ask, I don't think they ever got around to depositing
with the OTA. ;-)
> So how many council members are (a) on the beach (b) in Montreal this week?
Neither sadly, but I did have a nice lunch in the sun... but I'm sure I
shouldn't be boring the rest of Council with its details.
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 08:57:17 EDT
From lou.burnard at oucs.ox.ac.uk Wed Aug 8 16:55:44 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 08 Aug 2007 21:55:44 +0100 Subject: [tei-council] facsimile draft (fwd) In-Reply-To: <46BA0BA3.6070403@uvic.ca> Message-ID: <46BA2DD0.2020106@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 08 Aug 2007 21:55:44 +0100
Martin Holmes wrote:
>
> Reading about the @facs attribute, it seemed to me quite likely that
> I'd want to point it at multiple items; for instance, where there are
> images of the same surface at different resolutions, you'd want to
> point to all of them:
>
>
> I can see that this could be accomplished by including both of the
> relevant graphics inside one element, and pointing to the
> xml:id of that element, but that might not always be appropriate or
> possible.
The idea is to make simple things simple, and not so simple things
slightly less so. So if you want to point to alternative images, you
have to wrap them in something i.e. a , and point to that.

> Can @facs point to multiple space-separated identifiers?
>
yes, but it then means something different -- the pb corresponds with
the concatenation (not the alternation) of the two images pointed at.
(Note that it is this rule which makes it possible to just have a bunch
of inside a single )
> I can see an objection to restricting both and to
> rectangular areas through the @box attribute. Although my own Image
> Markup Tool suffers the sad limitation that it can only deal in
> rectangular areas, that's definitely a shortcoming and is often
> pointed out as such, and I think there's a clear case to be made for
> allowing the coordinate system for these areas to specify ellipses and
> polygons.
Same logic as before, I'm afraid. Simple things are done simply.
Non-rectangular zones are not simple to specify. The recommendation is
that if you dont want boxes, you need to define the shapes you do want
in SVG and point to bits of that.
> For instance, a text paragraph might run across two columns on a page
> surface, so that it constitutes an eight-sided shape, or an
> illustration might be circular, and have text wrapping around it such
> that a rectangular zone would end up including bits of text at the
> corners. Objects in an image, even if they're rectangular in real
> life, may end up as parallelograms or distorted rectangles due to
> perspective effects. I wonder if it might be simpler, and more
> flexible, to borrow from the XHTML image map attributes:
>
>
>
> specifically @shape and @coords, to allow more flexibility here?
> @shape would allow circles and polygons (although not, oddly,
> ellipses, which seems a pointless limitation).
Yes, we looked at this. My view is that the way that image maps do it in
XHTML is not really very satisfactory as it doesn't scale up properly.
> Another possibility is to look at how SVG uses the element.
> @box is nice and simple, so I can see the appeal, especially given
> that this is a new module, but I think people will want more options
> here than a simple rectangle.
See above.
>
> I think this sentence is missing a closing parenthesis (presumably
> after ):
>
> "Since all zone elements use the same co-ordinate system
> (that defined by their parent surface, there is no need to
> demonstrate enclosure of one zone within another by means of nesting."
>
correctamundo.

> The example which includes this:
>
>


>
> Efter ????r
> h??lender blah blah I cant read this help they only taught me old
> english in print form ....


>
> is a bit confusing, coming out of nowhere -- I guess it's a genuine
> sample but the deviation from OE text into ModE complaint, shorn of
> its context, is a little puzzling, to me at least, and a more
> straightforward example might be more helpful to the reader.
>
er sorry... that was an example of me being literal. The example in
question is an OE ms page which Conal circulated to Council earlier, and
which I started transcribing before realising that I couldnt do it!
> Finally, the document seems to have an extra
near the end, so
> it's not quite well-formed. I think this is caused by commenting out
> the opening
and the heading "Surfaces and zones"
> without commenting out its closing div tag.
>
correct again.... welcome to the engine room!

> Hope this is useful,
Yes, thanks very much. You didn't say "this is unworkable" which is what
I was worrying you might!

>
> Martin
>
> Lou Burnard wrote:
>> Dear Martin
>>
>> I wonder if you have 5 minutes to take a look at a new section in
>> P5? Christian
>> Wittern suggested you would be a good person to review its
>> feasibility (see below)
>>
>> Please send me any comments you have asap: the draft urgently needs
>> more
>> reality checking before it's ready for prime time, and I'd really
>> appreciate
>> your feedback
>>
>> best wishes
>>
>> Lou
>>
>>
>> ----- Forwarded message from Christian Wittern com>
>> -----
>>
>> From: Christian Wittern com>
>> To: Lou Burnard oxford.ac.uk>
>> Subject: Re: [tei-council] facsimile draft
>> Date: Tue, 07 Aug 2007 14:59:28 +0900
>>
>>
>> Lou Burnard wrote:
>>> As mentioned in the call, I've been working on trying to produce a
>>> section about facsimile markup which could be plugged into the
>>> current chapter on physical transcription, using as many as possible
>>> of the ideas discussed here by Conal and others over the last few
>>> weeks.
>>>
>>> Time is running out, and we need to get closure on this, so I hope
>>> Conal and Dot will excuse me for steaming ahead on this without
>>> consulting with them privately first. I've used the documents
>>> circulated and followed (as far as I can) the discussion so far to
>>> produce a straw-person kind of a draft which is now posted for your
>>> (particularly their) urgent attention at
>>> http://www.tei-c.org/Drafts/facs.odd
>>>
>> Thanks for getting it this far. It seems pretty well worked through,
>> at least as far as I can see by just reading through it. I wonder if
>> it would be worthwhile to show this to Martin Holmes to see what he
>> thinks -- if we get ever an implementation of this, he is among the
>> likely implementers.
>>
>>
>>> I've deliberately restricted the scope of what this draft makes
>>> possible to what I hope we can all agree on as a bare minimum of
>>> functionality. It supports linking from text to image and image to
>>> text with a minimum of fuss ; it also supports linking between text
>>> and image fragments, but only provides one way to do it. It tries to
>>> fit in with existing TEI idiom and practice.
>> I feel a bit uneasy about @facs doubling as a direct and indirect
>> link -- are there other cases where we do something similar?
>>
>> One tiny piece of nit-picking: in this list, you probably dont want
>> the word "element" after facsimile?
>>
>> legal TEI document may thus comprise any of the following:-
>>
>> a TEI Header and a text
>> a TEI Header and a facsimile element
>> a TEI Header, a facsimile, and a text
>>
>>
>>
>>
>>> -- I've also made a wild guess about how to specify the datatype of
>>> my @box attribute (formerly known as @coords -- I renamed it because
>>> it is considerably more restricted than the synonymous XHTML attribute)
>>>
>> As Sebastian said, I would use the same type of arrangement for the
>> coordinates as in HTML, SVG, CSS and who knows what, that is starting
>> from the upper left corner.
>>
>> Christian
>>
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 08 2007 - 17:03:48 EDT

From daniel.odonnell at uleth.ca Wed Aug 8 18:14:03 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 08 Aug 2007 16:14:03 -0600 Subject: [tei-council] Did my rdg/app/edInt posting ever make it to the council list? Message-ID: <1186611243.7409.30.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 08 Aug 2007 16:14:03 -0600
Hi all,
Finally finished having to rely on MS Exchange: did any of my attempts
to get the rdg/app/edInt stuff out to the list work?
I'm a couple of days behind on my other tasks but am getting on them now
after a particularly nasty jetlag.
-dan
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 18:17:04 EDT
From daniel.odonnell at uleth.ca Wed Aug 8 19:29:15 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 08 Aug 2007 17:29:15 -0600 Subject: [tei-council] facsimile draft In-Reply-To: <46B63C00.4080903@computing-services.oxford.ac.uk> Message-ID: <1186615755.7409.66.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 08 Aug 2007 17:29:15 -0600
My only comments have been addressed or anticipated: I don't like having
@facs work with both IDREFs and URLs and indeed, surface is clearly a
specialised form of choice while facsimile is a list but not choice.
As to the first point, I wonder if the "simple" version is really all
that simple--or if it isn't doing something other than building
facsimiles. Having constructed facsimile for sound theoretical reasons
as a parallel to text, I'm not sure what the advantage is in allowing
users to abandon it for a free floating URL. I see three standard ways
in which users will come to this:
1) I have a full set of basic page-by-page images which I want to link
to my transcriptions
2) I have a full set of facsimiles with details and infra-red etc.
extras that I want to link to my transcriptions
3) I have an incomplete set of images or am only interest in
occasionally connecting my images to my transcriptions.
In cases 1 and 2, I don't see that requiring facsimile/graphic and
restricting @facs to IDREFs is a significant burden and grouping them
together in facsimile is both theoretically appropriate and will help
interchange by ensuring that all the referents are in the same place. In
case 3, you don't really have a facsimile at all, you have an
illustration: I'd say graphic is an appropriate medium for reflecting
this.
As for surface being choice: I'd say this is yet another argument that
there is an abstract logical choice content model that is not phrase
restricted. But I've given up on that for P5 and am instead
concentrating on making the phrasal model internally consistent.
On Sun, 2007-08-05 at 22:07 +0100, Lou Burnard wrote:
> As mentioned in the call, I've been working on trying to produce a
> section about facsimile markup which could be plugged into the current
> chapter on physical transcription, using as many as possible of the
> ideas discussed here by Conal and others over the last few weeks.
>
> Time is running out, and we need to get closure on this, so I hope Conal
> and Dot will excuse me for steaming ahead on this without consulting
> with them privately first. I've used the documents circulated and
> followed (as far as I can) the discussion so far to produce a
> straw-person kind of a draft which is now posted for your (particularly
> their) urgent attention at http://www.tei-c.org/Drafts/facs.odd
>
> I've deliberately restricted the scope of what this draft makes possible
> to what I hope we can all agree on as a bare minimum of functionality.
> It supports linking from text to image and image to text with a minimum
> of fuss ; it also supports linking between text and image fragments, but
> only provides one way to do it. It tries to fit in with existing TEI
> idiom and practice.
>
> It is however in desperate need of help on the following counts:
>
> -- I haven't the faintest idea how to transcribe the Old English ms
> we're using as an example. (The one Conal circulated earlier). Either
> someone needs to transcribe it for me, or I need to find another example
> which I can transcribe. (Actually, as this one claims to be copyright of
> the Bodleian, the second is probably the wiser course)
>
> -- in defining how the co-ordinate system works, I have had to rely on
> my vague recollections of O level maths. Someone who actually knows
> about this stuff should read it carefully to see how plausible this is.
> Also how feasible it is to implement it!
>
> -- I've also made a wild guess about how to specify the datatype of my
> @box attribute (formerly known as @coords -- I renamed it because it is
> considerably more restricted than the synonymous XHTML attribute)
>
> All comments, bouquets, and brickbats gratefully received
>
> Lou
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 19:32:15 EDT
From daniel.odonnell at uleth.ca Wed Aug 8 19:41:56 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 08 Aug 2007 17:41:56 -0600 Subject: [tei-council] updated facsimile odd In-Reply-To: <46B2E3A3.3030407@oucs.ox.ac.uk> Message-ID: <1186616516.7409.73.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 08 Aug 2007 17:41:56 -0600
On Fri, 2007-08-03 at 09:13 +0100, Sebastian Rahtz wrote:
> Christian Wittern wrote:
> > As I understand it you link to the surface coordinates and then go and
> > see which graphic covers the area you are interested in. That seems
> > to be the whole point of this indirection.
> umm. expand on "the surface coordinates" for me. if they are unitless
> and unbounded,
> they cannot mean anything.
I think myself subject to clarification that we should be calling a
spade a spade here: everything in the ODD and its description suggests
to me that we are counting pixels. If we were doing anything else surely
we'd need some kind of translation table and discussion of how real
world measurements get converted to locations on the image?
I think real world object coordinates would be brilliant to have.
Conservators would love them too, I bet, since they would be image
independent (you'd just need to add new reference coordinates to your
lookup table). But we are simply not talking about that or any other
measurement as far as I can see.
The hi/lo res issue is an important one: if I have
surface/graphic_at_id="hi1"|graphic_at_id="lo1" then the references for the
bottom right corners of the box (at least) will be different in each;
and if we are not starting in 0,0, then botheth sets will be different.
Should we perhaps somehow indicate a reference image in those cases?
This would allow the images to be aligned, since one would be expressed
in terms of the other. Of course, then surtheface is starting to look
like app; but that's neither here nor there ;)
-dan
> >>
> >
> > My understanding is that they will be exactly the same, since the
> > coords are expressed relative to the .
> relative is good, but you must either have units, or proportions of a
> bounding box. just units
> won't cut it.
> > As I understand it, the pointing goes through the indirection of the
> > surface: You express the location of in terms of the
> > coords, using the same reference system as is used for the zones. You
> > will then discover from these coords in which of the zones (in this
> > case all three) your is located.
> we really really need worked examples of this to understand it....
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 19:44:57 EDT
From daniel.odonnell at uleth.ca Wed Aug 8 18:36:46 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 08 Aug 2007 16:36:46 -0600 Subject: [tei-council] reduex In-Reply-To: <46B1A98E.2010808@computing-services.oxford.ac.uk> Message-ID: <1186612606.7409.47.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 08 Aug 2007 16:36:46 -0600
Me, I'm annoyed still by how close they are, and especially given their
attributes (i.e. in Syd's last posting on this). However, at this point
I'm happy to go with the consensus: abolish measureGrp and reinstate
dimensions.
On Thu, 2007-08-02 at 10:53 +0100, Lou Burnard wrote:
> My understanding of this issue may be summarised as follows.
>
> 1. MsDesc had an element which allowed either just text or
> some number the specialised elements
>
> 2. There was a consensus in favour of generalising these three rather
> specific not to say obsessive elements. A very early draft version of
> MsDesc had am element rather cutely named for this purpose
>
> 3. It was observed that was pretty close to the existing
> so maybe we should use the latter instead
>
> I'd like us to agree on one of the following strategies
>
> a. do nothing i.e. try to make function satisfactorily both as
> a measurement of quantity and as a statement of dimensions; live with
> the oddity of a which doesnt just contain s
>
> b. do some cosmetics i.e. rename @extent as @quantity, as
> etc as already discussed
>
> c. revert i.e. leave more or less as is, reintroduce
> , abolish
>
> If you choose (c) then you need to decide between the following content
> models for
>
> c-1 : text
> c-2 : text | model.dimLike+
> c-3 : text | model.dimLike.sequence
>
> and you also need to decide whether the members of model.dimLike are --
>
> d. height, width, depth
> e. dim
> f. dim, height, width, depth
> g. dim, height, width, depth, measure
>
> Assuming that we don't do (a), my recommendations are
>
> c, c-2, f
>
>
> Syd Bauman wrote:
> > LB> Really, I think the best solution is to bring back !
> > SB> [Maybe not best, but a good idea.]
> > SR> yes. it would seem much more honest to have as a
> > SR> container for text.
> > CW> Then let the MS people have their dimensions. Seems like a good
> > CW> compromise.
> >
> > OK, as I'm still waiting for votes for or agin (about which I
> > see Lou just posted) or more discussion on facsimile markup, I'll get
> > going on this presently.
> >
> >
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 19:53:33 EDT
From daniel.odonnell at uleth.ca Wed Aug 8 20:08:26 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 08 Aug 2007 18:08:26 -0600 Subject: [tei-council] facsimile diagram In-Reply-To: <1186124406.22202.121.camel@localhost> Message-ID: <1186618106.7409.97.camel@localhost>
From: Daniel O'Donnell
Date: Wed, 08 Aug 2007 18:08:26 -0600
On Fri, 2007-08-03 at 19:00 +1200, Conal Tuohy wrote:
> On Fri, 2007-08-03 at 07:26 +0100, James Cummings wrote:
> > Conal Tuohy wrote:
> > > It's true I didn't mean to imply that a graphic could act as a zone - I
> > > don't think people should in general be linking bits of text to those
> > > graphics.
> >
> > So really people should only be linking to and from zones generally.
>
> yes
OK now I'm confused: in Lou's ODD we have the following possibilities:
facsimile/graphic
facsimile/surface/graphic
facsimile/surface/graphic|zone
facsimile/surface/graphic|zone/graphic
And we have examples of @facs pointing to free-floating URLs and
graphics and zones.
But if I understand this aright, we should actually have zones
everywhere as the target for @facs. I.e. if I have a single facsimile
100px*100px image for f.1r of some manuscript and I want pb to point at
the whole thing, I should be doing this?







floo flow fl??
If zones are the preferred targets of @facs, and if they express a
region of the graphic, then should it not be the case that they are
children of graphic after all, then?
Sorry if I'm misunderstanding this or there is a version control issue
going on.

>
> > > Within the same as the stamp's , there would be some
> > > elements, and if those graphics had @coords which overlapped
> > > the @coords of the stamp's zone, then those graphics would actually
> > > depict the stamp itself. Any of those associated graphics might be used
> > > to present a view of that zone. Obviously a graphic whose coords
> > > entirely enclosed the coords of the zone would be best (because it will
> > > show the full stamp), and a graphic whose resolution is higher will be
> > > better (if zooming), etc.
> >
> > Ok, and if those graphic/@coords are relative to the surface, how do we on the
> > surface indicate what unit of measurement they are using? Surely a surface may
> > be measured in all sorts of units (millimetres, inches, metres,
> > kilometres,etc.)?
>
> Well, it's not really needed in order to align the graphics and the
> zones (all that's needed is that the units are consistent). But for
> documentary purposes, perhaps a surface's dimensions could be given
> using a element?
>
> > How do I know that one graphic is higher resolution than the
> > other? i.e. they both cover the same area of the surface "0 0 100 100" but one
> > was taken with a hi-res camera, and one was taken quite awhile ago with some
> > low-res camera. How is that resolution indicated?
>
> The 2 graphics may use @height and @width to indicate their intrinsic
> dimensions. The hi-res image should be higher and wider, despite having
> the same @coords as the equivalent lo-res image. The resolution of a
> graphic could be calculated by dividing the @width by the width as
> specified in the @coords (which says how much of the surface the graphic
> covers).
>
> But to be honest, rereading the documentation for @height, @width and
> @scale, I'm not entirely sure that I understand how @height and @width
> are supposed to work together with @scale.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
>
> If I have an image which is 200px wide, I would expect to mark it up as
> a graphic with @width="200px", but what do I do with @scale? And what is
> the "desired display size" anyway? If I give @scale="2", I'd be saying
> that I wanted the image to be displayed as 400 pixels wide, which sounds
> like an odd thing to want to do.
>
> I'd be interested in seeing any examples of the use of @scale.
>
> As an alternative to calculations involving graphic/@height, etc,
> presentation software could choose among graphics on the basis of
> metadata encoded in a linked element. Could that be a
> useful approach?
>
> Con
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 20:11:28 EDT

From cwittern at gmail.com Wed Aug 8 21:06:37 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 09 Aug 2007 10:06:37 +0900 Subject: [tei-council] Did my rdg/app/edInt posting ever make it to the council list? In-Reply-To: <1186611243.7409.30.camel@localhost> Message-ID: <46BA689D.9050807@gmail.com>
From: Christian Wittern
Date: Thu, 09 Aug 2007 10:06:37 +0900
Daniel O'Donnell wrote:
> Hi all,
>
> Finally finished having to rely on MS Exchange: did any of my attempts
> to get the rdg/app/edInt stuff out to the list work?
>
Unfortunately not, at least I have not seen it. Please show it to us again.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 21:06:46 EDT
From cwittern at gmail.com Wed Aug 8 21:17:49 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 09 Aug 2007 10:17:49 +0900 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186616516.7409.73.camel@localhost> Message-ID: <46BA6B3D.5020405@gmail.com>
From: Christian Wittern
Date: Thu, 09 Aug 2007 10:17:49 +0900
Daniel O'Donnell wrote:
> On Fri, 2007-08-03 at 09:13 +0100, Sebastian Rahtz wrote:
>
>> Christian Wittern wrote:
>>
>>> As I understand it you link to the surface coordinates and then go and
>>> see which graphic covers the area you are interested in. That seems
>>> to be the whole point of this indirection.
>>>
>> umm. expand on "the surface coordinates" for me. if they are unitless
>> and unbounded,
>> they cannot mean anything.
>>
>
> I think myself subject to clarification that we should be calling a
> spade a spade here: everything in the ODD and its description suggests
> to me that we are counting pixels. If we were doing anything else surely
> we'd need some kind of translation table and discussion of how real
> world measurements get converted to locations on the image?
>
Let's assume you have a page of 297x210mm, which is covered by the
surface element, which gives you also a grid of 0 0 100 100 to work
from. The grid is more like the one you have on maps, which simple go
from A, B, C, D,... and 1, 2, 3, 4, ... which allows you to say that
something you are interested in is in C1, without any need to worry
about the scale of the map. In the same way, you could say there is a
spot of spilled ink at 20 20 40 40. If and only if you want to know the
size of this spot, then you will need to look up the dimensions and
calculate the scale factor.
> I think real world object coordinates would be brilliant to have.
> Conservators would love them too, I bet, since they would be image
> independent (you'd just need to add new reference coordinates to your
> lookup table). But we are simply not talking about that or any other
> measurement as far as I can see.
>
See above, I think we can't really do without providing the possibility
of registering dimensions.
> The hi/lo res issue is an important one: if I have
> surface/graphic_at_id="hi1"|graphic_at_id="lo1" then the references for the
> bottom right corners of the box (at least) will be different in each;
> and if we are not starting in 0,0, then botheth sets will be different.
> Should we perhaps somehow indicate a reference image in those cases?
> This would allow the images to be aligned, since one would be expressed
> in terms of the other. Of course, then surtheface is starting to look
> like app; but that's neither here nor there ;)
>
Now this seems coming closer and closer to reinventing METS...
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 08 2007 - 21:17:57 EDT

From Conal.Tuohy at vuw.ac.nz Thu Aug 9 02:32:14 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 9 Aug 2007 18:32:14 +1200 Subject: [tei-council] facsimile draft In-Reply-To: <46B63C00.4080903@computing-services.oxford.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABDF@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 9 Aug 2007 18:32:14 +1200
G'day Lou, et al
I have had a look at the draft and I have a few comments and queries about your proposed changes:
Regarding box, I agree with the others who've suggested that the origin of our coordinate spaces should be at the upper left, and that positive values are to the right, and below, the origin. That's pretty conventional in my experience. I like the name of box!
Can you comment on the new facsimile/front and facsimile/back - what would be encoded there?
My main set of issues relates to the changes about how graphics relate to zones, and to surfaces, and how textual elements relate to zones or graphics. This is quite a different system - can you explain the rationale behind the changes?
In the previous draft, it was possible to assign graphical coordinates to individual elements in a transcription, but this is now dropped. What was the reason for that? I am pretty sure that Dot was particularly keen on that feature, and I was also convinced of its utility. For instance, imagine a TEI transcript originating in an OCR process, which would have image coordinates assigned to each word by the OCR software. Using your draft markup, if I understand correctly, it would be necessary to create a distinct zone element for each word, essentially a parallel of the transcription, and link each word in the transcript to its corresponding zone. This would be quite an overhead!
I also think that the value space for @facs is too loose - in the sense that a

or a

could use a @facs pointer to point to either an image file, to a zone, or to a graphic. I have a feeling this is not going to be so convenient for processing. In the previous draft, the idea was that such links would be ONLY to zones, which were facsimile equivalents of elements in a transcription.
You've also allowed inside , and I'm having a hard time understanding the rationale for this change. It seems to be of a piece with the change to remove from att.coordinated. Now, since a graphic has no @box of its own, it inherits one from its parent , is that right? In my previous draft, a graphic had a @box (or @coords as it was still called) attribute of its own, and hence didn't need to be enclosed in a zone, and I don't see why we'd want to wrap those graphics in zones, when they could just have their own @box. What does that gain us?
Requiring graphics to be contained in zones would be convenient to the extent that the distinct graphics correspond exactly to areas of interest (i.e. if they have been exactly cropped to that size), but I'm not sure this is likely to be a common case. It seems to me more likely that graphics will tend to be larger than zones, in almost all cases. Hence there would need to be an analytical zone (highlighted the area of interest) and a graphical zone (to contain a graphic which showed the area of interest). Only if the graphic had been cropped to exactly cover the area of interest could its parent zone be accurately used as an analytical zone, and linked to a piece of transcript.
Removing graphic from zone (and giving graphic its own @box) would mean that zones would be always empty, and this would simplify processing, too, I believe.
Regarding the "short-cut" which allows facsimile/graphic instead of requiring facsimile/surface/graphic, this seems reasonable, though I wonder if there's much prospect of people using this short-cut, and if not, I think the shortcut should be abolished (to simplify processing). The reason I doubt it would be popular is that if you have a single graphic, you already have the option of linking to it directly from a pb, which is an even shorter short-cut. If you use the facsimile/graphic shortcut (i.e. a graphic as a direct child of facsimile, rather than mediated by a surface), you don't have the option of using zones anyway, so this slightly-longer shortcut doesn't cater for any distinct use case as far as I can see).
In short, I'm a bit flummoxed. I liked the linking better the way it was.
Con
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Lou Burnard
Sent: Mon 06/08/07 9:07
To: tei-council_at_lists.village.Virginia.EDU
Subject: [tei-council] facsimile draft

As mentioned in the call, I've been working on trying to produce a
section about facsimile markup which could be plugged into the current
chapter on physical transcription, using as many as possible of the
ideas discussed here by Conal and others over the last few weeks.
Time is running out, and we need to get closure on this, so I hope Conal
and Dot will excuse me for steaming ahead on this without consulting
with them privately first. I've used the documents circulated and
followed (as far as I can) the discussion so far to produce a
straw-person kind of a draft which is now posted for your (particularly
their) urgent attention at http://www.tei-c.org/Drafts/facs.odd
I've deliberately restricted the scope of what this draft makes possible
to what I hope we can all agree on as a bare minimum of functionality.
It supports linking from text to image and image to text with a minimum
of fuss ; it also supports linking between text and image fragments, but
only provides one way to do it. It tries to fit in with existing TEI
idiom and practice.
It is however in desperate need of help on the following counts:
-- I haven't the faintest idea how to transcribe the Old English ms
we're using as an example. (The one Conal circulated earlier). Either
someone needs to transcribe it for me, or I need to find another example
which I can transcribe. (Actually, as this one claims to be copyright of
the Bodleian, the second is probably the wiser course)
-- in defining how the co-ordinate system works, I have had to rely on
my vague recollections of O level maths. Someone who actually knows
about this stuff should read it carefully to see how plausible this is.
Also how feasible it is to implement it!
-- I've also made a wild guess about how to specify the datatype of my
@box attribute (formerly known as @coords -- I renamed it because it is
considerably more restricted than the synonymous XHTML attribute)
All comments, bouquets, and brickbats gratefully received
Lou

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 02:32:52 EDT

From Conal.Tuohy at vuw.ac.nz Thu Aug 9 02:32:29 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 9 Aug 2007 18:32:29 +1200 Subject: [tei-council] facsimile diagram In-Reply-To: <1186618106.7409.97.camel@localhost> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABE0@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 9 Aug 2007 18:32:29 +1200
Hi Daniel
It is true that the relationships between zones, graphics, etc, are quite different between Lou's draft and the previous ones.
Con

-----Original Message-----
From: Daniel O'Donnell [mailto:daniel.odonnell_at_uleth.ca]
Sent: Thu 09/08/07 12:08
To: Conal Tuohy
Cc: James.Cummings_at_oucs.ox.ac.uk; TEI Council
Subject: Re: [tei-council] facsimile diagram

On Fri, 2007-08-03 at 19:00 +1200, Conal Tuohy wrote:
> On Fri, 2007-08-03 at 07:26 +0100, James Cummings wrote:
> > Conal Tuohy wrote:
> > > It's true I didn't mean to imply that a graphic could act as a zone - I
> > > don't think people should in general be linking bits of text to those
> > > graphics.
> >
> > So really people should only be linking to and from zones generally.
>
> yes
OK now I'm confused: in Lou's ODD we have the following possibilities:
facsimile/graphic
facsimile/surface/graphic
facsimile/surface/graphic|zone
facsimile/surface/graphic|zone/graphic
And we have examples of @facs pointing to free-floating URLs and
graphics and zones.
But if I understand this aright, we should actually have zones
everywhere as the target for @facs. I.e. if I have a single facsimile
100px*100px image for f.1r of some manuscript and I want pb to point at
the whole thing, I should be doing this?







floo flow flu



If zones are the preferred targets of @facs, and if they express a
region of the graphic, then should it not be the case that they are
children of graphic after all, then?
Sorry if I'm misunderstanding this or there is a version control issue
going on.

>
> > > Within the same as the stamp's , there would be some
> > > elements, and if those graphics had @coords which overlapped
> > > the @coords of the stamp's zone, then those graphics would actually
> > > depict the stamp itself. Any of those associated graphics might be used
> > > to present a view of that zone. Obviously a graphic whose coords
> > > entirely enclosed the coords of the zone would be best (because it will
> > > show the full stamp), and a graphic whose resolution is higher will be
> > > better (if zooming), etc.
> >
> > Ok, and if those graphic/@coords are relative to the surface, how do we on the
> > surface indicate what unit of measurement they are using? Surely a surface may
> > be measured in all sorts of units (millimetres, inches, metres,
> > kilometres,etc.)?
>
> Well, it's not really needed in order to align the graphics and the
> zones (all that's needed is that the units are consistent). But for
> documentary purposes, perhaps a surface's dimensions could be given
> using a element?
>
> > How do I know that one graphic is higher resolution than the
> > other? i.e. they both cover the same area of the surface "0 0 100 100" but one
> > was taken with a hi-res camera, and one was taken quite awhile ago with some
> > low-res camera. How is that resolution indicated?
>
> The 2 graphics may use @height and @width to indicate their intrinsic
> dimensions. The hi-res image should be higher and wider, despite having
> the same @coords as the equivalent lo-res image. The resolution of a
> graphic could be calculated by dividing the @width by the width as
> specified in the @coords (which says how much of the surface the graphic
> covers).
>
> But to be honest, rereading the documentation for @height, @width and
> @scale, I'm not entirely sure that I understand how @height and @width
> are supposed to work together with @scale.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
>
> If I have an image which is 200px wide, I would expect to mark it up as
> a graphic with @width="200px", but what do I do with @scale? And what is
> the "desired display size" anyway? If I give @scale="2", I'd be saying
> that I wanted the image to be displayed as 400 pixels wide, which sounds
> like an odd thing to want to do.
>
> I'd be interested in seeing any examples of the use of @scale.
>
> As an alternative to calculations involving graphic/@height, etc,
> presentation software could choose among graphics on the basis of
> metadata encoded in a linked element. Could that be a
> useful approach?
>
> Con
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 02:35:06 EDT

From Conal.Tuohy at vuw.ac.nz Thu Aug 9 02:49:51 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 9 Aug 2007 18:49:51 +1200 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186616516.7409.73.camel@localhost> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABE1@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Thu, 9 Aug 2007 18:49:51 +1200
I want to stress that the units used in @coords (in my draft) and in @box (if I understand Lou's draft correctly) are not pixels, or at least are not necessarily pixels.
The coordinate system used is defined by the encoder to be whatever suits them. Now of course, those numbers will correspond to something in reality. The units might be cm, mm, furlongs, or any real-world unit of distance. Or the units might be 1.3235mm in length. For some purposes, the actual real-world dimensions of those units is not relevant. For aligning areas within a coordinate space, it's only necessary the measurements of those areas are made in terms of the units which that coordinate space uses. i.e. what's important for alignment is only proportions, or ratios between sets of coordinates. Ultimately, for presentation, these measurements will be converted into regions of a real bitmapped image, and to do this, but the use case of text/image alignment just does not require that real units be specified.
On the other hand, other use cases may require measurements in real-world units, and to my mind the way to do this is to use and as children of . Or have as a child of , and have height and width within that. That would give conservators real-world figures.
Finally, since measurements are actually being made in a common coordinate space, the high- and low- resolution images in your example would actually have the same @box value. The difference in resolution could be made apparent by encoding @width and @height on the graphic (i.e. the high res image might be while the lo res image would be
Cheers
Con
-----Original Message-----
From: Daniel O'Donnell [mailto:daniel.odonnell_at_uleth.ca]
Sent: Thu 09/08/07 11:41
To: Sebastian Rahtz
Cc: Christian Wittern; TEI Council; James.Cummings_at_oucs.ox.ac.uk; Conal Tuohy
Subject: Re: [tei-council] updated facsimile odd

On Fri, 2007-08-03 at 09:13 +0100, Sebastian Rahtz wrote:
> Christian Wittern wrote:
> > As I understand it you link to the surface coordinates and then go and
> > see which graphic covers the area you are interested in. That seems
> > to be the whole point of this indirection.
> umm. expand on "the surface coordinates" for me. if they are unitless
> and unbounded,
> they cannot mean anything.
I think myself subject to clarification that we should be calling a
spade a spade here: everything in the ODD and its description suggests
to me that we are counting pixels. If we were doing anything else surely
we'd need some kind of translation table and discussion of how real
world measurements get converted to locations on the image?
I think real world object coordinates would be brilliant to have.
Conservators would love them too, I bet, since they would be image
independent (you'd just need to add new reference coordinates to your
lookup table). But we are simply not talking about that or any other
measurement as far as I can see.
The hi/lo res issue is an important one: if I have
surface/graphic_at_id="hi1"|graphic_at_id="lo1" then the references for the
bottom right corners of the box (at least) will be different in each;
and if we are not starting in 0,0, then botheth sets will be different.
Should we perhaps somehow indicate a reference image in those cases?
This would allow the images to be aligned, since one would be expressed
in terms of the other. Of course, then surtheface is starting to look
like app; but that's neither here nor there ;)
-dan
> >>
> >
> > My understanding is that they will be exactly the same, since the
> > coords are expressed relative to the .
> relative is good, but you must either have units, or proportions of a
> bounding box. just units
> won't cut it.
> > As I understand it, the pointing goes through the indirection of the
> > surface: You express the location of in terms of the
> > coords, using the same reference system as is used for the zones. You
> > will then discover from these coords in which of the zones (in this
> > case all three) your is located.
> we really really need worked examples of this to understand it....
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 02:50:18 EDT
From lou.burnard at oucs.ox.ac.uk Thu Aug 9 03:36:30 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 08:36:30 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABE1@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46BAC3FE.90904@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 08:36:30 +0100
Conal Tuohy wrote:
> I want to stress that the units used in @coords (in my draft) and in @box (if I understand Lou's draft correctly) are not pixels, or at least are not necessarily pixels.
>
+1
> Finally, since measurements are actually being made in a common coordinate space, the high- and low- resolution images in your example would actually have the same @box value. The difference in resolution could be made apparent by encoding @width and @height on the graphic (i.e. the high res image might be while the lo res image would be
>
>
-1

As previously noted, this usage of @height and @width on graphic is a
major difference in the way these attributes are currently defined.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 03:44:37 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 9 03:40:31 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 08:40:31 +0100 Subject: [tei-council] facsimile draft In-Reply-To: <1186615755.7409.66.camel@localhost> Message-ID: <46BAC4EF.5010402@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 08:40:31 +0100
Daniel O'Donnell wrote:
> My only comments have been addressed or anticipated: I don't like having
> @facs work with both IDREFs and URLs
It does not work with IDREFS. It only works with URLs.

> 3) I have an incomplete set of images or am only interest in
> occasionally connecting my images to my transcriptions.
>
...
> In
> case 3, you don't really have a facsimile at all, you have an
> illustration: I'd say graphic is an appropriate medium for reflecting
> this.
>
>
You need to distinguish the graphic within the text from the graphic
representing the text (or a part of it). In the forner case, you embed a
within ther ; in the latter, you still supply the
within a .

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 03:48:38 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 9 03:47:36 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 08:47:36 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186616516.7409.73.camel@localhost> Message-ID: <46BAC698.1000609@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 08:47:36 +0100
Daniel O'Donnell wrote:
>
>
> I think myself subject to clarification that we should be calling a
> spade a spade here: everything in the ODD and its description suggests
> to me that we are counting pixels. If we were doing anything else surely
> we'd need some kind of translation table and discussion of how real
> world measurements get converted to locations on the image?
>
I considered whether or not this would be desirable: if there's a strong
feeling in favour of giving real world dimensions, then some way of
defining them could certainly be added.. It's not entirely obvious what
that should be though. And, as Conal notes, we really don't need it for
the use cases envisaged so far.
> I think real world object coordinates would be brilliant to have.
> Conservators would love them too, I bet, since they would be image
> independent (you'd just need to add new reference coordinates to your
> lookup table).
I think there may be a "not" missing in that sentence. Again, this is
hypothetical, and the happy Conservators in question haven't spoken up
yet. It seems to me to be purely image metadata, which we're not
messing with.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 03:55:43 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 9 03:53:52 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 08:53:52 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <46BA6B3D.5020405@gmail.com> Message-ID: <46BAC810.7030801@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 08:53:52 +0100
Christian Wittern wrote:
> Let's assume you have a page of 297x210mm, which is covered by the
> surface element, which gives you also a grid of 0 0 100 100 to work
> from. The grid is more like the one you have on maps, which simple go
> from A, B, C, D,... and 1, 2, 3, 4, ... which allows you to say that
> something you are interested in is in C1, without any need to worry
> about the scale of the map. In the same way, you could say there is a
> spot of spilled ink at 20 20 40 40. If and only if you want to know
> the size of this spot, then you will need to look up the dimensions
> and calculate the scale factor.
>
Exactly. I will steal this explanation for the draft!
>> I think real world object coordinates would be brilliant to have.
>> Conservators would love them too, I bet, since they would be image
>> independent (you'd just need to add new reference coordinates to your
>> lookup table). But we are simply not talking about that or any other
>> measurement as far as I can see.
>>
> See above, I think we can't really do without providing the
> possibility of registering dimensions.
>
Is there a negative too many in that sentence, or are you suggesting we
*should* include the dimensions of the original somewhere? and if so, how?

> Now this seems coming closer and closer to reinventing METS...
>
+1

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 04:01:59 EDT

From cwittern at gmail.com Thu Aug 9 04:16:04 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 09 Aug 2007 17:16:04 +0900 Subject: [tei-council] updated facsimile odd In-Reply-To: <46BAC810.7030801@oucs.ox.ac.uk> Message-ID: <46BACD44.2@gmail.com>
From: Christian Wittern
Date: Thu, 09 Aug 2007 17:16:04 +0900
Lou Burnard wrote:
> Christian Wittern wrote:
>> Let's assume you have a page of 297x210mm, which is covered by the
>> surface element, which gives you also a grid of 0 0 100 100 to work
>> from. The grid is more like the one you have on maps, which simple
>> go from A, B, C, D,... and 1, 2, 3, 4, ... which allows you to say
>> that something you are interested in is in C1, without any need to
>> worry about the scale of the map. In the same way, you could say
>> there is a spot of spilled ink at 20 20 40 40. If and only if you
>> want to know the size of this spot, then you will need to look up the
>> dimensions and calculate the scale factor.
>>
>
> Exactly. I will steal this explanation for the draft!
My pleasure, but you have to clean up the English yourself:-(
>
>>> I think real world object coordinates would be brilliant to have.
>>> Conservators would love them too, I bet, since they would be image
>>> independent (you'd just need to add new reference coordinates to your
>>> lookup table). But we are simply not talking about that or any other
>>> measurement as far as I can see.
>>>
>> See above, I think we can't really do without providing the
>> possibility of registering dimensions.
>>
>
> Is there a negative too many in that sentence, or are you suggesting
> we *should* include the dimensions of the original somewhere? and if
> so, how?
>
Yes, lets have dimensions. As to the details, well... If we have a
serious of page-scans of the same size, it would surely be enough to
have one child on . Otherwise, if we have
elements to provide for multiple graphics, I'd suggest a
child there as well.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 04:16:12 EDT
From lou.burnard at oucs.ox.ac.uk Thu Aug 9 04:37:59 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 09:37:59 +0100 Subject: [tei-council] updated facsimile odd In-Reply-To: <46BACD44.2@gmail.com> Message-ID: <46BAD267.2040001@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 09:37:59 +0100
Christian Wittern wrote:
>
>>
>> Is there a negative too many in that sentence, or are you suggesting
>> we *should* include the dimensions of the original somewhere? and if
>> so, how?
>>
> Yes, lets have dimensions. As to the details, well... If we have a
> serious of page-scans of the same size, it would surely be enough to
> have one child on . Otherwise, if we have
> elements to provide for multiple graphics, I'd suggest a
> child there as well.
>
If we have as a child of then it potentially
duplicates or contradicts as a child of , which
is confusing.
My preference would be for an attribute such as @originalSize on
. That would at least be explicit. Or @height and @width on on
. Since is defined relative to surface you shouldn't
need it anywhere else.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 04:46:05 EDT
From lou.burnard at oucs.ox.ac.uk Thu Aug 9 05:00:02 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 10:00:02 +0100 Subject: [tei-council] facsimile draft In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABDF@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <46BAD792.8070302@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 10:00:02 +0100
Conal Tuohy wrote:
> Regarding box, I agree with the others who've suggested that the origin of our coordinate spaces should be at the upper left, and that positive values are to the right, and below, the origin. That's pretty conventional in my experience. I like the name of box!
>
OK
> Can you comment on the new facsimile/front and facsimile/back - what would be encoded there?
>
>
Same as and elsewhere -- I was imagining that you might
want to associate some text or other with the facsimile itself, distinct
from front and back of the transcription. It might also provide a home
for some additional image-specific metadata if we decide not to put that
in the header.
> My main set of issues relates to the changes about how graphics relate to zones, and to surfaces, and how textual elements relate to zones or graphics. This is quite a different system - can you explain the rationale behind the changes?
>
> In the previous draft, it was possible to assign graphical coordinates to individual elements in a transcription, but this is now dropped. What was the reason for that? I am pretty sure that Dot was particularly keen on that feature, and I was also convinced of its utility.
The problem with the way this was done before (and I may have
misunderstood) is that you had to have special rules telling you which
the @coords supplied for it were relative to (see earlier
discussion with Sebastian). URL pointing solves this by the concept of
xml:base, which might have been a good solution, if only there were an
xpointer location scheme for locating boxes within the graphic that we
all agreed on. We could define our own but I felt we ought to learn our
lesson from last time and wait for someone else to do it!

> For instance, imagine a TEI transcript originating in an OCR process, which would have image coordinates assigned to each word by the OCR software. Using your draft markup, if I understand correctly, it would be necessary to create a distinct zone element for each word, essentially a parallel of the transcription, and link each word in the transcript to its corresponding zone. This would be quite an overhead!
>
Why? It's an automated process anyway, isn't it? You would indeed need
to define a zone for each word, but wouldn't that be precisely what the
OCR process outputs anyway?
> I also think that the value space for @facs is too loose - in the sense that a

or a

could use a @facs pointer to point to either an image file, to a zone, or to a graphic. I have a feeling this is not going to be so convenient for processing. In the previous draft, the idea was that such links would be ONLY to zones, which were facsimile equivalents of elements in a transcription.
>
>
We can't enforce this kind of rule (even for s) -- it's a
data.pointer and it can point anywhere it pleases. I felt it was useful
to spell out what it *means* when it points to different kinds of thing.
An application can of course choose not to support a particular class of
target, but that's a different issue.

> You've also allowed inside , and I'm having a hard time understanding the rationale for this change. It seems to be of a piece with the change to remove from att.coordinated. Now, since a graphic has no @box of its own, it inherits one from its parent , is that right?
inside means the same as inside
(you may recall that I wanted to use recursively) -- this is
an image of the zone/graphic defined here, so yes: the bounding box of
the graphic/s inside a are defined by the parent zone.
I wanted to avoid change to , if at all possible. And I also
wanted to separate the co-ordinate information from the graphical
pointing information.

> In my previous draft, a graphic had a @box (or @coords as it was still called) attribute of its own, and hence didn't need to be enclosed in a zone, and I don't see why we'd want to wrap those graphics in zones, when they could just have their own @box. What does that gain us?
>
>
A clearer separation of concepts, imho. Plus the ability to give
multiple graphic realisations for the same space in a relatively
non-prolix manner.
> Requiring graphics to be contained in zones would be convenient to the extent that the distinct graphics correspond exactly to areas of interest (i.e. if they have been exactly cropped to that size), but I'm not sure this is likely to be a common case. It seems to me more likely that graphics will tend to be larger than zones, in almost all cases. Hence there would need to be an analytical zone (highlighted the area of interest) and a graphical zone (to contain a graphic which showed the area of interest). Only if the graphic had been cropped to exactly cover the area of interest could its parent zone be accurately used as an analytical zone, and linked to a piece of transcript.
>
>
This depends on how you define the zone/surface, surely?

> Removing graphic from zone (and giving graphic its own @box) would mean that zones would be always empty, and this would simplify processing, too, I believe.
>
>
Because empty elements are easier to process than full ones? I find that
hard to believe!
> Regarding the "short-cut" which allows facsimile/graphic instead of requiring facsimile/surface/graphic, this seems reasonable, though I wonder if there's much prospect of people using this short-cut, and if not, I think the shortcut should be abolished (to simplify processing). The reason I doubt it would be popular is that if you have a single graphic, you already have the option of linking to it directly from a pb, which is an even shorter short-cut. If you use the facsimile/graphic shortcut (i.e. a graphic as a direct child of facsimile, rather than mediated by a surface), you don't have the option of using zones anyway, so this slightly-longer shortcut doesn't cater for any distinct use case as far as I can see).
>
See my comment to Dan before breakfast. It seems a good idea to have a
clear distinction between graphics in the text and graphics representing
the text. It seems a good idea to have a place where all the information
about the latter can be collected together. But I agree it won't seem
that short a cut to people who just want to pepper their transcriptions
with explicit pointers off into the wild blue yonder with no concern for
the morrow... such people are probably beyond help anyway.

> In short, I'm a bit flummoxed. I liked the linking better the way it was.
>
>
Well, fair enough. I apologize if you feel I've messed up your ideas
completely, and am very grateful for your willingness to engage in the
debate. I think there's been a pretty convincing groundswell of approval
for the direction things are going so the process can't be all bad.

> Con
>
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Lou Burnard
> Sent: Mon 06/08/07 9:07
> To: tei-council_at_lists.village.Virginia.EDU
> Subject: [tei-council] facsimile draft
>
> As mentioned in the call, I've been working on trying to produce a
> section about facsimile markup which could be plugged into the current
> chapter on physical transcription, using as many as possible of the
> ideas discussed here by Conal and others over the last few weeks.
>
> Time is running out, and we need to get closure on this, so I hope Conal
> and Dot will excuse me for steaming ahead on this without consulting
> with them privately first. I've used the documents circulated and
> followed (as far as I can) the discussion so far to produce a
> straw-person kind of a draft which is now posted for your (particularly
> their) urgent attention at http://www.tei-c.org/Drafts/facs.odd
>
> I've deliberately restricted the scope of what this draft makes possible
> to what I hope we can all agree on as a bare minimum of functionality.
> It supports linking from text to image and image to text with a minimum
> of fuss ; it also supports linking between text and image fragments, but
> only provides one way to do it. It tries to fit in with existing TEI
> idiom and practice.
>
> It is however in desperate need of help on the following counts:
>
> -- I haven't the faintest idea how to transcribe the Old English ms
> we're using as an example. (The one Conal circulated earlier). Either
> someone needs to transcribe it for me, or I need to find another example
> which I can transcribe. (Actually, as this one claims to be copyright of
> the Bodleian, the second is probably the wiser course)
>
> -- in defining how the co-ordinate system works, I have had to rely on
> my vague recollections of O level maths. Someone who actually knows
> about this stuff should read it carefully to see how plausible this is.
> Also how feasible it is to implement it!
>
> -- I've also made a wild guess about how to specify the datatype of my
> @box attribute (formerly known as @coords -- I renamed it because it is
> considerably more restricted than the synonymous XHTML attribute)
>
> All comments, bouquets, and brickbats gratefully received
>
> Lou
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 05:08:10 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 9 09:44:07 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 09 Aug 2007 14:44:07 +0100 Subject: [tei-council] listZZZ things Message-ID: <46BB1A27.7050003@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 09 Aug 2007 14:44:07 +0100
When I rename to (which I probably should), P5 will
have six listXXX things, which together with itself constitute
the model.listLike class
Would it be reasonable to expect them all to have similar content
models? Currently, they don't. Here's what I just noticed (alerted by
a useful sourceforge ticket from the indefatigable T Schassen)
listBibl: (divTop|global)*, biblLike+, global*, (divBottom, global*)*
listNym: (nym|listNym)+
listOrg: (pLike+ | org+)
listPerson: (plike+ | (personLike+, particLinks?))
listPlace: (placeLike+, relation*)
listWit: (headLike?, (witness|listWit)+)
I note the following anomalies:
a) listWit and listNym can recurse, which seems like a generally useful
idea; listPlace can too, but only because listPlace and place are both
members of model.placeLike. None of the others can.
b) listOrg and listPerson can have just paragraph content but none of
the others can.
c) listBibl permits all sorts of tosh at beginning and end, but none of
the others does.
d) listPerson and listPlace permit encoding of relationships between
their children by means of a relation elements, albeit in different
ways, but none of the others does.
What's to do?
Here's a straw person proposal for bringing these content models to heel:
listBibl: (headLike*, (biblLike|listBibl)+)
listNym: (headLike*, (nym|listNym)+)
listOrg: (headLike* (org|listOrg)+, relation*)
listPerson: (headLike* (personLike|listPerson)+, relation*)
listPlace: (headLike*, (placeLike|listPlace)+, relation*)
listWit: (headLike*, (witness|listWit)+)
This would also mean changing places where listPerson and listOrg are
referenced to permit pLike as an alternative; possibly moving some
things currently permitted within listBibl out of it; moving listPlace
out of the model.placeLike class.
Or we could just let sleeping dogs lie.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 09:44:10 EDT

From daniel.odonnell at uleth.ca Thu Aug 9 10:43:32 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 08:43:32 -0600 Subject: [tei-council] listZZZ things In-Reply-To: <46BB1A27.7050003@oucs.ox.ac.uk> Message-ID: <1186670612.11898.1.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 08:43:32 -0600
As a first go, I think this is exactly the type of thing we should be
doing. We will not be able to bring the type rationality to our models
that the model system invites for this iteration of P5, but I think we
should pluck the low-lying fruit now.
On Thu, 2007-08-09 at 14:44 +0100, Lou Burnard wrote:
> When I rename to (which I probably should), P5 will
> have six listXXX things, which together with itself constitute
> the model.listLike class
>
> Would it be reasonable to expect them all to have similar content
> models? Currently, they don't. Here's what I just noticed (alerted by
> a useful sourceforge ticket from the indefatigable T Schassen)
>
> listBibl: (divTop|global)*, biblLike+, global*, (divBottom, global*)*
> listNym: (nym|listNym)+
> listOrg: (pLike+ | org+)
> listPerson: (plike+ | (personLike+, particLinks?))
> listPlace: (placeLike+, relation*)
> listWit: (headLike?, (witness|listWit)+)
>
> I note the following anomalies:
>
> a) listWit and listNym can recurse, which seems like a generally useful
> idea; listPlace can too, but only because listPlace and place are both
> members of model.placeLike. None of the others can.
> b) listOrg and listPerson can have just paragraph content but none of
> the others can.
> c) listBibl permits all sorts of tosh at beginning and end, but none of
> the others does.
> d) listPerson and listPlace permit encoding of relationships between
> their children by means of a relation elements, albeit in different
> ways, but none of the others does.
>
> What's to do?
>
> Here's a straw person proposal for bringing these content models to heel:
>
> listBibl: (headLike*, (biblLike|listBibl)+)
> listNym: (headLike*, (nym|listNym)+)
> listOrg: (headLike* (org|listOrg)+, relation*)
> listPerson: (headLike* (personLike|listPerson)+, relation*)
> listPlace: (headLike*, (placeLike|listPlace)+, relation*)
> listWit: (headLike*, (witness|listWit)+)
>
> This would also mean changing places where listPerson and listOrg are
> referenced to permit pLike as an alternative; possibly moving some
> things currently permitted within listBibl out of it; moving listPlace
> out of the model.placeLike class.
>
> Or we could just let sleeping dogs lie.
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 10:46:38 EDT
From daniel.odonnell at uleth.ca Thu Aug 9 11:06:28 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 09:06:28 -0600 Subject: [tei-council] updated facsimile odd In-Reply-To: <46BA6B3D.5020405@gmail.com> Message-ID: <1186671988.11898.21.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 09:06:28 -0600
On Thu, 2007-08-09 at 10:17 +0900, Christian Wittern wrote:
> >
> > I think myself subject to clarification that we should be calling a
> > spade a spade here: everything in the ODD and its description suggests
> > to me that we are counting pixels. If we were doing anything else surely
> > we'd need some kind of translation table and discussion of how real
> > world measurements get converted to locations on the image?
> >
> Let's assume you have a page of 297x210mm, which is covered by the
> surface element, which gives you also a grid of 0 0 100 100 to work
> from. The grid is more like the one you have on maps, which simple go
> from A, B, C, D,... and 1, 2, 3, 4, ... which allows you to say that
> something you are interested in is in C1, without any need to worry
> about the scale of the map. In the same way, you could say there is a
> spot of spilled ink at 20 20 40 40. If and only if you want to know the
> size of this spot, then you will need to look up the dimensions and
> calculate the scale factor.
O.K. Conal also talks about them not "necessarily" being pixels. So do
users need to define the outer limits of the box? How do I know what the
coordinates of the far right, and bottom left and bottom right corners
of the box are so that I can identify where 21 33 75 92 is?
I'm sure you are explaining the obvious to me, but at least we are
making progress on this, I think--see Lou's comment on the paragraph for
inclusion in the guide.
>
> > I think real world object coordinates would be brilliant to have.
> > Conservators would love them too, I bet, since they would be image
> > independent (you'd just need to add new reference coordinates to your
> > lookup table). But we are simply not talking about that or any other
> > measurement as far as I can see.
> >
> See above, I think we can't really do without providing the possibility
> of registering dimensions.
>
> > The hi/lo res issue is an important one: if I have
> > surface/graphic_at_id="hi1"|graphic_at_id="lo1" then the references for the
> > bottom right corners of the box (at least) will be different in each;
> > and if we are not starting in 0,0, then botheth sets will be different.
> > Should we perhaps somehow indicate a reference image in those cases?
> > This would allow the images to be aligned, since one would be expressed
> > in terms of the other. Of course, then surtheface is starting to look
> > like app; but that's neither here nor there ;)
> >
> Now this seems coming closer and closer to reinventing METS...
>
> Christian
>
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 11:09:33 EDT
From daniel.odonnell at uleth.ca Thu Aug 9 11:14:29 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 09:14:29 -0600 Subject: [tei-council] facsimile draft In-Reply-To: <75CF552F30ECFA439D9B3008906F2A3701ABABDF@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <1186672469.11898.27.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 09:14:29 -0600
As I understand things, we seem to be making real progress on the
coordinate business--at least in explaining how it works.
The zone-graphic-surface and @facs is the other main area of contention
and we seem to be making less progress there--or rather now have two
competing versions.
Would it be worth while for Con to take Lou's ODD and perhaps redo the
surface-graphic-zone business so it does what he and Dot had envisioned?
This wouldn't be a step backwards, since, as Con notes, much has been
clarified in Lou's ODD. But I think it might be useful to have alternate
proposals to look at that are only minimally different in the area we
are supposed to be considering.
-dan
On Thu, 2007-08-09 at 18:32 +1200, Conal Tuohy wrote:
> G'day Lou, et al
>
> I have had a look at the draft and I have a few comments and queries about your proposed changes:
>
> Regarding box, I agree with the others who've suggested that the origin of our coordinate spaces should be at the upper left, and that positive values are to the right, and below, the origin. That's pretty conventional in my experience. I like the name of box!
>
> Can you comment on the new facsimile/front and facsimile/back - what would be encoded there?
>
> My main set of issues relates to the changes about how graphics relate to zones, and to surfaces, and how textual elements relate to zones or graphics. This is quite a different system - can you explain the rationale behind the changes?
>
> In the previous draft, it was possible to assign graphical coordinates to individual elements in a transcription, but this is now dropped. What was the reason for that? I am pretty sure that Dot was particularly keen on that feature, and I was also convinced of its utility. For instance, imagine a TEI transcript originating in an OCR process, which would have image coordinates assigned to each word by the OCR software. Using your draft markup, if I understand correctly, it would be necessary to create a distinct zone element for each word, essentially a parallel of the transcription, and link each word in the transcript to its corresponding zone. This would be quite an overhead!
>
> I also think that the value space for @facs is too loose - in the sense that a

or a

could use a @facs pointer to point to either an image file, to a zone, or to a graphic. I have a feeling this is not going to be so convenient for processing. In the previous draft, the idea was that such links would be ONLY to zones, which were facsimile equivalents of elements in a transcription.
>
> You've also allowed inside , and I'm having a hard time understanding the rationale for this change. It seems to be of a piece with the change to remove from att.coordinated. Now, since a graphic has no @box of its own, it inherits one from its parent , is that right? In my previous draft, a graphic had a @box (or @coords as it was still called) attribute of its own, and hence didn't need to be enclosed in a zone, and I don't see why we'd want to wrap those graphics in zones, when they could just have their own @box. What does that gain us?
>
> Requiring graphics to be contained in zones would be convenient to the extent that the distinct graphics correspond exactly to areas of interest (i.e. if they have been exactly cropped to that size), but I'm not sure this is likely to be a common case. It seems to me more likely that graphics will tend to be larger than zones, in almost all cases. Hence there would need to be an analytical zone (highlighted the area of interest) and a graphical zone (to contain a graphic which showed the area of interest). Only if the graphic had been cropped to exactly cover the area of interest could its parent zone be accurately used as an analytical zone, and linked to a piece of transcript.
>
> Removing graphic from zone (and giving graphic its own @box) would mean that zones would be always empty, and this would simplify processing, too, I believe.
>
> Regarding the "short-cut" which allows facsimile/graphic instead of requiring facsimile/surface/graphic, this seems reasonable, though I wonder if there's much prospect of people using this short-cut, and if not, I think the shortcut should be abolished (to simplify processing). The reason I doubt it would be popular is that if you have a single graphic, you already have the option of linking to it directly from a pb, which is an even shorter short-cut. If you use the facsimile/graphic shortcut (i.e. a graphic as a direct child of facsimile, rather than mediated by a surface), you don't have the option of using zones anyway, so this slightly-longer shortcut doesn't cater for any distinct use case as far as I can see).
>
> In short, I'm a bit flummoxed. I liked the linking better the way it was.
>
> Con
>
> -----Original Message-----
> From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Lou Burnard
> Sent: Mon 06/08/07 9:07
> To: tei-council_at_lists.village.Virginia.EDU
> Subject: [tei-council] facsimile draft
>
> As mentioned in the call, I've been working on trying to produce a
> section about facsimile markup which could be plugged into the current
> chapter on physical transcription, using as many as possible of the
> ideas discussed here by Conal and others over the last few weeks.
>
> Time is running out, and we need to get closure on this, so I hope Conal
> and Dot will excuse me for steaming ahead on this without consulting
> with them privately first. I've used the documents circulated and
> followed (as far as I can) the discussion so far to produce a
> straw-person kind of a draft which is now posted for your (particularly
> their) urgent attention at http://www.tei-c.org/Drafts/facs.odd
>
> I've deliberately restricted the scope of what this draft makes possible
> to what I hope we can all agree on as a bare minimum of functionality.
> It supports linking from text to image and image to text with a minimum
> of fuss ; it also supports linking between text and image fragments, but
> only provides one way to do it. It tries to fit in with existing TEI
> idiom and practice.
>
> It is however in desperate need of help on the following counts:
>
> -- I haven't the faintest idea how to transcribe the Old English ms
> we're using as an example. (The one Conal circulated earlier). Either
> someone needs to transcribe it for me, or I need to find another example
> which I can transcribe. (Actually, as this one claims to be copyright of
> the Bodleian, the second is probably the wiser course)
>
> -- in defining how the co-ordinate system works, I have had to rely on
> my vague recollections of O level maths. Someone who actually knows
> about this stuff should read it carefully to see how plausible this is.
> Also how feasible it is to implement it!
>
> -- I've also made a wild guess about how to specify the datatype of my
> @box attribute (formerly known as @coords -- I renamed it because it is
> considerably more restricted than the synonymous XHTML attribute)
>
> All comments, bouquets, and brickbats gratefully received
>
> Lou
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 11:17:34 EDT
From daniel.odonnell at uleth.ca Thu Aug 9 16:06:55 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 14:06:55 -0600 Subject: [tei–council] choice, etc.––finally. In-Reply-To: <03AF7903F10BB64CA22CDF89EE5D80BA9B6056@EXCHCL2.uleth.ca> Message-ID: <1186690016.5748.12.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 14:06:55 -0600
This is the piece I tried to send several times to council last week. It
was written as a discussion piece.

-----Original Message-----
From: O'Donnell, Dan
Sent: Wed 01/08/2007 16:28
To: tei-council_at_lists.village.virginia.edu
Subject: I'm not sure this made it on the list this morning

Hi all,
I sent this early this morning, and it was in my "sent" box, but I never
saw a copy unlike what usually happens. If it didn't make it out, sorry
for the delay; if it did, I've added a new small postscript:
Hi all,
Sorry for the delay in getting this out. With my jetlag, I just fell
asleep last night and then only woke up long enough for a planning call
for tomorrow's meeting. On the other hand, jetlag also means its a snap
getting up at 5.
I was asked by Christian to look into combining my proposals for
rearranging the model.pPartEdit and children classes (choice,
abbr/expan, and transcription elements; see: http://tinyurl.com/39qoua)
with Matthew's editorial proposals (regarding edInt, subst., and the
like: see http://www.tei-c.org/Drafts/edInt.xml). There has already been
some discussion of both.
==The class models==
As far as I am aware there have been no objections to the reorganisation
and modifications I proposed, which involved
* Some changes to the description of choice's element description to
reflect the fact that its usage currently concerns entirely grouping
transcriptional and editorial alternate states/alternative rather than
alternate states in general.
* making various additions and changes to the membership of
model.pPartEdit and model.choiceLike and (since the new model.choiceLike
coincides exactly with the final content of model.pPartEditorial and
model.pPartTranscriptional), getting rid of these classes
* creating a class model.restoreLike to allow us to built a more
specific content model for restore
* moving app to model.listLike
==Matthew's Proposals==
Mathew's proposals centred around two elements, and ,
both of which are arguably semantically specific versions of .
is to be used to group children like and when these
children refer to interventions in the abstract editorial text rather
than physical changes in a witness. This, if an editor notices that a
text has "brian" instead of "brain" would be used:

My cert="high">brianbrain hurts.


But if a scribe had noticed it, would be preferred:

My brian hand="#scribeB">brain hurts.


Where is not like , however, is that the proposal allows
its content model to include text:
t
is to be used when a scribal change in a witness is to be seen
as part of a single act: e.g. if a correction is clearly the result of a
scribe catching an error and correcting it him/herself:

my brain rend="overstrike">burns place="margin">hurts.


If on the other hand the encoder doesn't want to make this assertion (or
if the add/del are not in the same hand or otherwise clearly not part of
a single act), choice would again be used:

my brain hand="#scribeA">burns hand="#scribeB">hurts.


Integrating these proposals into mine would be a relatively simple
matter if we did not allow to contain text directly. Their
allowed children are all members of the revised model.choicePart content
model and, as I argue above, they are both really semantic refinements
of . Basically all that would be required is creating a
model.choiceLike to include them and the generic case and
substituting this wherever would otherwise be used (in my
proposal in model.pPartEdit; currently in model.pPartEditorial).
The idea of a model.choiceLike class appeals to me, because I think
is going to be a productive element once people get used to it.
However, I am a bit wary at this point of proposing two semantic
specialisations this early in its development: why provide elements for
the equivalent of choice_at_type="editorial" and choice_at_type="substitution"
but not choice_at_type="fire damage" or choice_at_type="scribal"? So my
recommendation is that for P5 we don't add a model.choiceLike class and
leave out and , encouraging people instead to use @type
or @reason to cover semantic attributes of the grouping. If we decide to
put one or both in anyway, I'd recommend making them real
specialisations of choice and disallowing textual content in either.
Regardless, I think that Matthew's work shows we need to be prepared for
people to discover new uses for the generic element: for this reason
I've changed my mind on including a generic
From conal.tuohy at vuw.ac.nz Thu Aug 9 18:17:52 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 10 Aug 2007 10:17:52 +1200 Subject: [tei-council] updated facsimile odd In-Reply-To: <46BAC3FE.90904@oucs.ox.ac.uk> Message-ID: <1186697872.18890.295.camel@localhost>
From: Conal Tuohy
Date: Fri, 10 Aug 2007 10:17:52 +1200
On Thu, 2007-08-09 at 08:36 +0100, Lou Burnard wrote:
> Conal Tuohy wrote:
> > Finally, since measurements are actually being made in a common
>> coordinate space, the high- and low- resolution images in your
>> example would actually have the same @box value. The difference in
>> resolution could be made apparent by encoding @width and @height on
>> the graphic (i.e. the high res image might be
>> width="1000px" height="2000px"/> while the lo res image would be
>>
> >
> >
> -1
>
>
> As previously noted, this usage of @height and @width on graphic is a
> major difference in the way these attributes are currently defined.
Sorry ... I haven't really understood this, but I've gone back and
re-read your earlier email and the guidelines, and I think I have it
clearer now.
At the very least I think that the documentation for
data.outputMeasurement and for graphic need to be clarified. For
instance where it says that they are for "specifying the size of an
object that is intended for display on the web", it should probably make
it clear at that point that the size specified is the desired size of
the display, not the size of the object itself. Currently, the sentence
is ambiguous on that point.
It's worth pointing out that the dimensions of graphics are potentially
valuable in other contexts than "display on the web".
As you said earlier, the schema and documentation is vague in places,
and hence it's not really clear what you can do with graphic's @height,
@width, and @scale attributes in practice. At present there isn't a lot
of actual usage which encoders can refer to, either.
The nub of the problem, IMHO, is that the value space of @width and
@height (defined by data.outputMeasurement) is based on CSS units which
include quite different measurements systems: pixels (i.e. measurement
in "device space"), real-world distance units such as mm and pt, and
also percentages (which incidentally pretty much renders @scale
redundant anyway).
So it would be valid against the schema to say that a graphic was
supposed to be rendered as "100px" width, or at "100%" width, but what
would that mean in practice? If the image is 100px wide, that would mean
rendering it 100px wide. However, the real-world dimensions of that will
vary depending on the resolution of the rendering device: on a computer
monitor that might be a few cm across, whereas on a laser printer it
would be more like a few mm. I think it's clear that the measurement
units used here should not make assumptions about the resolution of the
end-user's display device. That should be a matter for presentation
software.
It seems to me that our earlier discussion of the semantics of @rend is
parallel: does the value of @rend indicate how the text should be
rendered for display, or how it WAS rendered in the original? We agreed
that it was the latter. But with graphic, we have a situation more like
the former, don't we? Wouldn't it be better to provide "real-world"
measurements as the dimensons of graphics, and allow presentation
software to scale the graphics appropriately for different output
devices? Perhaps a better way would be to give 2 distinct sets
of measurements, such as @width and @height given in pixels, and also a
child (or and children), as has been
proposed for , given in real-world units?
Con
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 18:18:00 EDT
From daniel.odonnell at uleth.ca Thu Aug 9 18:47:43 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 16:47:43 -0600 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186697872.18890.295.camel@localhost> Message-ID: <1186699663.11097.9.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 16:47:43 -0600
On Fri, 2007-08-10 at 10:17 +1200, Conal Tuohy wrote:

> So it would be valid against the schema to say that a graphic was
> supposed to be rendered as "100px" width, or at "100%" width, but what
> would that mean in practice?
in CSS terms, 100% means "100% of the width of the image" and has
nothing to do with the real world object.
> If the image is 100px wide, that would mean
> rendering it 100px wide. However, the real-world dimensions of that will
> vary depending on the resolution of the rendering device: on a computer
> monitor that might be a few cm across, whereas on a laser printer it
> would be more like a few mm. I think it's clear that the measurement
> units used here should not make assumptions about the resolution of the
> end-user's display device. That should be a matter for presentation
> software.
>
> It seems to me that our earlier discussion of the semantics of @rend is
> parallel: does the value of @rend indicate how the text should be
> rendered for display, or how it WAS rendered in the original? We agreed
> that it was the latter. But with graphic, we have a situation more like
> the former, don't we?
Yes and no--both to your premise and what is desirable. THE most
desirable situation would be that real world dimensions are correlated
to graphic dimensions so that a reference to the graphic could be
converted to a reference to the real world object. But that's beyond
what we're doing here.
In our more limited P5 world, the reference is still to the original
graphic rather than the rendition device. So 100 230 450 453 refers to a
point on the original graphic file rather than my output. Technically it
is a moot point, I suspect, since if I'm using Lynx or a screedocumentn
reader I can't reference the point anyway, and if I'm using a cell phone
on some huge graphic I'll find the point by scrolling. But the reference
is to the input image rather than the output. If my cellphone does some
kind of compression routine in order to get large images on the screen,
the output coorindates will need to be translated.
> Wouldn't it be better to provide "real-world"
> measurements as the dimensons of graphics, and allow presentation
> software to scale the graphics appropriately for different output
> devices? Perhaps a better way would be to give 2 distinct sets
> of measurements, such as @width and @height given in pixels, and also a
> child (or and children), as has been
> proposed for , given in real-world units?
I think this is getting beyond what we need for P5: what is wrong with
saying the box coordinates ref a point in the input graphic as a minimal
feature? If the user needs more, there is METS, as I am always reminded.
>
> Con
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 18:50:50 EDT
From conal.tuohy at vuw.ac.nz Thu Aug 9 19:30:04 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 10 Aug 2007 11:30:04 +1200 Subject: [tei-council] facsimile draft In-Reply-To: <46BAD792.8070302@oucs.ox.ac.uk> Message-ID: <1186702204.18890.347.camel@localhost>
From: Conal Tuohy
Date: Fri, 10 Aug 2007 11:30:04 +1200
On Thu, 2007-08-09 at 10:00 +0100, Lou Burnard wrote:
> Conal Tuohy wrote:
> The problem with the way this was done before (and I may have
> misunderstood) is that you had to have special rules telling you which
> the @coords supplied for it were relative to (see earlier
> discussion with Sebastian).
Well ... which to be precise, and from there, to the graphics
which depict that surface. But yes, a "special rule" is what it was.
I can accept that.
> URL pointing solves this by the concept of
> xml:base, which might have been a good solution, if only there were an
> xpointer location scheme for locating boxes within the graphic that we
> all agreed on. We could define our own but I felt we ought to learn our
> lesson from last time and wait for someone else to do it!
agreed
> > For instance, imagine a TEI transcript originating in an OCR process,
>> which would have image coordinates assigned to each word by the OCR
>> software. Using your draft markup, if I understand correctly, it
>> would be necessary to create a distinct zone element for each word,
>> essentially a parallel of the transcription, and link each word in
>> the transcript to its corresponding zone. This would be quite an
>> overhead!
> Why? It's an automated process anyway, isn't it? You would indeed need
> to define a zone for each word, but wouldn't that be precisely what the
> OCR process outputs anyway?
Sure ... it would be an overhead only in terms of the amount of markup
required, not necessarily in terms of the encoding work involved in
making that markup (which in the OCR case would be fully automated
anyway), or the extra post-processing involved (which is just some
de-referencing some URLs).
So I'm not too fussed on this point.
I think when people are going to do a lot of alignment (such as aligning
each word), then they're more likely to be using some automated tools
anyway, so the extra markup overhead is not an issue. I could be wrong
about that, though. Perhaps you comment on that, Dot?
As a distinct benefit, dropping @coords (or @box) from textual elements
also makes for a cleaner separation between the facsimile and the text,
in that the text is not polluted with any "facsimilar" data, and the
facsimile is then "pure" standoff.
> > I also think that the value space for @facs is too loose - in the
>> sense that a

or a

could use a @facs pointer to point to
>> either an image file, to a zone, or to a graphic. I have a feeling
>> this is not going to be so convenient for processing. In the previous
>> draft, the idea was that such links would be ONLY to zones, which
>> were facsimile equivalents of elements in a transcription.

> We can't enforce this kind of rule (even for s) -- it's a
> data.pointer and it can point anywhere it pleases.
Can't it be enforced with schematron, though?
In any case, there are already attributes which are supposed to point to
elements of a particular type (even if this constraint is only expressed
in the text of the guidelines).
e.g. add/@hand, must point to a hand
> I felt it was useful
> to spell out what it *means* when it points to different kinds of thing.
> An application can of course choose not to support a particular class of
> target, but that's a different issue.
>From the point of view of promoting interoperability, any constraints we
can place on it will be a help. If we could say "@facs always points to
a zone", for instance, then this would help to prevent a situation where
some applications support this and other applications support that.
> > You've also allowed inside , and I'm having a hard
>> time understanding the rationale for this change. It seems to be of a
>> piece with the change to remove from att.coordinated. Now,
>> since a graphic has no @box of its own, it inherits one from its
>> parent , is that right?
> inside means the same as inside
> (you may recall that I wanted to use recursively) -- this is
> an image of the zone/graphic defined here, so yes: the bounding box of
> the graphic/s inside a are defined by the parent zone.
>
> I wanted to avoid change to , if at all possible. And I also
> wanted to separate the co-ordinate information from the graphical
> pointing information.
OK this makes sense.
> > In my previous draft, a graphic had a @box (or @coords as it was
>> still called) attribute of its own, and hence didn't need to be
>> enclosed in a zone, and I don't see why we'd want to wrap those
>> graphics in zones, when they could just have their own @box. What
>> does that gain us?
> A clearer separation of concepts, imho. Plus the ability to give
> multiple graphic realisations for the same space in a relatively
> non-prolix manner.
Fair enough.

> > Removing graphic from zone (and giving graphic its own @box)
>> would mean that zones would be always empty, and this would simplify
>> processing, too, I believe.

> Because empty elements are easier to process than full ones? I find that
> hard to believe!
No - I didn't word that sentence well - the simplification would have
come from facsimle graphics always having a parent, rather
than sometimes a and sometimes a
> > Regarding the "short-cut" which allows facsimile/graphic instead of
>> requiring facsimile/surface/graphic, this seems reasonable, though I
>> wonder if there's much prospect of people using this short-cut, and
>> if not, I think the shortcut should be abolished (to simplify
>> processing). The reason I doubt it would be popular is that if you
>> have a single graphic, you already have the option of linking to it
>> directly from a pb, which is an even shorter short-cut. If you use
>> the facsimile/graphic shortcut (i.e. a graphic as a direct child of
>> facsimile, rather than mediated by a surface), you don't have the
>> option of using zones anyway, so this slightly-longer shortcut
>> doesn't cater for any distinct use case as far as I can see).
> >
> See my comment to Dan before breakfast. It seems a good idea to have a
> clear distinction between graphics in the text and graphics representing
> the text. It seems a good idea to have a place where all the information
> about the latter can be collected together. But I agree it won't seem
> that short a cut to people who just want to pepper their transcriptions
> with explicit pointers off into the wild blue yonder with no concern for
> the morrow... such people are probably beyond help anyway.
Can we agree to drop that feature then?
If so, we could restrict to only contain elements
(no s), each could be restricted to only contain
elements, and facsimile s would only ever be contained
in elements, while @facs could be restricted to point only to a
or (as a concessionary shortcut, for those people who can't
afford elements) directly to an image file.
> > In short, I'm a bit flummoxed. I liked the linking better the way it was.
> Well, fair enough. I apologize if you feel I've messed up your ideas
> completely, and am very grateful for your willingness to engage in the
> debate. I think there's been a pretty convincing groundswell of approval
> for the direction things are going so the process can't be all bad.
No, no problem at all! Sorry if I sounded bitter - I'm certainly not! In
fact I'm really pleased with the work you've put into it, Lou,
especially now that I understand it better :-)
I'm happy for you to propose whatever you see fit. I think it's
important though present some of the real reasons for the differences,
though, so we can make evaluate them correctly.
I agree we are making progress on this, so I've got no complaints.
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 19:30:12 EDT

From conal.tuohy at vuw.ac.nz Thu Aug 9 19:41:10 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 10 Aug 2007 11:41:10 +1200 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186699663.11097.9.camel@localhost> Message-ID: <1186702870.3312.2.camel@localhost>
From: Conal Tuohy
Date: Fri, 10 Aug 2007 11:41:10 +1200
On Thu, 2007-08-09 at 16:47 -0600, Daniel O'Donnell wrote:
> On Fri, 2007-08-10 at 10:17 +1200, Conal Tuohy wrote:
> > If the image is 100px wide, that would mean
> > rendering it 100px wide. However, the real-world dimensions of that will
> > vary depending on the resolution of the rendering device: on a computer
> > monitor that might be a few cm across, whereas on a laser printer it
> > would be more like a few mm. I think it's clear that the measurement
> > units used here should not make assumptions about the resolution of the
> > end-user's display device. That should be a matter for presentation
> > software.
> In our more limited P5 world, the reference is still to the original
> graphic rather than the rendition device.
Well it seems to me Lou was stating precisely the opposite - that
graphic/@width and @height specify the desired OUTPUT dimensions, and
definitely NOT the width and height of the image file itself.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 09 2007 - 19:41:15 EDT
From cwittern at gmail.com Thu Aug 9 19:55:55 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 10 Aug 2007 08:55:55 +0900 Subject: [tei-council] facsimile draft In-Reply-To: <46BAD792.8070302@oucs.ox.ac.uk> Message-ID: <46BBA98B.4020706@gmail.com>
From: Christian Wittern
Date: Fri, 10 Aug 2007 08:55:55 +0900
Lou Burnard wrote:
> Conal Tuohy wrote:
>
>> For instance, imagine a TEI transcript originating in an OCR process,
>> which would have image coordinates assigned to each word by the OCR
>> software. Using your draft markup, if I understand correctly, it
>> would be necessary to create a distinct zone element for each word,
>> essentially a parallel of the transcription, and link each word in
>> the transcript to its corresponding zone. This would be quite an
>> overhead!
>>
>
> Why? It's an automated process anyway, isn't it? You would indeed need
> to define a zone for each word, but wouldn't that be precisely what
> the OCR process outputs anyway?
I would like to second Conal here, I think it ought to be
straightforward to do a mapping from the text elements to the
facsimile. I have seen and used two applications who do this kind of
mapping, Omnipage XML and Dejavu XML; both provide a direct way to link
from words or characters to the corresponding bounding box on the
associated image (both do it in absolute pixels).
In our case, I think we could reasonably say that the coordinates on
textual elements are thought to be expressed relative to the entity that
is linked to through the @facs target of the preceding milestone (pb, cb
or whatever). This should cover the simple case with one image per
page, linked directly as well as more complex cases where there is an
intermediate surface element involved.

Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 19:56:23 EDT

From cwittern at gmail.com Thu Aug 9 20:16:34 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 10 Aug 2007 09:16:34 +0900 Subject: [tei-council] Next teleconference Aug 24, 2007 1200 UTC Message-ID: <46BBAE62.3000405@gmail.com>
From: Christian Wittern
Date: Fri, 10 Aug 2007 09:16:34 +0900
Dear Council members,
>From the responses (7 so far) meetomatic recommends Friday Aug. 24, so I
would like to set that date for our meeting.
I suggest that we ask John Walsh again to host the conference; the audio
quality seemed to be much better this way.
All the best,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 20:17:07 EDT

From daniel.odonnell at uleth.ca Thu Aug 9 20:34:37 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 09 Aug 2007 18:34:37 -0600 Subject: [tei-council] updated facsimile odd In-Reply-To: <1186702870.3312.2.camel@localhost> Message-ID: <1186706077.8432.0.camel@localhost>
From: Daniel O'Donnell
Date: Thu, 09 Aug 2007 18:34:37 -0600
On Fri, 2007-08-10 at 11:41 +1200, Conal Tuohy wrote:
> On Thu, 2007-08-09 at 16:47 -0600, Daniel O'Donnell wrote:
> > On Fri, 2007-08-10 at 10:17 +1200, Conal Tuohy wrote:
> > > If the image is 100px wide, that would mean
> > > rendering it 100px wide. However, the real-world dimensions of that will
> > > vary depending on the resolution of the rendering device: on a computer
> > > monitor that might be a few cm across, whereas on a laser printer it
> > > would be more like a few mm. I think it's clear that the measurement
> > > units used here should not make assumptions about the resolution of the
> > > end-user's display device. That should be a matter for presentation
> > > software.
>
> > In our more limited P5 world, the reference is still to the original
> > graphic rather than the rendition device.
>
> Well it seems to me Lou was stating precisely the opposite - that
> graphic/@width and @height specify the desired OUTPUT dimensions, and
> definitely NOT the width and height of the image file itself.
This seems to me worth straightening out. David or John W., any
opinions?
>
-- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell_at_uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 09 2007 - 20:37:44 EDT
From cwittern at gmail.com Fri Aug 10 00:35:26 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 10 Aug 2007 13:35:26 +0900 Subject: [tei-council] Questions regarding HD-The TEI Header Message-ID: <46BBEB0E.60207@gmail.com>
From: Christian Wittern
Date: Fri, 10 Aug 2007 13:35:26 +0900
Council members,
While working on my assignments for the new chapter triage, I came across
the following questions:
* Examples showing the teiHeader structure:







These are looking as if they would be valid as empty elements. I wonder if
it wouldn't be better to show them as


...
...
...


to enforce the point that they do not by itself form a valid TEI file.

* model.sourceDescPart:
There seem to be five different models for sourceDescPart:
model.sourceDescPart = scriptStmt | recordingStmt
model.sourceDescPart_sequence = scriptStmt, recordingStmt
model.sourceDescPart_sequenceOptional = scriptStmt?, recordingStmt?
model.sourceDescPart_sequenceOptionalRepeatable = scriptStmt*, recordingStmt*
model.sourceDescPart_sequenceRepeatable = scriptStmt+, recordingStmt+
(similar models are also defined for encodingDesc)
under what conditions are which models activated?
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 10 2007 - 00:35:50 EDT

From cwittern at gmail.com Fri Aug 10 01:59:45 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 10 Aug 2007 14:59:45 +0900 Subject: [tei-council] Next teleconference Aug 24, 2007 1200 UTC In-Reply-To: <1186722766.3312.136.camel@localhost> Message-ID: <46BBFED1.4010007@gmail.com>
From: Christian Wittern
Date: Fri, 10 Aug 2007 14:59:45 +0900
Dear Conal,
Yes, I did get your response, in fact it was one of the first.
Meetomatic reported three "best" dates with one of the respondents
unable to attend each. Of those, I chose the earliest possible one,
without actually looking at who was excluded.
Since the schedule is tight, I wanted to fix the date as instructed by
today, but only half of the expected attendees has responded so far.
For that reason, I do not want to rule out the possibility of changing
the date (although I'd be reluctant to do that, since the schedules are
bound to fill up on the free spots once this meetings date is
announced), for example to Fri Aug 31, which is another "best date"
candidate.
I hope we get the facsimile ironed out before long!
All the best,
Christian
Conal Tuohy wrote:
> Hi Christian
>
> Just checking - did you get my response? I wasn't sure, since in the
> past I've used meetomatic and got automated emails from it, which I
> didn't this time.
>
> I'll be a bit disappointed to miss the meeting, although actually I
> think the facsimile discussion is going rather well via email anyway,
> and it's probably better for me not to stay up so late ;-)
>
> Hope you have a good weekend!
>
> Con
>
> On Fri, 2007-08-10 at 09:16 +0900, Christian Wittern wrote:
>
>> Dear Council members,
>>
>> >From the responses (7 so far) meetomatic recommends Friday Aug. 24, so I
>> would like to set that date for our meeting.
>>
>> I suggest that we ask John Walsh again to host the conference; the audio
>> quality seemed to be much better this way.
>>
>> All the best,
>>
>> Christian
>>
>>
>>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 10 2007 - 02:00:16 EDT

From Syd_Bauman at Brown.edu Sat Aug 11 19:37:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 11 Aug 2007 19:37:46 -0400 Subject: [tei-council] listZZZ things In-Reply-To: <1186670612.11898.1.camel@localhost> Message-ID: <18110.18506.520461.699986@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 11 Aug 2007 19:37:46 -0400
I thought this was exactly the sort of sleeping dog that we were told
could not be woken after 01 or 04 Aug or whatever it was. On the
other hand, this looks like a very useful improvement, and if we have
the time, I think it is a good idea.
| listBibl: ( headLike*, ( biblLike | listBibl )+ )
| listNym: ( headLike*, ( nym | listNym )+ )
| listOrg: ( headLike*, ( org | listOrg )+, relation* )
| listPerson: ( headLike*, ( personLike | listPerson )+, relation* )
| listPlace: ( headLike*, ( placeLike | listPlace )+, relation* )
| listWit: ( headLike*, ( witness | listWit )+ )

In order to make nested lists work, it will likely prove useful to
have a type= attribute on the various list elements. Therefore I
would suggest adding and to att.typed.
I think is properly left out of this list and should remain
just (ptr+). But perhaps should be in this list, get added
to att.typed, and get a content model something like
listHand: ( headLike*, ( handNote | listHand )+ )
And lastly, are we happy saying that these things are not used for
transcription? If so, they're fine as they are. But those that need to
be used for transcription need to have model.global added all over,
e.g.:
listBibl: ( ( headLike | global )*, ( ( biblLike | listBibl ), global* )+ )

> > This would also mean changing places where listPerson and listOrg
> > are referenced to permit pLike as an alternative;
My initial reaction is that this is probably a good idea.

> > possibly moving some things currently permitted within listBibl
> > out of it;
The divTop and divBottom stuff don't seem to belong there, anyway.

> > moving listPlace out of the model.placeLike class.
On the face of it, seems like the right thing to do. (After all, a
list is not very placeLike, even if it does contain places.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 11 2007 - 19:37:51 EDT

From Syd_Bauman at Brown.edu Sat Aug 11 19:55:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 11 Aug 2007 19:55:14 -0400 Subject: [tei–council] choice, etc.––finally. In-Reply-To: <1186690016.5748.12.camel@localhost> Message-ID: <18110.19554.914244.572205@emt.wwp.brown.edu>
From: Syd Bauman
Date: Sat, 11 Aug 2007 19:55:14 -0400
> As far as I am aware there have been no objections to the
> reorganisation and modifications I proposed, which involved
True, but I don't remember seeing a proposal which had been tested
(i.e., been shaped into an ODD and proven to produce valid content
models, etc.) Did you post one that I missed? I've had some e-mail
problems, could you re-post a pointer to the proposal as it stands,
even w/o a full ODD? Thanks.

> ==Matthew's Proposals==
I'm sorry, I don't remember having read Matthew's proposal at the
moment. Could someone provide a pointer to it, too? Thanks.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 11 2007 - 19:55:19 EDT

From Syd_Bauman at Brown.edu Sat Aug 11 22:58:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 11 Aug 2007 22:58:21 -0400 (EDT) Subject: [tei-council] updated facsimile odd In-Reply-To: <1186697872.18890.295.camel@localhost> Message-ID: <200708120258.l7C2wL1w018109@draco.services.brown.edu>
From: Syd Bauman
Date: Sat, 11 Aug 2007 22:58:21 -0400 (EDT)
I have not been able to keep up with the facsimile thread while away,
but I just inadvertently noticed an item that I think deserves
mentioning. Apologies if this has already been discussed further but
I've missed something.

> At the very least I think that the documentation for
> data.outputMeasurement ... where it says that they are for
> "specifying the size of an object that is intended for display on
> the web", it should probably make it clear at that point that the
> size specified is the desired size of the display, not the size of
> the object itself. Currently, the sentence is ambiguous on that
> point.
Not that I really understand what the poster means by the terms
"object" and "display" here -- I could read more of the tread or
guess, but it doesn't really matter. It seems to me the documentation
for data.outputMeasurement should remain as neutral as possible about
*what* is being measured. That is a matter for the semantics of the
attribute which is declared to be of type data.outputMeasurement.
(Yes, I realize that the semantics of some of these units,
particularly "%", have to do with the relationship between an object
and the region in which it is situated, but that still seems to me to
be part of the semantics of the attribute, not the datatype.)
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Aug 11 2007 - 22:58:24 EDT

From lou.burnard at oucs.ox.ac.uk Sun Aug 12 17:09:05 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 12 Aug 2007 22:09:05 +0100 Subject: [tei-council] Re: listZZZ things In-Reply-To: <110069BB6C7D3C469B38E48E8A513FC204378F5C@svrshir060.gloscc.gov.uk> Message-ID: <46BF76F1.2010608@oucs.ox.ac.uk>
From: Lou Burnard
Date: Sun, 12 Aug 2007 22:09:05 +0100
COTHEY, Viv wrote:
> And mine (I think).
>
> Can I just check what is happening to which used to be in as a container for ? Unless this is a slip of the finger would seem no longer to be required.
>
Well, it's not completely a slip of the finger. particLinks seems pretty
redundant to me. Especially if we go with your suggestion of allowing
s promiscuously within s.
It seems tidier to put them all together, but since all the linking is
done by pointers there's no reason they can't just hang out wherever you
care to put them.

> I like what is being proposed for . But I would like it even more if I could have, say
>
>
>
>
>
>
>
>
>
>
>
>
>
> and not have to put all the s at the foot of the list which is my understanding of the effect of the straw proposal.
>
>
> Viv
>
>
>
> Viv Cothey
> Gloucestershire Archives
>
>
>> -----Original Message-----
>> From: Richard Light [mailto:richard_at_light.demon.co.uk]
>> Sent: 10 August 2007 12:38
>> To: Lou Burnard
>> Cc: TEI Council; tei-chars_at_maillist.ox.ac.uk
>> Subject: Re: listZZZ things
>>
>>
>> In message <46BB1A27.7050003_at_oucs.ox.ac.uk>, Lou Burnard
>> ox.ac.uk> writes
>>
>>> Here's a straw person proposal for bringing these content
>>>
>> models to heel:
>>
>>> listBibl: (headLike*, (biblLike|listBibl)+)
>>> listNym: (headLike*, (nym|listNym)+)
>>> listOrg: (headLike* (org|listOrg)+, relation*)
>>> listPerson: (headLike* (personLike|listPerson)+, relation*)
>>> listPlace: (headLike*, (placeLike|listPlace)+, relation*)
>>> listWit: (headLike*, (witness|listWit)+)
>>>
>> This would get my vote. Can anyone see loss of opportunity in this,
>> especially within listBibl?
>>
>> Richard
>>
>> --
>> Richard Light
>> SGML/XML and Museum Information Consultancy
>> richard_at_light.demon.co.uk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tei-chars-unsubscribe_at_maillist.ox.ac.uk
>> For additional commands, e-mail: tei-chars-help_at_maillist.ox.ac.uk
>>
>>
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Think before you print - only print this email if absolutely necessary.
>
> This email and any attachments are strictly confidential and intended for the addressee only.
> If you are not the named addressee you must not disclose, copy or take any action in
> reliance of this transmission and you should notify us as soon as possible.
>
> This email and any attachments are believed to be free from viruses but it is your
> responsibility to carry out all necessary virus checks and Gloucestershire County Council
> accepts no liability in connection therewith.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tei-chars-unsubscribe_at_maillist.ox.ac.uk
> For additional commands, e-mail: tei-chars-help_at_maillist.ox.ac.uk
>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Aug 12 2007 - 17:17:32 EDT

From lou.burnard at oucs.ox.ac.uk Mon Aug 13 06:24:07 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 13 Aug 2007 11:24:07 +0100 Subject: [tei-council] how about this one? Message-ID: <46C03147.5080403@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 13 Aug 2007 11:24:07 +0100
Looking around for a nice example for the facsimile section, I have hit
on a page in olde frenche which may make it a bit less accessible for
some TEI people, but it's nicely printed which should make it a lot more
accessible for others. And it's got bells on it.
If you share my fondness for this page, who'd like to volunteer to (a)
transcribe and mark it up (b) draw boxes on it and give it back ?
It's at http://www.tei-c.org/Drafts/Bouelles-49r.gif ... if you like it
I will contact the copyright holders.
I've corrected the draft to say that co-ordinates are counted from top
left rather than bottom left, but not made any other revision, pending
Dot's comments. So the numbers in the example are Wrong.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 13 2007 - 06:24:10 EDT

From laurent.romary at loria.fr Mon Aug 13 17:58:34 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 13 Aug 2007 23:58:34 +0200 Subject: [tei-council] how about this one? In-Reply-To: <46C03147.5080403@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Mon, 13 Aug 2007 23:58:34 +0200
At least, here's a first attempt of a "plain" (nearly absolutely bear
+ lb + pb)transcription. Can someone do something out of this?
Laurent

Le 13 ao?t 07 ? 12:24, Lou Burnard a ?crit :
> Looking around for a nice example for the facsimile section, I have
> hit on a page in olde frenche which may make it a bit less
> accessible for some TEI people, but it's nicely printed which
> should make it a lot more accessible for others. And it's got
> bells on it.
>
> If you share my fondness for this page, who'd like to volunteer to
> (a) transcribe and mark it up (b) draw boxes on it and give it back ?
>
> It's at http://www.tei-c.org/Drafts/Bouelles-49r.gif ... if you
> like it I will contact the copyright holders.
>
> I've corrected the draft to say that co-ordinates are counted from
> top left rather than bottom left, but not made any other revision,
> pending Dot's comments. So the numbers in the example are Wrong.
>
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council






...


...




...

...





De Geometrie.


DU SON ET ACCORD DES CLOCHES ET des
alleures des chevaulx, chariotz
& charges, des fontaines:&
encyclie du monde,
& de la dimension du corps humain.

Chapitre septiesme

Le son & accord des cloches
pendans en ung mesme
axe, est faict en contraires
parties.

LEs cloches ont quasi figures de
rondes pyramides
imperfaictes &
irregulieres: & leur accord se
fait par reigle geometrique.
Comme si les deux cloches C
& D sont pendans ? ung
mesme axe ou essieu A B:
ie dis que leur accord se fera
en c?‹traires parties c?me
voyez icy figur?. Car qu?d
lune sera en hault, laultre
declinera embas. Aultrement si elles
declinent toutes deux
ensembles en une mesme partie, elles
seront discord, &
sera leur sonnerie mal plaisante ?
oyr.




Le vray accord de deux cloches par
lattouchement des
bataulx, est faict diametralement. head>

CHascune cloche a deux divers
costez, entre lesquelz le
batail touche par diverses
fois. Et ? cause que laccord
de deux cloches se fait par
linclination delles en diverses
& contraires parties: Il fault
que ledict accord se
fasse diametralem?t.




G.j.







_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 13 2007 - 18:00:24 EDT

From conal.tuohy at vuw.ac.nz Mon Aug 13 18:20:27 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 14 Aug 2007 10:20:27 +1200 Subject: [tei-council] how about this one? In-Reply-To: <46C03147.5080403@oucs.ox.ac.uk> Message-ID: <1187043627.22294.3.camel@localhost>
From: Conal Tuohy
Date: Tue, 14 Aug 2007 10:20:27 +1200
Are there multiple images available of that same page?
I think it's a very nice example, but I also think that we should have
at least one example which uses multiple images (such as an additional
high-res detail image)

On Mon, 2007-08-13 at 11:24 +0100, Lou Burnard wrote:
> Looking around for a nice example for the facsimile section, I have hit
> on a page in olde frenche which may make it a bit less accessible for
> some TEI people, but it's nicely printed which should make it a lot more
> accessible for others. And it's got bells on it.
>
> If you share my fondness for this page, who'd like to volunteer to (a)
> transcribe and mark it up (b) draw boxes on it and give it back ?
>
> It's at http://www.tei-c.org/Drafts/Bouelles-49r.gif ... if you like it
> I will contact the copyright holders.
>
> I've corrected the draft to say that co-ordinates are counted from top
> left rather than bottom left, but not made any other revision, pending
> Dot's comments. So the numbers in the example are Wrong.
>
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 13 2007 - 18:20:37 EDT

From arianna.ciula at kcl.ac.uk Wed Aug 15 10:55:40 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 15:55:40 +0100 Subject: [tei-council] List of contributors to P5 In-Reply-To: <46AFE8B2.7040005@gmail.com> Message-ID: <46C313EC.1060007@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 15:55:40 +0100
Dear all,
I have just now finished reading the long thread of emails after my
holidays, so I'll start replying to the easiest thing.
Lou said he would have put a corrected list somewhere. I don't know
where he has out it, so here are the corrections I had for Christian's
lataest version:
Ariana --> Arianna
King's College --> King's College London

- ** TEI Personography Activity
Active Jan. 2006 - May 2007
I am not sure what is the criterion in including people here, but if we
have to list all the people that attended the place meeting in London we
should also add:
- Stuart Dunn, Methods Network
- Leif Isaksen, Oxford Archaeology
As Sebastian said, I think other people also participated to the two
personography meetings before the one in London, but I don't have a full
list myself.

Thank you,
Arianna
Christian Wittern wrote:
> Council members,
>
> Below is my list of contributors to P5. Please compare it to your
> memory or notes and alert me of any mistakes or omissions.
>
>
>
> * Council
>
> Chair:
> John Unsworth (Jan 2002 - Jun 2003)
> Christian Wittern (Jul 2003 - )
>
> Members
> non-elected
> John Unsworth 2002 - Jul 2003
> Julia Flanders 2004 - 2005
> Matthew Zimmerman 2006
> Daniel O'Donnell 2007 -
> Sebastian Rahtz 2002 -
> Lou Burnard 2002 -
> Syd Baumann 2002 -
>
> elected
> Christian Wittern 2002 -
> Perry Willett 2002 - 2005
> Geoffrey Rockwell 2002
> Merrilee Proffitt 2002 - 2003
> Matthew Driscoll 2002 -
> Arnamagn??an Institute, University of Copenhagen, Denmark
> David Durand 2002 - 2004
> Laurent Romary 2002 -
> David Birnbaum 2002 - 2004, 2006 -
> University of Pittsburgh djbpitt+@pitt.edu
> Toma?? Erjavec 2002 - 2004
> Fotis Jannidis 2002
> Martin Mueller 2002
> Peter Robinson 2002
> Alejandro Bia 2003 - Apr 2006
> Amit Kumar May 2006 - Dec 2006
> Susan Schreibman 2003 -
> Natasha Smith 2004 - 2005
> Edward Vanhoutte 2004 - 2005
> John Walsh 2005 -
> Indiana University
> James Cummings 2005 -
> Dot Porter 2006 -
> University of Kentucky dporter_at_uky.edu
> Conal Tuohy 2006 -
> New Zealand Electronic Text Centre Conal.Tuohy_at_vuw.ac.nz
> Tone Merete Bruvik 2007 -
> University of Bergen
> Ariana Ciula 2007 -
> King's College London
>
> * WGs
> ** TEI character set WG
> Active July 2001 to Jan. 2005
> Members
> * Christian Wittern, Kyoto University : chair
> * Deborah Anderson, Berkeley
> * Michael Beddow, Independent Scholar
> * David Birnbaum, Pittsburgh University
> * Robin Cover, OASIS/Isogen
> * Martin Duerst, W3C/Keio University
> * Patrick Durusau,Society of Biblical Literature
> * Tony McEnery, Lancaster University
> * Tomohiko Morioka, Kyoto University
> * Espen Ore, National Library of Norway
>
> ** TEI Meta task force
> Active Feb 2003 to Feb 2005
> Members:
> # Sebastian Rahtz (Chair)
> # Syd Bauman (editor, ex-officio)
> # Lou Burnard (editor, ex-officio)
> # Laurent Romary
> # David Durand
> # Alejandro Bia
> # Michael Sperberg-McQueen
> # Norman Walsh
> # Christian Wittern
>
> ** TEI Workgroup on Stand-Off Markup, XLink and XPointer
> Active Feb 2002 to Jan 2006
> Members:
> # DD David G. Durand (chair)
> # SB Syd Bauman
> # JC Jean Carletta
> # JH Jessica Hekman
> # NI Nancy M. Ide
> # FV Fabio Vitali
>
> ** MS Description Task Force
> Active Feb 2003 - December 2005
> Members:
> S. Bauman,
> D. Birnbaum,
> L. Burnard,
> M. Driscoll,
> M. Proffitt
>
> ** TEI Personography Activity
> Active Jan. 2006 - May 2007
> Members:
> Matthew Driscoll (Chair)
> Lou Burnard, Oxford University
> Sebastian Rahtz, Oxford University
> Syd Bauman, Brown University
> James Cummings, Oxford Text Archive
> Ariana Ciula, Kings College
> Tom Elliott, University of North Carolina at Chapel Hill
>
>
> ** Project on Internationalization and Localization
> Active Oct. 2005 -
> Sebastian Rahtz (Chair)
> Chinese Marcus Bingenheimer, Chung-hwa Institute of Buddhist Studies,
> Taipei
> French Jean-Luc Bemoit, ATILF
> German Werner Wegstein, Wuerzburg University
> Japanese Ohya Kazushi, Tsurumi University, Yokohama
> Spanish Carmen Arronis Llopis, University of Alicante
>
>
> * Hosts for Council Meetings
>
> 2002: Kings College, London
> 2003: Oxford University, Oxford
> 2004: Koninklijke Academie voor Nederlandse Taal- en Letterkunde, Ghent
> 2005: association fran??aise de normalisation, Paris
> 2006: Kyoto University, Institute for Research in Humanities, Kyoto
> 2007: Berlin-Brandenburgische Akademie der Wissenschaften, Berlin
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 10:55:33 EDT

From arianna.ciula at kcl.ac.uk Wed Aug 15 10:59:25 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 15:59:25 +0100 Subject: [tei-council] reduex In-Reply-To: <46B1A98E.2010808@computing-services.oxford.ac.uk> Message-ID: <46C314CD.7050706@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 15:59:25 +0100
Lou Burnard wrote:
> Assuming that we don't do (a), my recommendations are
>
> c, c-2, f
I agreed with this, but it is probably irrelevant now since things have
been tidied up by Syd (same for ).
Arianna
>
>
> Syd Bauman wrote:
>> LB> Really, I think the best solution is to bring back !
>> SB> [Maybe not best, but a good idea.]
>> SR> yes. it would seem much more honest to have as a
>> SR> container for text.
>> CW> Then let the MS people have their dimensions. Seems like a good
>> CW> compromise.
>>
>> OK, as I'm still waiting for votes for or agin (about which I
>> see Lou just posted) or more discussion on facsimile markup, I'll get
>> going on this presently.
>>
>>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 10:58:49 EDT
From arianna.ciula at kcl.ac.uk Wed Aug 15 11:01:39 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 16:01:39 +0100 Subject: [tei-council] rendition/rend proposal In-Reply-To: <71752389-E62B-46C6-B3A8-A9375402DD42@indiana.edu> Message-ID: <46C31553.4040904@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 16:01:39 +0100
Dear John,
I deduce from the minutes that your proposal has been approved and will
be integrated in the guidelines.
Some comments below:
-'To describe the rendition of any given element in the text, the global
rendition element points to one or more elements.' --> did
you mean 'the global rendition attribute points to one or more
elements.'
- I prefer 'scheme' to 'type'
- I don't know if a new attribute name has been chosen; @rendered
instead of @rendition sounded good to me or may be @declRend or @defRend?
Arianna
John A. Walsh wrote:
> Hi all,
>
> Here is a summary of the rend/rendition proposal. If we choose to adopt
> something along these lines, I can work with Lou and Syd to flesh it out.
>
>
>
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www:
> | Voice:812-856-0707 Fax:812-856-2062 edu>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 11:01:43 EDT
From arianna.ciula at kcl.ac.uk Wed Aug 15 12:31:52 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 17:31:52 +0100 Subject: [tei-council] facsimile diagram In-Reply-To: <1186124406.22202.121.camel@localhost> Message-ID: <46C32A78.4080205@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 17:31:52 +0100
Dear all,
I have tried to catch up with all the emails on the facsimile work, fist
on Conal and Dot's original proposal and than on Lou's draft and I am
sorry I wasn't able to contribute when needed.
To simplify things, I'll report first on the first draft (but only for
those things that I think are still relevant for the new draft, since we
don't want to waste time, I believe...) and then in my next email on the
new draft revised by Lou.
########## General structure and preference for stand-off ###########
I do like the model Conal proposed (facsimile/text). Between the two
examples of markup Conan quoted, I would prefer the second one or
stand-off sample, since it looks cleaner to me. [this relates to some
comments on the new draft to follow]
########## Avoid 'page' or make definitions more general ###########
SR> So please, don't tie us down to page breaks!
As said in Berlin I agree with this; however, the definition page breaks
(or begin...better) could be may be expanded to include scenarios where
we don't really have beginning of new pages as such, but new units (e.g.
gravestone surfaces, membranes of rolls etc...).
In my mind the was something conceptual rather then physical,
so I was also going to propose something more convoluted such as 'The
element represents a conceptual unit (page, membrane etc.) of
the source material that can have one or more physical realisations.',
but then I saw the discussion on coordinates and realised that it may be
better to highlight its physical character for practical reasons.
In general I would try to substitute 'page' with 'source unit' or
similar. [I have seen Lou has corrected this already in the new draft]
########### Relationship with ###########
CD>if graphic were added to the att.declaring class, it could use @decls
to point to a bibl that describes it
Agree. We should include the explicit relationship between
and the content of as Conan has explained it and ideally
should be added to the att.declaring class.
Arianna
Conal Tuohy wrote:
> On Fri, 2007-08-03 at 07:26 +0100, James Cummings wrote:
>> Conal Tuohy wrote:
>>> It's true I didn't mean to imply that a graphic could act as a zone - I
>>> don't think people should in general be linking bits of text to those
>>> graphics.
>> So really people should only be linking to and from zones generally.
>
> yes
>
>>> Within the same as the stamp's , there would be some
>>> elements, and if those graphics had @coords which overlapped
>>> the @coords of the stamp's zone, then those graphics would actually
>>> depict the stamp itself. Any of those associated graphics might be used
>>> to present a view of that zone. Obviously a graphic whose coords
>>> entirely enclosed the coords of the zone would be best (because it will
>>> show the full stamp), and a graphic whose resolution is higher will be
>>> better (if zooming), etc.
>> Ok, and if those graphic/@coords are relative to the surface, how do we on the
>> surface indicate what unit of measurement they are using? Surely a surface may
>> be measured in all sorts of units (millimetres, inches, metres,
>> kilometres,etc.)?
>
> Well, it's not really needed in order to align the graphics and the
> zones (all that's needed is that the units are consistent). But for
> documentary purposes, perhaps a surface's dimensions could be given
> using a element?
>
>> How do I know that one graphic is higher resolution than the
>> other? i.e. they both cover the same area of the surface "0 0 100 100" but one
>> was taken with a hi-res camera, and one was taken quite awhile ago with some
>> low-res camera. How is that resolution indicated?
>
> The 2 graphics may use @height and @width to indicate their intrinsic
> dimensions. The hi-res image should be higher and wider, despite having
> the same @coords as the equivalent lo-res image. The resolution of a
> graphic could be calculated by dividing the @width by the width as
> specified in the @coords (which says how much of the surface the graphic
> covers).
>
> But to be honest, rereading the documentation for @height, @width and
> @scale, I'm not entirely sure that I understand how @height and @width
> are supposed to work together with @scale.
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-graphic.html
>
> If I have an image which is 200px wide, I would expect to mark it up as
> a graphic with @width="200px", but what do I do with @scale? And what is
> the "desired display size" anyway? If I give @scale="2", I'd be saying
> that I wanted the image to be displayed as 400 pixels wide, which sounds
> like an odd thing to want to do.
>
> I'd be interested in seeing any examples of the use of @scale.
>
> As an alternative to calculations involving graphic/@height, etc,
> presentation software could choose among graphics on the basis of
> metadata encoded in a linked element. Could that be a
> useful approach?
>
> Con
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 12:31:56 EDT
From arianna.ciula at kcl.ac.uk Wed Aug 15 12:32:57 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 17:32:57 +0100 Subject: [tei-council] how about this one? In-Reply-To: <46C03147.5080403@oucs.ox.ac.uk> Message-ID: <46C32AB9.7020606@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 17:32:57 +0100
I hope I have read the right draft
(http://www.tei-c.org/Drafts/facs.odd). Below my comments.

########### introductory statement ###########
'And it may also be complemented by
a trancribed or encoded version of the original source, which may be
linked to the page images.'
I wander whether we could add the case where the objective of the
encoder is to comment the physical aspect of the source. It doesn't deal
with a real transcription or more traditional edition, but rather with a
commentary of codicological/pelograpohycal nature, where the interest is
still in aligning the explanatory text with the physical samples.
If people think this is a case for using the facsimile module, as i
hope, then I could provide a concrete example once the draft is approved.
########### direct/indirect use of @facs #######
As other people, I am not sure about the proposed direct an indirect use
of @facs, but don't want to throw fire so late...so will shut my mouth
up if it has been agreed upon.
########### dimensions of real objects #########
LB>Is there a negative too many in that sentence, or are you suggesting
we *should* include the dimensions of the original somewhere? and if so,
how?
Unless I am misunderstanding the discussion here, I don't think we
should include any dimension of a real object. We could have images of
an object that doesn't exist any more.
CW>Yes, lets have dimensions. As to the details, well... If we have a
serious of page-scans of the same size, it would surely be enough to
have one child on . Otherwise, if we have
elements to provide for multiple graphics, I'd suggest a
child there as well.
I thought this information should go in the or in general
in the header.
########## Manual alignment ###########
CD>I think when people are going to do a lot of alignment (such as aligning
each word), then they're more likely to be using some automated tools
anyway, so the extra markup overhead is not an issue. I could be wrong
about that, though. Perhaps you comment on that, Dot?
Well it depends which images you are dealing with. If we are talking
about manuscripts where not only lines of text overlap but words are not
properly separated there is no automated process that can help us
yet...unfortunately...such an OCR would be the dream of any manuscript
scholar.
######### stand-off ###########
CD>As a distinct benefit, dropping @coords (or @box) from textual elements
also makes for a cleaner separation between the facsimile and the text,
in that the text is not polluted with any "facsimilar" data, and the
facsimile is then "pure" standoff.
Agree!
######### false shortcut for ###########
CD>the simplification would have
come from facsimle graphics always having a parent, rather
than sometimes a and sometimes a
[...]
If so, we could restrict to only contain elements
(no s), each could be restricted to only contain
elements, and facsimile s would only ever be contained
in elements, while @facs could be restricted to point only to a
or (as a concessionary shortcut, for those people who can't
afford elements) directly to an image file.
Agree.
This would also avoid to have @box in and would avoid the
confusion between the as a conceptual container for a physical
unit (e.g. a page) and the actual that may consists of a fragment
of the source unit or coincide with the chosen unit itself. Things get
complex though, because I think would have to allow nesting.
To give a concrete example, since I would argue that, depending on the
interests of the encoder, the opening of a book could be considered a
where the wrapper could contain the for the
opening and two further s children (the two pages contained in
it), we could have:













######## Niggle ##########
- 'This might be a sheet of paper or parchment, a face of a monument, a
billboard, a scroll' --> '...a membrane of a scroll' because the whole
scroll would be the equivalent of a codex or a volume.
Arianna

Lou Burnard wrote:
> Looking around for a nice example for the facsimile section, I have hit
> on a page in olde frenche which may make it a bit less accessible for
> some TEI people, but it's nicely printed which should make it a lot more
> accessible for others. And it's got bells on it.
>
> If you share my fondness for this page, who'd like to volunteer to (a)
> transcribe and mark it up (b) draw boxes on it and give it back ?
>
> It's at http://www.tei-c.org/Drafts/Bouelles-49r.gif ... if you like it
> I will contact the copyright holders.
>
> I've corrected the draft to say that co-ordinates are counted from top
> left rather than bottom left, but not made any other revision, pending
> Dot's comments. So the numbers in the example are Wrong.
>
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 12:32:37 EDT

From arianna.ciula at kcl.ac.uk Wed Aug 15 12:44:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 15 Aug 2007 17:44:15 +0100 Subject: [tei-council] workplan In-Reply-To: <46B15680.10503@gmail.com> Message-ID: <46C32D5F.60406@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 15 Aug 2007 17:44:15 +0100
I have been assigned the following chapters for review:
15 Critical Apparatus ??
9 Manuscript Description ? (classes, maybe)
Now, I could edit the ODD for trivial stuff and make comments for the
editors for the rest as done in the past, but since I think the editors
are working/will work soon on these two chapters (DOD proposal for
etc. and business for manuscripts), could the editors
suggest whether is fine for me to read what we have on
tei.oucs.ox.ac.uk? whether I should wait? whether it doesn't really
matter and it is obvious I am just trying to postpone the task ;) ?
Thank you
Arianna
Christian Wittern wrote:
> Dear Council members,
>
> As promised yesterday and after discussion in the planning subcommittee
> (Daniel, Sebastian, Christian), here is the proposed work plan for the weeks
> to come:
>
>
> Overall timetable:
>
> Aug 4th: feature freeze (more or less)
> Aug 4th - September 7th: integration of proposed items (e.g. facsimile)
> in chapters and review (see below)
> September 11th - September 16th: final council review sessions
> we will put the chapters to vote 1 by 1
> September 15th - October 19th: all text locked for single master edit,
> assigned to Lou
> (at this point, I think it would be counter - productive to try
> to do cross-atlantic editing)
> September 15th - October 19th: final decisions about layout, publication,
> web site, assigned to Syd
> October 20th - October 30th: implementation of publication, assigned to
> Sebastian
>
>
> The details for the chapter triage are at
> http://tei.oucs.ox.ac.uk/trac/TEIP5/wiki/Review [1]
> one of the ideas behind this being that those who still carry stuff not
> integrated stuff (eg facsimile) will take ownership of that chapter for the
> month Aug 4 to Sep 7.
>
> The task assigned with the chapter review is as follows:
>
> Read thechapter again and fix anything which looks wrong. You can do this in
> one of two ways:
>
> - writing replacement lines/paragraphs/sections and sending them to Lou
> - editing the source ODD file in situ, if you are sure you know what
> they are doing
>
> Saying "this section looks wrong, it needs a rewrite" is only acceptable
> _in extremis_. If you edit the ODD, you will have to be extremely
> careful to work in a way which allows someone else to see
> the differences. Proposals for changes to the schema
> can be made, and recorded in trac for P5 1.1.
>
> All the best,
>
> Christian
>
>
> [1] The last column has more ? if the chapter is deemed to have more
> work to do, and a * if its vitally important that it be edited
>
>
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 15 2007 - 12:44:05 EDT
From conal.tuohy at vuw.ac.nz Wed Aug 15 18:47:35 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 16 Aug 2007 10:47:35 +1200 Subject: [tei-council] how about this one? In-Reply-To: <46C32AB9.7020606@kcl.ac.uk> Message-ID: <1187218055.22294.229.camel@localhost>
From: Conal Tuohy
Date: Thu, 16 Aug 2007 10:47:35 +1200
Hi Arianna
Just one point I wanted to pick up on from your email:
On Wed, 2007-08-15 at 17:32 +0100, Arianna Ciula wrote:
> Things get
> complex though, because I think would have to allow nesting.
I don't think this is true ... see below
> To give a concrete example, since I would argue that, depending on the
> interests of the encoder, the opening of a book could be considered a
> where the wrapper could contain the for the
> opening and two further s children (the two pages contained in
> it), we could have:
So this is a "double-page spread", right?
I agree that it should be possible to treat this as either 2 surfaces,
or as a single surface (with a crease down the middle ;-)
In your example, you've used nested zones, like so:













However, I don't think it's necessary to use nested zones to do this,
since presumably the areas defined by the @box attributes of the nested
zones "157v" and "158r" will fall within the area defined by the @box
attribute of the outer zone "op157-158". So the fact that the inner
zones are graphically part of the outer zone is already expressed using
the @box attributes and doesn't need to be redundantly expressed in the
nesting of XML elements.
I can see that nesting makes things more complicated for encoders, and
even introduces the possibility of a difference between the inter-zone
relationships expressed by the nesting, and those expressed by the @box
attributes. For instance: it may be that the outer zone (containing a
"double-page" graphic) has been cropped tightly to show only the 2
pages, whereas the 2 inner zones (containing graphics of each page
individually) might have substantial margins in which you can see a
strip of the bed of a book-scanner. In such a case, these zone/zone/@box
attributes might not fall entirely within the @box of their parent zone.
In such a case, would you encode the single-page zones inside the
double-page zone, or not? I don't think it's even helpful to pose this
conundrum, so I'd recommend a single, flat, list of zones, without
nesting.
Cheers
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 15 2007 - 18:47:48 EDT
From lou.burnard at computing-services.oxford.ac.uk Wed Aug 15 20:17:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 16 Aug 2007 01:17:53 +0100 Subject: [tei-council] how about this one? In-Reply-To: <1187218055.22294.229.camel@localhost> Message-ID: <46C397B1.2050807@computing-services.oxford.ac.uk>
From: Lou's Laptop
Date: Thu, 16 Aug 2007 01:17:53 +0100
I think I agree with Conal here. A zone defines some area within the
co-ordinate system defined by its parent surface. Nesting has no other
significance. If you allowed one zone to nest within another, the inner
zone would still have to define its area in terms of the co-ordinate
system defined by its grandparent surface. Therefore there is nothing to
be gained by nesting zones within each other. I considered other
possibilities for approx one nano second, before deciding that the
possible loss in prolixity was not worth the definite increase in
complexity.

Conal Tuohy wrote:
> Hi Arianna
>
> Just one point I wanted to pick up on from your email:
>
> On Wed, 2007-08-15 at 17:32 +0100, Arianna Ciula wrote:
>
>> Things get
>> complex though, because I think would have to allow nesting.
>>
>
> I don't think this is true ... see below
>
>
>> To give a concrete example, since I would argue that, depending on the
>> interests of the encoder, the opening of a book could be considered a
>> where the wrapper could contain the for the
>> opening and two further s children (the two pages contained in
>> it), we could have:
>>
>
> So this is a "double-page spread", right?
>
> I agree that it should be possible to treat this as either 2 surfaces,
> or as a single surface (with a crease down the middle ;-)
>
> In your example, you've used nested zones, like so:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> However, I don't think it's necessary to use nested zones to do this,
> since presumably the areas defined by the @box attributes of the nested
> zones "157v" and "158r" will fall within the area defined by the @box
> attribute of the outer zone "op157-158". So the fact that the inner
> zones are graphically part of the outer zone is already expressed using
> the @box attributes and doesn't need to be redundantly expressed in the
> nesting of XML elements.
>
> I can see that nesting makes things more complicated for encoders, and
> even introduces the possibility of a difference between the inter-zone
> relationships expressed by the nesting, and those expressed by the @box
> attributes. For instance: it may be that the outer zone (containing a
> "double-page" graphic) has been cropped tightly to show only the 2
> pages, whereas the 2 inner zones (containing graphics of each page
> individually) might have substantial margins in which you can see a
> strip of the bed of a book-scanner. In such a case, these zone/zone/@box
> attributes might not fall entirely within the @box of their parent zone.
> In such a case, would you encode the single-page zones inside the
> double-page zone, or not? I don't think it's even helpful to pose this
> conundrum, so I'd recommend a single, flat, list of zones, without
> nesting.
>
> Cheers
>
> Con
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 15 2007 - 20:17:58 EDT

From Syd_Bauman at Brown.edu Wed Aug 15 20:47:00 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 15 Aug 2007 20:47:00 -0400 Subject: [tei-council] how about this one? In-Reply-To: <46C397B1.2050807@computing-services.oxford.ac.uk> Message-ID: <18115.40580.387933.898415@emt.wwp.brown.edu>
From: Syd Bauman
Date: Wed, 15 Aug 2007 20:47:00 -0400
I'm not 100% sure I understand all the nuances (and I don't
understand what "prolixity" means in this context), but my instinct
is that Lou & Conal are right: so long as the area of coverage of a
is with respect to its closest ancestor , then
nesting a in a just causes confusion.
The question is whether it should be possible to define the area of
coverage of a with respect to its parent or
(as an alternative to its first ancestor ). Personally, I
think that would add way too much complexity for too little gain, and
that s should be left as they are.

> I think I agree with Conal here. A zone defines some area within the
> co-ordinate system defined by its parent surface. Nesting has no other
> significance. If you allowed one zone to nest within another, the inner
> zone would still have to define its area in terms of the co-ordinate
> system defined by its grandparent surface. Therefore there is nothing to
> be gained by nesting zones within each other. I considered other
> possibilities for approx one nano second, before deciding that the
> possible loss in prolixity was not worth the definite increase in
> complexity.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 15 2007 - 20:47:04 EDT

From arianna.ciula at kcl.ac.uk Thu Aug 16 05:06:18 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 16 Aug 2007 10:06:18 +0100 Subject: [tei-council] how about this one? In-Reply-To: <1187218055.22294.229.camel@localhost> Message-ID: <46C4138A.6010209@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 16 Aug 2007 10:06:18 +0100
I am convinced and thanks-you for the explanation. Does this also mean
that is better to have the @box attribute for ?
According to the example of images you had originally marked at
http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg,
assuming we are now adopting the new draft I would think that:
- what is marked there as surface is still surface, correct?
- what is marked there as graphic remains a but within a
(the outer zone)
- the zone elements remains such but will contain s
If the @box attributes alone can allow us to determine which zone is
inner and which is outer without the need to complicate things with
nesting, do we still need @box for ?
Sometimes the actual page of a codex doesn't correspond at all with the
what was original size of the page because of cropping, damage, invasive
restoration etc. and can be often reconstructed using old rules of
proportion between the extant textual mirror and the original width of
the margins. I can see a possible confusion here. Would my @box for
encode the coordinates of the current page based on the images
I have or the supposed size?
I am not trying to be pedantic here, but just to understand the rational
behind the proposed markup.
Arianna
Conal Tuohy wrote:
> Hi Arianna
>
> Just one point I wanted to pick up on from your email:
>
> On Wed, 2007-08-15 at 17:32 +0100, Arianna Ciula wrote:
>> Things get
>> complex though, because I think would have to allow nesting.
>
> I don't think this is true ... see below
>
>> To give a concrete example, since I would argue that, depending on the
>> interests of the encoder, the opening of a book could be considered a
>> where the wrapper could contain the for the
>> opening and two further s children (the two pages contained in
>> it), we could have:
>
> So this is a "double-page spread", right?
>
> I agree that it should be possible to treat this as either 2 surfaces,
> or as a single surface (with a crease down the middle ;-)
>
> In your example, you've used nested zones, like so:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> However, I don't think it's necessary to use nested zones to do this,
> since presumably the areas defined by the @box attributes of the nested
> zones "157v" and "158r" will fall within the area defined by the @box
> attribute of the outer zone "op157-158". So the fact that the inner
> zones are graphically part of the outer zone is already expressed using
> the @box attributes and doesn't need to be redundantly expressed in the
> nesting of XML elements.
>
> I can see that nesting makes things more complicated for encoders, and
> even introduces the possibility of a difference between the inter-zone
> relationships expressed by the nesting, and those expressed by the @box
> attributes. For instance: it may be that the outer zone (containing a
> "double-page" graphic) has been cropped tightly to show only the 2
> pages, whereas the 2 inner zones (containing graphics of each page
> individually) might have substantial margins in which you can see a
> strip of the bed of a book-scanner. In such a case, these zone/zone/@box
> attributes might not fall entirely within the @box of their parent zone.
> In such a case, would you encode the single-page zones inside the
> double-page zone, or not? I don't think it's even helpful to pose this
> conundrum, so I'd recommend a single, flat, list of zones, without
> nesting.
>
> Cheers
>
> Con
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 16 2007 - 05:06:52 EDT
From conal.tuohy at vuw.ac.nz Thu Aug 16 22:57:55 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 17 Aug 2007 14:57:55 +1200 Subject: [tei-council] how about this one? In-Reply-To: <46C4138A.6010209@kcl.ac.uk> Message-ID: <1187319475.22294.382.camel@localhost>
From: Conal Tuohy
Date: Fri, 17 Aug 2007 14:57:55 +1200
On Thu, 2007-08-16 at 10:06 +0100, Arianna Ciula wrote:
> I am convinced and thanks-you for the explanation. Does this also mean
> that is better to have the @box attribute for ?
>
> According to the example of images you had originally marked at
> http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg,
> assuming we are now adopting the new draft I would think that:
>
> - what is marked there as surface is still surface, correct?
> - what is marked there as graphic remains a but within a
> (the outer zone)
> - the zone elements remains such but will contain s
Yes, I think so.
> If the @box attributes alone can allow us to determine which zone is
> inner and which is outer without the need to complicate things with
> nesting, do we still need @box for ?
I don't think @box is needed for - at least, it isn't needed
merely to align textual transcriptions with facsimile images.
On the other hand, a surface/@box attribute WOULD allow you to model the
area of the physical page itself, though as you point out below, that
could itself be ambiguous...
> Sometimes the actual page of a codex doesn't correspond at all with the
> what was original size of the page because of cropping, damage, invasive
> restoration etc. and can be often reconstructed using old rules of
> proportion between the extant textual mirror and the original width of
> the margins. I can see a possible confusion here. Would my @box for
> encode the coordinates of the current page based on the images
> I have or the supposed size?
I would guess it would encode the size of the physical page you
transcribed. But I really don't know. If you wanted to encode the area
of the original surface (now lost to invasive restoration), you could
define a in that to represent the estimated area of the
original.
> I am not trying to be pedantic here, but just to understand the rational
> behind the proposed markup.
I think it's an interesting question.
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 16 2007 - 22:58:19 EDT
From cwittern at gmail.com Fri Aug 17 02:54:00 2007 From: cwittern at gmail.com (Christian Wittern) Date: Fri, 17 Aug 2007 15:54:00 +0900 Subject: [tei-council] CHANGED DATE: telecon now scheduled for 2007-08-31, 12:00 UTC (was: Re: Next teleconference Aug 24, 2007 1200 UTC) In-Reply-To: <46BBAE62.3000405@gmail.com> Message-ID: <46C54608.7030509@gmail.com>
From: Christian Wittern
Date: Fri, 17 Aug 2007 15:54:00 +0900
Council members,
Some more responses have come in via meetomatic (viewable at
http://www.meetomatic.com/responses.php?id=2J30GBI1A6KE), which make it more
desirable to choose Aug. 31 as the date for our next telecon, since we get
one more member on board: we loose David, but gain Conal and Laurent.
(Sorry, David -- I am counting only heads here!)
On top of that, I have no word from John Walsh, so I am not sure he will be
able to host our telecon if we do it next week.
So I would like to take the unusual step of changing the once-announced date
for the next telecon and move it to 2007-08-31 12:00 UTC. Please adjust
your diaries accordingly and sorry for this inconvenience.

All the best from record-setting hot Kyoto,
Christian

Christian Wittern wrote:
> Dear Council members,
>
>>From the responses (7 so far) meetomatic recommends Friday Aug. 24, so I
> would like to set that date for our meeting.
>
> I suggest that we ask John Walsh again to host the conference; the audio
> quality seemed to be much better this way.
>
> All the best,
>
> Christian
>
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 17 2007 - 02:54:29 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 23 18:48:30 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 23 Aug 2007 23:48:30 +0100 Subject: [tei-council] Questions regarding HD-The TEI Header In-Reply-To: <46BBEB0E.60207@gmail.com> Message-ID: <46CE0EBE.5000305@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 23 Aug 2007 23:48:30 +0100
Christian Wittern wrote:
> Council members,
>
> While working on my assignments for the new chapter triage, I came across
> the following questions:
>
> * Examples showing the teiHeader structure:
>
>
>
>
>
>
>
>
>
> These are looking as if they would be valid as empty elements. I wonder if
> it wouldn't be better to show them as
>
>
>
> ...
> ...
> ...
>
>
>
There are several places where XML comments have been lost from the
examples: I have corrected these and will look out for others.
> to enforce the point that they do not by itself form a valid TEI file.
>
>
> * model.sourceDescPart:
>
> There seem to be five different models for sourceDescPart:
>
> model.sourceDescPart = scriptStmt | recordingStmt
>
> model.sourceDescPart_sequence = scriptStmt, recordingStmt
>
> model.sourceDescPart_sequenceOptional = scriptStmt?, recordingStmt?
>
> model.sourceDescPart_sequenceOptionalRepeatable = scriptStmt*, recordingStmt*
>
> model.sourceDescPart_sequenceRepeatable = scriptStmt+, recordingStmt+
>
> (similar models are also defined for encodingDesc)
> under what conditions are which models activated?
>
>
This is a consequence of the "generate all possible models" design
decision for ODD, which we may wish to review.
On another matter, I noticed that the discussion of the
element implies the possibility of using non-standard values for e.g.
date valued attributes. Since the schemas don't permit this, I wonder
whether there is any point in retaining this element. I've retained it
for the moment, but reworded as follows to make clear that it's not in
general a good idea...

In most cases, attributes bearing standardized values (such as the
when or when-iso attribute on dates) should
conform to a defined W3C or ISO
datatype. In cases where this is not appropriate, this element may be
used to describe the standardization methods underlying the values
supplied.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 23 2007 - 18:50:37 EDT

From cwittern at gmail.com Fri Aug 24 20:38:35 2007 From: cwittern at gmail.com (Christian Wittern) Date: Sat, 25 Aug 2007 08:38:35 +0800 Subject: [tei-council] next Council telecon scheduled for Aug 31, 1200 UTC Message-ID: <5268d87d0708241738l271b1b27k705fa0846f9a898c@mail.gmail.com>
From: Christian Wittern
Date: Sat, 25 Aug 2007 08:38:35 +0800
Dear Council members,
This is just a reminder that our next telecon is scheduled to be held
next Friday, Aug 31.
We are now well into our final leg in the preparations that should
lead up to having P5 ready for final editing. All open tasks,
including those tentatively accepted into P5 at the last meeting, will
have to show considerable progress and the potential to be completed
within the timeframe to move along.
One of the main functions of the upcoming meeting will be to make the
necessary re-adjustments where they prove to be necessary.
So please check out the open tasks assigned to you, including the
chapter triage (http://tei.oucs.ox.ac.uk/trac/TEIP5/wiki/Review) and
try to get as much done as possible *before* the meeting, preferably
in time to show us the results.
If there are any other issues that needs discussion, please drop me a
line so that I can put them on the agenda.
All the best,
Christian
-- Christian Wittern, Kyoto _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 24 2007 - 20:38:38 EDT
From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 26 19:01:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 00:01:29 +0100 Subject: [tei-council] facsimile Message-ID: <46D20649.1090901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 00:01:29 +0100
staring at the correspondence, I tried to make sense of it by converting
some of my own work. I find a situation where I have a record of
a facsimile, but not an image of it. That is to say, I know the
catalogue number of the photograph, but don't have a JPEG.
Do people think I should be using some other markup
entirely, or using in some way? I know msdesc
has its , but as usual that's so bound up in
over-specific manuscript language I want to steer clear of it....
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Aug 26 2007 - 19:01:32 EDT
From conal.tuohy at vuw.ac.nz Mon Aug 27 00:11:32 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 27 Aug 2007 16:11:32 +1200 Subject: [tei-council] facsimile In-Reply-To: <46D20649.1090901@oucs.ox.ac.uk> Message-ID: <1188187892.3176.56.camel@localhost>
From: Conal Tuohy
Date: Mon, 27 Aug 2007 16:11:32 +1200
On Mon, 2007-08-27 at 00:01 +0100, Sebastian Rahtz wrote:
> staring at the correspondence, I tried to make sense of it by converting
> some of my own work. I find a situation where I have a record of
> a facsimile, but not an image of it. That is to say, I know the
> catalogue number of the photograph, but don't have a JPEG.
>
> Do people think I should be using some other markup
> entirely, or using in some way?
I think that much of the facsimile markup could still be useful, even in
the absence of any facsimile images. If you use it to encode the
position of pieces of text on the page, then you can use that
information to produce a "print facsimile". As an example, you may
remember the HTML "print facsimile" I showed off in Berlin. This demo
took the coordinates expressed in the TEI markup, and transformed them
to CSS attributes to precisely position the HTML elements on a web page.
But if you don't have a digital image to hand, chances are that you also
won't have established the coordinates of the textual elements anyway (I
imagine).
If you don't have digital images or coordinates, then I think the only
advantage you'd get from using is being able to associate
individual pages with their surrogate images (I don't think you can do
this with ). On the other hand, allows for the
use of to point to the surrogates, whereas with
facsimile/surface/zone/graphic you only have a @url attribute. I don't
know if you'd be able to sensibly wedge your catalogue numbers into @url
attributes (perhaps using "info" URLs? or OpenURL?).
> I know msdesc
> has its , but as usual that's so bound up in
> over-specific manuscript language I want to steer clear of it....
>
-- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 00:11:39 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 06:32:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 11:32:12 +0100 Subject: [tei-council] facsimile In-Reply-To: <1188187892.3176.56.camel@localhost> Message-ID: <46D2A82C.6070003@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 11:32:12 +0100
Conal Tuohy wrote:
> If you don't have digital images or coordinates, then I think the only
> advantage you'd get from using is being able to associate
> individual pages with their surrogate images (I don't think you can do
> this with ).
indeed. and I can also use the thing, since I am dealing with
multi-surface originals (gravestones) with zones on them. I am wondering
if I could say





...




...






i.e. I would not record coordinates at all for , but rely
on the
From lou.burnard at oucs.ox.ac.uk Mon Aug 27 07:30:01 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 27 Aug 2007 12:30:01 +0100 Subject: [tei-council] facsimile In-Reply-To: <46D20649.1090901@oucs.ox.ac.uk> Message-ID: <20070827113001.1B336EB08E@webmail221.herald.ox.ac.uk>
From: Lou Burnard
Date: Mon, 27 Aug 2007 12:30:01 +0100
If you dont have an image you shouldn't be using in my view. I
wondered whether the generality of the word "surface" was going to cause
problems, and the subsequent messages on this thread confirm it.
a is an object composed of *images*, NOT data about images (that
belongs in the header), NOT data about objects (we mostly don't have a home for
that). A contains data about an *image of a surface*, NOT data about
the original surface.
This is meant to be a simple well-defined solution to a known problem, not a
general catch all.

In message <46D20649.1090901_at_oucs.ox.ac.uk> Sebastian Rahtz
ox.ac.uk> writes:
> staring at the correspondence, I tried to make sense of it by converting
> some of my own work. I find a situation where I have a record of
> a facsimile, but not an image of it. That is to say, I know the
> catalogue number of the photograph, but don't have a JPEG.
>
> Do people think I should be using some other markup
> entirely, or using in some way? I know msdesc
> has its , but as usual that's so bound up in
> over-specific manuscript language I want to steer clear of it....
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 27 2007 - 07:30:03 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 07:35:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 12:35:48 +0100 Subject: [tei-council] facsimile In-Reply-To: <20070827113001.1B336EB08E@webmail221.herald.ox.ac.uk> Message-ID: <46D2B714.50901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 12:35:48 +0100
Lou Burnard wrote:
> If you dont have an image you shouldn't be using in my view.
I do have an image, though. It's just not available electronically.
> a is an object composed of *images*, NOT data about images (that
> belongs in the header)
where? can you give an example?
> NOT data about objects (we mostly don't have a home for
> that). A contains data about an *image of a surface*, NOT data about
> the original surface.
I suggest that Joe in the street will find this sophistry as hard to
grasp as I do....
Regardless, I still think and would benefit from
From lou.burnard at oucs.ox.ac.uk Mon Aug 27 07:35:01 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 27 Aug 2007 12:35:01 +0100 Subject: [tei-council] facsimile In-Reply-To: <46D2A82C.6070003@oucs.ox.ac.uk> Message-ID: <20070827113501.CA45DEB32A@webmail221.herald.ox.ac.uk>
From: Lou Burnard
Date: Mon, 27 Aug 2007 12:35:01 +0100
In message <46D2A82C.6070003_at_oucs.ox.ac.uk> Sebastian Rahtz
ox.ac.uk> writes:
> Conal Tuohy wrote:
> > If you don't have digital images or coordinates, then I think the only
> > advantage you'd get from using is being able to associate
> > individual pages with their surrogate images (I don't think you can do
> > this with ).
No, you can too associate a with an image of it, using the @facs
attribute!
But since Sebastian doesn't have any images, I don't see the relevance of this
remark anyway.

> indeed. and I can also use the thing, since I am dealing with
> multi-surface originals (gravestones) with zones on them. I am wondering
> if I could say
>
>
>
>
>
>
> ...
>
>
>
>
> ...
>
>
>
>
>
>
>
> i.e. I would not record coordinates at all for , but rely
> on the

This is major tag abuse. Count yourself lucky it's a bank holiday so I can't
send the men with the funny waistcoats round.

>
> To achieve this, I would need
>
> *
> * added to content model of and
>
> I suggest that these would be generally useful anyway.
>
At a stretch I could see a case for

> In general, where do you suggest we store technical information
> about the image referred to by ?
> ie date, lighting conditions, method (infra-red, b/w),
> photographer etc.
METS. In the header.

>
> Or am I moving into other territory?
>
Looks like injun country to me.

> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 27 2007 - 07:51:40 EDT

From lou.burnard at oucs.ox.ac.uk Mon Aug 27 07:40:22 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 27 Aug 2007 12:40:22 +0100 Subject: [tei-council] facsimile In-Reply-To: <46D2B714.50901@oucs.ox.ac.uk> Message-ID: <20070827114022.83859EB0E3@webmail221.herald.ox.ac.uk>
From: Lou Burnard
Date: Mon, 27 Aug 2007 12:40:22 +0100
In message <46D2B714.50901_at_oucs.ox.ac.uk> Sebastian Rahtz
ox.ac.uk> writes:
> Lou Burnard wrote:
> > If you dont have an image you shouldn't be using in my view.
> I do have an image, though. It's just not available electronically.
for "image", read "digital image" then.
> > a is an object composed of *images*, NOT data about images (that
> > belongs in the header)
> where? can you give an example?
you could have a listBibl containing bibls most places, and not necesarily in
the Header.
I think what you're trying to do is create a listBibl with rather specialised
content.

> > NOT data about objects (we mostly don't have a home for
> > that). A contains data about an *image of a surface*, NOT data about
> > the original surface.
> I suggest that Joe in the street will find this sophistry as hard to
> grasp as I do....
Then we have to try harder. It's not sophistry: it's surprisingly similar to the
difference between e.g. and
>
> Regardless, I still think and would benefit from
> and .
>
> --
> Sebastian Rahtz
>
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 27 2007 - 07:54:27 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 09:00:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 14:00:35 +0100 Subject: [tei-council] facsimile In-Reply-To: <20070827113501.CA45DEB32A@webmail221.herald.ox.ac.uk> Message-ID: <46D2CAF3.9030308@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 14:00:35 +0100
Lou Burnard wrote:
> This is major tag abuse.
>
its only tag abuse when the semantics of the tags are agreed, tho!
>> In general, where do you suggest we store technical information
>> about the image referred to by ?
>> ie date, lighting conditions, method (infra-red, b/w),
>> photographer etc.
>>
>
> METS. In the header.
>
that's called "punting". _where_ in the header?
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 09:00:39 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 10:03:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 15:03:12 +0100 Subject: [tei-council] more on facsimile Message-ID: <46D2D9A0.5000509@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 15:03:12 +0100
in Lou's current draft, we have, eg



In this, I find the use of @box on both
and confusing. One establishes the limits of a grid, the
other specifies an area within that grid. The description
of @box covers the latter case:
"identifies a rectangular area or bounding box by specifying
four numbers, which give the x,y co-ordinates of the box's upper left
corner, followed by the x,y co-ordinates of its lower right
corner."
The @box on should really be ,
I suggest. Then you can add @width and @height to specify the absolute
size of the original if desired (though then the semantics differs
from @width and @height on ).
In fact, I think I'd go further and drop @box in favour of
@llx, @lly, @urx and @ury. Better syntax checking. Use
the power of XML.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 10:03:16 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 11:41:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 16:41:44 +0100 Subject: [tei-council] testing facsimile Message-ID: <46D2F0B8.3010102@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 16:41:44 +0100
I have tried to apply the current draft to a real life example,
a picture of a WW1 gravestone I took near Thiepval a couple
of weeks ago. Can people confirm that this is how it should be used?
I define a single surface with an associated image, then some
zones within it. Four of those are used to link lines
of transcribed text, and the other is used to describe a closeup
of part of the object; only the latter has its own extra .
The @xdim and @ydim on are the result of a
longish discussion I just had with Lou about the relationship
between the image, which shows more than the gravestone,
and the object visible therein. The @xdim and @ydim define
the grid on which all child s depend; the @box on
describes the surface area.
Now I have to attempt an HTML rendering ....
PS no, Private Moulds is not a relative, I just picked him
at random.

xdim="1024"
ydim="681"
box="6 354 336 914">













Private Moulds' gravestone



12851 PRIVATE
H. MOULDS
NORTHAMPTONSHIRE REGT.
23RD JULY 1916 AGED 21




-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 11:41:49 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 13:12:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 18:12:41 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <46D2F0B8.3010102@oucs.ox.ac.uk> Message-ID: <46D30609.7010901@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 18:12:41 +0100
following on my earlier example, I have managed
to write a trivial application to use this data, visible at
http://users.ox.ac.uk/~rahtz/testtransc.html
If you mouseover the lines of the inscription, you should
get a popup with the transcribed text in.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 13:12:46 EDT
From lou.burnard at oucs.ox.ac.uk Mon Aug 27 13:41:58 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 27 Aug 2007 18:41:58 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <46D2F0B8.3010102@oucs.ox.ac.uk> Message-ID: <46D30CE6.8000206@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 27 Aug 2007 18:41:58 +0100
Sebastian Rahtz wrote:
> I
>
> The @xdim and @ydim on are the result of a
> longish discussion I just had with Lou about the relationship
> between the image, which shows more than the gravestone,
> and the object visible therein. The @xdim and @ydim define
> the grid on which all child s depend; the @box on
> describes the surface area.
Now implemented. But I decided to call them xMax and yMax instead.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 27 2007 - 13:42:02 EDT

From arianna.ciula at kcl.ac.uk Mon Aug 27 15:09:12 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 27 Aug 2007 20:09:12 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <46D30CE6.8000206@oucs.ox.ac.uk> Message-ID: <46D32158.4020703@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 27 Aug 2007 20:09:12 +0100
Lou Burnard wrote:
> Sebastian Rahtz wrote:
>> I
>>
>> The @xdim and @ydim on are the result of a
>> longish discussion I just had with Lou about the relationship
>> between the image, which shows more than the gravestone,
>> and the object visible therein. The @xdim and @ydim define
>> the grid on which all child s depend; the @box on
>> describes the surface area.
>
> Now implemented. But I decided to call them xMax and yMax instead.
Si, if I understand well, xmax and yMax should give the whole
coordinated for the considered as the 'total' digital image
(e.g. a page of a manuscript that includes a scale and scanning plan);
while the box attribute describes the section of interest within it
(e.g. the page as unit of analysis). Correct?
I think Sebastian's example is a good one to show a straight forward use
(works with ie by the way, but not with firefox); although my thought
went straight to more complex cases of the Ecole des Charters dossiers
on paleography (e.g. http://theleme.enc.sorbonne.fr/dossiers/vue1.php).
Arianna
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 15:08:38 EDT
From lou.burnard at oucs.ox.ac.uk Mon Aug 27 15:16:36 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 27 Aug 2007 20:16:36 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <46D32158.4020703@kcl.ac.uk> Message-ID: <46D32314.8050800@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 27 Aug 2007 20:16:36 +0100
Arianna Ciula wrote:
>
>
> Lou Burnard wrote:
>> Sebastian Rahtz wrote:
>>> I
>>>
>>> The @xdim and @ydim on are the result of a
>>> longish discussion I just had with Lou about the relationship
>>> between the image, which shows more than the gravestone,
>>> and the object visible therein. The @xdim and @ydim define
>>> the grid on which all child s depend; the @box on
>>> describes the surface area.
>>
>> Now implemented. But I decided to call them xMax and yMax instead.
>
> Si, if I understand well, xmax and yMax should give the whole
> coordinated for the considered as the 'total' digital image
> (e.g. a page of a manuscript that includes a scale and scanning plan);
> while the box attribute describes the section of interest within it
> (e.g. the page as unit of analysis). Correct?
>
perfetto!
I have just checked in a new version of the PH chapter, which hopefully
makes this a bit clearer by way of two simple examples. Should be
visible at
http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/PH.html#FAX shortly.
> I think Sebastian's example is a good one to show a straight forward
> use (works with ie by the way, but not with firefox); although my
> thought went straight to more complex cases of the Ecole des Charters
> dossiers on paleography (e.g.
> http://theleme.enc.sorbonne.fr/dossiers/vue1.php).
>
> Arianna
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Aug 27 2007 - 15:16:39 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 27 15:22:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Aug 2007 20:22:20 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <46D32158.4020703@kcl.ac.uk> Message-ID: <46D3246C.2040008@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 27 Aug 2007 20:22:20 +0100
Arianna Ciula wrote:
>
> Si, if I understand well, xmax and yMax should give the whole
> coordinated for the considered as the 'total' digital image
> (e.g. a page of a manuscript that includes a scale and scanning plan);
> while the box attribute describes the section of interest within it
> (e.g. the page as unit of analysis). Correct?
yes. seems to make sense in practice. @box on is a shortcut for
a describing the physical page limits in the photo.
>
> I think Sebastian's example is a good one to show a straight forward
> use (works with ie by the way, but not with firefox); although my
> thought went straight to more complex cases of the Ecole des Charters
> dossiers on paleography (e.g.
> http://theleme.enc.sorbonne.fr/dossiers/vue1.php).
yes, identical technique. you could probably take that example
and reverse-engineer it to TEI quite easily (if they have
appropriate licence for the image).
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Aug 27 2007 - 15:22:28 EDT
From sebastian.rahtz at oucs.ox.ac.uk Wed Aug 29 12:25:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 29 Aug 2007 17:25:50 +0100 Subject: [tei-council] testing facsimile In-Reply-To: <96f3df640708290627t3d562bc5xfb3a779a848f48a2@mail.gmail.com> Message-ID: <46D59E0E.6090204@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Wed, 29 Aug 2007 17:25:50 +0100
Dot Porter wrote:
> It should be possible to create an XSLT that will output this new
> markup from @coords-bearing elements, or to take a file using the new
> system and make it into a file with @coords-bearning elements.
you mean go from

...
...
to
..
yes, I guess that would be very easy.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Aug 29 2007 - 12:25:42 EDT
From cwittern at gmail.com Wed Aug 29 21:45:07 2007 From: cwittern at gmail.com (Christian Wittern) Date: Thu, 30 Aug 2007 10:45:07 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on Aug 31, 2007 at 1200 UTC Message-ID: <46D62123.6000800@gmail.com>
From: Christian Wittern
Date: Thu, 30 Aug 2007 10:45:07 +0900
DRAFT Agenda for the TEI Council teleconference on Aug 31, 2007 at 1200 UTC
Expected to participate:
Syd Bauman, Tone Merete Bruvik, Lou Burnard, Arianna
Ciula, James Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter,
Sebastian Rahtz Laurent Romary, Conal Tuohy, John Walsh, Christian
Wittern
ent apologies: David Birnbaum

============================================================
How to connect:
Phone Number: (812) 856-3600
PIN: 000920#
For conferencing assistance please call 812-855-4848.
(this is copied from the last meeting.
@John: please correct if this is wrong)
============================================================
The purpose of this meeting is to see how things are coming along with
respect to the timetable agreed upon at the last meeting and
to remove any road-blocks that might have appeared.
============================================================
1) Open action items
* We will look at the open action items from the last meeting
at http://www.tei-c.org/Council/tcm33.xml?style=printable
* Chapter triage
http://tei.oucs.ox.ac.uk/trac/TEIP5/wiki/Review
2) next meeting
Mid September ?

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Aug 29 2007 - 21:45:24 EDT

From lou.burnard at oucs.ox.ac.uk Thu Aug 30 06:34:11 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 30 Aug 2007 11:34:11 +0100 Subject: [tei-council] Report on actions. so far Message-ID: <46D69D23.6090505@oucs.ox.ac.uk>
From: Lou Burnard
Date: Thu, 30 Aug 2007 11:34:11 +0100
A brief report on the actions assigned to me/eds in the minutes tcm33.xml:
1. (titlepage) Syd seems to have done this already
2. (workgroup members list) Not done. I started, but got distracted.
4. (rendition) Not done yet.
6. (facsimile) Done.
8. (nonhierarchic) Nothing done on this by me yet, but I think Syd has
started on it.
9. (dictionary) Nothing done yet
10. (FSD/R) I am still waiting for feedback on outcome of ISO meeting;
am in touch with new editor of the ISO FSD draft but he seems to think
he wont start till mid September (!)
13 (transcription) I am working on a thorough revision of PH, to include
as many as possible of the known problems in this area. See below for
details
19 (stemmata) Not done yet
20 (handlist/note) Done
The revision of PH so far addresses the following issues
(a) confusion about what means -- word or string
(b) lots of stuff left over from P3 (e.g. use of entity refs rather than
)
I plan also to grasp the following nettle
(c) confusion about what means -- scribal or editorial?
You can see what changes have been made so far by looking in the usual
places (on SourceForge for the source, on tei.oucs.ox.ac.uk/Guidelines/
for the rendering)
This is taking longer than anticipated, so I fear there won't be time
left to do much about the more sweeping revisions proposed by Daniel but
I'll take another look at them when I get to the end of the chapter.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 30 2007 - 06:34:15 EDT

From arianna.ciula at kcl.ac.uk Thu Aug 30 12:53:48 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 30 Aug 2007 17:53:48 +0100 Subject: [tei-council] notes on TC Critical apparatus Message-ID: <46D6F61C.5030503@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 30 Aug 2007 17:53:48 +0100
Dear council,
I have read the Critical Apparatus chapter, edited the minimal straight
forward mistakes in the prose and send it back to the editors.
These are just my additional notes for things that could be changed, but
that I haven't done:
- "N.B. the term lemma is used here in the text-critical sense of ???the
reading accepted as that of the original or of the base text??? ??? it is
not to be confused with ???the heading of an entry in a reference book,
especially a dictionary, nor with ???a subsidiary proposition introduced
in the proof of some other proposition; a helping theorem.???"
I would also add:
"...it is not to be confused with ???the heading of an entry in a
reference book, especially a dictionary,??? *nor with ???the word's lemma???*,
nor with ???a subsidiary proposition ..."
- I am not sure why the element has att.placement. Its
purpose isn't to encode the information about a witness as recorded in
the source (therefore least of all where in the source), is it? or am I
missing something?
- the attribute @with has as data type 'data.pointer' when within the
class att.textCritical or att.rdgPart, but has data type 'data.code'
when it is used as attribute of . I can see a possible reason
for this, but I thought I pointed it out if we are aiming to get rid of
these inconsistencies as much as possible.
- "Of course, the sigla used for different witnesses need not be the
same in the source and the wit attribute, as shown particularly in the
apparatus for the second line of the poem (Diet.1.2)."
Do we mean here: "Of course, the sigla used for different witnesses need
not be the same in the * element* and the @wit attribute, as shown
particularly in the apparatus for the second line of the poem (Diet.1.2)."?
- "For examples of this element, see the following sections. The formal
declaration is given in section 2.3.3 The Editorial Practices Declaration."
Shouldn't this point to 2.3.9 The Variant-Encoding Method Element?
- " location="external"/>
"
This is the only example where the is commented out.
- "
Experience
Experiment
Eryment
"
If this example is still referring to the internal location of the
apparatus and it is only an alternative to the example above, I don't
understand why is using the @to attribute to point to an anchor in the text.
- the example with should be substituted with now,
shouldn't it?
Best,
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Aug 30 2007 - 12:53:08 EDT
From Syd_Bauman at Brown.edu Thu Aug 30 13:52:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 30 Aug 2007 13:52:36 -0400 Subject: [tei-council] notes on TC Critical apparatus In-Reply-To: <46D6F61C.5030503@kcl.ac.uk> Message-ID: <18135.996.532150.756983@emt.wwp.brown.edu>
From: Syd Bauman
Date: Thu, 30 Aug 2007 13:52:36 -0400
> I have read the Critical Apparatus chapter, edited the minimal
> straight forward mistakes in the prose and send it back to the
> editors.
I've checked that Arianna's version does not cause any invalidities
in the Guidelines, and committed it to Sourceforge.

I haven't looked at Arianna's additional notes carefully, yet.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Aug 30 2007 - 13:52:40 EDT

From Conal.Tuohy at vuw.ac.nz Fri Aug 31 07:58:31 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 31 Aug 2007 23:58:31 +1200 Subject: [tei-council] testing facsimile In-Reply-To: <46D2F0B8.3010102@oucs.ox.ac.uk> Message-ID: <75CF552F30ECFA439D9B3008906F2A3701ABABEC@STAWINCOMAILCL1.staff.vuw.ac.nz>
From: Conal Tuohy
Date: Fri, 31 Aug 2007 23:58:31 +1200
-----Original Message-----
From: tei-council-bounces_at_lists.village.Virginia.EDU on behalf of Sebastian Rahtz
Sent: Tue 28/08/07 3:41
To: TEI Council
Subject: [tei-council] testing facsimile

> I have tried to apply the current draft to a real life example,
> a picture of a WW1 gravestone I took near Thiepval a couple
> of weeks ago. Can people confirm that this is how it should be used?
>
> I define a single surface with an associated image, then some
> zones within it. Four of those are used to link lines
> of transcribed text, and the other is used to describe a closeup
> of part of the object; only the latter has its own extra .
That's all good as far as I can see. But what I don't understand is why you wouldn't nest the other in its own , i.e.

xdim="1024"
ydim="681">












instead of

xdim="1024"
ydim="681"
box="6 354 336 914">










Note that in the markup I prefer, above, has a more rigid ("crystal") structure, in that a zone is always a child of a surface, and a graphic must always be nested inside a zone. So in this example the two facsimile images are encoded with parallel markup, the only difference being that one of the zones has an xml:id so it can be linked to from the transcript.
> The @xdim and @ydim on are the result of a
> longish discussion I just had with Lou about the relationship
> between the image, which shows more than the gravestone,
> and the object visible therein. The @xdim and @ydim define
> the grid on which all child s depend; the @box on
> describes the surface area.
That seems reasonable. Though shouldn't the @xdim and @ydim values of the then match the maximal coordinates in the @box attributes of the children?
Con
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Aug 31 2007 - 07:58:57 EDT
From laurent.romary at loria.fr Fri Aug 31 07:58:00 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 31 Aug 2007 13:58:00 +0200 Subject: [tei-council] Comments - Using the TEI Message-ID:
From: Laurent Romary
Date: Fri, 31 Aug 2007 13:58:00 +0200
Replace [The wording is probably too strong and may frighten users]
" For these reasons, it is almost impossible to use the TEI scheme
without customizing or personalizing it in some way." by
" For these reasons, a first step in using the TEI scheme is to
customize or personalize it in some way."
Replace [The corresponding paragraph is quite essential and could be
quoted in isolation]
" Formally speaking, these Guidelines" by
" Formally speaking, the TEI Guidelines"
[First series]
Question: does the definition of "clean" (imposing the reference to
elements in the TEI namespace) implies that any TEI+SVG combination
(or TEI+MathML, or...) is unclean right from the start?
In section 24.2.1.1 (Deletion of elements) nothing is said about how
users can know which element is mandatory. Should we do something
about this?
Replace [section 24.2.1.4]
"" by
"@source"
In the example [section 24.2.1.4], could not we have a policy about
using dummy namespaces: http://www.hatstand.org/ does exist and has
nothing to do with the TEI... I gues we should use http://
www.example.com/ns
Replace [just incompatible with the definition of "clean"!]
"The set of documents matched by a schema generated from an ODD
modified in this way, and the set of documents matched by the
unmodified schema may be related in several different ways. It is
certainly possible that the former could properly include the latter
or vice versa; either of these could be said to be clean
modifications because the set to be matched has become strictly
larger or strictly smaller. But it is more likely that such
modifications will be unclean." by
"The set of documents matched by a schema generated from an ODD
modified in this way, and the set of documents matched by the
unmodified schema may be related in several different ways. It is
certainly possible that the latter could properly include the former;
which could be said to be a clean modification because the set to be
matched has become strictly smaller. But it is more likely that such
modifications will be unclean."
A question, which may have been discussed already... : why don't we
use the 'mode' attribute on (adding a class, deleting a
class, etc.), possibly having more than one declaration.
This would make the thing more in line with the other modification
mechanisms.
I am not sure about this sentence [section 24.2.1.5 - again, may be
not compliant with the notion of cleanliness]:
" Adding a new attribute to a class however can be a clean
modification only if the new attribute is labelled as belonging to
some namespace other than the TEI."
Replace (wrong use of namespace syntax):
"


Flopsy, Mopsy, Cottontail, and
Peter...


" by
"


Flopsy, Mopsy, Cottontail, and
Peter...


"
Again, I am not sure about the sentence: "Since topic is explicitly
labelled as belonging to something other than the TEI namespace, we
regard the modification which introduced it as clean." We should
discuss this at the Tekon (cf. note 112 ? If this is true, I have no
problem...)

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Aug 31 2007 - 07:59:45 EDT

From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 31 08:11:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 31 Aug 2007 13:11:34 +0100 Subject: [tei-council] current draft of facsimile Message-ID: <46D80576.4000107@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Fri, 31 Aug 2007 13:11:34 +0100
See http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/PH.html
for proposal
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 31 2007 - 08:11:38 EDT
From Syd_Bauman at Brown.edu Fri Aug 31 11:41:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 31 Aug 2007 11:41:21 -0400 Subject: [tei-council] NH work re-shedule Message-ID: <18136.13985.138749.987627@emt.wwp.brown.edu>
From: Syd Bauman
Date: Fri, 31 Aug 2007 11:41:21 -0400
Attn: James

I have just learned that 2 members of the NH-revision group will be
away with only intermittent e-mail contact at best during the first
week of Sep. Therefore I am going to suggest that the NH action be
broken into two: I should still have the changes suggested so far
incorporated by Thu 06 Sep, and hopefully an English example by Mon
10 Sep. but there should be a separate action on the group to review
the changes I've made and make fixes, etc., by, say, Fri 14 Sep.
Sorry for the confusion, folks.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Aug 31 2007 - 11:41:29 EDT

From lou.burnard at oucs.ox.ac.uk Fri Aug 31 12:55:49 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Fri, 31 Aug 2007 17:55:49 +0100 Subject: [tei-council] Editorial work after 17 sept Message-ID: <46D84815.4090104@oucs.ox.ac.uk>
From: Lou Burnard
Date: Fri, 31 Aug 2007 17:55:49 +0100
[I meant to bring this up in the call, but didn't get round to it.]
Syd and I had a brief discussion about how best to get the
copy-editing/proof-reading etc. done once the text is locked to me
for final corrections on 17 Sep.
We agreed that the chances of getting a complete professional proof
reading job done before the Members Meeting is null. We also agreed that
leaving the text unreviewed by anyone after I've had my wicked way with
it is undesirable. We kicked around the idea of drafting in some extra
hands to the job -- both at Oxford and Brown we could identify people
who could usefully and reliably do some checking if they had the time,
or we could maybe farm the whole job out to the whole TEI community.
The conclusions we reached are as follows (Syd, please correct me if I
misrepresent your view)
1. We are trying to produce the best possible online readable text we
can for the MM. We are not trying to produce a completely wart-free
professional-publication-standard document, yet. At this 1.0 release the
technical specs (the schemas) are fixed, but not (necessarily) all the
spelling errors.
2. However, we do want to make sure that the prose is clear, consistent,
comprehensible etc. That's what I am doing, post Sept 17: checking that
we always say "you do" or "one does", that the headings are cased
consistently, that set phrases such as "To include this module in a
schema..." or "This constraint cannot be expressed in the schema but may
be instantiated by means of a Schematron rule" are deployed
consistently; etc.
3. I need someone to do a reality check on what I have done and ring
alarm bells wherever I have messed up. This naturally would be the
responsibility of the other editor, and other duties permitting, Syd
is willing and able to do some of this task. (We had hoped that he
could co-ordinate its being done by others, but this looks difficult
given the current timetable).
4. Based on the recommendation of the planning committee, Council
allocated Syd the task of co-ordinating publishing/production issues,
liaising amongst James, Dot, Sebastian, and Chris. This was during
the early August conference call. On the basis of what we've seen so
far, progress on these has been good, and we would therefore like
Council to reconsider the relatively priority he should allocate to
that task.
5. Our preferred plan of campaign is that, as I complete my sweep
through a chapter I will pass it over to Syd for review. He may be able
to farm it out to someone else, he may not. Either way, there will be a
deadline (typically of a few days) by which the chapter must be either
signed off, or marked as unproofed.
We think this process is likely to result in a better quality product
without slowing down production, and without requiring more than our
already strained resources can cope with. But it does require that
Syd not be spending too much time on publishing/production issues.
Is there more to this task that we are missing, or is it reasonable
to believe that this won't eat up the majority of Syd's time during
the 17 Sep to 19 Oct period?
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Fri Aug 31 2007 - 12:55:52 EDT
From cwittern at gmail.com Fri Aug 31 22:09:34 2007 From: cwittern at gmail.com (Christian Wittern) Date: Sat, 01 Sep 2007 11:09:34 +0900 Subject: [tei-council] next meeting's meetomatic Message-ID: <46D8C9DE.5080200@gmail.com>
From: Christian Wittern
Date: Sat, 01 Sep 2007 11:09:34 +0900
Dear Council members,

For the next telecon, I've proposed the dates below.

Please visit the following web page to fill in your own
constraints:
http://www.meetomatic.com/respond.php?id=5A5H5N
PROPOSED MEETING DATES:
Monday 17th September 2007
Tuesday 18th September 2007
Wednesday 19th September 2007
Thursday 20th September 2007
Friday 21st September 2007
Monday 24th September 2007
Tuesday 25th September 2007
Wednesday 26th September 2007
Thursday 27th September 2007
Friday 28th September 2007
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Fri Aug 31 2007 - 22:09:53 EDT

From lou.burnard at oucs.ox.ac.uk Sat Sep 1 08:28:54 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sat, 01 Sep 2007 13:28:54 +0100 Subject: [tei-council] stdVals : for the chop Message-ID: <46D95B06.9040905@oucs.ox.ac.uk>
From: Lou Burnard
Date: Sat, 01 Sep 2007 13:28:54 +0100
Last week I asked on this list whether there was still any need for the
element. I didn't get any answer. If no-one can come up with a
good reason for protracting the half-life of this utterly otiose
element, I am therefore going to remove it.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Sep 01 2007 - 08:28:58 EDT
From James.Cummings at oucs.ox.ac.uk Sat Sep 1 13:26:53 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 01 Sep 2007 18:26:53 +0100 Subject: [tei-council] Minutes Message-ID: <46D9A0DD.7040000@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 01 Sep 2007 18:26:53 +0100
Hi all,
Some minutes of the meeting yesterday are now online. I'm sure there are a
number of corrections, omissions and inaccuracies, so do feel free to send these
to me and I'll correct them.

http://www.tei-c.org/Council/tcm34.xml?style=printable
Best,
-James
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Sep 01 2007 - 13:26:56 EDT

From James.Cummings at oucs.ox.ac.uk Sat Sep 1 18:50:49 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 01 Sep 2007 23:50:49 +0100 Subject: [tei-council] and formatting Message-ID: <46D9ECC9.9070305@oucs.ox.ac.uk>
From: James Cummings
Date: Sat, 01 Sep 2007 23:50:49 +0100
Dear All,
One of my actions was today sometime to post an explanation of the background of
the brief discussion we were having concerning the formatting of specGrpRef and
specGrp elements in the Guidelines. I've been thinking about it because of some
ongoing work on the formatting, but I think the inclusion or non-inclusion of
the material is more than just a mere formatting decision. My main complaint is
not the inclusion of Relax NG fragments. I think these are useful. (Though, I
think it might be more readable if in converting the XML to HTML they were
gathered together at the end of any chapter which defines a module.) What irks
me in reading the prose of the guidelines is the (mostly automatically
generated) references to the specGrp's and their numbering. Can anyone (without
looking it up) tell me what Specification Group 42 consists of? No? Well, if we
don't know, then why are we introducing this numbering scheme to our readers?[1]
For example, looking at a random chapter, see Chapter 6 (DR: Performance
Texts).

At some point it says:
======
This module is organized as follows:
?? include 70: Specialized front and back matter for performance texts ??
?? include 75: Stage directions ??
?? include 76: Screenplays and other technical matters ??
======
While that is partly useful because it explains how the module is organized --
though do our readers really care what order elements are added to a module? --
what bothers me is the "include 75:" bits of it. How does this really help me
understand the TEI? Never mind encoding Performance Texts? Later inside
'include 70' it says:
======
Specification group 70: Specialized front and back matter for performance texts
?? include 71: The set element ??
?? include 72: The prologue and epilogue elements ??
?? include 73: The performance element ??
?? include 74: The castList element ??
======
And whenever one of these are actually included it says something like:
======
The element is formally defined as follows:
Specification group 71: The set element
Element set [then some relax ng]
======
What I'd say is that (in most cases) the ?? include 71: The set element ??
links aren't very useful. People are reading the chapters as a set of
sections and subsections, I feel the list of inclusions is ugly and
unhelpful. In addition when something is included I don't really think we
need 'Specification group 71: The set element'. At very least we should
get rid of the number. This is just a generated number, and has no real
meaning to the reader. Another option is to, in presentation form on, as a
final division to each chapter have a section where all of these are dealt with
at once, once per module/chapter, rather than having them spread throughout the
chapter.
As there is often prose which introduces the specGrpRefs and specGrps, there
would need to be editorial changes to this, and the editors have been tasked
with removing this regardless. (We should be able to automate the addition of
leading prose if we do decide to retain these.)
As you've all doubtless read in the minutes, you are all tasked with discussing
this and coming to some decision by 2007-09-07.
-James
[1] I chose Specification Group 42 at (near)random and really have no interest
in that one in particular, I've not bothered to look it up.
-- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sat Sep 01 2007 - 18:50:53 EDT

From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 2 16:09:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 02 Sep 2007 21:09:33 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46D84815.4090104@oucs.ox.ac.uk> Message-ID: <46DB187D.3010801@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Sun, 02 Sep 2007 21:09:33 +0100
can I put in a plea for work on Appendix D Bibliography
and Appendix E Index, please? and more on Appendix F.
I'd feel happier if these were cleaned up/deleted/replaced
sooner rather than later.
In an ideal world we'd put all the bibliographical
references in the text into the bibliography
and cite them properly/consistently. I realize
that may be a task beyond us, though its a pity
if we can't meet the highest standards for this
sort of thing.
(why is F.5 not Appendix G, by the way?)

Sebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sun Sep 02 2007 - 16:09:36 EDT
From cwittern at gmail.com Sun Sep 2 19:27:03 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 03 Sep 2007 08:27:03 +0900 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46D84815.4090104@oucs.ox.ac.uk> Message-ID: <46DB46C7.5040405@gmail.com>
From: Christian Wittern
Date: Mon, 03 Sep 2007 08:27:03 +0900
Dear Council members,
This sounds like an excellent plan to me. I think it should be of
highest priority to us to let the Editors do the editing and the plan
laid out here looks like it is going to make sure we do assign our
scarce resources in the best possible way. As Lou is pointing out here,
the publishing task itself seems to be coming along pretty well and can
be re-assigned differently if that becomes necessary. So I for one
encourage you to go ahead with this plan and hope that we do indeed have
the drafts ready as required!
All the best,
Christian
Lou Burnard wrote:
> [I meant to bring this up in the call, but didn't get round to it.]
>
> Syd and I had a brief discussion about how best to get the
> copy-editing/proof-reading etc. done once the text is locked to me
> for final corrections on 17 Sep.
>
> We agreed that the chances of getting a complete professional proof
> reading job done before the Members Meeting is null. We also agreed that
> leaving the text unreviewed by anyone after I've had my wicked way with
> it is undesirable. We kicked around the idea of drafting in some extra
> hands to the job -- both at Oxford and Brown we could identify people
> who could usefully and reliably do some checking if they had the time,
> or we could maybe farm the whole job out to the whole TEI community.
>
> The conclusions we reached are as follows (Syd, please correct me if I
> misrepresent your view)
>
> 1. We are trying to produce the best possible online readable text we
> can for the MM. We are not trying to produce a completely wart-free
> professional-publication-standard document, yet. At this 1.0 release the
> technical specs (the schemas) are fixed, but not (necessarily) all the
> spelling errors.
>
> 2. However, we do want to make sure that the prose is clear, consistent,
> comprehensible etc. That's what I am doing, post Sept 17: checking that
> we always say "you do" or "one does", that the headings are cased
> consistently, that set phrases such as "To include this module in a
> schema..." or "This constraint cannot be expressed in the schema but may
> be instantiated by means of a Schematron rule" are deployed
> consistently; etc.
>
> 3. I need someone to do a reality check on what I have done and ring
> alarm bells wherever I have messed up. This naturally would be the
> responsibility of the other editor, and other duties permitting, Syd
> is willing and able to do some of this task. (We had hoped that he
> could co-ordinate its being done by others, but this looks difficult
> given the current timetable).
>
> 4. Based on the recommendation of the planning committee, Council
> allocated Syd the task of co-ordinating publishing/production issues,
> liaising amongst James, Dot, Sebastian, and Chris. This was during
> the early August conference call. On the basis of what we've seen so
> far, progress on these has been good, and we would therefore like
> Council to reconsider the relatively priority he should allocate to
> that task.
>
> 5. Our preferred plan of campaign is that, as I complete my sweep
> through a chapter I will pass it over to Syd for review. He may be able
> to farm it out to someone else, he may not. Either way, there will be a
> deadline (typically of a few days) by which the chapter must be either
> signed off, or marked as unproofed.
>
> We think this process is likely to result in a better quality product
> without slowing down production, and without requiring more than our
> already strained resources can cope with. But it does require that
> Syd not be spending too much time on publishing/production issues.
> Is there more to this task that we are missing, or is it reasonable
> to believe that this won't eat up the majority of Syd's time during
> the 17 Sep to 19 Oct period?
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Sep 02 2007 - 19:27:21 EDT

From cwittern at gmail.com Sun Sep 2 19:54:28 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 03 Sep 2007 08:54:28 +0900 Subject: [tei-council] concerns regarding Message-ID: <46DB4D34.1060200@gmail.com>
From: Christian Wittern
Date: Mon, 03 Sep 2007 08:54:28 +0900
Dear Council members,
As I mentioned briefly during the call, I found a few problems in the
WD-Nonstandard glyphs chapter that I am currently reviewing.
One of them concerns the element. This element contains a list
of the characters or glyphs that need a special description. However, the
name of the element is modelled on the other *Desc elements in the header at
various levels. Now, as far as I can see, all of them are describing a
*single* entity, like , , etc. The
content of however is a *list* of things, quite similar to
and other list* elements in the TEI.
To avoid confusion and for consistency with general TEI practice, I would
therefore propose to have this element renamed to and at the same
time also to update its , which currently reads 'provides descriptive
information about characters or glyphs.' to 'contains a list of
and/or elements that provide descriptive information about
characters or glyphs' or something similar.
Please give me your comments,
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Sep 02 2007 - 19:54:45 EDT

From cwittern at gmail.com Sun Sep 2 21:58:46 2007 From: cwittern at gmail.com (Christian Wittern) Date: Mon, 03 Sep 2007 10:58:46 +0900 Subject: [tei-council] Minutes In-Reply-To: <46D9A0DD.7040000@oucs.ox.ac.uk> Message-ID: <46DB6A56.6080604@gmail.com>
From: Christian Wittern
Date: Mon, 03 Sep 2007 10:58:46 +0900
Dear James,
the minutes looks fine to me. Thanks for getting them up to shape so
speedy!
All the best,
Christian
James Cummings wrote:
>
> Hi all,
>
> Some minutes of the meeting yesterday are now online. I'm sure there
> are a number of corrections, omissions and inaccuracies, so do feel
> free to send these to me and I'll correct them.
>
>
> http://www.tei-c.org/Council/tcm34.xml?style=printable
>
> Best,
>
> -James
>

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Sun Sep 02 2007 - 21:59:05 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 04:44:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 09:44:35 +0100 Subject: [tei-council] concerns regarding In-Reply-To: <46DB4D34.1060200@gmail.com> Message-ID: <46DBC973.1010909@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 09:44:35 +0100
may be more consistent to name it , in line with ?
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 04:44:39 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 04:51:09 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 09:51:09 +0100 Subject: [tei-council] concerns regarding In-Reply-To: <46DB4D34.1060200@gmail.com> Message-ID: <46DBCAFD.7060904@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 09:51:09 +0100
I could live with this change. However:
(a) I have an ousttanding action to make all listXXX things look the
same, and I don't think that would work for listChar (which would
presumably contain a mixture of char and glyph elements and wouldn'tt
self-nest)
(b) the pattern elsewhere in the header is to have a *decl including
multiple *desc
(c) each individual or is really a *desc
How about
nonstandardChars containing (charDesc|glyphDesc)+
I dunno what the is doing inside the current --
wouldnt it be more use be inside each and ?

Christian Wittern wrote:
> Dear Council members,
>
> As I mentioned briefly during the call, I found a few problems in the
> WD-Nonstandard glyphs chapter that I am currently reviewing.
>
> One of them concerns the element. This element contains a list
> of the characters or glyphs that need a special description. However, the
> name of the element is modelled on the other *Desc elements in the header at
> various levels. Now, as far as I can see, all of them are describing a
> *single* entity, like , , etc. The
> content of however is a *list* of things, quite similar to
> and other list* elements in the TEI.
>
> To avoid confusion and for consistency with general TEI practice, I would
> therefore propose to have this element renamed to and at the same
> time also to update its , which currently reads 'provides descriptive
> information about characters or glyphs.' to 'contains a list of
> and/or elements that provide descriptive information about
> characters or glyphs' or something similar.
>
> Please give me your comments,
>
> Christian
>
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 04:51:14 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 05:08:34 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 10:08:34 +0100 Subject: [tei-council] Re: chapter reviewing In-Reply-To: <46DBC8FF.6090101@oucs.ox.ac.uk> Message-ID: <46DBCF12.1010808@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 10:08:34 +0100
Sebastian Rahtz wrote:
> Given some problems with getting chapters reviewed, should
> we make a quick call on TEI-L? or does that make us look bad?
I'd reserve that for later, post-MM.
>
> David will be unable to get namesdates done in time, it seems,
has he reported that?
> and that at least needs a disinterested reviewer; and we still
> don't have enough on USE.
>
> Or do we target individuals? off the top of my head,
> can we attempt to acquire Julia Flanders, Fotis Jannidis
> and Michael Beddow for the cause?
>
Targetted individuals sounds like a good plan to me. Buty I think
they're more likely to respond to a personal call than a blanket
invititatoion.
Wendell might be a good person to ask to review USE.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 05:08:39 EDT
From arianna.ciula at kcl.ac.uk Mon Sep 3 05:23:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 10:23:58 +0100 Subject: [tei-council] and formatting In-Reply-To: <46D9ECC9.9070305@oucs.ox.ac.uk> Message-ID: <46DBD2AE.5010600@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 10:23:58 +0100
James Cummings wrote:
> At very least we should
> get rid of the number. This is just a generated number, and has no real
> meaning to the reader.
Agree
Another option is to, in presentation form on,
> as a final division to each chapter have a section where all of these
> are dealt with at once, once per module/chapter, rather than having them
> spread throughout the chapter.
I think this is a good idea, but I am not sure how feasible it is given
the short time we have and more urgent priorities. Indeed, it seems to
me that every chapter has a slightly different structure that would make
this task rather time consuming. The editors know better.
Arianna

> As there is often prose which introduces the specGrpRefs and specGrps,
> there would need to be editorial changes to this, and the editors have
> been tasked with removing this regardless. (We should be able to
> automate the addition of leading prose if we do decide to retain these.)
>
> As you've all doubtless read in the minutes, you are all tasked with
> discussing this and coming to some decision by 2007-09-07.
>
> -James
>
> [1] I chose Specification Group 42 at (near)random and really have no
> interest in that one in particular, I've not bothered to look it up.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 05:24:07 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 05:29:14 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 10:29:14 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DBD2AE.5010600@kcl.ac.uk> Message-ID: <46DBD3EA.9080800@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 10:29:14 +0100
Arianna Ciula wrote:
>
> Another option is to, in presentation form on,
>> as a final division to each chapter have a section where all of these
>> are dealt with at once, once per module/chapter, rather than having
>> them spread throughout the chapter.
>
> I think this is a good idea, but I am not sure how feasible it is given
> the short time we have and more urgent priorities. Indeed, it seems to
> me that every chapter has a slightly different structure that would make
> this task rather time consuming. The editors know better.
>
Not difficult. I have already done it in PH, for example.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 05:29:18 EDT
From arianna.ciula at kcl.ac.uk Mon Sep 3 05:33:42 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 10:33:42 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DB187D.3010801@oucs.ox.ac.uk> Message-ID: <46DBD4F6.9010301@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 10:33:42 +0100
Sebastian Rahtz wrote:
> can I put in a plea for work on Appendix D Bibliography
> and Appendix E Index, please? and more on Appendix F.
> I'd feel happier if these were cleaned up/deleted/replaced
> sooner rather than later.
> In an ideal world we'd put all the bibliographical
> references in the text into the bibliography
> and cite them properly/consistently.
Sure, but it seems to me that the bibliography contains references that
are not necessarily cited or even used in the chapters. Am I wrong? if
yes, then we could try and collect all the references chapter by chapter
into one full bibliography as you probably are suggesting already.
So in the single chapters we would just have references to the entries
in the full bibliography rather than the other way round.
Easy to give advise, isn't it?...ok, I would volunteer to do this, but
is this something we can do before all the chapters are in a sort of
frozen state?
Appendix F can go for me.
Arianna
I realize
> that may be a task beyond us, though its a pity
> if we can't meet the highest standards for this
> sort of thing.
>
> (why is F.5 not Appendix G, by the way?)
>
> Sebastian
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 05:34:25 EDT
From arianna.ciula at kcl.ac.uk Mon Sep 3 05:38:26 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 10:38:26 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DBD3EA.9080800@oucs.ox.ac.uk> Message-ID: <46DBD612.20502@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 10:38:26 +0100
Lou Burnard wrote:
> Arianna Ciula wrote:
>>
>> Another option is to, in presentation form on,
>>> as a final division to each chapter have a section where all of these
>>> are dealt with at once, once per module/chapter, rather than having
>>> them spread throughout the chapter.
>>
>> I think this is a good idea, but I am not sure how feasible it is
>> given the short time we have and more urgent priorities. Indeed, it
>> seems to me that every chapter has a slightly different structure that
>> would make this task rather time consuming. The editors know better.
>>
>
> Not difficult. I have already done it in PH, for example.
Great then. I am for consistency: all in one section. However, I would
not eliminate the references myself.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 05:38:16 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 05:51:43 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 10:51:43 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DBD4F6.9010301@kcl.ac.uk> Message-ID: <46DBD92F.1020709@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 10:51:43 +0100
Arianna Ciula wrote:
>
>
> Sebastian Rahtz wrote:
>> can I put in a plea for work on Appendix D Bibliography
>> and Appendix E Index, please? and more on Appendix F.
>> I'd feel happier if these were cleaned up/deleted/replaced
>> sooner rather than later. In an ideal world we'd put all the
>> bibliographical
>> references in the text into the bibliography
>> and cite them properly/consistently.
There is an long standing action (on Syd if memory serves) to revise the
bibliography. It contains much that is superannuated and irrelevant.
>
> Sure, but it seems to me that the bibliography contains references that
> are not necessarily cited or even used in the chapters. Am I wrong? if
> yes, then we could try and collect all the references chapter by chapter
> into one full bibliography as you probably are suggesting already.
> So in the single chapters we would just have references to the entries
> in the full bibliography rather than the other way round.
The original bibliog was conceived as a demonstration of how
worked and as a reading list of useful relevant stuff. It was not
conceived as the kind of formal academic bibliog you are thinking of
here -- the kind that collects all the works cited in the body of the
text. I think I agree that a bibliog of the latter kind would indeed be
an improvement, but would represent a *lot* of work. Should it also
include the source for all the cited examples?

>
> Easy to give advise, isn't it?...ok, I would volunteer to do this, but
> is this something we can do before all the chapters are in a sort of
> frozen state?
Not a good idea to do it yet -- but if you're volunteering, I am sure I
can find a slot for you to do it in!

>
> Appendix F can go for me.
>
Tsk tsk, where's your sense of history?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 05:51:48 EDT

From arianna.ciula at kcl.ac.uk Mon Sep 3 06:33:35 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 11:33:35 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DBD92F.1020709@oucs.ox.ac.uk> Message-ID: <46DBE2FF.9000108@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 11:33:35 +0100
Lou Burnard wrote:
>> Appendix F can go for me.
>>
>
> Tsk tsk, where's your sense of history?
>
>
Sorry sorry, I didn't mean appendix F but E here. I don't understand
what is it supposed to be useful for, since the entries don't lead anywhere.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 06:33:31 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 06:42:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 11:42:15 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DBD92F.1020709@oucs.ox.ac.uk> Message-ID: <46DBE507.5090007@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 11:42:15 +0100
Lou Burnard wrote:
>
> The original bibliog was conceived as a demonstration of how
> worked and as a reading list of useful relevant stuff.
if its to be that, then it needs serious work (as mentioned approx twice
a year for the last N years....).
> It was not conceived as the kind of formal academic bibliog you are
> thinking of here -- the kind that collects all the works cited in the
> body of the text.
yes please..... in some ways easier than the reading list.
> think I agree that a bibliog of the latter kind would indeed be an
> improvement, but would represent a *lot* of work. Should it also
> include the source for all the cited examples?
ideally, but that _would_ be a big task to turn the comments into useful
s

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 06:42:19 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 07:02:25 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 12:02:25 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DBE2FF.9000108@kcl.ac.uk> Message-ID: <46DBE9C1.20401@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 12:02:25 +0100
Arianna Ciula wrote:
>>
> Sorry sorry, I didn't mean appendix F but E here. I don't understand
> what is it supposed to be useful for, since the entries don't lead
> anywhere.
>
Well, some of them used to lead you somewhere ... at least they did in
the print edition. But I agree with you that this whole appendix could
be removed from the online edition and no-one would care. Or notice.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 07:02:28 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 07:23:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 12:23:01 +0100 Subject: [tei-council] Editorial work after 17 sept In-Reply-To: <46DBE9C1.20401@oucs.ox.ac.uk> Message-ID: <46DBEE95.70807@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 12:23:01 +0100
Lou Burnard wrote:
>
> Well, some of them used to lead you somewhere ... at least they did in
> the print edition. But I agree with you that this whole appendix could
> be removed from the online edition and no-one would care. Or notice.
>
gone
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 07:23:05 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 07:44:29 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 12:44:29 +0100 Subject: [tei-council] p5 contributor list Message-ID: <46DBF39D.2010900@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 12:44:29 +0100
I've made a first pass through Christian's mail, tagging it as a series
of lists. I haven't checked spelling of name or affiliations, most of
which are missing, and I haven't sorted the lists alphabetically yet. I
have also moved the list into where I think it's destined to fit
eventually: http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/FM1.html
so that you can see it and shout if there any obvious omissions or
infelicities.
This is just to show some progress -- of course what I really want to do
is to make a for TEI land, and generate lists like this one
automatically from it.
Questions for Council to consider:
* I have not included the Board membership here. Should it go somewhere
in the preface?
* My preference is for names to appear in the form "Forename Surname
(affiliation)" without titles.
* My preference for most lists is that they should be run on rather than
bulleted, and sorted by surname.
* Should I include counts of meetings under WG heads as well as dates of
activity? links to website if any?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 07:44:32 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 07:47:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 12:47:38 +0100 Subject: [tei-council] p5 contributor list In-Reply-To: <46DBF39D.2010900@oucs.ox.ac.uk> Message-ID: <46DBF45A.2030001@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 12:47:38 +0100
>
> * I have not included the Board membership here. Should it go
> somewhere in the preface?
shld go _somewhere_, yes.
>
> * My preference is for names to appear in the form "Forename Surname
> (affiliation)" without titles.
agree
>
> * My preference for most lists is that they should be run on rather
> than bulleted
why? to save space? anyway, thats a CSS issue, still mark them up as list
>
> * Should I include counts of meetings under WG heads as well as dates
> of activity? links to website if any?
is the meeting count available? website proabbly misleading
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 07:47:41 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 10:35:52 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 15:35:52 +0100 Subject: [tei-council] damage - what is it good for? Message-ID: <46DC1BC8.6040409@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 15:35:52 +0100
As I proceed through PH wreaking havoc, I have come upon the
element. This is allegedly used to mark a part of a manuscript within
which there has been some damage to the carrier, e.g. by rubbing or
singeing or spilling marmalade, but not so much as to make the
transcriber unsure of what the writing actually says (if that were the
case, the element should be used), nor so extensive as to make
the writing (or the carrier) actually disintegrate or disappear (for
which the element is available).
As defined, respects textual structures even less than the
other elements. If it is to be kept, it should probably be given a
sister (analogous to ) so that it can point across
div boundaries for example. Though even then there isn't any really
satisfactory way of dealing with things like circular spots of damage in
the middle of the page, which have to be split up into numerous
elements.
But since it is really about the state of the carrier, not the text, why
would you want to record it anyway? I am sorely tempted to just remove
it and see who protests....

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 10:35:55 EDT

From laurent.romary at loria.fr Mon Sep 3 10:51:31 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 3 Sep 2007 16:51:31 +0200 Subject: [tei-council] Mode attribute for Message-ID: <114F354F-ED89-40D8-AF2C-3EB86B3EA4EC@loria.fr>
From: Laurent Romary
Date: Mon, 3 Sep 2007 16:51:31 +0200
My point was to have the same mechanism for modifying class
relationships as we have for other aspects of an elementSpec.
In the current version, the only way to change the classes attached
to an element is to make a complete declaration with all
new and old classes. Beyond the fact that it is not coherent with the
rest of the specification mechanisms, it prevents anyone to know what
is actually deleted or added from the initial declaration. I would
thus suggest to add a mode attribute both for and
, with the following meaning:
- means look inside at he mode attributes of
the embedded (see below).
- means all declarations have to
be removed from the existing element specification
- means all declarations should be
added to the existing element specification
- means the relation should be added to the
existing element specification
- means the relation should be deleted from
the existing element specification
This specification allows the same thing to be expressed in two
different ways, for instance an addition and a deletion could be
either expressed as






or








But (unless it is a major implementation problem => Seb?) we should
leave this choice to the users.
Best wishes,
Laurent
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 10:53:22 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 11:06:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 16:06:26 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: <114F354F-ED89-40D8-AF2C-3EB86B3EA4EC@loria.fr> Message-ID: <46DC22F2.7090302@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 16:06:26 +0100
Laurent Romary wrote:
> My point was to have the same mechanism for modifying class
> relationships as we have for other aspects of an elementSpec.
> In the current version, the only way to change the classes attached to
> an element is to make a complete declaration with all new
> and old classes.
yes, because it is not identifiable. is a black box like
, you either take
it away or replace it. Within , is not identifiable
either, ie
it has no @ident.
> Beyond the fact that it is not coherent with the rest of the
> specification mechanisms
technically, it is :-}
> it prevents anyone to know what is actually deleted or added from the
> initial declaration. I would thus suggest to add a mode attribute both
> for and , with the following meaning:
> - means look inside at he mode attributes of
> the embedded (see below).
> - means all declarations have to be
> removed from the existing element specification
> - means all declarations should be
> added to the existing element specification
>
I _could_ do that, but it would conflict the semantics of @mode elsewhere
> - means the relation should be added to the
> existing element specification
> - means the relation should be deleted from
> the existing element specification
ditto.
>
> This specification allows the same thing to be expressed in two
> different ways, for instance an addition and a deletion could be
> either expressed as
>
>
>
>
>
>
> or
>
>
>
>
>
>
>
>
>
cannot appear twice, I think.
I am extraordinarily reluctant to get into implementing this
proposal, because it would lose a week of my life. But I will,
of course, if everyone says it is needed, and are willing to accept
the contradictions.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 11:06:31 EDT
From laurent.romary at loria.fr Mon Sep 3 11:08:59 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 3 Sep 2007 17:08:59 +0200 Subject: [tei-council] Mode attribute for In-Reply-To: <46DC22F2.7090302@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Mon, 3 Sep 2007 17:08:59 +0200
OK. Making the thing nicer is not worth making Seb loose a whole
week. Just Imagine I had said nothing...
Le 3 sept. 07 ? 17:06, Sebastian Rahtz a ?crit :
> Laurent Romary wrote:
>> My point was to have the same mechanism for modifying class
>> relationships as we have for other aspects of an elementSpec.
>> In the current version, the only way to change the classes
>> attached to an element is to make a complete declaration
>> with all new and old classes.
> yes, because it is not identifiable. is a black box like
> , you either take
> it away or replace it. Within , is not
> identifiable either, ie
> it has no @ident.
>> Beyond the fact that it is not coherent with the rest of the
>> specification mechanisms
> technically, it is :-}
>> it prevents anyone to know what is actually deleted or added from
>> the initial declaration. I would thus suggest to add a mode
>> attribute both for and , with the following
>> meaning:
>> - means look inside at he mode attributes
>> of the embedded (see below).
>> - means all declarations have
>> to be removed from the existing element specification
>> - means all declarations should be
>> added to the existing element specification
>>
> I _could_ do that, but it would conflict the semantics of @mode
> elsewhere
>> - means the relation should be added to the
>> existing element specification
>> - means the relation should be deleted
>> from the existing element specification
> ditto.
>>
>> This specification allows the same thing to be expressed in two
>> different ways, for instance an addition and a deletion could be
>> either expressed as
>>
>>
>>
>>
>>
>>
>> or
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> cannot appear twice, I think.
>
> I am extraordinarily reluctant to get into implementing this
> proposal, because it would lose a week of my life. But I will,
> of course, if everyone says it is needed, and are willing to accept
> the contradictions.
>
> --
> Sebastian Rahtz Information Manager, Oxford University
> Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 11:10:53 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 11:12:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 16:12:54 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: Message-ID: <46DC2476.8020108@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 16:12:54 +0100
Laurent Romary wrote:
> OK. Making the thing nicer is not worth making Seb loose a whole week.
if the blithering idiots who mend computers for this so-called
major research university pulled out their fingers and got me
back the computer which has been out of action since early July,
I could work harder. sigh.
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 11:12:59 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 11:23:39 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 16:23:39 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: Message-ID: <46DC26FB.7040201@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 16:23:39 +0100
Nothing could make Sebastian looser than he already is. However, even
though Laurent has magnaminously withdrawn this suggestion, I think we
could consider doing something along those lines.
Firstly does not need to have an identifier, because only one
occurrence is permitted within an . So there is no real
problem in putting a @mode on it. This is not however true of
elements, which *do* repeat and are *not* identifiable. But I see no
need to give them a @mode attribute anyway.
means "add my parent to the classes indicated by my
children without changing its existing memberships"
means "remove my parent from the classes
indicated by my children"
means "replace my parent's existing class
memberships by those indicated by my children"
means the same as mode="add", except that it
should raise an error if my parent has no class memberships.
Am I missing something? This seems neither too hard nor too inconsistent
with what we currently have.

Laurent Romary wrote:
> OK. Making the thing nicer is not worth making Seb loose a whole week.
> Just Imagine I had said nothing...
>
> Le 3 sept. 07 ? 17:06, Sebastian Rahtz a ?crit :
>
>> Laurent Romary wrote:
>>> My point was to have the same mechanism for modifying class
>>> relationships as we have for other aspects of an elementSpec.
>>> In the current version, the only way to change the classes attached
>>> to an element is to make a complete declaration with all
>>> new and old classes.
>> yes, because it is not identifiable. is a black box like
>> , you either take
>> it away or replace it. Within , is not
>> identifiable either, ie
>> it has no @ident.
>>> Beyond the fact that it is not coherent with the rest of the
>>> specification mechanisms
>> technically, it is :-}
>>> it prevents anyone to know what is actually deleted or added from the
>>> initial declaration. I would thus suggest to add a mode attribute
>>> both for and , with the following meaning:
>>> - means look inside at he mode attributes of
>>> the embedded (see below).
>>> - means all declarations have to
>>> be removed from the existing element specification
>>> - means all declarations should be
>>> added to the existing element specification
>>>
>> I _could_ do that, but it would conflict the semantics of @mode elsewhere
>>> - means the relation should be added to the
>>> existing element specification
>>> - means the relation should be deleted from
>>> the existing element specification
>> ditto.
>>>
>>> This specification allows the same thing to be expressed in two
>>> different ways, for instance an addition and a deletion could be
>>> either expressed as
>>>
>>>
>>>
>>>
>>>
>>>
>>> or
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> cannot appear twice, I think.
>>
>> I am extraordinarily reluctant to get into implementing this
>> proposal, because it would lose a week of my life. But I will,
>> of course, if everyone says it is needed, and are willing to accept
>> the contradictions.
>>
>> --Sebastian Rahtz Information Manager, Oxford University
>> Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 11:23:44 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 11:32:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 16:32:22 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: <46DC26FB.7040201@oucs.ox.ac.uk> Message-ID: <46DC2906.9070605@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 16:32:22 +0100
Lou Burnard wrote:
> means "add my parent to the classes indicated by
> my children without changing its existing memberships"
> means "remove my parent from the classes
> indicated by my children"
> means "replace my parent's existing class
> memberships by those indicated by my children"
> means the same as mode="add", except that it
> should raise an error if my parent has no class memberships.
>
> Am I missing something? This seems neither too hard nor too
> inconsistent with what we currently have.
it seems hard to me, because the semantics of an unadulterated
now vary. sometimes it means "off with my head",
sometimes it means "add me"
oh well
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 11:32:25 EDT
From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 11:50:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 16:50:43 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: <46DC26FB.7040201@oucs.ox.ac.uk> Message-ID: <46DC2D53.3050804@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 16:50:43 +0100
Lou and I, having wagged our chins, are vaguely thinking that adding
@mode to
is the least worst thing to do. Leave alone, but allow
to mean "remove me from the
att.global class".
I don't like it, but I'd rather deal with that than a mode on
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 11:50:45 EDT
From laurent.romary at loria.fr Mon Sep 3 11:57:38 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 3 Sep 2007 17:57:38 +0200 Subject: [tei-council] Mode attribute for In-Reply-To: <46DC2D53.3050804@oucs.ox.ac.uk> Message-ID:
From: Laurent Romary
Date: Mon, 3 Sep 2007 17:57:38 +0200
I would vote for this base line.
Le 3 sept. 07 ? 17:50, Sebastian Rahtz a ?crit :
> Lou and I, having wagged our chins, are vaguely thinking that
> adding @mode to
> is the least worst thing to do. Leave alone,
> but allow
> to mean "remove me from the
> att.global class".
>
> I don't like it, but I'd rather deal with that than a mode on
>
>
> --
> Sebastian Rahtz Information Manager, Oxford University
> Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 11:59:26 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 12:07:23 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 17:07:23 +0100 Subject: [tei-council] Mode attribute for In-Reply-To: Message-ID: <46DC313B.5050603@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 17:07:23 +0100
for the record, here's what I think we just agreed to investigate
1. Allow @mode on memberOf (the @key value acts as its unique identifier
since within a single Spec, you can't be a member of the same class more
than once)
2. Interpret @mode values on memberOf as follows
not specified means mode=add
add : means make this element a member of the class nominated if it
isn't already and raise an error if it is
change: doesn't mean anything so should probably raise an error
delete : means remove this element from the class nominated if it is a
member of it already and raise an error if it is not

Laurent Romary wrote:
> I would vote for this base line.
>
> Le 3 sept. 07 ? 17:50, Sebastian Rahtz a ?crit :
>
>> Lou and I, having wagged our chins, are vaguely thinking that adding
>> @mode to
>> is the least worst thing to do. Leave alone, but
>> allow
>> to mean "remove me from the
>> att.global class".
>>
>> I don't like it, but I'd rather deal with that than a mode on
>>
>> --Sebastian Rahtz Information Manager, Oxford University
>> Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council_at_lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 12:07:27 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 12:11:13 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 17:11:13 +0100 Subject: [tei-council] [Fwd: Re: damage - what is it good for?] Message-ID: <46DC3221.4090304@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 17:11:13 +0100
-------- Original Message --------
Subject: Re: damage - what is it good for?
Date: Mon, 03 Sep 2007 17:07:35 +0100
From: Gabriel Bodard ac.uk>
To: Lou Burnard ox.ac.uk>
CC: TEI Council village.virginia.edu>
References: <46DC1BC8.6040409_at_oucs.ox.ac.uk>
We've never used , I don't think. (Although there was at some
time talk of using it to link a and that are really
part of the same bit of damage. I didn't really see the point, since the
whole problem with linking such things was that they might cross div or
word structures. And now it appears that would have been abuse anyway.)
As you describe it, however, it is the sort of thing that an epigrapher
*would* want to record--deliberate or other damage to the surface of the
stone not affecting our ability to read the text. (For deliberate I
guess we use .)
What *would* certainly be useful, however, is some way to indicate
precisely what you describe: separate bits of damage (whether indicated
by , , , or ) that are in fact the
result of the same gouge out of the front of the stone, for example.
Traditionally both epigraphers and papyrologists indicate that a gap and
a supplied are part of the same damage by enclosing the two in a single
set of square brackets. E.g.:
[abc ...]
(we can restore "abc" but not the rest of whatever was in that bit of
damage... as opposed to:
[abc] [...]
= "abc" was lost because of (e.g.) surface wear, something else was lost
because of (e.g.) the stone being cut down for re-use, and can't be
restored)
So in summary I've never used , and the only time I'd be likely
to want to could arguably be handled by --but unclear for us
has the very specific meaning that the letters so marked would not be
unambiguous outside of their context. Therefore I'd vote for keeping it,
but not scream and shout if I'm out-voted. :)
Best,
Gabby
Lou Burnard a ?crit :
> As I proceed through PH wreaking havoc, I have come upon the
> element. This is allegedly used to mark a part of a manuscript within
> which there has been some damage to the carrier, e.g. by rubbing or
> singeing or spilling marmalade, but not so much as to make the
> transcriber unsure of what the writing actually says (if that were the
> case, the element should be used), nor so extensive as to make
> the writing (or the carrier) actually disintegrate or disappear (for
> which the element is available).
>
> As defined, respects textual structures even less than the
> other elements. If it is to be kept, it should probably be given a
> sister (analogous to ) so that it can point across
> div boundaries for example. Though even then there isn't any really
> satisfactory way of dealing with things like circular spots of damage in
> the middle of the page, which have to be split up into numerous
> elements.
>
> But since it is really about the state of the carrier, not the text, why
> would you want to record it anyway? I am sorely tempted to just remove
> it and see who protests....

-- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London Kay House 7, Arundel Street London WC2R 3DX Email: gabriel.bodard_at_kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 12:11:16 EDT

From mjd at hum.ku.dk Mon Sep 3 12:41:55 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 3 Sep 2007 18:41:55 +0200 Subject: SV: [tei-council] damage - what is it good for? Message-ID: <69E99682EC8E03448CD15F49438219CDF7E511@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Mon, 3 Sep 2007 18:41:55 +0200
Well, for what it's worth, I've never used , nor really understood
why anyone would. If you can read what it says, no problem; if you can read
enough of it to make a reasonable guess at the missing bits use type="illegible">; and if you can't read anything at all use .
Come to think of it, I've never really understood what was for
either.
Matthew
-----Oprindelig meddelelse-----
Fra: Lou Burnard [mailto:lou.burnard_at_oucs.ox.ac.uk]
Sendt: 03 September 2007 16:36
Til: TEI Council; Gabriel Bodard
Emne: [tei-council] damage - what is it good for?
As I proceed through PH wreaking havoc, I have come upon the
element. This is allegedly used to mark a part of a manuscript within
which there has been some damage to the carrier, e.g. by rubbing or
singeing or spilling marmalade, but not so much as to make the
transcriber unsure of what the writing actually says (if that were the
case, the element should be used), nor so extensive as to make
the writing (or the carrier) actually disintegrate or disappear (for
which the element is available).
As defined, respects textual structures even less than the
other elements. If it is to be kept, it should probably be given a
sister (analogous to ) so that it can point across
div boundaries for example. Though even then there isn't any really
satisfactory way of dealing with things like circular spots of damage in
the middle of the page, which have to be split up into numerous
elements.
But since it is really about the state of the carrier, not the text, why
would you want to record it anyway? I am sorely tempted to just remove
it and see who protests....

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 12:43:18 EDT

From arianna.ciula at kcl.ac.uk Mon Sep 3 12:44:44 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 17:44:44 +0100 Subject: [tei-council] MS Manuscript Description chapter: notes Message-ID: <46DC39FC.4040905@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 17:44:44 +0100
Hi,
I have sent the MS chapter to the editors (I have probably just added a
full stop..don't remember) and here are my notes...sorry it's quite
long, but some of these are things that need to be corrected, while
other comments may ignored if useless right now.
- "The element will normally appear within the
element of the header of a TEI conformant document, where the document
being encoded is a digital representation of some manuscript original,
whether as a transcription, as a collection of digital images, or as
some combination of the two."
I think something should be said here about the new facsimile section on
the Representation of Primary sources chapter, at least in a footnote.
- att.measurement/att.dimensions
I know that thanks to Syd's work theseclasses had reached a more stable
state
(and sorry it didn't get enough feedback or attention from us when
needed), but it seems really silly to have slightly different
definitions of @unit and @quantity (they should be uniformed to what is
now in att.measurement, in my opinion).
- I think the attribute @targets for should be @target instead,
for consistency with
- by the way, this attribute of may conflict with @facs in its
function when the PH module is loaded even if here we are not
transcribing but describing a manuscript. This raises the question: can
the facsimile element be used in combination with a manuscript
description without a transcription? I think it should.
We could may be mention that if the PH module is also used, the @facs
attribute is preferred over @targets to connect less directly but more
explicitly to image files.
- "The reference #txt182 in this example is assumed to reference the
section of the manuscript ???up to fol. 182v??? which has been transcribed
elsewhere in the current document; the references
http://www.images.fr#F33R and http://www.images.fr#F59V link to images
of the relevant pages, held presumably in an image archive."
The first part of this sentence doesn't seem to refer to a pointer in
the example (#txt182 is not in the example). Probably the example has
been changed and the prose left as it was.
- example with multiple foliation schemes: TO DO
I could provide one.
- "In order for this second Hoccleve example to be valid, a
element must be provided which has the value HOCCL1 for its xml:id
attribute; the same value will be used as the key attribute of every
reference to Hoccleve in the document (however spelled), but there will
only be one element with this identifier."
@ref should be used instead of @key in the example and substituted in
the prose.
- "Similar mechanisms may be used to create and maintain canonical lists
of places or organizations, but no specific elements are defined for
this purpose."
There are now...so we need a reference to the new section on places here.
- the formal definition of in the Specs is "(secundo folio) The
word or words taken from a fixed point in a codex (typically the
beginning of the second leaf) in order to provide a unique identifier
for it." This seems general enough but the prose is too restricted to
one tradition and I think should be changed:
from:
"The element (for ???secundo folio???) is used to record the
opening word or words of the second leaf of a manuscript. Since these
words differ from one copy of a text to another, the practice originated
in the middle ages of using them when cataloguing a manuscript in order
to distinguish individual copies of a work in a way which its opening
words could not."
to something like the following:
"The element (for ???secundo folio???) is used to record the
???identifying phrase??? (called also dictio probatoria) taken from a fixed
point in a codex.
Since these words differ from one copy of a text to another, the
practice originated in the middle ages of using them when cataloguing a
manuscript in order to distinguish individual copies of a work in a way
which its opening words could not."
- I wander whether should actually be part of
model.placeNamePart.
In this way, leaving the content model of as is, you
would have a sequence
with:
* one or more elements -that may occur only once- defining the location
in general (members of model.placeNamePart_sequenceOptional)
* one or two elements (repository/collection) defining the internal
location
At the same time though seems to be a special case of what
is now . Should this be at least mentioned?
- "As mentioned above, the smallest possible description is one that
contains only the element ; internally to that element,
the three subelements , , and are
required, since they provide what is, by common consent, the minimum
amount of information necessary to identify a manuscript."
But this is not what is enforced by the schema for which
is - rightly in my opinion - more permissive.
- "In the latter, however, the subelements, if used, must be given in
the order specified above; they may be repeated, with the exception of
, , and , each of which can appear only once."
unless I am wrong, should be substituted with:
"In the latter, however, the subelements, if used, must be given in the
order specified above; they may be repeated, with the exception of
, , , and , each of
which can appear only once."
- "Neither nor may contain untagged running
text, although may contain one or more

elements as an
unstructured alternative to the possible components listed above."
but also can contain, alternatively, one or more model.pLike.
- the examples with must be checked to see whether needs to
be used instead.
- "If it is desired to retain the form of the author's name as given in
the manuscript, this may be tagged as a distinct element, nested
within the element with the normalized form of the name on its
reg attribute. Alternatively, the normalized form of the name may be
supplied as the value of a reg attribute on the element."
The last sentence should be taken out.
- Specs for : in the description for the attribute
@mainLang/@otherLangs a link to the IANA Language Subtag registry could
be added (http://www.iana.org/assignments/language-subtag-registry).
- if the work on stemmata will be included in the guidelines, a
reference to that could be included under the 'Filiation' section in
this chapter.
- I am not sure the example with the Old Church Slavonic language is
appropriate since there is already a IANA subtag - Cyrs - for Old Church
Slavonic written in Cyrillic. Same is valid for Russian and Greek.
- "10 Bl."
I think this is wrong. 'count' cannot be a unit. The leaf is the unit here.
- I understand why the attribute @scribe for has as value
data.name, since most of the times we don't know much about scribes
besides what their hand witnesses, but when we do, I think this
attribute could be used as pointer to a person element. How could we
allow for this second use?
The same attribute name (@scribe) has data type data.code for .
[but see below]
- While I was looking at , I realised how confusing is the
situation with hands and this reminded me of an email read quickly after
my holidays (30th of July TEI list - conversation between Elena
Pierazzo/Lou).
In summary we have the elements:
- hand/ - PH
- handList - PH
- handShift/ - PH
- handDesc - MS
- handNote - MS
and share various attributes, some of which describe
the same thing with different names (e.g @ink vs. @medium). I propose that:
1) clean attributes for (take out redundant attributes such as
@first) and include in a class e.g. att.handwritten:
scribe
hand
script
medium
scope
2) add additional attributes to e.g. @resp
3) model.handDescPart should contain only
4) can contain loose or model.handDescPart
4) should not be empty and include
If it is too much trouble for people to load the MS module when they
just want a list of hands, they could still use within the
profile description; although I would be tempted to eliminate this
possibility to avoid confusion.
- the elements , and are
all events related to objects and have the same content. It would make
sense to group them into a class e.g. model.objEventLike if they were
all used by the element , which currently uses them all, expect
which is included in instead.
This chapter is very granular and therefore useful, but sometimes new
elements are used where old could be adapted (e.g. history and custHistory).
- under the surrogates section a reference could be added to the new
digital facsimile material.
Arianna
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 12:44:13 EDT

From arianna.ciula at kcl.ac.uk Mon Sep 3 12:50:53 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 03 Sep 2007 17:50:53 +0100 Subject: SV: [tei-council] damage - what is it good for? In-Reply-To: <69E99682EC8E03448CD15F49438219CDF7E511@humxsrv1.hum.ku.dk> Message-ID: <46DC3B6D.3080303@kcl.ac.uk>
From: Arianna Ciula
Date: Mon, 03 Sep 2007 17:50:53 +0100
mh...I think that if you are interest only in the transcription as
'pure' text, you are not really worried about causes of damage or
suspected stains, but if you are interested in the history of the object
then those stains may become important clues and you may want to record
them carefully.
Given the difficulty in defining a damage though, it may be better to
use to point to a better description in the physical
description section if you have included the MS module (as I am sure
someone interested in the object would do) or in a taxonomy.
I would be in favour of keeping it myself.
Arianna
Matthew James Driscoll wrote:
> Well, for what it's worth, I've never used , nor really understood
> why anyone would. If you can read what it says, no problem; if you can read
> enough of it to make a reasonable guess at the missing bits use
> type="illegible">; and if you can't read anything at all use .
>
> Come to think of it, I've never really understood what was for
> either.
>
> Matthew
>
> -----Oprindelig meddelelse-----
> Fra: Lou Burnard [mailto:lou.burnard_at_oucs.ox.ac.uk]
> Sendt: 03 September 2007 16:36
> Til: TEI Council; Gabriel Bodard
> Emne: [tei-council] damage - what is it good for?
>
> As I proceed through PH wreaking havoc, I have come upon the
> element. This is allegedly used to mark a part of a manuscript within
> which there has been some damage to the carrier, e.g. by rubbing or
> singeing or spilling marmalade, but not so much as to make the
> transcriber unsure of what the writing actually says (if that were the
> case, the element should be used), nor so extensive as to make
> the writing (or the carrier) actually disintegrate or disappear (for
> which the element is available).
>
> As defined, respects textual structures even less than the
> other elements. If it is to be kept, it should probably be given a
> sister (analogous to ) so that it can point across
> div boundaries for example. Though even then there isn't any really
> satisfactory way of dealing with things like circular spots of damage in
> the middle of the page, which have to be split up into numerous
> elements.
>
> But since it is really about the state of the carrier, not the text, why
> would you want to record it anyway? I am sorely tempted to just remove
> it and see who protests....
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 12:50:05 EDT
From mjd at hum.ku.dk Mon Sep 3 12:57:25 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 3 Sep 2007 18:57:25 +0200 Subject: SV: SV: [tei-council] damage - what is it good for? Message-ID: <69E99682EC8E03448CD15F49438219CDF7E515@humxsrv1.hum.ku.dk>
From: Matthew James Driscoll
Date: Mon, 3 Sep 2007 18:57:25 +0200
Sorry, should have mentioned (I mean "history of the object" could be my
middle name): there is a place in for describing the state of the
artefact, in practice (I assume) mostly used for a description of damaged
bits, in particular as they affect the text.
I certainly take your point, though, that as a pointer to a fuller
description (i.e. this bit of damage starts here), it could be useful. Which
I suppose means that I agree with Lou (again; how boring).
Matthew
-----Oprindelig meddelelse-----
Fra: Arianna Ciula [mailto:arianna.ciula_at_kcl.ac.uk]
Sendt: 03 September 2007 18:51
Til: Matthew James Driscoll
Cc: Lou Burnard; TEI Council; Gabriel Bodard
Emne: Re: SV: [tei-council] damage - what is it good for?
mh...I think that if you are interest only in the transcription as
'pure' text, you are not really worried about causes of damage or
suspected stains, but if you are interested in the history of the object
then those stains may become important clues and you may want to record
them carefully.
Given the difficulty in defining a damage though, it may be better to
use to point to a better description in the physical
description section if you have included the MS module (as I am sure
someone interested in the object would do) or in a taxonomy.
I would be in favour of keeping it myself.
Arianna
Matthew James Driscoll wrote:
> Well, for what it's worth, I've never used , nor really understood
> why anyone would. If you can read what it says, no problem; if you can
read
> enough of it to make a reasonable guess at the missing bits use
> type="illegible">; and if you can't read anything at all use .
>
> Come to think of it, I've never really understood what was for
> either.
>
> Matthew
>
> -----Oprindelig meddelelse-----
> Fra: Lou Burnard [mailto:lou.burnard_at_oucs.ox.ac.uk]
> Sendt: 03 September 2007 16:36
> Til: TEI Council; Gabriel Bodard
> Emne: [tei-council] damage - what is it good for?
>
> As I proceed through PH wreaking havoc, I have come upon the
> element. This is allegedly used to mark a part of a manuscript within
> which there has been some damage to the carrier, e.g. by rubbing or
> singeing or spilling marmalade, but not so much as to make the
> transcriber unsure of what the writing actually says (if that were the
> case, the element should be used), nor so extensive as to make
> the writing (or the carrier) actually disintegrate or disappear (for
> which the element is available).
>
> As defined, respects textual structures even less than the
> other elements. If it is to be kept, it should probably be given a
> sister (analogous to ) so that it can point across
> div boundaries for example. Though even then there isn't any really
> satisfactory way of dealing with things like circular spots of damage in
> the middle of the page, which have to be split up into numerous
> elements.
>
> But since it is really about the state of the carrier, not the text, why
> would you want to record it anyway? I am sorely tempted to just remove
> it and see who protests....
>
>
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 12:58:49 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 18:29:05 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 23:29:05 +0100 Subject: [tei-council] Re: damage - what is it good for? In-Reply-To: <46DC3147.4070509@kcl.ac.uk> Message-ID: <46DC8AB1.9040208@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 23:29:05 +0100
Thanks to everyone for their input. I've now checked in a series of
changes which not only preserve but add and a new
attribute @group designed to do the sort of grouping of bits of damage
Gabby describes here. The text already suggested using for this
purpose, but no-one has ever understood that element, probably because
of the extreme obscurity of its discussion ... When I feel a lot
stronger I might also add an example showing how you might use it for
this purpose to SA.
I'm holding back on further changes to PH . As far as I know the
unresolved issues are only
(a) what means -- waiting for input from Conal
(b) what to do about hand/handDesc etc. -- I need to digest Arianna's
comments
(c) some more examples of use of are needed
Comments on other bits gratefully received!
Lou

Gabriel Bodard wrote:
> We've never used , I don't think. (Although there was at some
> time talk of using it to link a and that are really
> part of the same bit of damage. I didn't really see the point, since
> the whole problem with linking such things was that they might cross
> div or word structures. And now it appears that would have been abuse
> anyway.) As you describe it, however, it is the sort of thing that an
> epigrapher *would* want to record--deliberate or other damage to the
> surface of the stone not affecting our ability to read the text. (For
> deliberate I guess we use .)
>
> What *would* certainly be useful, however, is some way to indicate
> precisely what you describe: separate bits of damage (whether
> indicated by , , , or ) that are in
> fact the result of the same gouge out of the front of the stone, for
> example. Traditionally both epigraphers and papyrologists indicate
> that a gap and a supplied are part of the same damage by enclosing the
> two in a single set of square brackets. E.g.:
>
> [abc ...]
>
> (we can restore "abc" but not the rest of whatever was in that bit of
> damage... as opposed to:
>
> [abc] [...]
>
> = "abc" was lost because of (e.g.) surface wear, something else was
> lost because of (e.g.) the stone being cut down for re-use, and can't
> be restored)
>
> So in summary I've never used , and the only time I'd be
> likely to want to could arguably be handled by --but unclear
> for us has the very specific meaning that the letters so marked would
> not be unambiguous outside of their context. Therefore I'd vote for
> keeping it, but not scream and shout if I'm out-voted. :)
>
> Best,
>
> Gabby
>
> Lou Burnard a ?crit :
>> As I proceed through PH wreaking havoc, I have come upon the
>> element. This is allegedly used to mark a part of a manuscript within
>> which there has been some damage to the carrier, e.g. by rubbing or
>> singeing or spilling marmalade, but not so much as to make the
>> transcriber unsure of what the writing actually says (if that were
>> the case, the element should be used), nor so extensive as
>> to make the writing (or the carrier) actually disintegrate or
>> disappear (for which the element is available).
>>
>> As defined, respects textual structures even less than the
>> other elements. If it is to be kept, it should probably be given a
>> sister (analogous to ) so that it can point
>> across div boundaries for example. Though even then there isn't any
>> really satisfactory way of dealing with things like circular spots of
>> damage in the middle of the page, which have to be split up into
>> numerous elements.
>>
>> But since it is really about the state of the carrier, not the text,
>> why would you want to record it anyway? I am sorely tempted to just
>> remove it and see who protests....
>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 18:29:11 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 18:36:25 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 23:36:25 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DBD2AE.5010600@kcl.ac.uk> Message-ID: <46DC8C69.3080005@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 23:36:25 +0100
In the version of PH I just checked in, I've moved all the declarations
etc. to a section at the end of the chapter.
Does this look better?
Sebastian -- do all the *Spec elements have to be within a ? I
think not, but I left one for safety's sake.

Arianna Ciula wrote:
>
>
> James Cummings wrote:
>
>> At very least we should
>> get rid of the number. This is just a generated number, and has no real
>> meaning to the reader.
>
> Agree
>
> Another option is to, in presentation form on,
>> as a final division to each chapter have a section where all of these
>> are dealt with at once, once per module/chapter, rather than having
>> them spread throughout the chapter.
>
> I think this is a good idea, but I am not sure how feasible it is
> given the short time we have and more urgent priorities. Indeed, it
> seems to me that every chapter has a slightly different structure that
> would make this task rather time consuming. The editors know better.
>
> Arianna
>
>
>
>> As there is often prose which introduces the specGrpRefs and
>> specGrps, there would need to be editorial changes to this, and the
>> editors have been tasked with removing this regardless. (We should be
>> able to automate the addition of leading prose if we do decide to
>> retain these.)
>>
>> As you've all doubtless read in the minutes, you are all tasked with
>> discussing this and coming to some decision by 2007-09-07.
>>
>> -James
>>
>> [1] I chose Specification Group 42 at (near)random and really have no
>> interest in that one in particular, I've not bothered to look it up.
>>
>
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 18:36:30 EDT

From cwittern at gmail.com Mon Sep 3 18:45:13 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 04 Sep 2007 07:45:13 +0900 Subject: [tei-council] concerns regarding In-Reply-To: <46DBCAFD.7060904@oucs.ox.ac.uk> Message-ID: <46DC8E79.1030905@gmail.com>
From: Christian Wittern
Date: Tue, 04 Sep 2007 07:45:13 +0900
Lou Burnard wrote:
> I could live with this change. However:
>
> (a) I have an ousttanding action to make all listXXX things look the
> same, and I don't think that would work for listChar (which would
> presumably contain a mixture of char and glyph elements and wouldn'tt
> self-nest)
>
Right. But it is still list-like enough to be called thus.
> (b) the pattern elsewhere in the header is to have a *decl including
> multiple *desc
> (c) each individual or is really a *desc
>
In short, the change is unnecessary and the naming follows established
practice? In that case, it is fine with me:-)
> How about
>
> nonstandardChars containing (charDesc|glyphDesc)+
>
No, please. This would cause too much confusion for current users of the
gaiji module.
> I dunno what the is doing inside the current --
> wouldnt it be more use be inside each and ?
>
>
There is also one inside these. We felt there should be a place for an
overall description of the whole bunch. Given that note is presumably
now allowed here, we might get rid of this. On the other hand, I am
unconfortable making such changes at this point.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 18:45:24 EDT

From cwittern at gmail.com Mon Sep 3 18:46:53 2007 From: cwittern at gmail.com (Christian Wittern) Date: Tue, 04 Sep 2007 07:46:53 +0900 Subject: [tei-council] concerns regarding In-Reply-To: <46DBC973.1010909@oucs.ox.ac.uk> Message-ID: <46DC8EDD.1090401@gmail.com>
From: Christian Wittern
Date: Tue, 04 Sep 2007 07:46:53 +0900
Sebastian Rahtz wrote:
> may be more consistent to name it , in line with ?
>
>
>
Yep. That might solve Lou's problem with naming it . So I'll
go with this if there is no strong opinion against it.
Christian

-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Mon Sep 03 2007 - 18:47:17 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 18:47:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 03 Sep 2007 23:47:27 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DC8C69.3080005@oucs.ox.ac.uk> Message-ID: <46DC8EFF.3060108@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Mon, 03 Sep 2007 23:47:27 +0100
Lou Burnard wrote:
> In the version of PH I just checked in, I've moved all the
> declarations etc. to a section at the end of the chapter.
>
> Does this look better?
To be honest, no. Maybe in the printed version, but on the web
page it looks redundant. In context I could see some point;
but grouped together, I'd just omit it.
>
> Sebastian -- do all the *Spec elements have to be within a ?
> I think not, but I left one for safety's sake.
*Spec must appear inside either or , so yes.
ebastian
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 18:47:00 EDT
From lou.burnard at oucs.ox.ac.uk Mon Sep 3 18:51:20 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 23:51:20 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DC8EFF.3060108@oucs.ox.ac.uk> Message-ID: <46DC8FE8.3030804@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 23:51:20 +0100
Sebastian Rahtz wrote:
> Lou Burnard wrote:
>> In the version of PH I just checked in, I've moved all the
>> declarations etc. to a section at the end of the chapter.
>>
>> Does this look better?
> To be honest, no. Maybe in the printed version, but on the web
> page it looks redundant. In context I could see some point;
> but grouped together, I'd just omit it.
It's handy to have a list of what this module makes available though. At
present this is what generates. Could this be tweaked to
give them in alphabetical rather than declaration order maybe? Then you
could just suppress output from the .

>>
>> Sebastian -- do all the *Spec elements have to be within a ?
>> I think not, but I left one for safety's sake.
> *Spec must appear inside either or , so yes.
>
OK. So we have, in the simple case, one specGrp per chapter.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 18:51:26 EDT

From lou.burnard at oucs.ox.ac.uk Mon Sep 3 18:52:50 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 03 Sep 2007 23:52:50 +0100 Subject: [tei-council] concerns regarding In-Reply-To: <46DC8EDD.1090401@gmail.com> Message-ID: <46DC9042.4070402@oucs.ox.ac.uk>
From: Lou Burnard
Date: Mon, 03 Sep 2007 23:52:50 +0100
Christian Wittern wrote:
> Sebastian Rahtz wrote:
>
>> may be more consistent to name it , in line with ?
>>
>>
>>
>>
> Yep. That might solve Lou's problem with naming it . So I'll
> go with this if there is no strong opinion against it.
>
>
But you wouldn't like renaming and to and
?

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 18:52:56 EDT

From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 3 19:08:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 04 Sep 2007 00:08:36 +0100 Subject: [tei-council] and formatting In-Reply-To: <46DC8FE8.3030804@oucs.ox.ac.uk> Message-ID: <46DC93F4.4040207@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 04 Sep 2007 00:08:36 +0100
Lou Burnard wrote:
> It's handy to have a list of what this module makes available though.
> At present this is what generates. Could this be tweaked
> to give them in alphabetical rather than declaration order maybe?
surely. done.

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Mon Sep 03 2007 - 19:08:09 EDT
From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 4 11:39:40 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 04 Sep 2007 16:39:40 +0100 Subject: [tei-council] bibliography and examples Message-ID: <46DD7C3C.8060907@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 04 Sep 2007 16:39:40 +0100
It struck me that normalizing a for as many s as we
possibly
can would be very useful for legal purposes; if we are challenged on our
right to take bits of published works, indicating that something *is*
a quotation would show (at least) that we were not being deliberately
dishonest.

-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Sep 04 2007 - 11:39:43 EDT

From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 4 12:29:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 04 Sep 2007 17:29:50 +0100 Subject: [tei-council] fully-licensed images of manuscripts Message-ID: <46DD87FE.1090908@oucs.ox.ac.uk>
From: Sebastian Rahtz
Date: Tue, 04 Sep 2007 17:29:50 +0100
It would make life easier if the TEI Guidelines were able
to use images of manuscripts which have unlimited
licenses (ie NOT with a "Non-Commercial" clause).[1]
Do any of you know where we can find such things?
We need some pictures of manuscripts which are
comprehensible to ordinary mortals (ie not in Greek or
Anglo-Saxon), and which exhibit common features
like crossing-out, illegible, etc etc.
Alternatively, a printed book with pictures which is out of
copyright would so as well.
[1] unless you want to re-open the debate of whether
the Guidelines should follow open-source licensing...
-- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Sep 04 2007 - 12:29:53 EDT
From cwittern at gmail.com Tue Sep 4 20:19:33 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 05 Sep 2007 09:19:33 +0900 Subject: [tei-council] concerns regarding In-Reply-To: <46DC9042.4070402@oucs.ox.ac.uk> Message-ID: <46DDF615.30303@gmail.com>
From: Christian Wittern
Date: Wed, 05 Sep 2007 09:19:33 +0900
Lou Burnard wrote:
> Christian Wittern wrote:
>
>> Sebastian Rahtz wrote:
>>
>>
>>> may be more consistent to name it , in line with ?
>>>
>>>
>>>
>>>
>>>
>> Yep. That might solve Lou's problem with naming it . So I'll
>> go with this if there is no strong opinion against it.
>>
>>
>>
> But you wouldn't like renaming and to and
> ?
>
>
>
>
Yes, I'd like to keep these two as they are. They are quite handy like
that and I would specifically not like to re-use the now abolished
, since this would cause confusion to current users, me thinks.
Christian
-- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Tue Sep 04 2007 - 20:19:46 EDT
From lou.burnard at oucs.ox.ac.uk Tue Sep 4 20:41:26 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Sep 2007 01:41:26 +0100 Subject: [tei-council] concerns regarding In-Reply-To: <46DDF615.30303@gmail.com> Message-ID: <46DDFB36.5080102@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 05 Sep 2007 01:41:26 +0100
Christian Wittern wrote:
> Lou Burnard wrote:
>
>> Christian Wittern wrote:
>>
>>
>>> Sebastian Rahtz wrote:
>>>
>>>
>>>
>>>> may be more consistent to name it , in line with ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Yep. That might solve Lou's problem with naming it . So I'll
>>> go with this if there is no strong opinion against it.
>>>
>>>
>>>
>>>
>> But you wouldn't like renaming and to and
>> ?
>>
>>
>>
>>
>>
> Yes, I'd like to keep these two as they are. They are quite handy like
> that and I would specifically not like to re-use the now abolished
> , since this would cause confusion to current users, me thinks.
>
> Christian
>
>
OK, tis done. And I am going to bed.
Good night!
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Tue Sep 04 2007 - 20:41:33 EDT
From laurent.romary at loria.fr Wed Sep 5 05:58:19 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 5 Sep 2007 11:58:19 +0200 Subject: [tei-council] Comments on "Documentation Elements" Message-ID:
From: Laurent Romary
Date: Wed, 5 Sep 2007 11:58:19 +0200
[I read the HTML version under http://tei.oucs.ox.ac.uk/P5/Guidelines-
web/en/html/TD.html]
Replace [for sake of simplifiation]:
- "which are to be documented and also declared" by
- "which are to be declared"
I would move the presentation of to "Elements available TEI
documents" not far from , and the like. At least a
sentence should be adde to the paragraph "The element may be
used...", i.e. "When an exemple is actually quoted from a source, the
element should be referably used." And should not be also
a member of model.qLike (since it is a specialized form of ).
Remove extraneous slash in the specDesc of specDesc (bug?)
Same bug with the speDesc's of specGrpRef and attRef

_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Sep 05 2007 - 06:00:09 EDT

From lou.burnard at oucs.ox.ac.uk Wed Sep 5 10:17:03 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Sep 2007 15:17:03 +0100 Subject: [tei-council] MS Manuscript Description chapter: notes (part 1) In-Reply-To: <46DC39FC.4040905@kcl.ac.uk> Message-ID: <46DEBA5F.1050008@oucs.ox.ac.uk>
From: Lou Burnard
Date: Wed, 05 Sep 2007 15:17:03 +0100
Thanks for this Arianna. Here's a quick report on how far I've got so
far with your very helpful comments on this chapter.

Arianna Ciula wrote:
> - "The element will normally appear within the
> element of the header of a TEI conformant document, where the document
> being encoded is a digital representation of some manuscript original,
> whether as a transcription, as a collection of digital images, or as
> some combination of the two."
>
> I think something should be said here about the new facsimile section on
> the Representation of Primary sources chapter, at least in a footnote.
>
Agreed; added a cross reference.

> - att.measurement/att.dimensions
>
> I know that thanks to Syd's work these classes had reached a more stable
> state
> (and sorry it didn't get enough feedback or attention from us when
> needed), but it seems really silly to have slightly different
> definitions of @unit and @quantity (they should be uniformed to what is
> now in att.measurement, in my opinion).
This is the result of an unresolved disagreement between the editors.
The current situation is that
att.dimensions (members being depth, dimensions, height, space, width)
gives you @unit, @quantity, @scope
att.measurement (members being measure and measureGrp) gives you @unit,
@quantity, @commodity
The definitions for the attributes in common should be consistent,
clearly, and the best way to do this would probably be to move the
attributes not shared between the two out of the class.
The unresolved disagreement (as far as I recall) is about what the
specification for @unit should say. I take the view that we should not
include (as att.measurement currently does) all SI units here, but
simply those which are most likely to be useful to text encoders, with a
reference to the others.
>
> - I think the attribute @targets for should be @target instead,
> for consistency with
I agree that consistency is desirable, but as you point out, this
attribute duplicates the function of the @facs attribute available when
PH is loaded. So the easiest thing would be to remove it.
> - by the way, this attribute of may conflict with @facs in its
> function when the PH module is loaded even if here we are not
> transcribing but describing a manuscript. This raises the question: can
> the facsimile element be used in combination with a manuscript
> description without a transcription? I think it should.
Yes.
> We could may be mention that if the PH module is also used, the @facs
> attribute is preferred over @targets to connect less directly but more
> explicitly to image files.
>
@facs can be used in *exactly* the same way as the current @targets --
i.e. without benefit of intervenming -- this was one of the
things that some council members expressed reservations about, but it is
clearly stated in PH as an option, though a deprecated one. So I have
now removed @targets.

> - "The reference #txt182 in this example is assumed to reference the
> section of the manuscript ???up to fol. 182v??? which has been transcribed
> elsewhere in the current document; the references
> http://www.images.fr#F33R and http://www.images.fr#F59V link to images
> of the relevant pages, held presumably in an image archive."
>
> The first part of this sentence doesn't seem to refer to a pointer in
> the example (#txt182 is not in the example). Probably the example has
> been changed and the prose left as it was.
This example is most peculiar! To avoid confusion, I've trimmed it down
to exclude the "up to fol.182v" bit completely.
>
> - example with multiple foliation schemes: TO DO
>
> I could provide one.
Please do!

>
> - "In order for this second Hoccleve example to be valid, a
> element must be provided which has the value HOCCL1 for its xml:id
> attribute; the same value will be used as the key attribute of every
> reference to Hoccleve in the document (however spelled), but there will
> only be one element with this identifier."
>
> @ref should be used instead of @key in the example and substituted in
> the prose.
Done
>
> - "Similar mechanisms may be used to create and maintain canonical lists
> of places or organizations, but no specific elements are defined for
> this purpose."
>
> There are now...so we need a reference to the new section on places here.
Indeed yes. Done. I have also added some discussion on @key as distinct
from @ref

>
> - the formal definition of in the Specs is "(secundo folio) The
> word or words taken from a fixed point in a codex (typically the
> beginning of the second leaf) in order to provide a unique identifier
> for it." This seems general enough but the prose is too restricted to
> one tradition and I think should be changed:
>
> from:
> "The element (for ???secundo folio???) is used to record the
> opening word or words of the second leaf of a manuscript. Since these
> words differ from one copy of a text to another, the practice originated
> in the middle ages of using them when cataloguing a manuscript in order
> to distinguish individual copies of a work in a way which its opening
> words could not."
>
> to something like the following:
> "The element (for ???secundo folio???) is used to record the
> ???identifying phrase??? (called also dictio probatoria) taken from a fixed
> point in a codex.
> Since these words differ from one copy of a text to another, the
> practice originated in the middle ages of using them when cataloguing a
> manuscript in order to distinguish individual copies of a work in a way
> which its opening words could not."
>
Fine.

> - I wander whether should actually be part of
> model.placeNamePart.
> In this way, leaving the content model of as is, you
> would have a sequence
> with:
> * one or more elements -that may occur only once- defining the location
> in general (members of model.placeNamePart_sequenceOptional)
> * one or two elements (repository/collection) defining the internal
> location
>
> At the same time though seems to be a special case of what
> is now . Should this be at least mentioned?
>
This does seem problematic. Can an institution have more than one
physical location? I would rather think that it can: hence it seems to
be more like an orgName than a placeName. Maybe we should throw out
institution in favour of orgName ?
Is a a kind of orgName or a kind of placeName? It seems
more like the latter. the BL Sound Archive for example has more than one
repository in different places.
No change yet, pending further contemplation.

> - "As mentioned above, the smallest possible description is one that
> contains only the element ; internally to that element,
> the three subelements , , and are
> required, since they provide what is, by common consent, the minimum
> amount of information necessary to identify a manuscript."
>
> But this is not what is enforced by the schema for which
> is - rightly in my opinion - more permissive.
>
Wording changed:

As mentioned above, the smallest possible description is one that
contains only the element msIdentifier; good practice in all
but exceptional circumstances requires the presence of the three
subelements settlement, repository, and
idno are required, since they provide what is, by common
consent, the minimum amount of information needed to identify a
manuscript.


> - "In the latter, however, the subelements, if used, must be given in
> the order specified above; they may be repeated, with the exception of
> , , and , each of which can appear only once."
>
> unless I am wrong, should be substituted with:
> "In the latter, however, the subelements, if used, must be given in the
> order specified above; they may be repeated, with the exception of
> , , , and , each of
> which can appear only once."
>
Correct. Also added a sentence to point ouit that msItemStruct can also
self-nest, bizarrely. The more I look at it, the more I think this
element is a Bad Idea, but I suppose I'd better not kill it just yet.
[... more to come later! ...]
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Sep 05 2007 - 10:17:07 EDT
From lou.burnard at oucs.ox.ac.uk Wed Sep 5 12:05:03 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Sep 2007 17:05:03 +0100 Subject: [tei-council] MS Manuscript Description chapter: notes In-Reply-To: <46DC39FC.4040905@kcl.ac.uk> Message-ID: <20070905160503.720C79A002@webmail223.herald.ox.ac.uk>
From: Lou Burnard
Date: Wed, 05 Sep 2007 17:05:03 +0100
....
> - "Neither nor may contain untagged running
> text, although may contain one or more

elements as an
> unstructured alternative to the possible components listed above."
>
> but also can contain, alternatively, one or more model.pLike.
This is not the least weird thing about it. However, I've not changed it but
simply expanded the discussion of its model to specify this possibility.

>
> - the examples with must be checked to see whether needs to
> be used instead.
absolutely: these examples are all Wrong by the new rules. Modified accordingly.
>
> - "If it is desired to retain the form of the author's name as given in
> the manuscript, this may be tagged as a distinct element, nested
> within the element with the normalized form of the name on its
> reg attribute. Alternatively, the normalized form of the name may be
> supplied as the value of a reg attribute on the element."
>
> The last sentence should be taken out.
>
... and shot. There is no @reg attribute on author, nor should there be since it
is defined as containing a regularized form of the name. And there is no @reg
attribute on either!

> - Specs for : in the description for the attribute
> @mainLang/@otherLangs a link to the IANA Language Subtag registry could
> be added (http://www.iana.org/assignments/language-subtag-registry).
>
The whole discussion of textLang attribute values is Wrong. I have tidied it up
considerably. I have not however checked to see if the reference you give is the
same thing as BCP47, which is what we seem to have decided we should be citing.

> - if the work on stemmata will be included in the guidelines, a
> reference to that could be included under the 'Filiation' section in
> this chapter.
Duly noted.
>
> - I am not sure the example with the Old Church Slavonic language is
> appropriate since there is already a IANA subtag - Cyrs - for Old Church
> Slavonic written in Cyrillic. Same is valid for Russian and Greek.

see above!
>
> - "10 Bl."
>
> I think this is wrong. 'count' cannot be a unit. The leaf is the unit here.
>
yes. this looks silly. I have changed to type=composition and unit=leaf
Don't ask me what "Bl." means though.
> - I understand why the attribute @scribe for has as value
> data.name, since most of the times we don't know much about scribes
> besides what their hand witnesses, but when we do, I think this
> attribute could be used as pointer to a person element. How could we
> allow for this second use?
> The same attribute name (@scribe) has data type data.code for .
> [but see below]
>
>
Changes to hand/List etc. and also the new class objEventLike I will discuss in
a separate message. When I've had a chance to try implementing your seductive
notions...
>
> - under the surrogates section a reference could be added to the new
> digital facsimile material.
>
Added.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Wed Sep 05 2007 - 12:05:06 EDT

From arianna.ciula at kcl.ac.uk Wed Sep 5 12:59:51 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 05 Sep 2007 17:59:51 +0100 Subject: [tei-council] MS Manuscript Description chapter: notes (part 1) In-Reply-To: <46DEBA5F.1050008@oucs.ox.ac.uk> Message-ID: <46DEE087.8000400@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 05 Sep 2007 17:59:51 +0100
Lou Burnard wrote:
>> - example with multiple foliation schemes: TO DO
>>
>> I could provide one.
>
> Please do!
>
http://www.diamm.ac.uk/diamm/apps/Source.jsp?navToggle=1&sourceKey=295
MS 65 Corpus Christi College, Cambridge
"The music pages are 2 flyleaves at the end of the ms and bear an
original foliation (XCIII =modern 135, and C =modern 136)."
where the specific locations in the MS could be wrapped as following:
XCIII
135
>> - I wander whether should actually be part of
>> model.placeNamePart.
>> In this way, leaving the content model of as is, you
>> would have a sequence
>> with:
>> * one or more elements -that may occur only once- defining the
>> location in general (members of model.placeNamePart_sequenceOptional)
>> * one or two elements (repository/collection) defining the internal
>> location
>>
>> At the same time though seems to be a special case of what
>> is now . Should this be at least mentioned?
>>
>
> This does seem problematic. Can an institution have more than one
> physical location? I would rather think that it can: hence it seems to
> be more like an orgName than a placeName. Maybe we should throw out
> institution in favour of orgName ?
Yes, I do agree that is more like an and I
wouldn't cry if we use and take out .
>
> Is a a kind of orgName or a kind of placeName? It seems
> more like the latter. the BL Sound Archive for example has more than one
> repository in different places.
>
> No change yet, pending further contemplation.
mh... seems to be more of a .
Arianna
>
>> - "As mentioned above, the smallest possible description is one that
>> contains only the element ; internally to that element,
>> the three subelements , , and are
>> required, since they provide what is, by common consent, the minimum
>> amount of information necessary to identify a manuscript."
>>
>> But this is not what is enforced by the schema for
>> which is - rightly in my opinion - more permissive.
>>
>
> Wording changed:
>
>

As mentioned above, the smallest possible description is one that
> contains only the element msIdentifier; good practice in all
> but exceptional circumstances requires the presence of the three
> subelements settlement, repository, and
> idno are required, since they provide what is, by common
> consent, the minimum amount of information needed to identify a
> manuscript.


>
>> - "In the latter, however, the subelements, if used, must be given in
>> the order specified above; they may be repeated, with the exception of
>> , , and , each of which can appear only once."
>>
>> unless I am wrong, should be substituted with:
>> "In the latter, however, the subelements, if used, must be given in
>> the order specified above; they may be repeated, with the exception of
>> , , , and , each of
>> which can appear only once."
>>
>
> Correct. Also added a sentence to point ouit that msItemStruct can also
> self-nest, bizarrely. The more I look at it, the more I think this
> element is a Bad Idea, but I suppose I'd better not kill it just yet.
>
> [... more to come later! ...]
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Sep 05 2007 - 12:59:06 EDT
From arianna.ciula at kcl.ac.uk Wed Sep 5 12:59:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 05 Sep 2007 17:59:58 +0100 Subject: [tei-council] MS Manuscript Description chapter: notes In-Reply-To: <20070905160503.720C79A002@webmail223.herald.ox.ac.uk> Message-ID: <46DEE08E.3020909@kcl.ac.uk>
From: Arianna Ciula
Date: Wed, 05 Sep 2007 17:59:58 +0100
Lou Burnard wrote:
>> - "If it is desired to retain the form of the author's name as given in
>> the manuscript, this may be tagged as a distinct element, nested
>> within the element with the normalized form of the name on its
>> reg attribute. Alternatively, the normalized form of the name may be
>> supplied as the value of a reg attribute on the element."
>>
>> The last sentence should be taken out.
>>
>
> ... and shot. There is no @reg attribute on author, nor should there be since it
> is defined as containing a regularized form of the name. And there is no @reg
> attribute on either!
that's what I meant, yes.
>
>
>> - Specs for : in the description for the attribute
>> @mainLang/@otherLangs a link to the IANA Language Subtag registry could
>> be added (http://www.iana.org/assignments/language-subtag-registry).
>>
> The whole discussion of textLang attribute values is Wrong. I have tidied it up
> considerably. I have not however checked to see if the reference you give is the
> same thing as BCP47, which is what we seem to have decided we should be citing.
It should be the most updated list...but we need someone more expert
than me on this. In general, I find it daunting when a resource points
to the description of a standard but doesn't give the list of concrete
codes to use.
>> - "10 Bl."
>>
>> I think this is wrong. 'count' cannot be a unit. The leaf is the unit here.
>>
>
> yes. this looks silly. I have changed to type=composition and unit=leaf
> Don't ask me what "Bl." means though.
I thinks it stays for 'blank'.
Arianna
>
>> - I understand why the attribute @scribe for has as value
>> data.name, since most of the times we don't know much about scribes
>> besides what their hand witnesses, but when we do, I think this
>> attribute could be used as pointer to a person element. How could we
>> allow for this second use?
>> The same attribute name (@scribe) has data type data.code for .
>> [but see below]
>>
>>
>
> Changes to hand/List etc. and also the new class objEventLike I will discuss in
> a separate message. When I've had a chance to try implementing your seductive
> notions...
>
>> - under the surrogates section a reference could be added to the new
>> digital facsimile material.
>>
>
> Added.
>
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Wed Sep 05 2007 - 12:59:24 EDT
From lou.burnard at oucs.ox.ac.uk Thu Sep 6 12:30:52 2007 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 06 Sep 2007 17:30:52 +0100 Subject: [tei-council] Further update on PH Message-ID: <20070906163052.4C7619A002@webmail223.herald.ox.ac.uk>
From: Lou Burnard
Date: Thu, 06 Sep 2007 17:30:52 +0100
I've now done more work on updating PH, following a set of very helpful comments
from Arianna and others at King's. Details attached.
I'm still waiting on Conal for input about what a surface is though. And I still
haven#'t sorted out the mess which is etc. But the rest of this
chapter is now looking quite solid, methinks.

AC] - "It should be noted that this chapter focuses primarily upon problems
AC] associated with manuscript materials, and that consequently problems of
AC] codicology and other matters peculiar to early printed materials are not
AC] specifically addressed here."
AC]
AC] I am not sure that 'consequently' is a good word here. Indeed codicology
AC] deals mainly with manuscript materials and the way they are combined. We
AC] could probably say that this chapter aims at facilitating the basic
AC] representation of cultural artifacts in connection with their textual
AC] components rather than dealing with the description of their detailed
AC] physical making and composition.
AC]
How about
"It should be noted that, as elsewhere in these Guidelines, this
chapter places more emphasis on the problems of representing the
textual components of a document than on those relating to the
description of the document's physical characteristics such as the
carrier medium or physical construction. These aspects, of particular
importance in codicology and the bibliographic study of incunables,
are touched on in the chapter on Manuscript Description ( target="#MS"/>) and also form the subject of ongoing work in the TEI
Physical Bibliography workgroup."
I've also revised the following para, as follows:

Although this chapter discusses manuscript materials more
frequently than other forms of written text, most of the
recommendations presented are equally applicable mutatis
mutandis in the encoding of printed matter or indeed any
form of written source, including monumental inscriptions. Similarly,
where in the following descriptions terms such as
scribe, author,
editor, annotator or
corrector are used, these may be re-interpreted
in terms more appropriate to the medium being transcribed. In printed
material, for example, the compositor plays a
role analogous to the scribe, while in an
authorial manuscript, the author and the scribe are the same person.


AC]
AC] - trancribed --> trascribed
AC]
Ooops!

AC] - "The grid point a b is understood to be
AC] the point which is located a points from the origin along the AC] rend=3D"math">x
AC] (horizontal) axis, and b points from the origin
AC] along the y (vertical)
AC] axis"
AC]
AC] should be
AC]
AC] "The grid point a b is understood to be
AC] the point which is located a points from the origi=
AC] n
AC] along the x
AC] (horizontal) axis, and b points from the origin
AC] along the y (vertical)
AC] axis"
Indeed it should. And now does.

AC]
AC] By the way doesn't seem to be rendered anyway different
AC] from the main text, which doesn't help readability in this case.
One for James/Dot!

AC]
AC] I think some people may understand better this note and the concept
AC] behind it whit the help of an image of a grid superimposed on a figure.
AC]
A figure inside the footnote? I hope you don't mean that. I suppose a
figure in the text might be useful, but it might look as if we were
trying to teach is fairly elementary geometry. The footnote is just
there as an aide memoire for those (like me) whose memory of O-level
maths is starting to fade...

AC] - "more delicate grid"
AC]
AC] do you mean more granular here?
Well, to be exact I mean "a grid of more delicate granularity", but
that's a bit of a mouthful!
AC]
AC] - "Since this image contains more than one page however, and has not
AC] been cropped, it might be better to define two distinct surfaces, one
AC] for each page."
AC]
AC] I would add "...one for each page, including the illuminated margins" to
AC] make clear that we are not considering the writing frame only as cropped
AC] section.
AC]
have added ", including its illuminated margins" before the
fullstop. But note that this may need further revision if Conal
persuades us that "surface" means something different.

AC] - either I am not understanding how this works or there is something
AC] wrong here:
AC]
AC]
AC]
AC]
AC] AC]
AC] url=3D"http://commons.wikimedia.org/wiki/Image:Handschrift.karlsruhe.blb.=
AC] jpg"/>
AC]
AC]
AC]
AC] AC]
AC] url=3D"http://commons.wikimedia.org/wiki/Image:Handschrift.karlsruhe.blb.=
AC] jpg"/>
AC]
AC]
AC]
AC] The coordinates of the left hand page are not well defined. The
AC] second couple of coordinates is wrong. It should be something like 220
AC] 280 instead; same in the example that follows where otherwise the
AC] writing frame wouldn't be included in the coordinates of the surface.
AC]
You are right. This is a typo. Should be 50 20 210 280.

AC] I am not dealing here with the meaning of (I believe we can
AC] express our preferences once Conal has drafted his proposal).
AC]
yes.

AC] - written part --> writing frame
AC]
Hmm, is this a technical term? I havent come across it before (and am
not online so cannot check) I've changed it to "written area" for the
moment. And note that we are not talking about the area actually
marked for writing in in the original (e.g. by pricking); it includes
margins etc.

AC] - "Since all elements use the same co-ordinate system (that
AC] defined by their parent ," --> missing closing round bracket
AC]
Fixed

AC] - what about having @facsRef when the attribute points to a
AC] element -and only @facs when it points to another type of URI (e.g.=20
AC] image)-; we could then have @textRef instead of @start, which, to be=20
AC] honest, I don't like very much.
AC]
I'm a bit reluctant to add yet more attributes, to tell the truth. We
have lots of URI attributes, and only in a few cases do we try to express any
constraint on what they can point to, even fewer where we go to the
lengths of providing two different attributes to do the same thing but
with different names depending on how you reach the desired target. The @facs
attribute
points to an image. Sometimes you find the image via a proper
element, which is our recommendation; sometimes you find
it floating about in cyberspace. I think that's a reasonable
compromise between ease of processing and ease of encoding.
I'm not crazy about @start myself. But it needs to make explicit that
you are not necessarily pointing to all and only the text depicted by
the image: so the name is chosen to indicate that at least the "start"
of the image (whatever that means) and the start of the text are
aligned.

AC] - "In many cases the glyph found in the manuscript source also exists
AC] in the Unicode character set: for example ."
AC]
AC] You could use the following:
AC] MUFI entity: &et;
AC] Code point (Unicode): 204A
AC] Junicode: F143
AC] Unicode descriptive name: TIRONIAN SIGN ET
AC] MUFI descriptive name: LATIN ABBREVIATION SIGN ET
AC]
Beautiful example, just what I wanted!
Have now inserted
"

In many cases the glyph found in the manuscript source also exists
in the Unicode character set: for example the common Latin brevigraph
⁊, standing for et and often known as
the Tironian et can be directly represented in
any XML document as the Unicode character with code point
x204A (see further and target="#CHSH"/>). " before "In cases where it does not..."
AC] - I think the proposal with expan/ex is great! [I asked Elena's opinion
AC] as well and she seems very satisfied by this]. My only doubt is about
AC] nesting. Indeed both and seem to have the possibility to=20
AC] self nest. Has this been done on purpose?
AC]
Well, (and ) cannot self nest. It's true that and
can though. The problem is both defining a content model to preclude
this or coming up with a good reason why you might not want to. Some
mad person will always want to treat e.g. USAF as two abbreviations
("US" and "AF"), and hence producing two nested expansions ("United
States" and "Air Force").... it's the TEI Way. (trademark)

AC] - "In the general case, encoding this is best done using the mechanisms
AC] described in the module for textual criticism described in chapter 24.2
AC] Personalization and Customization."
AC]
AC] I think here you probably wanted to link to the Critical Apparatus
AC] chapter instead.
Ooops. yes. That sentence is a bit wordy too.

AC]
AC] - "This encoding asserts that the reading wyf found in Gg is regarded as
AC] a correction by Parkes."
AC]
AC] I am not sure about this example where @resp is within in a
AC] . I understand it, but I think in general an editor would use the
AC] element, wouldn't he? it is true that can occur only once in
AC] an and therefore it would be difficult to express multiple
AC] responsibilities on different corrections as this examples shows, but in
AC] general to use a single reading to make a new edition you would use
AC] .
AC]
It seems strange to me too, because elsewhere we use
only for things that are not witnessed at all, whereas here it means
"not witnessed in the source being encoded". I am agnostic on whether
or not to keep this discussion; removing it is quite a big change
though.

AC] - "If no other source is indicated (either by the source attribute, or
AC] by the wit attribute of a parent ), the reading supplied within a
AC] has been provided by the person indicated by the resp attribute."
AC]
AC] As above I understand this, but the meaning of is a bit stretched
AC] here, since it is not a variant witnessed in a source we are talking
AC] about in this case, but rather what is normally considered in these
AC] guidelines as a 'supplied' string.
But it is witnessed, surely? It's in Gg. The encoding is saying (a)
there is a different reading at this point in a certain ms and (b)
Parkes thinks that this different reading should be used to correct
the others.

AC]
AC] -
AC]
AC] if will get the same attributes of the current , this
AC] should be:
AC]
AC]
AC]
This loses the fact that Max is the author as well as the writer,
doesn't it? But you're right that the attribute value should not be a
string of words
AC] or even better
AC]
AC] This manuscript is an holograph by Max Beerbohm
AC]
AC]
AC] Whatever happens with the attributes of , the @scribe value should
AC] still be a pointer, according to the specs.
AC] Same is valid for in the exam=
AC] ple
AC] that follows.
Yes. These attributes will need some fiddling when we work out what to
do with hands...

AC]
AC] - "If deletions are classified systematically, the type attribute may be
AC] useful to indicate the classification; when they are classified by the
AC] manner in which they were effected, or by their appearance, however,
AC] this will lead to a certain arbitrariness in deciding whether to use the
AC] type or the rend attribute to hold the information."
AC]
AC] But att.tracsriptional doesn't include @type (while
AC] att.authorialIntervention used to include it). If, as I believe the P5
AC] practice is, @type should not be included within existing classes, I
AC] think att.typed should be added to , , , .
AC] So also in the examples of the use of that follow, @n should=20
AC] be substituted by @type, in my opinion.
I have added add, addSpan, del, delSpan to att.typed
AC]
AC] -
AC]
AC] Why is @n used instead of @scribe here?
No idea. I#'ve changed it to scribe for now. Do you think @scribe
should be analogous to @key or to @ref ?

AC]
AC] - I wander whether should be allowed to selfnest as
AC] does. In any case, I think this element is a good and useful addition in=20
AC] this chapter.
Some of these elements are members of model.pPart.transcriptional and some
are members of model.pPart.editorial -- the latter indicating a
greater degree of editorial intervention than the former. The content
model for subst includes only members of the former, which maybe needs
rethinking. Not sure.
AC] We could also add in the prose that when the sequence of authorial=20
AC] intervention in a manuscript cannot be determined with certainty=20
AC] (subjective time) the @resp and @cert attributes should be used within=20
AC] .
AC]
Not sure what you are implying here?
AC] - I understand the example with @varSeq, but in general I think @varSeq
AC] should be used to express dependency between variants found in different
AC] witnesses as the specs say, rather than for tracking the genesis of
AC] authorial manuscripts (where @seq should be used instead).
AC]
This is another occasion where I am simply preserving what was
originally proposed by the chapter without really thinking it is a
good idea. Maybe this possibility should be explicitly removed, or at
least clearly distinguished?
AC] - shouldn't belong to att.trascriptional plus att.typed
AC] instead of having its own set of attributes? I think @means could be
AC] expressed by using @rend and/or @type.
AC]
Yes. Now done.

AC] - "The value of the hand attribute should be one of the hand identifiers
AC] declared in the document header (see section 14.4.1 Document Hands)."
AC]
AC] If we keep two different ways of documenting hands (as described in the=20
AC] Critical apparatus and in the MS chapters), this reference needs to link=20
AC] to both sections, especially considering that the MS approach is more=20
AC] accurate.
AC]

This is a big IF however.

AC] - and --> , and
AC]
OK

AC] - machine-readable --> electronic? digital?
AC]
no need for any of these words I think: have removed m-r anyway.

AC] - should and be member of att.typed instead of having=20
AC] @type? You could still suggest values for the use of the attribute in a=20
AC] specific element, couldn't you?
This is a generic problem throughout P5. Last time I looked, about
half the uses of @type were specifically defined and half
inherited. It's probably time to review that now, as a lot has changed
since the last set of class system updates.
AC]
AC] - --> I would =
AC] also=20
AC] add @unit=3D"letter"
AC]
Done.

AC] - I wander whether @extent, @hand, @agent and @unit could be all part of
AC] att.damaging (or different class name), so that both and
AC] could be members of this class. We could then add @reason to and
AC] @degree and @group to .
AC] could also become member of att.damaging with the addition of=20
AC] @reason.
AC] In any case, I would add @unit to .
AC]
Looks good. I will investigate.

AC] - -->
AC]
Clearly a Scottish scribe took over at this point.

AC] - "The rules for combinations of the and elements, and for
AC] the interpretation of such combinations, are similar:"
AC]
AC] I think that after this section something should be said about the new
AC] @seq element that allows to disambiguate the sequence of interventions.
OK: how's this.

AC]
AC] - "Methods for recording page breaks, column breaks, and line breaks in
AC] the source are described in section 3.6 Simple Links and Cross References=
AC] ."
AC]
AC] Shouldn't this point to the Milestone Tags section instead?
Yes. I didn't check the link: it was wrong.
AC]
AC] - "The element allows us to record that the scribe wrote nota,
AC] but is not well-adapted to show that the nota points both at all four
AC] lines and at two pairs of lines within the four lines."
AC]
AC] Well...these are the cases where we can say that the digital facsimile
AC] elements facilitate representation even if they privilege an image-based
AC] approach. I assume the physical bibliography chapter will cope, as
AC] far as the text-base approach can deal with this, with this sort of=20
AC] encoding in the future.
AC]
OK, how's this:

At the lowest level, all such features could be captured by use of
the note element, containing a prose description of the
manuscript at this point, enhanced by a link to a visual
representation (or facsimile) of the feature in question.
Markup languages in general are limited in their abilities to describe
all possible features of layout or realization. For example,...

AC] However, towards the end, when it says " Some of these issues may be
AC] covered in future editions of these guidelines."
AC]
AC] we could add that the MS chapter deals with some of these features.
Yes: now reads
As noted above, many of these features may be encoded using the
elements provided by the module
for manuscript description documented in .

AC]
AC] - again, shouldn't be member of att.typed?
Why should it? I suspect you of being a secret member of FTG (the Front for
Type Globalization).

AC]
AC] - I wander whether should be mentioned in this chapter.
AC]
Well it could be, but so could any number of other things e.g.


... or do you think it is particularly important in
transcription?

AC] - I think I agree with Matthew that is a bit redundant and=20
AC] should be used instead eventually in combination with=20
AC] or detailed values for @reason.
AC]
I beg to differ. encloses text that is (you think, but
you're not sure) present in the source. encloses text that
you know is not there, but ewhich you think should be.
I agree that the distinction between and is pretty
vague though: is that what you meant?

AC] Arianna
AC]
AC] P.S. I finished reading the chapter last night, but just saw you have=20
AC] added today. I think it's good to have an element to enclose the=20
AC] abbreviation sign; although some may complain for the proliferation.
AC]
It's not only to enclose abbreviation signs of course: probably a
better exmaple is needed to make this clearer.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Thu Sep 06 2007 - 12:30:56 EDT

From arianna.ciula at kcl.ac.uk Thu Sep 6 13:13:54 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 06 Sep 2007 18:13:54 +0100 Subject: [tei-council] Further update on PH In-Reply-To: <20070906163052.4C7619A002@webmail223.herald.ox.ac.uk> Message-ID: <46E03552.6010207@kcl.ac.uk>
From: Arianna Ciula
Date: Thu, 06 Sep 2007 18:13:54 +0100
Lou Burnard wrote:
> How about
>
> "It should be noted that, as elsewhere in these Guidelines, this
> chapter places more emphasis on the problems of representing the
> textual components of a document than on those relating to the
> description of the document's physical characteristics such as the
> carrier medium or physical construction. These aspects, of particular
> importance in codicology and the bibliographic study of incunables,
> are touched on in the chapter on Manuscript Description (
> target="#MS"/>) and also form the subject of ongoing work in the TEI
> Physical Bibliography workgroup."
Great!

> AC]
> AC] I think some people may understand better this note and the concept
> AC] behind it whit the help of an image of a grid superimposed on a figure.
> AC]
>
> A figure inside the footnote? I hope you don't mean that. I suppose a
> figure in the text might be useful, but it might look as if we were
> trying to teach is fairly elementary geometry. The footnote is just
> there as an aide memoire for those (like me) whose memory of O-level
> maths is starting to fade...
A grid superimposed on the image after the original image would be good,
but if nobody thinks is necessary may be I am just underestimating our
audience.
> AC]
> AC] - "Since this image contains more than one page however, and has not
> AC] been cropped, it might be better to define two distinct surfaces, one
> AC] for each page."
> AC]
> AC] I would add "...one for each page, including the illuminated margins" to
> AC] make clear that we are not considering the writing frame only as cropped
> AC] section.
> AC]
>
> have added ", including its illuminated margins" before the
> fullstop. But note that this may need further revision if Conal
> persuades us that "surface" means something different.
Sure.
>
> AC] - written part --> writing frame
> AC]
>
> Hmm, is this a technical term? I havent come across it before (and am
> not online so cannot check) I've changed it to "written area" for the
> moment. And note that we are not talking about the area actually
> marked for writing in in the original (e.g. by pricking); it includes
> margins etc.
Written area is fine, but yes, writing frame is a technical term (see
http://vocabulaire.irht.cnrs.fr/vocab.htm when you have the network).
>
> AC] - I think the proposal with expan/ex is great! [I asked Elena's opinion
> AC] as well and she seems very satisfied by this]. My only doubt is about
> AC] nesting. Indeed both and seem to have the possibility to=20
> AC] self nest. Has this been done on purpose?
> AC]
>
> Well, (and ) cannot self nest. It's true that and
> can though. The problem is both defining a content model to preclude
> this or coming up with a good reason why you might not want to. Some
> mad person will always want to treat e.g. USAF as two abbreviations
> ("US" and "AF"), and hence producing two nested expansions ("United
> States" and "Air Force").... it's the TEI Way. (trademark)
Let's leave it as is then.

>
> AC]
> AC] - "This encoding asserts that the reading wyf found in Gg is regarded as
> AC] a correction by Parkes."
> AC]
> AC] I am not sure about this example where @resp is within in a
> AC] . I understand it, but I think in general an editor would use the
> AC] element, wouldn't he? it is true that can occur only once in
> AC] an and therefore it would be difficult to express multiple
> AC] responsibilities on different corrections as this examples shows, but in
> AC] general to use a single reading to make a new edition you would use
> AC] .
> AC]
>
> It seems strange to me too, because elsewhere we use
> only for things that are not witnessed at all, whereas here it means
> "not witnessed in the source being encoded". I am agnostic on whether
> or not to keep this discussion; removing it is quite a big change
> though.
I think it would be good to have others'opinion here. It may be just me
seeing confusion where things are clear.
>
> AC] - "If no other source is indicated (either by the source attribute, or
> AC] by the wit attribute of a parent ), the reading supplied within a
> AC] has been provided by the person indicated by the resp attribute."
> AC]
> AC] As above I understand this, but the meaning of is a bit stretched
> AC] here, since it is not a variant witnessed in a source we are talking
> AC] about in this case, but rather what is normally considered in these
> AC] guidelines as a 'supplied' string.
>
> But it is witnessed, surely? It's in Gg. The encoding is saying (a)
> there is a different reading at this point in a certain ms and (b)
> Parkes thinks that this different reading should be used to correct
> the others.
But in the bracket in the prose you envisage the possibility of not
having neither @source in nor a @wit in ....oh ..it occurs
to me only now that I am reading that 'or' as an 'and'...one of the two
NEEDS to be there, right?
> AC]
> AC] -
> AC]
> AC] if will get the same attributes of the current , this
> AC] should be:
> AC]
> AC]
> AC]
>
> This loses the fact that Max is the author as well as the writer,
> doesn't it? But you're right that the attribute value should not be a
> string of words
what about
> AC]
> AC] -
> AC]
> AC] Why is @n used instead of @scribe here?
>
> No idea. I#'ve changed it to scribe for now. Do you think @scribe
> should be analogous to @key or to @ref ?
mh...could we have both? certainly @ref should be recommended, but there
are cases in which you may want to have an internal reference system.
Also, as I think I have mentioned before, I realize that in lots of
cases a scribe is just a numbered hand rather than a real person (we
don't know anything about him), so neither @ref nor @key pointing to a
element would do the trick.
> AC] We could also add in the prose that when the sequence of authorial=20
> AC] intervention in a manuscript cannot be determined with certainty=20
> AC] (subjective time) the @resp and @cert attributes should be used within=20
> AC] .
> AC]
>
> Not sure what you are implying here?
Just that the prose could expand on the use of att.editLike in
as it does for other elements. In this element, the
responsibility/certainty on the determination of a sequence of
alternative changes helps to say: look this is what I think the author
has done, but the hands don't really allow me to be sure. I think my
author wrote first A, then deleted it and then substituted it with B. He
may have first added B and then deleted A...who knows? 'subjective time'
I think it's called in genetic editions.
> AC] - I understand the example with @varSeq, but in general I think @varSeq
> AC] should be used to express dependency between variants found in different
> AC] witnesses as the specs say, rather than for tracking the genesis of
> AC] authorial manuscripts (where @seq should be used instead).
> AC]
>
> This is another occasion where I am simply preserving what was
> originally proposed by the chapter without really thinking it is a
> good idea. Maybe this possibility should be explicitly removed, or at
> least clearly distinguished?
I would remove it to avoid confusion, but we need others'opinion.
> AC] - "The rules for combinations of the and elements, and for
> AC] the interpretation of such combinations, are similar:"
> AC]
> AC] I think that after this section something should be said about the new
> AC] @seq element that allows to disambiguate the sequence of interventions.
>
> OK: how's this.
?

> AC]
> AC] - "The element allows us to record that the scribe wrote nota,
> AC] but is not well-adapted to show that the nota points both at all four
> AC] lines and at two pairs of lines within the four lines."
> AC]
> AC] Well...these are the cases where we can say that the digital facsimile
> AC] elements facilitate representation even if they privilege an image-based
> AC] approach. I assume the physical bibliography chapter will cope, as
> AC] far as the text-base approach can deal with this, with this sort of=20
> AC] encoding in the future.
> AC]
>
> OK, how's this:
>
>

At the lowest level, all such features could be captured by use of
> the note element, containing a prose description of the
> manuscript at this point, enhanced by a link to a visual
> representation (or facsimile) of the feature in question.
> Markup languages in general are limited in their abilities to describe
> all possible features of layout or realization. For example,...
Ok

> AC]
> AC] - again, shouldn't be member of att.typed?
>
> Why should it? I suspect you of being a secret member of FTG (the Front for
> Type Globalization).
Because it can be so many different things...yes I am a member, is it
illegal?

> AC]
> AC] - I wander whether should be mentioned in this chapter.
> AC]
>
> Well it could be, but so could any number of other things e.g.


>

... or do you think it is particularly important in
> transcription?
I just thought of transcriptions of letters within novels (mentioned
both by Julia Flanders and Elena Pierazzo in the TEI list, I think)
which are not used in any of the examples here. It isn't necessary. It
was just a thought and you are right that we can't include everything.

> AC] - I think I agree with Matthew that is a bit redundant and=20
> AC] should be used instead eventually in combination with=20
> AC] or detailed values for @reason.
> AC]
>
> I beg to differ. encloses text that is (you think, but
> you're not sure) present in the source. encloses text that
> you know is not there, but ewhich you think should be.
>
> I agree that the distinction between and is pretty
> vague though: is that what you meant?
It could be improved....will have another look.

Arianna
> AC] Arianna
> AC]
> AC] P.S. I finished reading the chapter last night, but just saw you have=20
> AC] added today. I think it's good to have an element to enclose the=20
> AC] abbreviation sign; although some may complain for the proliferation.
> AC]
>
> It's not only to enclose abbreviation signs of course: probably a
> better exmaple is needed to make this clearer.
> _______________________________________________
> tei-council mailing list
> tei-council_at_lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch _______________________________________________ tei-council mailing list tei-council_at_lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Received on Thu Sep 06 2007 - 13:13:03 EDT

From Syd_Bauman at Brown.edu Fri Jan 5 21:24:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 5 Jan 2007 21:24:04 -0500 (EST) Subject: [tei-council] Comments on the conformance document In-Reply-To: <0F41634B-9414-489A-94C0-5FFD058B01A9@loria.fr> References: <20060927060258.ACM04057@expms1.cites.uiuc.edu> <451A5CE3.2080606@oucs.ox.ac.uk> <451A6056.1090906@computing-services.oxford.ac.uk> <96f3df640609270615k73663141jf2d8b016fd0dd0f1@mail.gmail.com> <451A7BBF.7000106@oucs.ox.ac.uk> <17693.32431.911391.818918@emt.wwp.brown.edu> <451D90FA.8050707@oucs.ox.ac.uk> <0F41634B-9414-489A-94C0-5FFD058B01A9@loria.fr> Message-ID: <200701060224.l062O4kR012397@draco.services.brown.edu> [Council -- my apologies. I wrote this back in late September, but for some reason it never got posted. The recent discussion on TEI-L had me look for it, and finding that it never got posted here it is ... I'm not sure there is much, if anything, new here.] LB> The TEI's claim is that has sufficient generality and coverage in LB> its semantics that it can be customized to meet most needs LB> without too much effort. ... we need to have a metric to assess LB> the interchangeability ... of the resulting documents. That's LB> what conformance is. While it may be a very good idea for us to have a metric to assess interchangeability, I don't think it's a requirement. After all, P3 and P4 did not have such a metric, or at least not at the same level of nuance. Nonetheless, I agree that it's a good idea to discuss such a metric in the Guidelines. But I think (*very* strongly) that the metric of ease of interchange should not be confused with a definition of conformance. After all, I can (and should be able to) create TEI documents that are 100% conformant, but because they rely on my own taxonomy of type=, my own method for indicating rhyme=, my own method for indicating rend=, etc., are not easily plopped into your system. On the other hand, I can create a document that has an added element which your system could accommodate with only the smallest of tweaks. That is, all of the degrees of interchangeability discussed at http://www.tei-c.org.uk/wiki/index.php/Conformance describe conformant documents (correction: #5 does not describe a TEI document at all, and I do not think it should be on the list). I think that we should focus this discussion on the degrees of interchangeability, and stop mis-using the term "conformance". Conformance is a separate (although related) issue about making what you've done with respect to the Guidelines explicit in a specified, predictable, way. From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 6 10:39:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 06 Jan 2007 15:39:58 +0000 Subject: [tei-council] numbered divs, a proposed solution Message-ID: <459FC2CE.5080805@oucs.ox.ac.uk> You can hardly have failed to notice the argument on TEI-L which revolved around Ron vd B's innocuous expectation that if he deleted mumbered divs in his ODD, he would get a valid DTD. I know one should not solve a general problem by dealing with a special case case, but I also think that there is a time for compromise and practicality, so I have a firm proposal which I'd like you to consider. I claim it will solve this problem at a relatively small cost, compared to the public embarassment this will keep on causing. The idea is that we much simplify the content model of , and to allow _either_ paragraph-like objects (macro.component) _or_ div-like objects (as well as the existing top and bottom elements). The "div-like" would be expressed as a new class model.divLike, and its membership would be div, div0, div1 and divGen. Good things: 1. so long as at least one member of the class exists, any other can be safely deleted 2. you can create new objects easily which will be allowed inside Bad things: 1. you can interleave div, div1 and div0 ad lib. 2. if model.divLike is entirely empty, it fails at present cos of globals being ambiguous Strange things: 1. you can interleave div and divGen ad lib. that strikes me as moderately desirable. To deal with the first bad thing, I have added a Schematron test which detects silly combinations. The second requires some more jiggery-pokery; I think it's solvable with a lot of patience. My proposal for the content model of is below. The fully-worked example is in P5/Test/testfand.odd in Subversion. Views? I have not tried integrating this into the main TEI and running all tests, but I have a tei_all with these changes and done some obvious tests which threw up no funnies. I take it as axiomatic that we cannot simply leave the current setup as it is. We must do _something_ to allow the simple case of "delete numbered divs" to work. You cannot mix numbered divs with unnumbered divs in body You cannot mix div0 with div1 at the same level in body -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From James.Cummings at oucs.ox.ac.uk Mon Jan 8 05:30:39 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 08 Jan 2007 10:30:39 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <459FC2CE.5080805@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> Message-ID: <45A21D4F.8020004@oucs.ox.ac.uk> Sebastian Rahtz wrote: > You can hardly have failed to notice the argument on TEI-L > which revolved around Ron vd B's innocuous expectation > that if he deleted mumbered divs in his ODD, he would > get a valid DTD. I agree that this is an innocuous expectation and that he should be able to delete numbered divs. When we discussed and decided to drop support for SGML (around 2006-09-14) it was mentioned that the support for DTDs was also difficult. I'm assuming this is an example of that. Does this problem exist in the generated schemas, or only the DTDs? > I know one should not solve a general problem by dealing > with a special case case, but I also think that there is a time for > compromise and practicality, so I have a firm proposal which > I'd like you to consider. I claim it will solve this problem > at a relatively small cost, compared to the public > embarassment this will keep on causing. I agree that the problem needs to be solved one way or another. > The "div-like" would be expressed as a new > class model.divLike, and its membership would be > div, div0, div1 and divGen. I suppose we couldn't re-open the issue of whether we should just get rid of the option of div0|div1 and just pick one or the other? > Bad things: > 1. you can interleave div, div1 and div0 ad lib. > 2. if model.divLike is entirely empty, it fails at present cos of > globals being ambiguous These are both quite bad in my mind. 1) The whole point of divs vs numbered divs is that they are mutually exclusive isn't it? I mean I'm not supposed to be able to use both in the same document? > To deal with the first bad thing, I have added a Schematron test > which detects silly combinations. The second requires > some more jiggery-pokery; I think it's solvable with a lot > of patience. So, is the real issue behind this whether we want to rely on Schematron for these tests? And to do so for a special case solution? Does adopting Schematron for this have any negative implications? > I take it as axiomatic that we cannot simply leave the > current setup as it is. We must do _something_ to allow > the simple case of "delete numbered divs" to work. I agree that something must be done. Does any one have any suggested alternatives? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Mon Jan 8 12:48:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 8 Jan 2007 12:48:10 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A21D4F.8020004@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> Message-ID: <17826.33754.484151.883531@emt.wwp.brown.edu> I may not get to give this issue full attention for a little while, but some brief thoughts follow. > > You can hardly have failed to notice the argument on TEI-L > > which revolved around Ron vd B's innocuous expectation > > that if he deleted mumbered divs in his ODD, he would > > get a valid DTD. > > I agree that this is an innocuous expectation and that he should be > able to delete numbered divs. I agree, too, although as I think I've said before, this could be documented around, rather than really solved. > When we discussed and decided to drop support for SGML (around > 2006-09-14) it was mentioned that the support for DTDs was also > difficult. I'm assuming this is an example of that. Does this > problem exist in the generated schemas, or only the DTDs? Exactly correct. The problem exists in DTDs and probably in W3C Schemata, although I don't know that anyone has tested the latter. The problem does *not* exist in Relax NG. > > I know one should not solve a general problem by dealing with a > > special case case, but I also think that there is a time for > > compromise and practicality, so I have a firm proposal which I'd > > like you to consider. I claim it will solve this problem at a > > relatively small cost, compared to the public embarassment this > > will keep on causing. > > I agree that the problem needs to be solved one way or another. I have not looked at Sebastian's proposal here closely enough to give a real opinion on it, so I am *not* saying here that I prefer the brute-force or hack methods better. But I am curious: does the above statement mean that you have looked at the FAND ODDs I posted on the wiki and don't think they are viable solutions?[1] > > The "div-like" would be expressed as a new class model.divLike, > > and its membership would be div, div0, div1 and divGen. > > I suppose we couldn't re-open the issue of whether we should just > get rid of the option of div0|div1 and just pick one or the other? We can, and perhaps should, but it doesn't make any significant difference. I.e., the non-deterministic content model problem will exist whenever all numbered divs are deleted in your ODD, whether div0 is among them or not. > These are both quite bad in my mind. 1) The whole point of divs vs > numbered divs is that they are mutually exclusive isn't it? I mean > I'm not supposed to be able to use both in the same document? Not within the same , , or . > So, is the real issue behind this whether we want to rely on > Schematron for these tests? And to do so for a special case > solution? Does adopting Schematron for this have any negative > implications? These are exactly the important questions to address up front, I think. > > I take it as axiomatic that we cannot simply leave the current > > setup as it is. We must do _something_ to allow the simple case > > of "delete numbered divs" to work. > > I agree that something must be done. Does any one have any > suggested alternatives? While I may be convinced that something must be done, I am not convinced yet. Notes ----- [1] http://www.tei-c.org/wiki/index.php/FAND1_hack and http://www.tei-c.org/wiki/index.php/FAND2_replace From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 15:56:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 20:56:54 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <17826.33754.484151.883531@emt.wwp.brown.edu> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> Message-ID: <45A2B016.6070906@oucs.ox.ac.uk> Syd Bauman wrote: > > But I am curious: does the above > statement mean that you have looked at the FAND ODDs I posted on the > wiki and don't think they are viable solutions?[1] > the ingenious hack #1 only works for DTDs. I am considering implementing this directly in odd2dtd, so that when you have an empty class, a _DUMMY_ is inserted. But it puzzles me as to _why_ it works, since the content model _is_ ambiguous. And what about W3C schema. hack #2 is too complex. sorry. such a simple task has to be easier, in my book. > >> So, is the real issue behind this whether we want to rely on >> Schematron for these tests? And to do so for a special case >> solution? Does adopting Schematron for this have any negative >> implications? >> > > These are exactly the important questions to address up front, I > think. > I am sure you and James have a nice view up there sitting on the fence :-} but I'd rather see a concrete expression of yes or no for the principal question..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From jawalsh at indiana.edu Mon Jan 8 16:13:12 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Mon, 8 Jan 2007 16:13:12 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: On Jan 8, 2007, at 3:56 PM, Sebastian Rahtz wrote: >> So, is the real issue behind this whether we want to rely on >> Schematron for these tests? And to do so for a special case >> solution? Does adopting Schematron for this have any negative >> implications? I think the negative implication is that if we tell the TEI user community that they need to use DTDs + Schematron (or W3C/RELAX NG + Schematron) to validate their documents correctly, many of them will run away screaming. Or they will run away silently because they don't want to admit they don't know or care what Schematron is. And they'll probably run back to the perceived warm comforting arms of P4 and plain old DTDs. I think the user community needs the choice between DTD and W3C; some, including me, want the choice of RELAX NG as well. They don't want a requirement to use Schematron, except for their own content validation. I think it's important that we avoid a need to use Schematron. John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 From djbpitt+tei at pitt.edu Mon Jan 8 16:13:04 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 08 Jan 2007 16:13:04 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: <45A2B3E0.3020503@pitt.edu> Dear Sebastian (cc Council), > I am sure you and James have a nice view up there > sitting on the fence :-} > > but I'd rather see a concrete expression of yes > or no for the principal question..... Reluctant yes. The two "bad things" bother me and I'm not happy about having to rely on Schematron, but those limitations pale in comparison to living in a world where one cannot remove numbered divs, and I can't think of a better solution. Best, David From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 16:40:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 21:40:11 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: <45A2BA3B.1020801@oucs.ox.ac.uk> John A. Walsh wrote: > > I think the user community needs the choice between DTD and W3C; > some, including me, want the choice of RELAX NG as well. They don't > want a requirement to use Schematron, except for their own content > validation. I think it's important that we avoid a need to use > Schematron. > Fair view. If that's what the majority think, back to the drawing board :-{ I'm trying some more tricks now. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 17:49:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 08 Jan 2007 22:49:11 +0000 Subject: [tei-council] solving unnumbered divs (bis) Message-ID: <45A2CA67.6020900@oucs.ox.ac.uk> I have done some more work on this, and I am able to solve one of the problems. I have implemented Syd's No1 Hack in the ODD processing, whereby any model class which has no members is replaced by "_DUMMY_". It shuts up the XML processor nicely. So far so good, it would let you entirely delete any kind of div. Now, supposed we have *two* classes, one for div and divGen, one for divGen, div1 and div0. Now we can say that you can have one set or the other. All well and good, we don't need the Schematron thing any more. Spotted the problem? yes, its . If its in both classes, its ambiguous. I could make _another_ class for divGen, I suppose. Oh lordy lordy. Anyone got a suggestion to get me out of this last hole? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Mon Jan 8 18:48:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 8 Jan 2007 18:48:35 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2B016.6070906@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> Message-ID: <17826.55379.927889.377121@emt.wwp.brown.edu> > > But I am curious: does the above statement mean that you have > > looked at the FAND ODDs I posted on the wiki and don't think they > > are viable solutions?[1] > > > the ingenious hack #1 only works for DTDs. Why do you say that? Both the .rng and .rnc files I get from roma are valid, and seem to work exactly as expected (i.e., as the DTD does). > I am considering implementing this directly in odd2dtd, so that > when you have an empty class, a _DUMMY_ is inserted. Seems like a route we may want to follow. > But it puzzles me as to _why_ it works, since the content model > _is_ ambiguous. Again, what makes you say that? The content model for , e.g., certainly looks deterministic to me.[1] Xerces J, xmllint, and onsgmls all say the DTD is fine. > And what about W3C schema. I don't know, and haven't tested, although it seems unlikely that what is deterministic in its Relax NG source would be converted into something non-deterministic by trang. > hack #2 is too complex. sorry. such a simple task has to be easier, > in my book. Allow me to play devil's advocate. First, I will argue that it's not an at all difficult task. To remove numbered divs go to the sample ODD, find the part that says "copy-and-paste this section", copy it, paste it into your ODD, and you're done. Heck, there could even be a little check-box on the Roma web interface that caused this oh-so-common request to happen for you. But more to the point, when did it become the TEI's goal to protect users from schema code? While certainly not as nice as a class-system change, this change is still easier than it was in P4. Notes ----- [1] It is as follows: ( ( %model.divWrapper; | %model.global; )*, ( ( ( %macro.component;, %model.global;*)+, ( ( divGen, %model.global;* )*, ( ( div, ( div | divGen | %model.global; )* ) | ( DO_NOT_USE_THIS, ( DO_NOT_USE_THIS | divGen | %model.global; )* ) | ( DO_NOT_USE_ME, ( DO_NOT_USE_ME | divGen | %model.global; )* ) )? ) ) | ( ( divGen, %model.global;* )*, ( ( div, ( div | divGen | %model.global; )* ) | ( DO_NOT_USE_THIS, ( DO_NOT_USE_THIS | divGen | %model.global; )* ) | ( DO_NOT_USE_ME, ( DO_NOT_USE_ME | divGen | %model.global; )* ) ) ) ), %model.divWrapper.bottom;* ) From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:03:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:03:24 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2CA67.6020900@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> Message-ID: <45A2DBCC.6040002@oucs.ox.ac.uk> I am glad to say that the question of W3C schema allowing non-deterministic content models appears to be a non-issue. My test XSD file seems to have come through with no problem. So I now have an ODD which can delete any or all of div0, div1, div and divGen, and the RELAXNG, DTD and XSD schemas all work as expected. div0|div1 and div cannot co-exist. The price I have had to pay is inventing *3* new classes, model.divLike, model.ndivLike, and model.divGenLike. It's a hideous price to pay, but it works. So, if you don't mind those 3 new classes, and you don't find it strange have a DTD like this: then I claim victory, pending a full test. Here is the final content model: -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:09:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:09:13 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <17826.55379.927889.377121@emt.wwp.brown.edu> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> <17826.55379.927889.377121@emt.wwp.brown.edu> Message-ID: <45A2DD29.8050008@oucs.ox.ac.uk> Syd Bauman wrote: >> the ingenious hack #1 only works for DTDs. >> > > Why do you say that? Both the .rng and .rnc files I get from roma are > valid, and seem to work exactly as expected (i.e., as the DTD does). > yes, sorry, I lied. The dummies are not needed in the other languages, of course. > >> But it puzzles me as to _why_ it works, since the content model >> _is_ ambiguous. >> > > Again, what makes you say that? The content model for , e.g., > certainly looks deterministic to me.[1] Xerces J, xmllint, and > onsgmls all say the DTD is fine. > yes, its technically OK. but if you have (DUMMY | foo), (DUMMY2 | foo) and you meet just a "foo", where does it come from? > > Allow me to play devil's advocate. First, I will argue that it's not > an at all difficult task. To remove numbered divs go to the sample > ODD, find the part that says "copy-and-paste this section", copy it, > paste it into your ODD, and you're done. Heck, there could even be a > little check-box on the Roma web interface that caused this > oh-so-common request to happen for you. > I wish I could go along with saying that's acceptable, but I just can't..... > But more to the point, when did it become the TEI's goal to protect > users from schema code? speaking for myself, since the dawn of creation. its axiomatic in my book. I realize we have different books :-} Anyway, having divLike classes adds the enormous advantage that you can now easily add your own new object to be a child of . Don't tell me *that* was easy before! -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 8 19:11:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 00:11:58 +0000 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2DD29.8050008@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> <17826.55379.927889.377121@emt.wwp.brown.edu> <45A2DD29.8050008@oucs.ox.ac.uk> Message-ID: <45A2DDCE.2040102@oucs.ox.ac.uk> I should also note that the technique of using DUMMY_model.***** to replace any empty class model.***** may well solve a slew of other nasty problems which are simply less common than the unnumbered div thing. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 8 20:50:10 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Tue, 09 Jan 2007 10:50:10 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2DBCC.6040002@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> Message-ID: <45A2F4D2.3010702@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > The price I have had to pay is inventing *3* new classes, > model.divLike, model.ndivLike, and model.divGenLike. > It's a hideous price to pay, but it works. It does not seem too high to me, though. Remember the class meeting, where we invented classes by the dozens before lunch? But seriously, I think this is the solution we have been hoping for, no schematron, no unpleasant ODD massaging. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From James.Cummings at oucs.ox.ac.uk Tue Jan 9 07:23:54 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Jan 2007 12:23:54 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A2DBCC.6040002@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> Message-ID: <45A3895A.8060709@oucs.ox.ac.uk> Sebastian Rahtz wrote: > So I now have an ODD which can delete any or all of div0, div1, div and > divGen, > and the RELAXNG, DTD and XSD schemas all work as expected. div0|div1 and > div cannot co-exist. > > The price I have had to pay is inventing *3* new classes, > model.divLike, model.ndivLike, and model.divGenLike. > It's a hideous price to pay, but it works. I think that Sebastian's solution is good and elegant. The only problem it causes is in fact a great opportunity. Currently his solution allows me to validate a document whose body looks like this: test

test

As you can see this allows me to have *both* div1 and div0 at the top level. However, I don't think his elegant solution should be thrown out with the bathwater. No, no, instead this is an opportunity to solve yet another TEI problem. If we remove div1 from the model.ndivLike class, then the solution works perfectly. The only side effect is that people are unable to start a document using div1 ... in my mind this is hardly a drawback. (While I have no preference of starting with div0 or div1, my cummings compromise for the month is that removing div1 from the class is a much easier change than removing div0 from the class and entirely.) Moreover, if people really want to start their documents at div1, all they have to do is add it to the model.ndivLike class (and optionally remove div0 from said class). This is not a flaw, it is an opportunity. -James > > So, if you don't mind those 3 new classes, > and you don't find it strange have a DTD like this: > > _DUMMY_model.divGenLike))*,(((%macro.component;),(%model.global; | > _DUMMY_model.divGenLike)*)+ | (_DUMMY_model.divLike,(%model.global; | > _DUMMY_model.divGenLike)*)+ | ((%model.ndivLike;),(%model.global; | > _DUMMY_model.divGenLike)*)+),(%model.divWrapper.bottom;)*)> > > then I claim victory, pending a full test. > > Here is the final content model: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 9 07:37:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 12:37:15 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A3895A.8060709@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> Message-ID: <45A38C7B.9030302@oucs.ox.ac.uk> Truly James he speaks the truth. This *is* the time to remove that div0/div1 weirdness. div1: "contains a first-level subdivision of the front, body, or back of a text (the largest, if div0 is not used, the second largest if it is)." sigh. OK, whats the case for the defence? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From laurent.romary at loria.fr Tue Jan 9 08:15:28 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Jan 2007 14:15:28 +0100 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A38C7B.9030302@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> Message-ID: It reminds me of Monty Python and the Holy Grail (1975): "Burn" Le 9 janv. 07 ? 13:37, Sebastian Rahtz a ?crit : > Truly James he speaks the truth. This *is* the time to remove that > div0/div1 weirdness. > > > div1: "contains a first-level subdivision of the front, body, > or back > of a text (the largest, if > div0 is not used, the second largest if it is)." > > sigh. > > OK, whats the case for the defence? > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 9 08:33:28 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 09 Jan 2007 13:33:28 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> Message-ID: <45A399A8.9000705@oucs.ox.ac.uk> I have just back-ported the contents of my test ODD into the body of the TEI [1] and re-run all the tests. There are no unexpected results, so I claim that my FAND approach works. However, having removed div1 from model.divNLike as per James' suggestion, I do hit a number of examples in the Guidelines which use in that way; if I reverse the polarity, I find some starting elements. There are three choices: 1. mandate div0 as the top level, and fix our own examples. 2. remove div0 entirely from the TEI 3. start again and try to reimplement the existing allowance. I'd vote for 1. [1] no, I have not submitted it to Sourceforge Subversion:-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Thu Jan 11 11:03:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 11 Jan 2007 11:03:21 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 Message-ID: <17830.24521.896613.773882@emt.wwp.brown.edu> Are we set for the dates for meeting in Berlin? pre-meeting event: 2007-04-25 meeting: 2007-04-26/27 Back in 2006-11-23/26 the following folks said they could make at least the meeting dates (and most, if not all, said they could make the pre-event, too): LR, SR, LB, CT, DO, CW, JC. Those dates are also fine w/ me, for both pre-meeting and meeting. JW posted saying pre-meeting event was OK; I presume you meant the meeting dates were OK, too, yes? That would mean 9 of the expected 14 attendees have responded in the affirmative. April 2007 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 From jawalsh at indiana.edu Thu Jan 11 11:04:40 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 11 Jan 2007 11:04:40 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <17830.24521.896613.773882@emt.wwp.brown.edu> References: <17830.24521.896613.773882@emt.wwp.brown.edu> Message-ID: <59623B8F-F89C-444F-A2CB-E80AAAE7C023@indiana.edu> Syd, Yes. I'm clear for both the meeting and the pre-meeting event. John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote: > Are we set for the dates for meeting in Berlin? > pre-meeting event: 2007-04-25 > meeting: 2007-04-26/27 > > Back in 2006-11-23/26 the following folks said they could make at > least the meeting dates (and most, if not all, said they could make > the pre-event, too): > LR, SR, LB, CT, DO, CW, JC. > Those dates are also fine w/ me, for both pre-meeting and meeting. > > JW posted saying pre-meeting event was OK; I presume you meant the > meeting dates were OK, too, yes? That would mean 9 of the expected 14 > attendees have responded in the affirmative. > > April 2007 > Su Mo Tu We Th Fr Sa > 1 2 3 4 5 6 7 > 8 9 10 11 12 13 14 > 15 16 17 18 19 20 21 > 22 23 24 25 26 27 28 > 29 30 > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From mjd at hum.ku.dk Thu Jan 11 11:09:19 2007 From: mjd at hum.ku.dk (M. J. Driscoll) Date: Thu, 11 Jan 2007 17:09:19 +0100 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <59623B8F-F89C-444F-A2CB-E80AAAE7C023@indiana.edu> References: <17830.24521.896613.773882@emt.wwp.brown.edu> Message-ID: <45A66F3F.6562.1CA0461@localhost> These dates are fine for me, too. I'm fairly sure I'd already confirmed this, but one never really knows, does one? MJD > Syd, > > Yes. I'm clear for both the meeting and the pre-meeting event. > > John > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: > | Voice:812-856-0707 Fax:812-856-2062 > > > On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote: > > > Are we set for the dates for meeting in Berlin? > > pre-meeting event: 2007-04-25 > > meeting: 2007-04-26/27 > > > > Back in 2006-11-23/26 the following folks said they could make at > > least the meeting dates (and most, if not all, said they could make > > the pre-event, too): > > LR, SR, LB, CT, DO, CW, JC. > > Those dates are also fine w/ me, for both pre-meeting and meeting. > > > > JW posted saying pre-meeting event was OK; I presume you meant the > > meeting dates were OK, too, yes? That would mean 9 of the expected 14 > > attendees have responded in the affirmative. > > > > April 2007 > > Su Mo Tu We Th Fr Sa > > 1 2 3 4 5 6 7 > > 8 9 10 11 12 13 14 > > 15 16 17 18 19 20 21 > > 22 23 24 25 26 27 28 > > 29 30 > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From arianna.ciula at kcl.ac.uk Thu Jan 11 11:53:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 11 Jan 2007 16:53:58 +0000 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <45A66F3F.6562.1CA0461@localhost> References: <17830.24521.896613.773882@emt.wwp.brown.edu> <45A66F3F.6562.1CA0461@localhost> Message-ID: <45A66BA6.6020708@kcl.ac.uk> I am sure I had confirmed as well, but probably directly with Laurent. Arianna M. J. Driscoll wrote: > These dates are fine for me, too. > > I'm fairly sure I'd already confirmed this, but one never really knows, does > one? > > MJD > >> Syd, >> >> Yes. I'm clear for both the meeting and the pre-meeting event. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: >> | Voice:812-856-0707 Fax:812-856-2062 >> >> >> On Jan 11, 2007, at 11:03 AM, Syd Bauman wrote: >> >>> Are we set for the dates for meeting in Berlin? >>> pre-meeting event: 2007-04-25 >>> meeting: 2007-04-26/27 >>> >>> Back in 2006-11-23/26 the following folks said they could make at >>> least the meeting dates (and most, if not all, said they could make >>> the pre-event, too): >>> LR, SR, LB, CT, DO, CW, JC. >>> Those dates are also fine w/ me, for both pre-meeting and meeting. >>> >>> JW posted saying pre-meeting event was OK; I presume you meant the >>> meeting dates were OK, too, yes? That would mean 9 of the expected 14 >>> attendees have responded in the affirmative. >>> >>> April 2007 >>> Su Mo Tu We Th Fr Sa >>> 1 2 3 4 5 6 7 >>> 8 9 10 11 12 13 14 >>> 15 16 17 18 19 20 21 >>> 22 23 24 25 26 27 28 >>> 29 30 >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Thu Jan 11 12:38:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 11 Jan 2007 12:38:47 -0500 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <45A66BA6.6020708@kcl.ac.uk> References: <17830.24521.896613.773882@emt.wwp.brown.edu> <45A66F3F.6562.1CA0461@localhost> <45A66BA6.6020708@kcl.ac.uk> Message-ID: <17830.30247.305923.647231@emt.wwp.brown.edu> > I am sure I had confirmed as well, but probably directly with > Laurent. Nope. You confirmed to the list, as did DP. I just missed it because you two confirmed *after* LR's follow-up. Sorry, no insult intended, I promise! So that means 11 of 14 have confirmed. I'm guessing that means we're a "go" for those dates, but would like to hear from the local organizer (LR) and chair (CW) before writing it down in pen on my calendar. From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 01:12:49 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 15:12:49 +0900 Subject: [tei-council] test of telecon options Message-ID: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, I hope everybody had a good start into the new year, the year of the wild pig in this part of the world. As usual, the start into the year is very slow in Japan, with lots of holidays, so we are just getting into working mode here again in the last couple of days. In preparation for our next teleconference, which is scheduled for Jan 23 at 1200 UTC, I would like to invite those who have time for a little chat at the same time this next Monday (Jan. 15). The purpose is to test if the highspeedconferencing.com system, which allows to call in from VoIP and landline phones would give us better acoustic performance than our current system. Personally, I would like to see Syd among the volunteers for this chat, since I had the most difficulties with the line from Brown so far (maybe because it is just on the opposite site of the planet?), but anybody is welcome. Sebastian, would you please give us instructions what to do? Apart from that, I hope everybody is busy chopping away on the action items (for a reminder, please look at http://www.tei-c.org/Council/tcm27.xml?style=printable) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:16:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:16:09 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45A77C09.3050604@oucs.ox.ac.uk> > anybody is welcome. Sebastian, would you please give us instructions > what to do? > > an email should come soon, if I have done it right -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:21:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:21:34 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A77C09.3050604@oucs.ox.ac.uk> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> <45A77C09.3050604@oucs.ox.ac.uk> Message-ID: <45A77D4E.6050701@oucs.ox.ac.uk> sigh. of course my gmail account cannot email council. I append the message it should have sent you. Dear TEI Council List, sebastian.rahtz has scheduled a conference for: Monday, January 15, 2007 12:00 PM (GMT+00:00) Notes: >From Skype call +99008275326922 In the US, call 1-712-432-4000 Calling from Europe, call In Austria: 0820 400 01562 In Belgium: 0703 59 984 In France: 0826 100 266 In Germany 01805 00 7620 In UK: 0870 119 2350 Enter Conference Room Number : 5326922 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 07:52:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 21:52:28 +0900 Subject: [tei-council] TEI Council meeting in Berlin, 2007 In-Reply-To: <17830.30247.305923.647231@emt.wwp.brown.edu> References: <17830.24521.896613.773882@emt.wwp.brown.edu> <45A66F3F.6562.1CA0461@localhost> <45A66BA6.6020708@kcl.ac.uk> <17830.30247.305923.647231@emt.wwp.brown.edu> Message-ID: <45A7848C.9040900@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: > So that means 11 of 14 have confirmed. I'm guessing that means we're > a "go" for those dates, but would like to hear from the local > organizer (LR) and chair (CW) before writing it down in pen on my > calendar. I had the impression we already decided about that. Anyway, if necessary, here we go "there is one more thing..." The TEI Tecnical Council will hold its annual meeting for 2007 in Berlin, Germany from April 26 to 27, with a pre-conference workshop on April 25. See you there! All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Jan 12 07:54:48 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 12 Jan 2007 21:54:48 +0900 Subject: [tei-council] test of telecon options In-Reply-To: <45A77D4E.6050701@oucs.ox.ac.uk> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> <45A77C09.3050604@oucs.ox.ac.uk> <45A77D4E.6050701@oucs.ox.ac.uk> Message-ID: <45A78518.3070802@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > sigh. of course my gmail account cannot email council. Thanks. > sebastian.rahtz has scheduled a conference for: > Monday, January 15, 2007 12:00 PM (GMT+00:00) > > Notes: > > > >>From Skype call +99008275326922 > In the US, call 1-712-432-4000 > Calling from Europe, call > In Austria: 0820 400 01562 > In Belgium: 0703 59 984 > In France: 0826 100 266 > In Germany 01805 00 7620 > In UK: 0870 119 2350 Is there a land line to call from Japan or New Zealand? Just curious if we have a fallback option here... All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 12 07:59:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Jan 2007 12:59:36 +0000 Subject: [tei-council] test of telecon options In-Reply-To: <45A78518.3070802@kanji.zinbun.kyoto-u.ac.jp> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> <45A77C09.3050604@oucs.ox.ac.uk> <45A77D4E.6050701@oucs.ox.ac.uk> <45A78518.3070802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45A78638.9030003@oucs.ox.ac.uk> Wittern Christian wrote: > > Is there a land line to call from Japan or New Zealand? > > Just curious if we have a fallback option here... > > no, I am afraid not, you'd have to call the US number. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Fri Jan 12 11:28:02 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 12 Jan 2007 09:28:02 -0700 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1168619282.32635.8.camel@caedmon> As much as I'd like to give it a tryout, I hope I'll be forgiven missing a GMT 1200 (MST 0500) test call! -dan On Fri, 2007-01-12 at 15:12 +0900, Wittern Christian wrote: > Dear Council members, > > I hope everybody had a good start into the new year, the year of the > wild pig in this part of the world. As usual, the start into the year > is very slow in Japan, with lots of holidays, so we are just getting > into working mode here again in the last couple of days. > > In preparation for our next teleconference, which is scheduled for Jan > 23 at 1200 UTC, I would like to invite those who have time for a little > chat at the same time this next Monday (Jan. 15). The purpose is to > test if the highspeedconferencing.com system, which allows to call in > from VoIP and landline phones would give us better acoustic performance > than our current system. > Personally, I would like to see Syd among the volunteers for this chat, > since I had the most difficulties with the line from Brown so far > (maybe because it is just on the opposite site of the planet?), but > anybody is welcome. Sebastian, would you please give us instructions > what to do? > > Apart from that, I hope everybody is busy chopping away on the action > items (for a reminder, please look at > http://www.tei-c.org/Council/tcm27.xml?style=printable) > > All the best, > > Christian > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Fri Jan 12 16:30:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 12 Jan 2007 16:30:44 -0500 Subject: [tei-council] test of telecon options In-Reply-To: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> References: <45A726E1.1070602@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17831.65028.155844.769109@emt.wwp.brown.edu> > ... a little chat at the same time this next Monday (Jan. 15). ... > I would like to see Syd among the volunteers for this chat, since I > had the most difficulties with the line from Brown so far I will make every effort to dial in at 2007-01-15 00:00Z [1], but as it is a holiday here in the States, I will have to do so from home, not from work. On the other hand, IIRC, most of the trouble we've had hearing each other, Christian, has been while I'm at home. (I generally take early morning conference calls from home.) Looking forward! Note ---- [1] Some timezone equivalents: Calgary Canada - Alberta Mon 05:00 Chicago U.S.A. - Illinois Mon 06:00 Indianapolis U.S.A. - Indiana Mon 07:00 Providence U.S.A. - Rhode Island Mon 07:00 London U.K. - England Mon 12:00 Paris France Mon 13:00 Taipei Taiwan Mon 20:00 Kyoto Japan Mon 21:00 Wellington New Zealand Tue 01:00 From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Jan 15 07:22:16 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Mon, 15 Jan 2007 21:22:16 +0900 Subject: [tei-council] teleconference scheduled for 2007-01-23, 1200 GMT on highspeedconferencing.com Message-ID: <45AB71F8.5030903@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, Thanks to Sebastian, Matthew Driscoll, Tone Merete and Laurent, we just successfully conducted our test on the highspeedconferencing.com system. The results were encouraging for me; the voices from Europe much more audible than usual. Although we missed our colleagues from the American continent, understandably, it is hard to say how it will scale to 15 people in the line instead of just 5, but I think it is worth a try and if successful should make the calls much less costly, since most participants would not need to make oversea calls. However, for those planning to use skype to connect -- please get a good headset to use, otherwise you will spoil the whole experience. Now, back to business. I am starting to collect agenda items. If you have something you think should be on our mind, please post it to the list. Updates on work items, reports, documents for review etc. please post them and announce them here before the weekend! All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 07:26:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 12:26:53 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45A38C7B.9030302@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> Message-ID: <45AE160D.8050404@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Truly James he speaks the truth. This *is* the time to remove that > div0/div1 weirdness. > > > div1: "contains a first-level subdivision of the front, body, or > back > of a text (the largest, if > div0 is not used, the second largest if it is)." > > sigh. > > OK, whats the case for the defence? > (a) History. Precedent. Early doc processing systems use h0 and some h1 as the biggest class; if you were brung up on a "start from zero" one, it's less of a headache. (b) Safety net. If you start from div1, as sure as eggs is eggs, some time you will find you need a bigger grouping, so you'll be glad that div0 is there. These both look pretty tenuous to me, but they're the best I can think of. Any others? From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 07:30:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 12:30:21 +0000 Subject: [tei-council] FAND Message-ID: <45AE16DD.6030705@oucs.ox.ac.uk> Can I ask for a decision on Monday about my proposal to sort out numbered divs in the body/front/back? It is encapsulated in the ODD at http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Test/testfand.odd?revision=1971&view=markup In summary: * define 3 newmodel classes: divLike, divNLike, divGenLike * redefine front/body/back to allow 3 basic models 1. paragraphs 2. divLike + divGenLike 3. divNLike + divGenLike * have divNLike consisting of div0 only. people who want to start with div1 need to do a customization I am really very keen to not have this drag on. Maybe we can start 2007 with some decision-making? :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 07:31:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 12:31:54 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE160D.8050404@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> Message-ID: <45AE173A.1050303@oucs.ox.ac.uk> Lou Burnard wrote: > > (a) History. Precedent. Early doc processing systems use h0 and some > h1 as the biggest class; if you were brung up on a "start from zero" > one, it's less of a headache. dont buy that one > > (b) Safety net. If you start from div1, as sure as eggs is eggs, some > time you will find you need a bigger grouping, so you'll be glad that > div0 is there. if you have that problem, you should be using

...... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Wed Jan 17 11:50:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 17 Jan 2007 11:50:45 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE173A.1050303@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> Message-ID: <17838.21477.770977.617028@emt.wwp.brown.edu> I was under the impression, perhaps incorrectly, that a large part of the decision to support both and (just as with the decision to support both numbered and unnumbered
s)q was because different communities within TEI were quite stuck on one or the other. In many ways the TEI is a set of community consensus Guidelines (as opposed to a standard from on high or a set of best practices, although I daresay it has elements of those, too). I doubt those communities have changed their love of one over the other, although perhaps with the advent of XSLT they are more willing to have local vs interchange formats that differ. Of course, now that our pricing structure is based on "div0" as the most expensive, we can't very well start at "div1", can we? :-) From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 12:08:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 17:08:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.21477.770977.617028@emt.wwp.brown.edu> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> Message-ID: <45AE57F3.7070702@oucs.ox.ac.uk> Syd Bauman wrote: > I was under the impression, perhaps incorrectly, that a large part of > the decision to support both and (just as with the > decision to support both numbered and unnumbered
s)q was because > different communities within TEI were quite stuck on one or the > other. Indeed. I am sure that is so, but let's look forward. What shall we do now, in P5? Is it your belief that we should leave things as they are? Sorry to push, but I want to avoid the outcome of "yes it's not right as it is, but we're not sure what to do, so we'll keep brooding over it and maybe look again next year". You know my views on the "it's ready when it's ready" philosophy :-} sebastian From daniel.odonnell at uleth.ca Wed Jan 17 12:22:22 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 10:22:22 -0700 Subject: [tei-council] Agenda item? Message-ID: <1169054542.7389.38.camel@odonned-eng06> Hi all, I have a topic that I hesitantly mention: tei:choice. My own conviction is that we have too narrow a content model for the element. But I understand that it may be too late to revisit the question? I've been asking around to find a consensus on when an element of P5 has been "decided" and only minor modifications are considered possible, but we apparently don't have one. If anybody thinks this is worth discussing at this telco or the next, I can prepare something. -dan -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Wed Jan 17 12:28:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 17 Jan 2007 12:28:22 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE57F3.7070702@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> Message-ID: <17838.23734.957343.873006@emt.wwp.brown.edu> You asked for the case for the defense (of both a and as top-level division). I am presenting one: users requested it, and unless we find out that they've changed their minds, that's an argument to keep them both. From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:47:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:47:13 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE6F31.4050504@oucs.ox.ac.uk> Syd Bauman wrote: > You asked for the case for the defense (of both a and > as top-level division). I am presenting one: users requested it, and > unless we find out that they've changed their minds, that's an > argument to keep them both. > > What evidence do you have for this? I don't recall any formal or informal consultation on this specific issue, but maybe that's my memory. From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:52:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:52:17 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169054542.7389.38.camel@odonned-eng06> References: <1169054542.7389.38.camel@odonned-eng06> Message-ID: <45AE7061.80200@oucs.ox.ac.uk> Dan O'Donnell wrote: > Hi all, > > I have a topic that I hesitantly mention: tei:choice. My own conviction > is that we have too narrow a content model for the element. But I > understand that it may be too late to revisit the question? > > I've been asking around to find a consensus on when an element of P5 has > been "decided" and only minor modifications are considered possible, but > we apparently don't have one. I seem to have missed out on this "asking around": were you seeking Council's opinion on the procedural issue of when/how element definitions get fixed, or on the specific technical issue of whether the current proposal for the content model of needs attention? > > If anybody thinks this is worth discussing at this telco or the next, I > can prepare something. > On which topic? > -dan From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 12:40:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 17:40:12 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE5F7C.603@oucs.ox.ac.uk> Syd Bauman wrote: > You asked for the case for the defense (of both a and > as top-level division). I am presenting one: users requested it, and > unless we find out that they've changed their minds, that's an > argument to keep them both. > I can see the argument, but I think it does not hold water, because we have not done any quantifiable user consultation for many years; how would we know if they have changed their minds? you can test the water on TEI-L, but that's pretty subjective. Sebastian From daniel.odonnell at uleth.ca Wed Jan 17 13:21:21 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 11:21:21 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE7061.80200@oucs.ox.ac.uk> References: <1169054542.7389.38.camel@odonned-eng06> <45AE7061.80200@oucs.ox.ac.uk> Message-ID: <1169058081.13385.15.camel@odonned-eng06> On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote: > Dan O'Donnell wrote: > > Hi all, > > > > I have a topic that I hesitantly mention: tei:choice. My own conviction > > is that we have too narrow a content model for the element. But I > > understand that it may be too late to revisit the question? > > > > I've been asking around to find a consensus on when an element of P5 has > > been "decided" and only minor modifications are considered possible, but > > we apparently don't have one. > > I seem to have missed out on this "asking around": were you seeking > Council's opinion on the procedural issue of when/how element > definitions get fixed, or on the specific technical issue of whether the > current proposal for the content model of needs attention? > > > > > If anybody thinks this is worth discussing at this telco or the next, I > > can prepare something. > > > > On which topic? The one I labelled as "a topic" above: tei:choice. The "asking around" about procedure, as the expression suggests, was informal and so didn't involve more than a couple of casual email exchanges with some old TEI hands in the course of other business: before proposing that we revisit choice, I thought I better check if it was maybe too late or if there was a procedure to indicate that certain topics were now closed or open. The answer I got back each time was that there seemed not to be a formal process in place covering this at council. It was suggested to me that the procedural aspect might be worth discussing at council as well, though that's at best a secondary interest of mine here. We seem to be doing all right on the whole and I'm just interested in choice. -dan > > > > -dan > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Jan 17 13:37:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 17 Jan 2007 18:37:40 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169058081.13385.15.camel@odonned-eng06> References: <1169054542.7389.38.camel@odonned-eng06> <45AE7061.80200@oucs.ox.ac.uk> <1169058081.13385.15.camel@odonned-eng06> Message-ID: <45AE6CF4.9080201@computing-services.oxford.ac.uk> Well, afaik the procedure for proposing changes to TEI P5 is like this: You write a feature request and send it to the sourceforge site. The editors review the list of outstanding requests and make proposals to council as to their disposition. Council then agrees (or not) and the change gets made (or not); or council can suggest there should be a new work item. Since you say you didnt want to talk about the procedure, but rather about choice -- why not write that feature request? Dan O'Donnell wrote: > On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote: > >> Dan O'Donnell wrote: >> >>> Hi all, >>> >>> I have a topic that I hesitantly mention: tei:choice. My own conviction >>> is that we have too narrow a content model for the element. But I >>> understand that it may be too late to revisit the question? >>> >>> I've been asking around to find a consensus on when an element of P5 has >>> been "decided" and only minor modifications are considered possible, but >>> we apparently don't have one. >>> >> I seem to have missed out on this "asking around": were you seeking >> Council's opinion on the procedural issue of when/how element >> definitions get fixed, or on the specific technical issue of whether the >> current proposal for the content model of needs attention? >> >> >>> If anybody thinks this is worth discussing at this telco or the next, I >>> can prepare something. >>> >>> >> On which topic? >> > > The one I labelled as "a topic" above: tei:choice. The "asking around" > about procedure, as the expression suggests, was informal and so didn't > involve more than a couple of casual email exchanges with some old TEI > hands in the course of other business: before proposing that we revisit > choice, I thought I better check if it was maybe too late or if there > was a procedure to indicate that certain topics were now closed or open. > > The answer I got back each time was that there seemed not to be a formal > process in place covering this at council. It was suggested to me that > the procedural aspect might be worth discussing at council as well, > though that's at best a secondary interest of mine here. We seem to be > doing all right on the whole and I'm just interested in choice. > > -dan > > >> >>> -dan >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> From daniel.odonnell at uleth.ca Wed Jan 17 13:52:42 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 11:52:42 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE6CF4.9080201@computing-services.oxford.ac.uk> References: <1169054542.7389.38.camel@odonned-eng06> <45AE7061.80200@oucs.ox.ac.uk> <1169058081.13385.15.camel@odonned-eng06> <45AE6CF4.9080201@computing-services.oxford.ac.uk> Message-ID: <1169059962.16650.12.camel@odonned-eng06> On Wed, 2007-17-01 at 18:37 +0000, Lou Burnard wrote: > Well, afaik the procedure for proposing changes to TEI P5 is like this: > You write a feature request and send it to the sourceforge site. The > editors review the list of outstanding requests and make proposals to > council as to their disposition. Council then agrees (or not) and the > change gets made (or not); or council can suggest there should be a new > work item. > > Since you say you didnt want to talk about the procedure, but rather > about choice -- why not write that feature request? Sure, if that's how we do it. I'll just follow the model used to get the DIV business we've been discussing added to the agenda (I thought I had been). Since this is a current topic that has apparently gone through a similar process, I'll presumably have no trouble taking it as my model. I also didn't actually say I didn't want to talk about procedure. I called it a secondary issue for me next to my interest in choice. If we've got one, then so be it. -dan > > > > > > Dan O'Donnell wrote: > > On Wed, 2007-17-01 at 18:52 +0000, Lou Burnard wrote: > > > >> Dan O'Donnell wrote: > >> > >>> Hi all, > >>> > >>> I have a topic that I hesitantly mention: tei:choice. My own conviction > >>> is that we have too narrow a content model for the element. But I > >>> understand that it may be too late to revisit the question? > >>> > >>> I've been asking around to find a consensus on when an element of P5 has > >>> been "decided" and only minor modifications are considered possible, but > >>> we apparently don't have one. > >>> > >> I seem to have missed out on this "asking around": were you seeking > >> Council's opinion on the procedural issue of when/how element > >> definitions get fixed, or on the specific technical issue of whether the > >> current proposal for the content model of needs attention? > >> > >> > >>> If anybody thinks this is worth discussing at this telco or the next, I > >>> can prepare something. > >>> > >>> > >> On which topic? > >> > > > > The one I labelled as "a topic" above: tei:choice. The "asking around" > > about procedure, as the expression suggests, was informal and so didn't > > involve more than a couple of casual email exchanges with some old TEI > > hands in the course of other business: before proposing that we revisit > > choice, I thought I better check if it was maybe too late or if there > > was a procedure to indicate that certain topics were now closed or open. > > > > The answer I got back each time was that there seemed not to be a formal > > process in place covering this at council. It was suggested to me that > > the procedural aspect might be worth discussing at council as well, > > though that's at best a secondary interest of mine here. We seem to be > > doing all right on the whole and I'm just interested in choice. > > > > -dan > > > > > >> > >>> -dan > >>> > >> _______________________________________________ > >> tei-council mailing list > >> tei-council at lists.village.Virginia.EDU > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > >> > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 14:20:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 19:20:55 +0000 Subject: [tei-council] Agenda item? In-Reply-To: <1169054542.7389.38.camel@odonned-eng06> References: <1169054542.7389.38.camel@odonned-eng06> Message-ID: <45AE7717.8070903@oucs.ox.ac.uk> I think this is a Bug Report on Sourceforge, not a Feature Request. You are going to argue that the content model for is wrong, that's all, right? But it is essential that the reports on SF be dealt with, and closed. Unclosed feature requests going back to 2004 make us look, er, rather silly. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From djbpitt+tei at pitt.edu Wed Jan 17 14:23:45 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 17 Jan 2007 14:23:45 -0500 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <17838.23734.957343.873006@emt.wwp.brown.edu> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> Message-ID: <45AE77C1.3040005@pitt.edu> Dear TEI Council, > You asked for the case for the defense (of both a and > as top-level division). I am presenting one: users requested it, and > unless we find out that they've changed their minds, that's an > argument to keep them both. > The TEI Guidelines strive mightily to be flexible, allowing multiple ways to do the same thing because different user subcommunities have different preferences. The arguments for doing what users want are self-evident and certainly sensible, but we pay a price for this, which has been brought to our attention recently in the discussion of how
, , and do or do not play well together. I'd like to suggest that TEI Council not be excessively shy about expressing a strong opinion (when we can more or less agree on one) about best practice, and about steering the Guidelines in that direction. Users who want to do something differently have the ability to customize, so nobody is suggesting that deviating from out-of-the-box TEI (to the extent that there is such a thing) means exile from the TEI community, but to the extent that we prioritize making it easier for people to do whatever they please, we move toward guidelines that don't guide as much as they might. In arguing that we should not be excessively flexible I certainly don't mean to suggest that we should be capriciously dictatorial. Rather, I think "some people want to do it this way" is an argument that should be treated with respect, but it is not something that puts an end to all argument. Best, David From daniel.odonnell at uleth.ca Wed Jan 17 16:13:16 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 17 Jan 2007 14:13:16 -0700 Subject: [tei-council] Agenda item? In-Reply-To: <45AE7717.8070903@oucs.ox.ac.uk> References: <1169054542.7389.38.camel@odonned-eng06> <45AE7717.8070903@oucs.ox.ac.uk> Message-ID: <1169068396.24012.3.camel@odonned-eng06> On Wed, 2007-17-01 at 19:20 +0000, Sebastian Rahtz wrote: > I think this is a Bug Report on Sourceforge, not a Feature Request. You > are going > to argue that the content model for is wrong, that's all, right? Conceptually wrong. I.e. that it should be much broader in what it can contain. I don't know if that is best considered a bug, or a feature request, or anything else. > > But it is essential that the reports on SF be dealt with, and closed. > Unclosed feature requests going back to 2004 make us look, er, rather silly. Indeed. > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at computing-services.oxford.ac.uk Wed Jan 17 17:25:06 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 17 Jan 2007 22:25:06 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AE77C1.3040005@pitt.edu> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> Message-ID: <45AEA242.5000707@computing-services.oxford.ac.uk> David J Birnbaum wrote: > I'd like to suggest that TEI Council not be excessively shy about > expressing a strong opinion (when we can more or less agree on one) > about best practice, and about steering the Guidelines in that > direction. Users who want to do something differently have the ability > to customize, so nobody is suggesting that deviating from out-of-the-box > TEI. Yes, and this reminds me that I have yet to finish my straw-man rewrite of the Conformance chapter. Mea Culpa. I will indeed do so, but it got delayed by the topic re-erupting on TEI-L. I'll try to take the issues mentioned there into consideration when doing so. Also, I'll not be able to participate in the upcoming council teleconference, my apologies. Although I'm much more of a
or if necessary kind of person than a , I am happy to compromise and support Sebastian's proposal of starting at by default and needing a (quite easy) customisation to change that if is preferred. > In arguing that we should not be excessively flexible I certainly don't > mean to suggest that we should be capriciously dictatorial. Rather, I > think "some people want to do it this way" is an argument that should be > treated with respect, but it is not something that puts an end to all > argument. Others' comments on whether switching to default start for those using numbered divs would seriously inconvenience the TEI community, leads me to a suggestion. How about I undertake a survey (something like surveymonkey) on behalf of the TEI which is then publicised on TEI-L to gauge the community's strength of feeling on this issue. Feel free to suggest questions to ask. If the council decides this is a good idea, I'll happily do so within the next month. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 18:00:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 23:00:52 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEA242.5000707@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> Message-ID: <45AEAAA4.7080906@oucs.ox.ac.uk> James Cummings wrote: > > How about I undertake a survey (something like surveymonkey) on > behalf of the TEI which is then publicised on TEI-L to gauge the > community's strength of feeling on this issue. Feel free to suggest > questions to ask. If the council decides this is a good idea, I'll > happily do so within the next month. it would be interesting to see what reaction we got, to test such a system. you could offer a choice between 1. remove all numbered divs from the TEI 2. remove div0 entirely 3. always start with div0 4. allow div0 or div1 as starting point -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 17 18:05:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Jan 2007 23:05:48 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEA242.5000707@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> Message-ID: <45AEABCC.9020506@oucs.ox.ac.uk> James Cummings wrote: > > Yes, and this reminds me that I have yet to finish my straw-man > rewrite of the Conformance chapter. Mea Culpa. I will indeed do so, > but it got delayed by the topic re-erupting on TEI-L. I'll try to > take the issues mentioned there into consideration when doing so. > Also, I'll not be able to participate in the upcoming council > teleconference, my apologies. It would be immensely good if we had to draft to discuss a few days before the telco next week. Then we could see at the telco whether there was any kind of consensus. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Jan 17 22:33:47 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 12:33:47 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEAAA4.7080906@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> Message-ID: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > you could offer a choice between > > 1. remove all numbered divs from the TEI > 2. remove div0 entirely > 3. always start with div0 > 4. allow div0 or div1 as starting point > To which I would like to add 5. numbered divs always start with div1 since that is what I prefer. Given the (perceived) demographics of the TEI community, I would expect this to be a popular one. And you should make it clear that everybody gets to choose only one! Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Jan 17 22:39:44 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 12:39:44 +0900 Subject: [tei-council] Agenda item? In-Reply-To: <45AE6CF4.9080201@computing-services.oxford.ac.uk> References: <1169054542.7389.38.camel@odonned-eng06> <45AE7061.80200@oucs.ox.ac.uk> <1169058081.13385.15.camel@odonned-eng06> <45AE6CF4.9080201@computing-services.oxford.ac.uk> Message-ID: <45AEEC00.2010406@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > Well, afaik the procedure for proposing changes to TEI P5 is like this: > You write a feature request and send it to the sourceforge site. The > editors review the list of outstanding requests and make proposals to > council as to their disposition. Council then agrees (or not) and the > change gets made (or not); or council can suggest there should be a new > work item. This is how it is supposed to work, however we are not that good at implementing this protocol. Closing a topic is still something that rarely happens, viz. div0 vs div1. But there is no obvious way to improve that... All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Conal.Tuohy at vuw.ac.nz Wed Jan 17 22:54:00 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 18 Jan 2007 16:54:00 +1300 Subject: [tei-council] solving unnumbered divs (bis) Message-ID: Christian wrote: > Sebastian Rahtz wrote: > > you could offer a choice between > > > > 1. remove all numbered divs from the TEI > > 2. remove div0 entirely > > 3. always start with div0 > > 4. allow div0 or div1 as starting point > > > > To which I would like to add > 5. numbered divs always start with div1 Isn't that the same as option 2? From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 00:00:45 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 14:00:45 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: References: Message-ID: <45AEFEFD.10809@kanji.zinbun.kyoto-u.ac.jp> Conal Tuohy wrote: > Christian wrote: >>> 2. remove div0 entirely >> To which I would like to add >> 5. numbered divs always start with div1 > Isn't that the same as option 2? Ah, you are right. Sometimes it is better first to think, then to write. Sorry for the noise. Now I'll try to do some thinking... All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:00:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:00:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45AF3713.6070809@oucs.ox.ac.uk> Wittern Christian wrote: > >> >> 1. remove all numbered divs from the TEI >> 2. remove div0 entirely >> 3. always start with div0 >> 4. allow div0 or div1 as starting point >> > > To which I would like to add > 5. numbered divs always start with div1 *and* keep div0? I assumed my 2. impluied your 5. sebastian From lou.burnard at computing-services.oxford.ac.uk Thu Jan 18 04:34:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 18 Jan 2007 09:34:42 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45AF3F32.4080905@computing-services.oxford.ac.uk> Wittern Christian wrote: > Sebastian Rahtz wrote: >> you could offer a choice between >> >> 1. remove all numbered divs from the TEI >> 2. remove div0 entirely >> 3. always start with div0 >> 4. allow div0 or div1 as starting point >> > > To which I would like to add > 5. numbered divs always start with div1 > > since that is what I prefer. Given the (perceived) demographics of > the TEI community, I would expect this to be a popular one. And you > should make it clear that everybody gets to choose only one! > > Christian > > > Is it wise to base this decision solely on "perceived demographics"? WHat's the basis for the perception? Where is the evidence?Those chaps in NZ have barely started their survey yet, let alone produced any results. I note also that we have in the past made far more radical changes in P5 (id to xml:id, lang to xml:lang) on the basis of other criteria, and even (in the latter case) in the teeth of voluble opposition from the "perceived demographic". Personally I would like to have a good technical argument for making (or not making) any of these changes. From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:38:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:38:58 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF4032.9040100@oucs.ox.ac.uk> Lou Burnard wrote: > > Personally I would like to have a good technical argument for making > (or not making) any of these changes. The technical argument is simple. If we don't do something about the content model of //, the promise of the TEI that you can remove more or less any element and things will sort themselves is out the window. So jump off the fence, and choose your preference: 1. leave things as they are. tell Ron to read Syd's solutions on the wiki 2. rewrite the body content model in such a clever way that it survives the loss of div0 and div1 in DTD 3. model-ize the divXX things so that things come out in the wash (my proposal) 4. rewrite the ODD processor to make a clean DTD whatever happens 5. all of 2, 3 and 4 simultaneously I can't believe that we need more info, and more discussion, we've already spent what seems like years of my life in this area, publicly or privately... Solutions 2. and 4. require resources, so anyone choosing those should explain who is going to do that work (clue: it aint me...). You could always call for a vote, Christian :-} Sebastian From lou.burnard at computing-services.oxford.ac.uk Thu Jan 18 04:55:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 18 Jan 2007 09:55:03 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF4032.9040100@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> <45AF4032.9040100@oucs.ox.ac.uk> Message-ID: <45AF43F7.3060107@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > The technical argument is simple. If we don't do something about the > content model of //, > the promise of the TEI that you can remove more or less any element > and things will sort themselves > is out the window. > > So jump off the fence, and choose your preference: > > 1. leave things as they are. tell Ron to read Syd's solutions on the > wiki > 2. rewrite the body content model in such a clever way that it > survives the loss of div0 and div1 in DTD > 3. model-ize the divXX things so that things come out in the wash (my > proposal) > 4. rewrite the ODD processor to make a clean DTD whatever happens > 5. all of 2, 3 and 4 simultaneously That's quite a different set of proposals from the set that Christian just presented! Forgive me if too much tropical sun has blunted my perceptions, but he seemed to be proposing abolition of one or more of the various flavours of div, not making them into distinct classes. If the latter is the issue before us, we've already agreed that references to classes should be preferred above references to elements wherever possible, so what's the argument about? > > I can't believe that we need more info, and more discussion, we've > already > spent what seems like years of my life in this area, publicly or > privately... > > Solutions 2. and 4. require resources, so anyone choosing those should > explain who is going to do that work (clue: it aint me...). > > You could always call for a vote, Christian :-} > > Sebastian > From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 04:53:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 09:53:27 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF43F7.3060107@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> <45AF4032.9040100@oucs.ox.ac.uk> <45AF43F7.3060107@computing-services.oxford.ac.uk> Message-ID: <45AF4397.90700@oucs.ox.ac.uk> Lou Burnard wrote: > That's quite a different set of proposals from the set that Christian > just presented! eh? thats a different, orthogonal, discussion (and it was my set) > Forgive me if too much tropical sun has blunted my perceptions, but he > seemed to be proposing abolition of one or more of the various > flavours of div, not making them into distinct classes. the div0 vs div1 debate follows on if you adopt my proposal for classing divXXXs, but it can also be had in isolation. > > If the latter is the issue before us, we've already agreed that > references to classes should be preferred above references to elements > wherever possible, so what's the argument about? if you class the divXXX things as per my proposal, you end up allowing ... ... in a document, because I drew the line at separate classes for div0 and div1. I commend a thorough read of testfand.odd. Sebastian From James.Cummings at oucs.ox.ac.uk Thu Jan 18 05:02:02 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 18 Jan 2007 10:02:02 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF459A.60101@oucs.ox.ac.uk> Lou Burnard wrote: > Is it wise to base this decision solely on "perceived demographics"? > What's the basis for the perception? Where is the evidence? Hence my proposed survey. I suggest I post a survey and give people a month to answer it. While I wouldn't want to make such a change *solely* on statistical results of such a survey, since we have a technical need for it, if the survey's findings point to one of the possible solutions as preferable then at least that is some evidence. Of course, we should be aware that the survey might produce information that only complicates the matter. (If for example there is a 60/40 split, do we go with the 60? Surely 40% of respondents would represent a significant portion of the community and thus we'd be back to trying to implement both.) Basically the question is whether people want to continue to support use of both div0 and div1 as a starting element. If people are fine with numbered divs starting only at div0, then that is fine. If a strong contingent feel they should also be allowed to start at div1, then it is more problematic. > Those chaps > in NZ have barely started their survey yet, let alone produced any results. The University of Sydney is in Australia. > I note also that we have in the past made far more radical changes in P5 > (id to xml:id, lang to xml:lang) on the basis of other criteria, and > even (in the latter case) in the teeth of voluble opposition from the > "perceived demographic". True, and the only reason I'm suggesting the survey is that it might shed some light on how strongly the community feels about this. (i.e. is this a lone voice crying in the wilderness or a general consensus) > Personally I would like to have a good technical argument for making (or > not making) any of these changes. I think Sebastian has already made the technical argument for making these changes (and the argument for not making them being that we're unable to have people cleanly remove numbered divs should they desire). -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Thu Jan 18 05:09:10 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 18 Jan 2007 10:09:10 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF459A.60101@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> <45AF459A.60101@oucs.ox.ac.uk> Message-ID: <45AF4746.4000802@kcl.ac.uk> Could we have a public summary of the 'technical argument' that people interested can have a look at before replying to the survey? James: I am happy to help out with the survey if you like. Arianna James Cummings wrote: > Lou Burnard wrote: >> Is it wise to base this decision solely on "perceived demographics"? >> What's the basis for the perception? Where is the evidence? > > Hence my proposed survey. I suggest I post a survey and give people a month to > answer it. While I wouldn't want to make such a change *solely* on statistical > results of such a survey, since we have a technical need for it, if the survey's > findings point to one of the possible solutions as preferable then at least that > is some evidence. Of course, we should be aware that the survey might produce > information that only complicates the matter. (If for example there is a 60/40 > split, do we go with the 60? Surely 40% of respondents would represent a > significant portion of the community and thus we'd be back to trying to > implement both.) Basically the question is whether people want to continue to > support use of both div0 and div1 as a starting element. If people are fine > with numbered divs starting only at div0, then that is fine. If a strong > contingent feel they should also be allowed to start at div1, then it is more > problematic. > >> Those chaps >> in NZ have barely started their survey yet, let alone produced any results. > > The University of Sydney is in Australia. > >> I note also that we have in the past made far more radical changes in P5 >> (id to xml:id, lang to xml:lang) on the basis of other criteria, and >> even (in the latter case) in the teeth of voluble opposition from the >> "perceived demographic". > > True, and the only reason I'm suggesting the survey is that it might shed some > light on how strongly the community feels about this. (i.e. is this a lone > voice crying in the wilderness or a general consensus) > >> Personally I would like to have a good technical argument for making (or >> not making) any of these changes. > > I think Sebastian has already made the technical argument for making these > changes (and the argument for not making them being that we're unable to have > people cleanly remove numbered divs should they desire). > > -James -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From James.Cummings at oucs.ox.ac.uk Thu Jan 18 05:12:11 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 18 Jan 2007 10:12:11 +0000 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AEABCC.9020506@oucs.ox.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEABCC.9020506@oucs.ox.ac.uk> Message-ID: <45AF47FB.4020206@oucs.ox.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> >> Yes, and this reminds me that I have yet to finish my straw-man >> rewrite of the Conformance chapter. Mea Culpa. I will indeed do so, >> but it got delayed by the topic re-erupting on TEI-L. I'll try to >> take the issues mentioned there into consideration when doing so. >> Also, I'll not be able to participate in the upcoming council >> teleconference, my apologies. > It would be immensely good if we had to draft to discuss a few days > before the > telco next week. Then we could see at the telco whether there was any > kind of consensus. I do apologise that this will not happen before the telco. Today and Sunday I will be preparing for a meeting in Amsterdam. (And said meeting is why I won't be able to make the telco.) Friday and Saturday I have previous personal commitments. I am happy to promise to submit a draft to council within a month (if that) of the telco though. Apologies, -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 07:24:51 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Thu, 18 Jan 2007 21:24:51 +0900 Subject: [tei-council] solving unnumbered divs (bis) In-Reply-To: <45AF3F32.4080905@computing-services.oxford.ac.uk> References: <45A2CA67.6020900@oucs.ox.ac.uk> <45A2DBCC.6040002@oucs.ox.ac.uk> <45A3895A.8060709@oucs.ox.ac.uk> <45A38C7B.9030302@oucs.ox.ac.uk> <45AE160D.8050404@computing-services.oxford.ac.uk> <45AE173A.1050303@oucs.ox.ac.uk> <17838.21477.770977.617028@emt.wwp.brown.edu> <45AE57F3.7070702@oucs.ox.ac.uk> <17838.23734.957343.873006@emt.wwp.brown.edu> <45AE77C1.3040005@pitt.edu> <45AEA242.5000707@computing-services.oxford.ac.uk> <45AEAAA4.7080906@oucs.ox.ac.uk> <45AEEA9B.7090206@kanji.zinbun.kyoto-u.ac.jp> <45AF3F32.4080905@computing-services.oxford.ac.uk> Message-ID: <45AF6713.1050703@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > Wittern Christian wrote: >> Sebastian Rahtz wrote: >>> you could offer a choice between >>> >>> 1. remove all numbered divs from the TEI >>> 2. remove div0 entirely >>> 3. always start with div0 >>> 4. allow div0 or div1 as starting point >>> >> >> To which I would like to add >> 5. numbered divs always start with div1 >> >> since that is what I prefer. Given the (perceived) demographics of >> the TEI community, I would expect this to be a popular one. And you >> should make it clear that everybody gets to choose only one! >> >> Christian > Is it wise to base this decision solely on "perceived demographics"? > WHat's the basis for the perception? Where is the evidence?Those chaps > in NZ have barely started their survey yet, let alone produced any results. > > I note also that we have in the past made far more radical changes in P5 > (id to xml:id, lang to xml:lang) on the basis of other criteria, and > even (in the latter case) in the teeth of voluble opposition from the > "perceived demographic". > > Personally I would like to have a good technical argument for making (or > not making) any of these changes. Well, I guess you noted the tongue in cheek. But as it happens, this is supposed to go into a questionaire to solicit some answers to this very questions -- with results that might be quite different from what I expected. And BTW, the original set originated with Sebastian, it is not something I made up. Best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 18 10:45:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 18 Jan 2007 15:45:03 +0000 Subject: [tei-council] another content model for body Message-ID: <45AF95FF.3090405@oucs.ox.ac.uk> OK, I think is now no longer controversial. It keeps all the div/div1/div0 distinctions, and also allows a 4th way, with paragraph-like objects before optional divisions. It is now not far off the existing model. Personally, I think my original iteration using Schematron was a lot more fun. Tested for situations with div deleted, div1/div0 deleted, and all div-like objects removed (testfand, testfand2, testfand3 in Sourceforge) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 19:47:01 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 09:47:01 +0900 Subject: [tei-council] open issues and planning Message-ID: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, In preparation for the telecon, I tried to take a stock of open issues for P5. The first stop was the Kyoto Declaration: http://www.tei-c.org/Council/tcw08.xml?style=printable In the essential department, we have (1) * chapter review, including review of examples (2) * decision on module dependency architecture made, and if yes implemented (3) * remove instructions on how to invoke TEI DTD from each chapter (4) * New user needs to have an easy way to generate customization ODD and generate schemas (5) * text of prose matches specs (6) * *Specs frozen! :-) (7) * Dictionary rewrite completed (8) * Modification and Conformance chapters rewritten I was wondering where we stand on these issues and how much work needs to be done. Since there is some dependency on this, it seems to me that we should see how much is needed to achieve (6). Also, (1) could commence on chapters that are already checked off with regards to the spec. Can someone remind me what we decided with respect to (2)? Laurent, what is the status of the Dictionary chapter. When can we expect a draft? As to (8), that is on James' table now. It seems to me that we should start (1), which will take a while to complete, as soon as possible. What are the preconditions to start here? Who will be in charge of this? These are questions we should adress. We also need a better way to track the progress -- Maybe we should start a Wiki page for this? As to other open issues, I have on my list (from combing the tei-council @lists and the minutes of our telecons, initials are the lead on for the item): * schematron rules (SR?) * simplifying of dates (SB) * 'limited phrase' (SB) * biblItems etc (JW) * PB followup (MD & DP) * infrastructure for examples (LB, SB) * FS request updates (LB, SB) * div0, div1 decision (SB) * choice content model (anything else?) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 19:53:21 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 09:53:21 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Message-ID: <45B01681.4080407@kanji.zinbun.kyoto-u.ac.jp> DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Expected to participate: Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern Sent apologies: JC ============================================================ How to connect We will use the highspeedconferencing.com service this time. Participants can use their skype account (www.skype.com) or regular phones to call. When calling via skype, *please use a headset*. If in doubt, it might be better to call via regular phone. Numbers as follow: Calling from the US... call # 1-712-432-4000 (long distance charges apply). Calling from Europe, call: Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350 The Conference Room Number is 5877524 ============================================================ Please read through the following. Wherever a report is requested, a brief note to the list before the call is much appreciated and will help us use the time during the call more effectively. ============================================================ 1) Minutes, work items, progress since last meeting: http://www.tei-c.org.uk/Council/tcm27.xml?style=printable Please look at the action items and report progress here before the meeting! ============================================================ 2) Workgroups monitoring: A) PB Dot & Matthew, please report on developments here. WG TEI website: http://www.tei-c.org.uk/Activities/PB/index.xml B) PERS Matthew, please give us an update on the preparations for the meeting etc. C) I18N Sebastian, please give us a brief report on where we stand here. ============================================================ 3) Road to P5: I am circulating a separete message lining out some of the issues I see. I would like to go away from this telecon with a clearer view of the road ahead and how we get there. ============================================================ 4) Meetings Council 2007: Berlin, preparations? Do we need more meetings? next call: Mid to end March 2007 ============================================================ 5) Other business TBA ============================================================ -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Thu Jan 18 20:29:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 18 Jan 2007 20:29:09 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17840.7909.19929.739280@emt.wwp.brown.edu> Perfect timing, Christian. I was just about to post a "where I am w/ dates" item. I'll intersperse it, below. > * schematron rules (SR?) This one is SB. > * simplifying of dates (SB) I am working on this issue right now. The results of our TEI-L poll about and are that absolutely no one except EpiDoc said they even use them at all, let alone the children we are going to eliminate. Since EpiDoc is already a significant customization (P4 at the moment), with significant talent available, they can easily add whatever they need back. (And I think it likely that they will actually find other mechanisms when they move to P5.) Thus I have no problem yanking 'em out. So I am right now in the process of removing the , , , , , , , and elements. Once done with that, I plan to post a summary of outstanding issues with some suggestions, probably over the weekend. > * 'limited phrase' (SB) > * biblItems etc (JW) > * PB followup (MD & DP) > * infrastructure for examples (LB, SB) Could someone remind me what this means? > * FS request updates (LB, SB) > * div0, div1 decision (SB) Did you really mean me? From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 22:02:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 12:02:28 +0900 Subject: [tei-council] open issues and planning In-Reply-To: <17840.7909.19929.739280@emt.wwp.brown.edu> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <17840.7909.19929.739280@emt.wwp.brown.edu> Message-ID: <45B034C4.5080306@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: > Perfect timing, Christian. I was just about to post a "where I am w/ > dates" item. I'll intersperse it, below. > Great, thanks. In fact I felt this was terribly late... >> * schematron rules (SR?) > This one is SB. Good. > >> * simplifying of dates (SB) > I am working on this issue right now. The results of our TEI-L poll > about and are that absolutely no one except > EpiDoc said they even use them at all, let alone the children we are > going to eliminate. Since EpiDoc is already a significant > customization (P4 at the moment), with significant talent available, > they can easily add whatever they need back. (And I think it likely > that they will actually find other mechanisms when they move to P5.) > Thus I have no problem yanking 'em out. So I am right now in the process > of removing the , , , , , > , , and elements. Great. > > Once done with that, I plan to post a summary of outstanding issues > with some suggestions, probably over the weekend. > Fine. It is probably as much as we can get, given the timeframe. >> * 'limited phrase' (SB) >> * biblItems etc (JW) >> * PB followup (MD & DP) >> * infrastructure for examples (LB, SB) > Could someone remind me what this means? That should also be SR here, the issue is how to make multilingual examples possible -- e.g. where to put them, and what to change in the toolchain. > >> * FS request updates (LB, SB) >> * div0, div1 decision (SB) > Did you really mean me? No, SR as well. It seems I got a bit confused halfway through. So, the updated and corrected list is * schematron rules (SB) * simplifying of dates (SB) * 'limited phrase' (SB) * biblItems etc (JW) * PB followup (MD & DP) * infrastructure for examples (LB, SR) * FS request updates (LB, SB) * div0, div1 decision (SR) * choice content model (?) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Jan 18 22:13:12 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Wittern Christian) Date: Fri, 19 Jan 2007 12:13:12 +0900 Subject: [tei-council] Budget news, PERS meeting Message-ID: <45B03748.2080202@kanji.zinbun.kyoto-u.ac.jp> Council members, I just got news from Dan that the Board approved a rollover of unspend budget of 2006 for 2007. If I understand correctly, we thus have roughly $4k more than last year to spend , i.e. $28k. This is a one time, no precedent-setting affair under the assumption that P5 will finally go out this year and thus needs some additional care. We might be able to squeeze in a second f2f meeting of the Council or a subcommittee modeled on the Oxford class meeting if that turns out to be necessary -- this is assuming that the April meeting in Berlin will be significantly less expensive than last years Kyoto meeting. Apart from that, and much more concrete, there has been a request from Matthew Driscoll to hold the PERS meeting in Vilnius. He expects this will set us back around $4-5k. This would also go out of this above mentioned budget. I would like to approve this, but am open to other opinions from the Council. We will need to act quickly on this, so if you disagree, please speek up now. I will set the cutoff time for protests to Sunday evening 23:59 GMT, which will allow me to notify Matthew of the results Monday morning JST. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 03:54:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 08:54:08 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B08730.40901@oucs.ox.ac.uk> Wittern Christian wrote: > (1) * chapter review, including review of examples > (2) * decision on module dependency architecture made, and if yes > implemented > (3) * remove instructions on how to invoke TEI DTD from each chapter > (4) * New user needs to have an easy way to generate customization > ODD and generate schemas > (5) * text of prose matches specs > (6) * *Specs frozen! :-) > (7) * Dictionary rewrite completed > (8) * Modification and Conformance chapters rewritten > > I was wondering where we stand on these issues and how much work needs > to be done. Since there is some dependency on this, it seems to me that > we should see how much is needed to achieve (6). One absolute requirement here is to assess all outstanding bug reports and feature requests in SF, and deal with them one way or another. If, for example, Dan is going to raise issues about , that needs a quick agreement. With my I18N hat on, there are now five groups translating descriptions of specs with a delivery date of the autumn at latest. I am taking it on trust therefore that the specs _are_ frozen to all intents and purposes. The PERS activity will likely need some Specs adding. and dictionaries of course. > Also, (1) could > commence on chapters that are already checked off with regards to the spec. > Can someone remind me what we decided with respect to (2)? > I (think) we agreed it was unworkable and not probably needed. The immediate requirement was met by the new model class facility to allow sequences as well as alternations. I think we should let this one die a natural death for now > It seems to me that we should start (1), which will take a while to > complete, as soon as possible. What are the preconditions to start > here? Who will be in charge of this? These are questions we should adress. > agreed. someone has to drive this in a pretty strict way. > We also need a better way to track the progress -- Maybe we should start > a Wiki page for this? > I did wonder about running trac (http://trac.edgewall.org/) as an aide. > * schematron rules (SR?) > what about them? support for them is implemented, but I the reaction I got a few weeks ago seemed to be against it. As I said then, I'd much rather implement a div0/div/div1 thing using Schematron if we accept its serious use > * infrastructure for examples (LB, SB) > In my opinion, we have no resources to deal with this. I think its a distraction this year. > * div0, div1 decision (SB) > If you accept my model class reimplementation of , can we just agree to abide by the results of James and Ariana's surveymonkey, and simply implement what they find out. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Fri Jan 19 10:04:17 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 10:04:17 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B08730.40901@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> Message-ID: <17840.56817.452436.521530@emt.wwp.brown.edu> > I am taking it on trust therefore that the specs _are_ frozen to > all intents and purposes. > > The PERS activity will likely need some Specs adding. and dictionaries > of course. I do not think the specifications are in any way frozen. In addition to those you've mentioned, just this week we have been discussing possible significant changes in the , , and specifications, and we will be discussing the revamping of dating attributes. There are probably quite a few others, as well. Not to mention that neither the editors nor the Council has announced that they can be or are frozen. From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 11:17:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 16:17:53 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <17840.56817.452436.521530@emt.wwp.brown.edu> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> Message-ID: <45B0EF31.7010204@oucs.ox.ac.uk> Syd Bauman wrote: > > I do not think the specifications are in any way frozen. in any way at all? out of 650, are more than 1% still gelid? > In addition > to those you've mentioned, just this week we have been discussing > possible significant changes in the , , and > specifications those are small details; bug fixes, really. They don't affect the descriptions or semantics etc > and we will be discussing the revamping of dating > attributes. details. You're zapping half a dozen elements, and will clean up after you. I count that as frozen. > There are probably quite a few others, as well. > Sorry, "probably quite a few" isn't good enough. What others, precisely? if they are recorded issues unresolved, let's list them, and solve them. Of course there are always more and more issues to find if we look hard enough, but the process must end soon if we are to meet our commitments. "What commitments", someone will ask? Well, if you (all) don't think we have a *commitment* to deliver TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't singing off the same song sheet. > Not to mention that neither the editors nor the Council has announced > that they can be or are frozen. > I didn't imply that. I said *I* regard them as frozen. I propose a strawman timetable for us: 1st February: accept no more feature requests for 5.0 1st March: all Sourceforge bug reports and feature requests from before Feb 1 closed or definitely put off for 5.1 1st April: all implementation resulting from those SF things complete 1st May: (after council meeting) technical freeze of specs, only serious bug fixes allowed after that I have a feeling you are all going to get fed up with me saying this, but I feel very strongly that we cannot carry on in "ready when its ready" mode. We need at least minimal project management here, and that includes timetables and deadlines. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Fri Jan 19 11:55:12 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Fri, 19 Jan 2007 09:55:12 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B0EF31.7010204@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> Message-ID: <1169225712.23841.14.camel@odonned-eng06> On Fri, 2007-19-01 at 16:17 +0000, Sebastian Rahtz wrote: > Syd Bauman wrote: > > > Sorry, "probably quite a few" isn't good enough. > What others, precisely? if they are recorded > issues unresolved, let's list them, and solve them. > Of course there are always more and more issues > to find if we look hard enough, but the process must > end soon if we are to meet our commitments. > > "What commitments", someone will ask? > > Well, if you (all) don't think we have a *commitment* to deliver > TEI 5.0 completely ready for use by the TEI MM 2007, > then we ain't singing off the same song sheet. > > Not to mention that neither the editors nor the Council has announced > > that they can be or are frozen. > > > I didn't imply that. I said *I* regard them as frozen. > > I propose a strawman timetable for us: > > 1st February: accept no more feature requests for 5.0 > 1st March: all Sourceforge bug reports and feature requests from before > Feb 1 closed or definitely put off for 5.1 > 1st April: all implementation resulting from those SF things complete > 1st May: (after council meeting) technical freeze of specs, only > serious bug fixes allowed after that > > I have a feeling you are all going to get fed up with me saying this, > but I feel very strongly that we cannot carry on in "ready when its ready" > mode. We need at least minimal project management here, and that includes > timetables and deadlines. I agree. The board was quite serious about getting P5 done this year and indeed had a "push money" line in the budget. The effort as currently structured may not be sustainable much after this calendar year either, as it is starting to take a toll on several major participants--or their employers' patience. That's why I'd originally asked around to find out when something is frozen. Obviously it is a fine line: we also can't put out substandard work either (not that that's ever been a TEI problem). And the Board and several TEI partners seem quite interested in stability after P5 (i.e. we should perhaps not move on to P6 right away if P6 means major revisioning). Given the nature of what we are up, therefore, to perhaps we should define "bug" to mean major conceptual issues with finished work as well. What I mean by this is if somebody discovers a major flaw in the underlying reasoning--something that would require us to move on to P6. I suspect from the above exchange that what we are really looking at is agreeing on and formalising what we mean by frozen and what makes something frozen: the things Syd mentions as not frozen fit Sebastian's definition of frozen. Should process (or project management for the next ten months--yikes!) be an agenda item after all? It certainly does seem to me that we need to say "x is done--to propose changes, there needs to be a serious issue involved." -dan > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Fri Jan 19 12:11:18 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Fri, 19 Jan 2007 10:11:18 -0700 Subject: [tei-council] Budget news, PERS meeting In-Reply-To: <45B03748.2080202@kanji.zinbun.kyoto-u.ac.jp> References: <45B03748.2080202@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1169226678.23841.25.camel@odonned-eng06> As an ex officio member, I believe I can still signal my lack of protest. Speaking personally, I think it is a good idea. -dan On Fri, 2007-19-01 at 12:13 +0900, Wittern Christian wrote: > Council members, > > I just got news from Dan that the Board approved a rollover of unspend > budget of 2006 for 2007. If I understand correctly, we thus have roughly > $4k more than last year to spend , i.e. $28k. This is a one time, no > precedent-setting affair under the assumption that P5 will finally go > out this year and thus needs some additional care. We might be able to > squeeze in a second f2f meeting of the Council or a subcommittee modeled > on the Oxford class meeting if that turns out to be necessary -- this is > assuming that the April meeting in Berlin will be significantly less > expensive than last years Kyoto meeting. > > Apart from that, and much more concrete, there has been a request from > Matthew Driscoll to hold the PERS meeting in Vilnius. He expects this > will set us back around $4-5k. This would also go out of this above > mentioned budget. I would like to approve this, but am open to other > opinions from the Council. We will need to act quickly on this, so if > you disagree, please speek up now. I will set the cutoff time for > protests to Sunday evening 23:59 GMT, which will allow me to notify > Matthew of the results Monday morning JST. > > All the best, > > Christian > > > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 19 12:10:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 19 Jan 2007 17:10:24 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <1169225712.23841.14.camel@odonned-eng06> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <1169225712.23841.14.camel@odonned-eng06> Message-ID: <45B0FB80.4000600@oucs.ox.ac.uk> The Birnbaum Declaration agreed last autumn covers what it means to be P5 1.0, 1.1, 1.2 as opposed to P6, I think. My concern is that we are juggling too many balls at the same time, without resources. We won't get through the "Steps To P5" if they all run in parallel, unless someone here miraculously takes a 6 month sabbatical and devotes themselves to TEI editing full-time. So although of course there are circular dependencies, let's at least try to clear out things in sequence. In our meetings, f2f or telco or email, we tend to have far too many varied things on the agenda at once.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Fri Jan 19 14:20:54 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 14:20:54 -0500 Subject: [tei-council] open issues and planning In-Reply-To: <45B0EF31.7010204@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> Message-ID: <17841.6678.27216.694302@emt.wwp.brown.edu> > Well, if you (all) don't think we have a *commitment* to deliver > TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't > singing off the same song sheet. Yes, we are singing off different sheets. Some may wonder, but I think we are singing the same piece of music, at least, just different arrangements, to carry the analogy too far. > 1st February: accept no more feature requests for 5.0 This has already happened twice, and need not be repeated. Feature requests submitted now would almost assuredly *not* be considered for the 1.0 releaes of P5. (Sorry, Daniel.) From daniel.odonnell at uleth.ca Fri Jan 19 14:26:21 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 19 Jan 2007 12:26:21 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <17841.6678.27216.694302@emt.wwp.brown.edu> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <17841.6678.27216.694302@emt.wwp.brown.edu> Message-ID: <1169234781.5519.5.camel@localhost> On Fri, 2007-01-19 at 14:20 -0500, Syd Bauman wrote: > > Well, if you (all) don't think we have a *commitment* to deliver > > TEI 5.0 completely ready for use by the TEI MM 2007, then we ain't > > singing off the same song sheet. > > Yes, we are singing off different sheets. Some may wonder, but I > think we are singing the same piece of music, at least, just > different arrangements, to carry the analogy too far. > > > > 1st February: accept no more feature requests for 5.0 > > This has already happened twice, and need not be repeated. Feature > requests submitted now would almost assuredly *not* be considered for > the 1.0 releaes of P5. (Sorry, Daniel.) It's a dog's life! ;) Frankly I suspected as much. I'm happier to see us progressing to 1.0 release than I am sad at not getting the right way of doing choice--strong wink--into the release! -dan > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From Syd_Bauman at Brown.edu Fri Jan 19 23:19:30 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 19 Jan 2007 23:19:30 -0500 Subject: [tei-council] , , and Message-ID: <17841.38994.991726.171153@emt.wwp.brown.edu> Great minds think alike. (But are they right?) I am in the midst of yanking out , , etc. from the Guidelines. In doing so I re-worked several examples that use the element. I found myself wondering if , which is pretty much syntactic sugar for , should also be ditched. Then I came across the following comment: I don't think Michael ever used "shd", and I know I didn't, so I'm giving Lou credit for this insight. But perhaps this one is syntactic sugar sweet enough to keep. Here's an example. A week before the meeting (Note that "P07D" is the ISO & W3C format for a period of seven days.) A week before the meeting (Note that "d" is the symbol for "day" approved by CIPM for use with SI units.) is also used within and for the same kind of thing, but it does not have the right attributes to provide a regularized value. Thus I'm in favor of using instead of for and . If I had my druthers, I think I'd prefer to use dur= on in alternation with the other three attributes: element measure { ( attribute dur { xsd:duration }? | ( attribute unit { data.enumerated }?, attribute quantity { data.numeric }?, attribute commodity { data.words }?, ) ), etc. } At the moment I don't think ODD processors can handle that sort of construct, so if we went this route we would probably want to enforce it with a Schematron rule. From lou.burnard at computing-services.oxford.ac.uk Sat Jan 20 04:59:58 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 20 Jan 2007 09:59:58 +0000 Subject: [tei-council] , , and In-Reply-To: <17841.38994.991726.171153@emt.wwp.brown.edu> References: <17841.38994.991726.171153@emt.wwp.brown.edu> Message-ID: <45B1E81E.6010809@computing-services.oxford.ac.uk> 1. If we are getting rid of the substructure of , then we're getting rid of all of it, so it makes no difference whether you represent old by or , it's still dead. The element in particular really really has to go. 2. As it happens, yes we do have a way of representing a choice of attributes in ODD. See http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html. There is a (not very good) example at 27.3.3.3 and we use it on eg and Syd Bauman wrote: > > > But perhaps this one is syntactic sugar sweet enough to keep. Here's > an example. > > > A week > before > the meeting > > > (Note that "P07D" is the ISO & W3C format for a period of seven > days.) > > > A week > before > the meeting > > > (Note that "d" is the symbol for "day" approved by CIPM for use with > SI units.) > > is also used within and for the > same kind of thing, but it does not have the right attributes to > provide a regularized value. Thus I'm in favor of using > instead of for and . > > If I had my druthers, I think I'd prefer to use dur= on in > alternation with the other three attributes: > > element measure { > ( > attribute dur { xsd:duration }? > | > ( > attribute unit { data.enumerated }?, > attribute quantity { data.numeric }?, > attribute commodity { data.words }?, > ) > ), > etc. > } > > At the moment I don't think ODD processors can handle that sort of > construct, so if we went this route we would probably want to enforce > it with a Schematron rule. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From Syd_Bauman at Brown.edu Sat Jan 20 07:51:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 07:51:25 -0500 Subject: [tei-council] , , and In-Reply-To: <45B1E81E.6010809@computing-services.oxford.ac.uk> References: <17841.38994.991726.171153@emt.wwp.brown.edu> <45B1E81E.6010809@computing-services.oxford.ac.uk> Message-ID: <17842.4173.302963.500608@emt.wwp.brown.edu> > 1. If we are getting rid of the substructure of , then we're > getting rid of all of it, so it makes no difference whether you > represent old by or , it's still > dead. The element in particular really really has to go. No, actually, and were not in the list of elements to be nuked. (The reasoning was that they are used inside , too, I believe.) > 2. As it happens, yes we do have a way of representing a choice of > attributes in ODD. See > http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html. > There is a (not very good) example at 27.3.3.3 and we use it on eg > and Right, but IIRC Sebastian has pointed out that this mechanism can only be used to alternate two attributes, not one attribute with a group of others or two groups. I am not sure whether this restriction existed only back then, exists currently, or will in perpetuity. From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 20 09:31:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 20 Jan 2007 14:31:59 +0000 Subject: [tei-council] , , and In-Reply-To: <17842.4173.302963.500608@emt.wwp.brown.edu> References: <17841.38994.991726.171153@emt.wwp.brown.edu> <45B1E81E.6010809@computing-services.oxford.ac.uk> <17842.4173.302963.500608@emt.wwp.brown.edu> Message-ID: <45B227DF.3070906@oucs.ox.ac.uk> Syd Bauman wrote: >> 2. As it happens, yes we do have a way of representing a choice of >> attributes in ODD. See >> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html. >> There is a (not very good) example at 27.3.3.3 and we use it on eg >> and >> > > Right, but IIRC Sebastian has pointed out that this mechanism can > only be used to alternate two attributes, not one attribute with a > group of others or two groups. I am not sure whether this restriction > existed only back then, exists currently, or will in perpetuity. > If you believe the attList specification allows what you need, then I should implement it. I'm willing to have a try, if its needed. On the other hand, restrictions like this are good candidates for Schematron, as you say. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From lou.burnard at computing-services.oxford.ac.uk Sat Jan 20 10:38:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 20 Jan 2007 15:38:23 +0000 Subject: [tei-council] , , and In-Reply-To: <45B227DF.3070906@oucs.ox.ac.uk> References: <17841.38994.991726.171153@emt.wwp.brown.edu> <45B1E81E.6010809@computing-services.oxford.ac.uk> <17842.4173.302963.500608@emt.wwp.brown.edu> <45B227DF.3070906@oucs.ox.ac.uk> Message-ID: <45B2376F.9070404@computing-services.oxford.ac.uk> The specification says that an attList can contain any combination of attRef, attDef, or attList, and that its org attribute determines whether its children are to be regarded as forming a group or an alternation. So I cannot for the life of me see what you might want that the spec doesn't support. If the current ODD processor doesn't support it, then it's a bug, and should be documented. HOWEVER, before we get all excited about using this wonderful facility, I'd like to record my profound skepticism about the wisdom of allowing @dur as an attribute on at all. Sebastian Rahtz wrote: > Syd Bauman wrote: >>> 2. As it happens, yes we do have a way of representing a choice of >>> attributes in ODD. See >>> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-attList.html. >>> There is a (not very good) example at 27.3.3.3 and we use it on eg >>> and >>> >> >> Right, but IIRC Sebastian has pointed out that this mechanism can >> only be used to alternate two attributes, not one attribute with a >> group of others or two groups. I am not sure whether this restriction >> existed only back then, exists currently, or will in perpetuity. >> > If you believe the attList specification allows what > you need, then I should implement it. I'm willing > to have a try, if its needed. > > On the other hand, restrictions like this are > good candidates for Schematron, as you say. > From Syd_Bauman at Brown.edu Sat Jan 20 10:55:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 10:55:36 -0500 Subject: [tei-council] , , and In-Reply-To: <45B227DF.3070906@oucs.ox.ac.uk> References: <17841.38994.991726.171153@emt.wwp.brown.edu> <45B1E81E.6010809@computing-services.oxford.ac.uk> <17842.4173.302963.500608@emt.wwp.brown.edu> <45B227DF.3070906@oucs.ox.ac.uk> Message-ID: <17842.15224.28276.20873@emt.wwp.brown.edu> > If you believe the attList specification allows what you need, then > I should implement it. I'm willing to have a try, if its needed. I certainly think the specification allows this: This states that a must have either both A1= and A2= or both B1= and B2=, and can't have all four of them (or zero, one, or three of them). This could be expressed in RelaxNG as which in the compact syntax requires what always looks to me like an extra layer of parenthesis, but makes sense when you think of the outer parens as and the inner parens as : element duck { ( ( attribute A1 { empty }, attribute A2 { empty } ) | ( attribute B1 { empty }, attribute B2 { empty } ) ), empty } What I'm not certain of is whether we want to change the implementation to do what the specification permits, or change the specification so that you can't do this. I lean towards the former, but it may be more effort than it's worth. > On the other hand, restrictions like this are good candidates for > Schematron, as you say. True. And although there are some disadvantages with using Schematron (speed problems jump to mind), it does have the advantage of providing a check for those who use DTDs. From Syd_Bauman at Brown.edu Sat Jan 20 11:08:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 20 Jan 2007 11:08:56 -0500 Subject: [tei-council] , , and In-Reply-To: <45B2376F.9070404@computing-services.oxford.ac.uk> References: <17841.38994.991726.171153@emt.wwp.brown.edu> <45B1E81E.6010809@computing-services.oxford.ac.uk> <17842.4173.302963.500608@emt.wwp.brown.edu> <45B227DF.3070906@oucs.ox.ac.uk> <45B2376F.9070404@computing-services.oxford.ac.uk> Message-ID: <17842.16024.499219.282091@emt.wwp.brown.edu> > HOWEVER, before we get all excited about using this wonderful > facility, I'd like to record my profound skepticism about the > wisdom of allowing @dur as an attribute on at all. I am also uneasy with putting a dur= on . But simultaneously, I'm uneasy about expressing a span of time using dur= if it is a
s"), but that we should not be considering new feature requests (like making
a permissible child of ). I realize that in some cases there is a fine line between the two, and room for disagreement, discussion, etc. But that doesn't change my basic premise. From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 12:02:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 17:02:14 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <17844.58341.865396.934650@emt.wwp.brown.edu> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> <17844.58341.865396.934650@emt.wwp.brown.edu> Message-ID: <45B4EE16.3020006@oucs.ox.ac.uk> Syd Bauman wrote: > I probably missed something, then. I thought we were quite careful > at the MM in Victoria *not* to make a full-fledged commitment to > have P5 done by College Park. Memories obviously vary. I thought we made an absolute commitment to do this! > Taiwan or not, I thought it was deliberate. Besides, Lou has > suggested, and I think he's right, that an additional face-to-face > meeting over chapter review is probably a good idea. That may (or > may not) make it quite difficult to be done with 1.0 by MM2007. > why can't we have another f2f before November? > - "frozen" means r/o, and is a drastic step that is taken > immediately before publication > - none of P5 is currently frozen > - much of it is close -- I like the word SR used "gelid" > I agree, none of it is yet definitively r/o. Freezing, not frozen > - I would guess some 95% of or Spec files are gelid, with a bunch > that are due for significant work, including (off the top of my > head) those affected by: > + changes to dating attrs > + limited-phrase decisions > these are in your ball court right now, correct? > + handling regularization of names > + handling spans > not sure about these > + whatever we end up doing about postscripts > ? > + new stuff on "placeography" > aAgreed, thats dependent on rapid work in the Baltic > + addition of Schematron rules > We don't _need_ to add any of these, do we? The facility is there, we can use, or not, any time > + the div0, div1, div0|div1, or no numbered divs decision > that's in hand, I hope. > + potential changes to bibl, biblStruct, biblItem system > oh lord, isn't that dead yet ??? Anyway, even your list sounds eminently doable between now and the Council f2f. Just needs some hard graft. We just work out a timetable week by week for which issues to resolve in that week, and stick to it. It's not rocket science.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From lou.burnard at computing-services.oxford.ac.uk Mon Jan 22 12:30:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 22 Jan 2007 17:30:03 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4EE16.3020006@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> <17844.58341.865396.934650@emt.wwp.brown.edu> <45B4EE16.3020006@oucs.ox.ac.uk> Message-ID: <45B4F49B.6000104@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Syd Bauman wrote: >> I probably missed something, then. I thought we were quite careful >> at the MM in Victoria *not* to make a full-fledged commitment to >> have P5 done by College Park. > Memories obviously vary. I thought we made an absolute > commitment to do this! Me too. >> Taiwan or not, I thought it was deliberate. Besides, Lou has >> suggested, and I think he's right, that an additional face-to-face >> meeting over chapter review is probably a good idea. That may (or >> may not) make it quite difficult to be done with 1.0 by MM2007. >> > why can't we have another f2f before November? I suggested a FTF meeting to review the state of chapters before publication, yes. It could be any time before November. In my opinion, the priorities are (still) - triage of outstanding SF feature requests - chapter review The specific items Syd mentions are all things that could be resolved quite quickly, I think, once we accept that it's more important to have a finished product than a perfect one. From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 13:15:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 18:15:15 +0000 Subject: [tei-council] telco details Message-ID: <45B4FF33.8090403@oucs.ox.ac.uk> From Skype call +99008278525675 In the US, call 1-712-432-4000 Calling from Europe, call In Austria: 0820 400 01562 In Belgium: 0703 59 984 In France: 0826 100 266 In Germany 01805 00 7620 In UK: 0870 119 2350 Enter Conference Room Number : 5326922 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Mon Jan 22 14:06:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 22 Jan 2007 14:06:53 -0500 Subject: [tei-council] telco details In-Reply-To: <45B4FF33.8090403@oucs.ox.ac.uk> References: <45B4FF33.8090403@oucs.ox.ac.uk> Message-ID: <17845.2893.511611.763191@emt.wwp.brown.edu> CW> The Conference Room Number is 5877524 SR> Enter Conference Room Number : 5326922 Which? (Or do we get to choose?) From daniel.odonnell at uleth.ca Mon Jan 22 14:39:40 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 12:39:40 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <17844.58341.865396.934650@emt.wwp.brown.edu> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> <17844.58341.865396.934650@emt.wwp.brown.edu> Message-ID: <1169494780.26853.14.camel@odonned-eng06> On Mon, 2007-22-01 at 11:18 -0500, Syd Bauman wrote: > * On feature requests and : > I do not think Daniel's idea is a bug-fix request at all, but a > feature request. I think we've already made two calls for feature > requests with cut-off dates, and we should *not* make a third. That > does not mean we should stop considering user input (e.g., bug > reports like "neither nor is not allowed between >
s"), but that we should not be considering new feature > requests (like making
a permissible child of ). I > realize that in some cases there is a fine line between the two, > and room for disagreement, discussion, etc. But that doesn't change > my basic premise. Happy to be put in my place. I know a couple of other people are interested in this specific question, so I'll try to talk to them over the next week about launching a feature request for 1.x. -dan > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:12:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:12:36 +0000 Subject: [tei-council] telco details In-Reply-To: <17845.2893.511611.763191@emt.wwp.brown.edu> References: <45B4FF33.8090403@oucs.ox.ac.uk> <17845.2893.511611.763191@emt.wwp.brown.edu> Message-ID: <45B51AB4.6030709@oucs.ox.ac.uk> Syd Bauman wrote: > CW> The Conference Room Number is 5877524 > SR> Enter Conference Room Number : 5326922 > > Which? (Or do we get to choose?) > *my room is definitely 5326922* Christian, did you register another room? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Mon Jan 22 15:15:25 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 22 Jan 2007 15:15:25 -0500 Subject: [tei-council] telco details In-Reply-To: <17845.2893.511611.763191@emt.wwp.brown.edu> References: <45B4FF33.8090403@oucs.ox.ac.uk> <17845.2893.511611.763191@emt.wwp.brown.edu> Message-ID: <96f3df640701221215v4f3fd5c6ucd662c73668edd0e@mail.gmail.com> If we use both rooms, will we get twice as much done? On 1/22/07, Syd Bauman wrote: > CW> The Conference Room Number is 5877524 > SR> Enter Conference Room Number : 5326922 > > Which? (Or do we get to choose?) > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:17:02 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:17:02 +0000 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: <45B4D706.40106@computing-services.oxford.ac.uk> References: <45B01681.4080407@kanji.zinbun.kyoto-u.ac.jp> <45B4D706.40106@computing-services.oxford.ac.uk> Message-ID: <45B51BBE.2030902@oucs.ox.ac.uk> Lou Burnard wrote: > > On multilingual exemplification, as Sebastian has already indicated, > there isn't a lot we *need* do at the moment, which is why I haven't > given the matter a lot of thought. I am willing to do so in due course, > when we have a bit more translation activity underway. bear in mind that we have no example translation scheduled. the target is descriptions for now. The urgency would be if we needed to change the ODD spec, and there is no current indication that we need to do so. There is a need for some rules about managing examples, and processes to be scripted, but do we see a need for different markup? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:46:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:46:49 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <17841.6678.27216.694302@emt.wwp.brown.edu> <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B522B9.1080009@oucs.ox.ac.uk> Christian Wittern wrote: > While there is still some last minute surgery going on in some > quarters, I think we have to cordon off some areas now and start to do > the clean-up there, although we can't > declare the whole building finished. it makes initial sense to me to do this by module. Obviously namesdates still has scaffolding on it, while textstructure probably just needs some last bits of painting. If we can declare some modules clean, we can simultaneously check the prose and do any last minute screen of the specs. What we *must* have is a clear schedule of affected areas; that's why finishing the SF work is so important. We don't want any unexpected change to msdescription popping up there. If there are 20 or 30 unresolved things, get them listed, work on them, kill them one by one. Don't let them get up again. > In fact, since there has been so much underground change in P5 it > seems likely that people will continue to discover changes, for > example in content models that where not intended but are a result of > the way we re-defined classes. > > Sure, that'll always be true. We can assume a degree of risk in anything we do. If I was drawing up a list of risks which would stop the "Finish P5 by October 1st" project from completing, unexpected bugs with wide impact found by users would come in relatively low. A bigger risk is dependency on volunteer or unscheduled labour; the greatest risk is, I would say, that no-one uses P5 when we are done. If we were a business, that would knock us dead, it would like no-one buying Windows Vista. It might amuse you to know that I used the conversion TEI to XML as my case study for a course on project management some years ago. Building up these lists of risks and so on was quite illuminating. Perhaps I should bore you all with a SWOT analysis? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Mon Jan 22 15:53:25 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 13:53:25 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B522B9.1080009@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <17841.6678.27216.694302@emt.wwp.brown.edu> <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp> <45B522B9.1080009@oucs.ox.ac.uk> Message-ID: <1169499205.26853.78.camel@odonned-eng06> On Mon, 2007-22-01 at 20:46 +0000, Sebastian Rahtz wrote: > Perhaps I should bore you all with a SWOT analysis? Would it be a less useful than boring analysis? I'd like to know! -dan > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:53:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:53:51 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B5245F.5040704@oucs.ox.ac.uk> Christian Wittern wrote: > > In an ideal world, the specs would have the approval from the Council > before being handed for translation. I realize that reality has > overtaken us here, but it still is a situation that worries me. Maybe > we need a status flag on the specs that indicates its state ("proposed", > "implemented", "tested", "approved") to track its status? > It worries me a little too; but I am also confident that I can work out for any given spec which of the translations is out of date at any given time. It isn't completely easy, but doable. > >> I did wonder about running trac (http://trac.edgewall.org/) as an aide. >> > > Do you have experience with this? It certainly looks good, but we can't > throw too much ressources on getting this up and runnin > I could justify a bit of work on this (Lou, as part of assessments for software palette), but there is one flaw - it can't link to the Subversion on Sourceforge. I *could* set it up to work for 6 months on its own Subversion, copied from SF, and keep them in sync, but I am not keen :-} Or we could use it without Subversion. Is anyone else interested in mechanical assistance like this? ie taking 50 open issues and managing them in an adhoc system until they are fixed? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 15:56:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 20:56:38 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <45B4244A.5030504@kanji.zinbun.kyoto-u.ac.jp> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <1169225712.23841.14.camel@odonned-eng06> <45B0FB80.4000600@oucs.ox.ac.uk> <45B4244A.5030504@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45B52506.4060804@oucs.ox.ac.uk> > Maybe we should schedule addtional topical meetings that take care of > specific issues? we could try. but it will not work until we have a firm culture within our group of accepting actions as firm commitments with deadlines, and sticking to them. I think I can say truthfully that we are all fairly bad at meeting our actions :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Mon Jan 22 16:20:13 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 22 Jan 2007 14:20:13 -0700 Subject: [tei-council] open issues and planning In-Reply-To: <45B5245F.5040704@oucs.ox.ac.uk> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <45B4229B.4000003@kanji.zinbun.kyoto-u.ac.jp> <45B5245F.5040704@oucs.ox.ac.uk> Message-ID: <1169500813.2854.8.camel@odonned-eng06> If there is a culture problem on council--and I'm a terrible procrastinator as well--then we need to try and change the culture for the year. It is relatively imperative, as I understand things, that we get through to P5 1.0 this year. I've been going through the board minutes and while there is no magic phrase--"We absolutely must have P5 out this year"--there is a lot of discussion about the sustainability of the current efforts beyond 2007 (and not much hope that we will be able to). The pressure is external as well as internal and affect both funding and cooperation with other agencies, so it is not simply a matter of finding small amounts of extra money. In addition, the Board is currently working on a model for the TEI in a post P5 world with a relatively clear idea that we are talking about "starting next year." I wonder if flagging items along the lines proposed here would not be doable without taking too much time away from actual guidelines work. It may be a very good practice as we close in on the end--and save us some time. I'd imagine editorial judgement is required for a final call, but we might be able to delegate somebody to go through and do a rough sorting first? What say? -dan On Mon, 2007-22-01 at 20:53 +0000, Sebastian Rahtz wrote: > Christian Wittern wrote: > > > > In an ideal world, the specs would have the approval from the Council > > before being handed for translation. I realize that reality has > > overtaken us here, but it still is a situation that worries me. Maybe > > we need a status flag on the specs that indicates its state ("proposed", > > "implemented", "tested", "approved") to track its status? > > > It worries me a little too; but I am also confident that I can work out > for any given spec which of the translations is out of date > at any given time. It isn't completely easy, but doable. > > > >> I did wonder about running trac (http://trac.edgewall.org/) as an aide. > >> > > > > Do you have experience with this? It certainly looks good, but we can't > > throw too much ressources on getting this up and runnin > > > I could justify a bit of work on this (Lou, as part of assessments for > software palette), but there is one flaw - it can't link to the Subversion > on Sourceforge. I *could* set it up to work for 6 months on > its own Subversion, copied from SF, and keep them in sync, but > I am not keen :-} Or we could use it without Subversion. > > Is anyone else interested in mechanical assistance like this? > ie taking 50 open issues and managing them in an adhoc > system until they are fixed? > > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 22 16:23:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 22 Jan 2007 21:23:26 +0000 Subject: [tei-council] open issues and planning In-Reply-To: <1169499205.26853.78.camel@odonned-eng06> References: <45B01505.6040601@kanji.zinbun.kyoto-u.ac.jp> <45B08730.40901@oucs.ox.ac.uk> <17840.56817.452436.521530@emt.wwp.brown.edu> <45B0EF31.7010204@oucs.ox.ac.uk> <17841.6678.27216.694302@emt.wwp.brown.edu> <45B41705.9030807@kanji.zinbun.kyoto-u.ac.jp> <45B522B9.1080009@oucs.ox.ac.uk> <1169499205.26853.78.camel@odonned-eng06> Message-ID: <45B52B4E.107@oucs.ox.ac.uk> Dan O'Donnell wrote: > >> Perhaps I should bore you all with a SWOT analysis? >> > > Would it be a less useful than boring analysis? I'd like to know! > > Actually, I think we already did the SWOT in Victoria, in our Board meeting, informally. In summary, for the project "P5 by October 1st": Strengths: makes it look as if the Consortium can deliver stuff; allows members to start using it; frees resources for other things Weaknesses: if it isn't polished and consistent it makes us look bad if we announce it and fail to finish, we look fools; if we fall behind, morale suffers badly and volunteer labour drops out Opportunities: we can take the TEI to a new level of interoperability if we get the mechanism right Threats: The editorial work of the TEI is delegated to two people; if one or both fall behind schedule we have no backup arranged. The editors can only do their work based on volunteer labour of others - this may dry up. The Council may reach deadlock in discussing an issue and fail to resolve it in time. and so on. Any ideas on mitigating the threats, or adding to the strengths and opportunities? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Mon Jan 22 17:23:37 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 22 Jan 2007 17:23:37 -0500 (EST) Subject: [tei-council] date attributes: summary, problems, and some suggestions Message-ID: <200701222223.l0MMNblR024839@perseus.services.brown.edu> First, a listing of the attributes that are directly involved with dating. ("dating" as in "timing", not as in "courtship" :-) States of Play, P4 ------ -- ----- -- calendar= certainty= value=
. I'm having many problems to do it as I'm unable to locate the model in which to include it and even which content model to give it. I've tried with macro.bodyPart.div but it seems that inside the bound I've to provide a
element... Can you help me please? -- Elena Pierazzo Associate Researcher Centre for Computing in the Humanities King's College London Kay House 7 Arundel St London WC2R 3DX Phone: 0207-848-1949 Fax: 0207-848-2980 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 27 06:15:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 27 Jan 2007 11:15:35 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17849.63654.420850.730026@emt.wwp.brown.edu> References: <45B61308.4080001@oucs.ox.ac.uk> <17846.5754.722320.172317@emt.wwp.brown.edu> <45B63003.5020103@oucs.ox.ac.uk> <17849.36672.912461.821023@emt.wwp.brown.edu> <45B9B3BE.9050200@oucs.ox.ac.uk> <17849.63654.420850.730026@emt.wwp.brown.edu> Message-ID: <45BB3457.5000205@oucs.ox.ac.uk> Syd Bauman wrote: > Yes. Defeats the purpose of model.divWrapper, which is to come before > the div-type-stuff, of which is one. > I'll look at that. > So if after the or in my copy of the source text > there is something obliterated by a big coffee stain, I can't use > to encode that? I have to pretend there is something after it? > > you may or may not be surprised to hear that this is not allowed in the current model either, which ends needs some more jiggery-pokery. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 27 08:09:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 27 Jan 2007 13:09:21 +0000 Subject: [tei-council] content model of body etc In-Reply-To: <17849.63654.420850.730026@emt.wwp.brown.edu> References: <45B61308.4080001@oucs.ox.ac.uk> <17846.5754.722320.172317@emt.wwp.brown.edu> <45B63003.5020103@oucs.ox.ac.uk> <17849.36672.912461.821023@emt.wwp.brown.edu> <45B9B3BE.9050200@oucs.ox.ac.uk> <17849.63654.420850.730026@emt.wwp.brown.edu> Message-ID: <45BB4F01.90906@oucs.ox.ac.uk> If you don't have a headache yet today, read on. I can help you get one... I have rewritten the body content model as below, to explicitly model the sequence of 1. global stuff 2. divWrapper; if one occurs, it can be followed by more of itself interspersed with globals 3. divGen; if one occurs, it can be followed by more of itself interspersed with globals 4. div*Like things; if one occurs, it can be followed by more of itself interspersed with globals and divGens (but you have to choose between divLike, divN1Like and divN0Like routes and there is no going back) 4a. or maybe some paragraph-like things. 5. divWrapper; if one occurs, it can be followed by more of itself interspersed with globals Which I _believe_ is what we intend. The crucial thing here is that any stage can end in globals, but not start with them. This, with the starting globals, allows the beasts to appear anywhere, so far as I can tell. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From laurent.romary at loria.fr Sat Jan 27 11:30:11 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 27 Jan 2007 17:30:11 +0100 Subject: [tei-council] updated biblItem document In-Reply-To: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> References: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> Message-ID: Bonjour, Having gone through John's note, I am close to be convinced by . Could we imagine (and have examples thereof) linking micro-components of ?, like: The Garden of Proserpine Swinburne, Algernon Charles The Poems of Algernon Charles Swinburne London Chatto 1 169-172 6 vols. I guess this is part of the intedended mechanism, isn't it? Best, Laurent PS: to Seb: that was not a real headache, but I deeply think we should take some strong decisions to simplify the model (div*...) Le 23 janv. 07 ? 13:51, John A. Walsh a ?crit : > Hi Council, > > I've updated the biblItem document at http://ella.slis.indiana.edu/ > ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/ > ~jawalsh/tei/biblItem.xml) with some ODD, rnc, and instance examples. > > John > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: > | Voice:812-856-0707 Fax:812-856-2062 > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Sat Jan 27 11:31:42 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 27 Jan 2007 17:31:42 +0100 Subject: [tei-council] updated biblItem document In-Reply-To: <1169578076.31094.17.camel@odonned-eng06> References: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> <1169578076.31094.17.camel@odonned-eng06> Message-ID: Yes, a

or a could do the trick. I would support this. Best, Laurent Le 23 janv. 07 ? 19:47, Dan O'Donnell a ?crit : > John, > > The only question I have from your paper is the type attribute on > related item: this seems to me either a place for a fixed set of > options > or an area where users will need to be discursive at times: > type="other" > for example seems like it doesn't say very much unless it is part of a > defined set of choices ("other" than what?). > > Or do you not think that a desire to be discursive will be an issue? > > Would a solution be to have a

or some other element right at > the top > where the relationship would be specified? > > -dan > > On Tue, 2007-23-01 at 07:51 -0500, John A. Walsh wrote: >> Hi Council, >> >> I've updated the biblItem document at http://ella.slis.indiana.edu/ >> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/ >> ~jawalsh/ >> tei/biblItem.xml) with some ODD, rnc, and instance examples. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: >> | Voice:812-856-0707 Fax:812-856-2062 >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- > Daniel Paul O'Donnell, PhD > Chair, Text Encoding Initiative > Director, Digital Medievalist Project www.digitalmedievalist.org/> > Associate Professor and Chair of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox: +1 403 329 2378 > Fax: +1 403 382-7191 > Homepage: http://people.uleth.ca/~daniel.odonnell/ > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From jawalsh at indiana.edu Sat Jan 27 13:42:41 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Sat, 27 Jan 2007 13:42:41 -0500 Subject: [tei-council] updated biblItem document In-Reply-To: <1169578076.31094.17.camel@odonned-eng06> References: <549E8212-4302-475D-8756-A4723FC806CE@indiana.edu> <1169578076.31094.17.camel@odonned-eng06> Message-ID: <04CA87AB-CB50-4910-9B4B-06E4C7494F66@indiana.edu> Dan, I shouldn't have used type="other" in my example. It's confusing. I was imagining the type attribute on relatedItem being populated with a fixed or user-defined list. MODS (metadata object description schema; http://www.loc.gov/standards/mods/) has a relatedItem element with a type attribute, with enumerated values of: preceding, succeeding, original, host, constituent, series, otherVersion, otherFormat, isReferencedBy). We could come up with a fixed list or suggested values. John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: | Voice:812-856-0707 Fax:812-856-2062 On Jan 23, 2007, at 1:47 PM, Dan O'Donnell wrote: > John, > > The only question I have from your paper is the type attribute on > related item: this seems to me either a place for a fixed set of > options > or an area where users will need to be discursive at times: > type="other" > for example seems like it doesn't say very much unless it is part of a > defined set of choices ("other" than what?). > > Or do you not think that a desire to be discursive will be an issue? > > Would a solution be to have a

or some other element right at > the top > where the relationship would be specified? > > -dan > > On Tue, 2007-23-01 at 07:51 -0500, John A. Walsh wrote: >> Hi Council, >> >> I've updated the biblItem document at http://ella.slis.indiana.edu/ >> ~jawalsh/tei/biblItem.html (and http://ella.slis.indiana.edu/ >> ~jawalsh/ >> tei/biblItem.xml) with some ODD, rnc, and instance examples. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: >> | Voice:812-856-0707 Fax:812-856-2062 >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- > Daniel Paul O'Donnell, PhD > Chair, Text Encoding Initiative > Director, Digital Medievalist Project www.digitalmedievalist.org/> > Associate Professor and Chair of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox: +1 403 329 2378 > Fax: +1 403 382-7191 > Homepage: http://people.uleth.ca/~daniel.odonnell/ > From Syd_Bauman at Brown.edu Sat Jan 27 20:15:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 27 Jan 2007 20:15:24 -0500 Subject: [tei-council] [Fwd: creating a div.like element] In-Reply-To: <45BB3325.9060700@oucs.ox.ac.uk> References: <45BB3325.9060700@oucs.ox.ac.uk> Message-ID: <17851.63788.141020.628282@emt.wwp.brown.edu> > Here's a reminder, from a relatively sophisticated TEI-er, as to > why that content model for is a barrier to normal TEI > extension processes. Indeed, but keep in mind that this particular request demonstrates only that

should be in a model class.[1] We were all agreed to this back at the Oxford class meeting in 2005-09, I believe, but it has not been implemented for a variety of reasons. Note ---- [1] Alright, not entirely true ... it also demonstrates that it is not a good idea to leave unused specifications lying around in the source tree. From Syd_Bauman at Brown.edu Mon Jan 29 16:11:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 29 Jan 2007 16:11:52 -0500 Subject: [tei-council] First draft of TC M 28, notes from this morning's call, are up In-Reply-To: <45B74B2C.5000100@kanji.zinbun.kyoto-u.ac.jp> References: <17846.25623.799043.846750@emt.wwp.brown.edu> <45B74B2C.5000100@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17854.25368.513779.788414@emt.wwp.brown.edu> > I skipped some action items, that were obvious to me, for the > record: I figured that, but didn't want to be presumptuous. > DO: inform MD how much money is available to Council > [?...?] > he did report and we allocated the moneys. I've rewritten this; CW & DO (at least) should check this section to see if I've got it right. > SR: report on high speed conferences .com system > he did report (maybe only privately to me) and we did carry out a > test conference on Jan 15 -- without a tennis match, but Laurent > had a funny echo. SR has already updated this section. > Here is one item I forgot to bring up: > eds.: update [SF feature request] doc ? > [?...?] > which refers to > http://www.tei-c.org/Drafts/edw93.xml?style=printable, I think. > This will come up again in the road-map list. So noted. I've also fixed a missing URL. From James.Cummings at oucs.ox.ac.uk Tue Jan 30 09:53:50 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 30 Jan 2007 14:53:50 +0000 Subject: [tei-council] TEI Numbered Divs Survey Message-ID: <45BF5BFE.3050200@oucs.ox.ac.uk> Very briefly for council's approval I have set up a TEI Numbered Divs survey on surveymonkey.com This will allow for 100 responses. The survey is available at: http://www.surveymonkey.com/s.asp?u=82203219378 and I have discussed the implications of some of the questions and the phrasings of their answers with Sebastian and Arianna. Question #4 may seem a little out in left-field but I intend to use it as a sanity check. (i.e. if lots of people think we should be able to mix numbered div content with generic divs, then maybe we shouldn't take the survey results too seriously.) I'll take any suggestions for changes anyone has until I post a message about it on TEI-L in the next day or so. Let me know if there are any major typos or questions I've forgotten. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Tue Jan 30 10:38:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 30 Jan 2007 10:38:25 -0500 Subject: [tei-council] time & date model classes: lump 'em? Message-ID: <17855.26225.658719.629980@emt.wwp.brown.edu> Since we've removed <(date|time)(Range|Struct)>, we have some leaner classes. - The class model.dateLike has one member, . - The class model.timeLike has one member,
is div2Like, and , , and are div3Like". From James.Cummings at oucs.ox.ac.uk Fri Feb 9 19:59:02 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 10 Feb 2007 00:59:02 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. Message-ID: <45CD18D6.60109@oucs.ox.ac.uk> Dear Council, I have closed the TEI Numbered Divs survey and would like to report on the results. I have made a PDF of the summary report that Survey Monkey provides. It is available for download at: http://james.cummingsfamily.org.uk/TEI/survey.pdf The results are interesting. There were 87 responses total. For the first question about whether the TEI should contain both numbered and generic div elements, 44.8% wanted there to be only one type whereas 43.7% thought the current support for both should be preserved. For the second question about if the TEI were to support only one of these, which they would prefer, 18.4% wanted numbered divs, and 75.9% wanted generic divs. For the third question on where numbered divs should start (div0 vs div1) 13.3% thought one should always start at div0, 34.9% thought one should always start at div1, and an identical 34.9% thought that they didn't care as long as there was a single starting point. 7.2% thought that we should continue support for div0 or div1 and 9.6% wasn't sure. The test question, number four of whether you should be allowed to mix numbered and generic divs 81.2% wanted to continue support for only one at a time and 10.6% wanted to be able to do this. I think this indicates a general level of trustworthiness of the survey. Question 5 was a comment question basically indicating two camps as expected, those who like the simplicity of numbered divs and those who find them unnecessary. There were some other comments which I found interesting, see the PDF. Recommendations: 1) There is no clear mandate to get rid of numbered divs, the community is split basically 50/50 on this issue. I recommend that we maintain support for both. It is interesting that if we were to only support one type, i.e. if they were forced to choose, that a clear majority would prefer generic divs. However, because of the response on the first question, I don't think this is able to be acted upon. 2) There is a clear majority who want to start at div1 (and this is increased if we lump in those who don't care but want there to be a single starting point). My recommendation is that we start numbered divs at div1 only and provide two example customisations: a) One which changes the start to div0 and another b) which returns to the current div0|div1 optional start. Sebastian has assured me that these ODDs would be fairly straightforward. Presenting the community with these would lessen any negative feelings occurring because of this change. 3) The use of a survey to scope feeling of the TEI community has been generally positively received, and should be considered for other issues where the Council feels it might be useful. I'm sure the Council will want to discuss the results and how we should progress. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Fri Feb 9 20:32:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 9 Feb 2007 20:32:57 -0500 Subject: [tei-council] numbered divs, a proposed solution In-Reply-To: <45A2DD29.8050008@oucs.ox.ac.uk> References: <459FC2CE.5080805@oucs.ox.ac.uk> <45A21D4F.8020004@oucs.ox.ac.uk> <17826.33754.484151.883531@emt.wwp.brown.edu> <45A2B016.6070906@oucs.ox.ac.uk> <17826.55379.927889.377121@emt.wwp.brown.edu> <45A2DD29.8050008@oucs.ox.ac.uk> Message-ID: <17869.8393.173640.515800@emt.wwp.brown.edu> I'm sorry, I just realized I never responded to this! SR> yes, its technically OK. but if you have SR> (DUMMY | foo), (DUMMY2 | foo) SR> and you meet just a "foo", where does it come from? The first parenthetical -- since it is not a it is required to be a in order to match, as one or the other of the two element types in the first parenthetical must be matched. But note that if I meet just a it's not valid (since the model requires two s in a row, presuming our good sense tells us DUMMY elements are not allowed). SR> Anyway, having divLike classes adds the enormous advantage that you SR> can now easily add your own new object to be a child of . SR> Don't tell me *that* was easy before! Yes, absolutely. This is a definite big plus I am all in favor of (and have always assumed we would do since the class meeting in Oxford). From Syd_Bauman at Brown.edu Fri Feb 9 20:33:49 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 9 Feb 2007 20:33:49 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <17869.8445.930274.347152@emt.wwp.brown.edu> Thank you so much, James, for putting the effort into this. I think, while many of us may not like the results, it is *very* useful to know them. Given the results, I support all 3 of James' recommendations. > Sebastian has assured me that these ODDs would be fairly > straightforward. Yes, they would be fairly straitforward. But how would a user incorporate the example into his or her own customization? From wittern at kanji.zinbun.kyoto-u.ac.jp Sat Feb 10 00:18:35 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 10 Feb 2007 14:18:35 +0900 Subject: [tei-council] Assessment of Example infrastructure Message-ID: <45CD55AB.5060304@kanji.zinbun.kyoto-u.ac.jp> Assessment of Example infrastructure At the last Council meeting, I was instructed to asses how the current infrastructure could cope with the internationalization of examples. Here is the result. 1. The current infrastructure embeds examples into the *spec file of the thing it is meant to illustrate. 2. Othe I18N features, for example the translation of elements is handles by embedding the translations into the *spec file. Translations are identified by their @xml:lang attribute value. A similar mechanism could be adopted for examples, which would be the easiest solution, that is using @xml:lang on egXML. A drawback of the current setup (not limited to I18N) is that there is a 1:1 relationship between example and exemplified feature. This means that if one and the same example could be used to illustrate multiple elements, it has to be repeated. A possible solution would be to store the examples elsewhere and indicate the identity of the thing illustrated by a @targets element, which should then point to the @ident value of the thing illustrated. This would require a reshuffling of bytes in the sourcetree, which if necessary should be undertaken rather soon. Christian Wittern -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 06:12:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 11:12:25 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CDA899.9070408@oucs.ox.ac.uk> I'm aiming to put some work in on this today, and test James' proposal locally, assuming agreement. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Sat Feb 10 07:18:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sat, 10 Feb 2007 07:18:16 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CDA899.9070408@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CDA899.9070408@oucs.ox.ac.uk> Message-ID: <96f3df640702100418l1dbf3cb2r7f11d60a4712af85@mail.gmail.com> I agree. On 2/10/07, Sebastian Rahtz wrote: > I'm aiming to put some work in on this today, > and test James' proposal locally, assuming agreement. > > -- > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From daniel.odonnell at uleth.ca Sat Feb 10 09:38:54 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 07:38:54 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <96f3df640702100418l1dbf3cb2r7f11d60a4712af85@mail.gmail.com> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CDA899.9070408@oucs.ox.ac.uk> <96f3df640702100418l1dbf3cb2r7f11d60a4712af85@mail.gmail.com> Message-ID: <1171118334.10295.3.camel@caedmon> I thought the comments about the library community were the most convincing reason for keeping both. -dan On Sat, 2007-02-10 at 07:18 -0500, Dot Porter wrote: > I agree. > > On 2/10/07, Sebastian Rahtz wrote: > > I'm aiming to put some work in on this today, > > and test James' proposal locally, assuming agreement. > > > > -- > > Sebastian Rahtz > > > > Information Manager, Oxford University Computing Services > > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > > > OSS Watch: JISC Open Source Advisory Service > > http://www.oss-watch.ac.uk > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 09:57:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 14:57:01 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <17869.8445.930274.347152@emt.wwp.brown.edu> References: <45CD18D6.60109@oucs.ox.ac.uk> <17869.8445.930274.347152@emt.wwp.brown.edu> Message-ID: <45CDDD3D.8020901@oucs.ox.ac.uk> Syd Bauman wrote: > Yes, they would be fairly straitforward. But how would a user > incorporate the example into his or her own customization? > There must be an 80:20 argument here. For some things, we provide a tick box in Roma, or an exemplar. For other things, we expect the ODD designer to be able to read a web page on the wiki or wherever, and know how to cut and paste. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 10:02:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 15:02:32 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CDDE88.9030909@oucs.ox.ac.uk> comment #27 was mildly interesting, because it is a bit like the way the TEI Guidelines themselves are marked up (on which subject I bent Lou's ear on Friday, arguing the Guidelines are unnecessarily complex in this respect). -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 10:31:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 15:31:53 +0000 Subject: [tei-council] tei release In-Reply-To: <17868.63837.318745.887157@emt.wwp.brown.edu> References: <45CB939B.4020201@oucs.ox.ac.uk> <17868.63837.318745.887157@emt.wwp.brown.edu> Message-ID: <45CDE569.3070004@oucs.ox.ac.uk> Syd Bauman wrote: > IMHO we need not only div0Like and div1Like, we also need div2Like, > div3Like, etc. There isn't really all that much point in having > numbered divs unless each is in its own model class, so that I can > easily say " and are div1Like,
is > div2Like, and , , and are div3Like". > It's going to be gruesome, but I can't deny the strength of the argument. I have duly implemented all this locally and am now running a full test. The main downside so far is that the Guidelines themselves are no longer valid (since they use div0). -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From lou.burnard at computing-services.oxford.ac.uk Sat Feb 10 12:27:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 10 Feb 2007 17:27:41 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CD18D6.60109@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> Message-ID: <45CE008D.6090704@computing-services.oxford.ac.uk> I think James has done a great job here. I assume he'll be posting this summary along with the decisions arising from it to TEI-L in due course. For the record, I also agree with his conclusions as follows: 1. we should abolish div0 2. we should retain a choice between div and div1 as the next hierarchic level within front, body, back 3. this kind of user-consultation can be very effective However, I feel the need for some reassurance about the way it's proposed to make all these additional model classes. Two reasons have been advanced: a. without them, it is hard or impossible to define a robust content model for body etc. b. with them, users can use more "natural" like element names ("chapter" "section" etc.) Reason (a) looks plausible -- "robust" here means that you can delete things from a schema without generating ambiguity, and this will at a stroke reduce the number of white hairs generated when trying to make sense of the existing content models Reason (b) I like less. Why do we have
s at all if we are going to do this? It is contrary to the original design decision, which was to apply Occam's razor to this problem (you say "section" and I say "part" -- let's call the whole thing "div"). Maybe I'm just worried about all the rewriting that will have to be done if we take this proposal seriously. Lou James Cummings wrote: > Dear Council, > > I have closed the TEI Numbered Divs survey and would like to report on > the results. I have made a PDF of the summary report that Survey > Monkey provides. It is available for download at: From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 10 12:37:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 10 Feb 2007 17:37:59 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE008D.6090704@computing-services.oxford.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> Message-ID: <45CE02F7.5030906@oucs.ox.ac.uk> Lou Burnard wrote: > > However, I feel the need for some reassurance about the way it's > proposed to make all these additional model classes. Two reasons have > been advanced: > > a. without them, it is hard or impossible to define a robust content > model for body etc. > b. with them, users can use more "natural" like element names > ("chapter" "section" etc.) > > Reason (a) looks plausible -- "robust" here means that you can delete > things from a schema without generating ambiguity, and this will at a > stroke reduce the number of white hairs generated when trying to make > sense of the existing content models want to bet? the content model for body remains quite complex.... > > Reason (b) I like less. Why do we have
s at all if we are going > to do this? It is contrary to the original design decision, which > was to apply Occam's razor to this problem (you say "section" and I > say "part" -- let's call the whole thing "div"). > Maybe I'm just worried about all the rewriting that will have to be > done if we take this proposal seriously. The ability to name "div1" to "chapter" is already there, its just what we now have is the ability to add "" _alongside_ "" so that it behaves in the same manner. Good or bad? who knows. Its a natural fallout from using classes. I don't think any serious rewriting is needed by a decision to remove "div0"; applying the class struggle to divN does not affect the day to day prose of the guidelines. We may note that it will now be much easier to remove div4, div5, div6 and div7. Anyway, the classification of the div elements is an obvious completion of the work started in 2005, and I don't see a real reason to reopen that subject. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From James.Cummings at oucs.ox.ac.uk Sat Feb 10 13:43:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 10 Feb 2007 18:43:52 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE008D.6090704@computing-services.oxford.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> Message-ID: <45CE1268.3000401@oucs.ox.ac.uk> Lou Burnard wrote: > I think James has done a great job here. I assume he'll be posting this > summary along with the decisions arising from it to TEI-L in due course. Yes, I will, but I will wait until Council agrees overall what should be done, or a reasonable length of time, whichever happens first. > For the record, I also agree with his conclusions as follows: > 1. we should abolish div0 > 2. we should retain a choice between div and div1 as the next hierarchic > level within front, body, back > 3. this kind of user-consultation can be very effective Is there anyone on council who, after reading the survey results, has good arguments for disagreeing with these proposals? (Please, speak now, I'd prefer to hear them before announcing such changes to TEI-L). -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From daniel.odonnell at uleth.ca Sat Feb 10 15:48:17 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 13:48:17 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE1268.3000401@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> <45CE1268.3000401@oucs.ox.ac.uk> Message-ID: <1171140497.6077.1.camel@caedmon> > > For the record, I also agree with his conclusions as follows: > > 1. we should abolish div0 > > 2. we should retain a choice between div and div1 as the next hierarchic > > level within front, body, back > > 3. this kind of user-consultation can be very effective > > Is there anyone on council who, after reading the survey results, has good > arguments for disagreeing with these proposals? (Please, speak now, I'd prefer > to hear them before announcing such changes to TEI-L). My only fear is the DLF people. Do we know if they start with div1 or div0? Syd has done work with them. Do you know Syd? I can't believe I'm urging caution on getting rid of any of the divNs ;) -dan > > -James -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Sat Feb 10 17:10:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 10 Feb 2007 17:10:47 -0500 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <1171140497.6077.1.camel@caedmon> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> <45CE1268.3000401@oucs.ox.ac.uk> <1171140497.6077.1.camel@caedmon> Message-ID: <17870.17127.991283.198786@emt.wwp.brown.edu> > My only fear is the DLF people. Do we know if they start with div1 > or div0? Syd has done work with them. Do you know Syd? I can't > believe I'm urging caution on getting rid of any of the divNs ;) I don't have any special knowledge in my tiny brain, but I do know where to look. * the survey itself -- I believe quite a few librarians responded * the current "TEI in Libraries" document, which explicitly says "we prefer that not be used since the TEI Guidelines does not make it available in or matter"[1] * the proposed "TEI Tite" document, which lists as one of the elements that has been excluded[2] So I think we're pretty safe in ditching (as much as it breaks my heart!)-: Notes ----- [1] http://www.diglib.org/standards/tei.htm I think I've already pointed out that disagreement in number to them, but perhaps should mention it again :-) [2] I just realized that this draft document has not been sent to Council or the DLF yet, which I thought was supposed to happen weeks ago. I will send an inquiry to John Unsworth right now. From daniel.odonnell at uleth.ca Sat Feb 10 17:21:50 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 10 Feb 2007 15:21:50 -0700 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <17870.17127.991283.198786@emt.wwp.brown.edu> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> <45CE1268.3000401@oucs.ox.ac.uk> <1171140497.6077.1.camel@caedmon> <17870.17127.991283.198786@emt.wwp.brown.edu> Message-ID: <1171146110.8918.0.camel@caedmon> Thanks Syd. On Sat, 2007-02-10 at 17:10 -0500, Syd Bauman wrote: > > My only fear is the DLF people. Do we know if they start with div1 > > or div0? Syd has done work with them. Do you know Syd? I can't > > believe I'm urging caution on getting rid of any of the divNs ;) > > I don't have any special knowledge in my tiny brain, but I do know > where to look. > > * the survey itself -- I believe quite a few librarians responded > > * the current "TEI in Libraries" document, which explicitly says "we > prefer that not be used since the TEI Guidelines does not > make it available in or matter"[1] > > * the proposed "TEI Tite" document, which lists as one of the > elements that has been excluded[2] > > So I think we're pretty safe in ditching (as much as it breaks > my heart!)-: > > Notes > ----- > [1] http://www.diglib.org/standards/tei.htm > I think I've already pointed out that disagreement in > number to them, but perhaps should mention it again :-) > [2] I just realized that this draft document has not been sent to > Council or the DLF yet, which I thought was supposed to happen > weeks ago. I will send an inquiry to John Unsworth right now. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Conal.Tuohy at vuw.ac.nz Sun Feb 11 16:47:13 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 12 Feb 2007 10:47:13 +1300 Subject: [tei-council] TEI Numbered Divs Survey: The Results. Message-ID: Cheers James! Interesting results and I agree with your recommendations. Con From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Feb 11 18:13:05 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 12 Feb 2007 08:13:05 +0900 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CDDE88.9030909@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CDDE88.9030909@oucs.ox.ac.uk> Message-ID: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> James, Arianna, Thanks for suggesting the survey and shepherding it along. This provides and excellent base for our decision. As I was foolish enough to indicate my expectations before, I am pleased to see them met here:-) So basically, I think we should go along with James recommendations. The only thing that worries me a bit is this: Sebastian Rahtz wrote: > comment #27 was mildly interesting, because it is a bit like > the way the TEI Guidelines themselves are marked up > (on which subject I bent Lou's ear on Friday, arguing the > Guidelines are unnecessarily complex in this respect). > The comment is We start with *div1* in almost all cases, but use *div0* where there is some extraordinary high-level division of a text (say, division of a work into "book 1" and "book 2"). That way, our navigation structure can continue to rely on *div1* for user display, but we can still accurately reflect the true structure of the work. If I understand things right, we would not be able to use
above to accomodate this use case? We should also make it clear that this was one of the reasons to *not* use numbered divs in the first case. (What do you intend to do with the Guidelines themselves? Continue with numbered divs or ditching them?) best, chw -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Sun Feb 11 18:19:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 11 Feb 2007 23:19:12 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CDDE88.9030909@oucs.ox.ac.uk> <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFA470.10305@computing-services.oxford.ac.uk> Christian Wittern wrote: > > (What do you intend to do with the Guidelines themselves? Continue > with numbered divs or ditching them?) > After discussion, Syd and I agreed to convert the Guidelines source from numbered to vanilla divs, and I have spent most of today implementing and testing same (along with abolishing div0 per Council decision) From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 11 18:23:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 11 Feb 2007 23:23:15 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CDDE88.9030909@oucs.ox.ac.uk> <45CFA301.10907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFA563.5080007@oucs.ox.ac.uk> Christian Wittern wrote: > > > We start with *div1* in almost all cases, but use *div0* where there > is some extraordinary high-level division of a text (say, division of > a work into "book 1" and "book 2"). That way, our navigation structure > can continue to rely on *div1* for user display, but we can still > accurately reflect the true structure of > the work. > > > If I understand things right, we would not be able to use
above > to accomodate this use case? > We should also make it clear that this was one of the reasons to *not* > use numbered divs in the first case. > no, but they could put back . There is an example file in the P5 Test area now to demonstrate this. > (What do you intend to do with the Guidelines themselves? Continue > with numbered divs or ditching them?) > Lou is working on this as we speak. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 11 18:44:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 11 Feb 2007 23:44:46 +0000 Subject: [tei-council] Assessment of Example infrastructure In-Reply-To: <45CD55AB.5060304@kanji.zinbun.kyoto-u.ac.jp> References: <45CD55AB.5060304@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45CFAA6E.9090101@oucs.ox.ac.uk> > A similar mechanism could be adopted for examples, which would be the > easiest solution, that is using @xml:lang on egXML. > or some type attribute on . is always inside . > A drawback of the current setup (not limited to I18N) is that there is a > 1:1 relationship between example and exemplified feature. This means > that if one and the same example could be used to illustrate multiple > elements, it has to be repeated. A possible solution would be to store > the examples elsewhere and indicate the identity of the thing > illustrated by a @targets element, which should then point to the @ident > value of the thing illustrated. This would require a reshuffling of > bytes in the sourcetree, which if necessary should be undertaken rather > soon. > can be empty, and could use one of the global attributes (is it @corresp? sorry, its late, am just off to bed) to indicate that another example (identified by ID) is equally good here. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From arianna.ciula at kcl.ac.uk Tue Feb 13 06:51:03 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 13 Feb 2007 11:51:03 +0000 Subject: [tei-council] TEI Numbered Divs Survey: The Results. In-Reply-To: <45CE1268.3000401@oucs.ox.ac.uk> References: <45CD18D6.60109@oucs.ox.ac.uk> <45CE008D.6090704@computing-services.oxford.ac.uk> <45CE1268.3000401@oucs.ox.ac.uk> Message-ID: <45D1A627.7000209@kcl.ac.uk> Sorry for replying so late. We had a power failure at King's still affecting some of our servers. I agree with all the recommendations James proposed and thanks to him to have taken charge of this. Arianna James Cummings wrote: > Lou Burnard wrote: >> I think James has done a great job here. I assume he'll be posting >> this summary along with the decisions arising from it to TEI-L in due >> course. > > Yes, I will, but I will wait until Council agrees overall what should be > done, or a reasonable length of time, whichever happens first. > > >> For the record, I also agree with his conclusions as follows: >> 1. we should abolish div0 >> 2. we should retain a choice between div and div1 as the next >> hierarchic level within front, body, back >> 3. this kind of user-consultation can be very effective > > Is there anyone on council who, after reading the survey results, has > good arguments for disagreeing with these proposals? (Please, speak > now, I'd prefer to hear them before announcing such changes to TEI-L). > > -James -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Thu Feb 15 11:03:31 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 11:03:31 -0500 (EST) Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45C867D4.3080206@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> Message-ID: <200702151603.l1FG3V2N007860@perseus.services.brown.edu> > > Problems > > -------- > > * Some are distressed by the fact that attributes that are of the > > same datatype (data.temporal) and serve similar functions have > > different names, in particular: > > value= of ,
: Done I'd like Council members to ponder this one though: 1007370: create new element possibly in FT I think there's a good case for this, but it needs someone to work on producing documentation for it. If I stop to do that, I won't get anything else done for a week. So should I just close the ticket and say "next release"? Could Council members please take a look at the ticket, and then respond (to me rather than the list) with their choice from the following: A: this is a daft idea for the following reasons B: this is a good idea, but needs more work: we should charter a workgroup to do it for P5.n C: this is a good idea and I will send you some material to support it by St Davids Day From Syd_Bauman at Brown.edu Thu Feb 15 19:26:48 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 19:26:48 -0500 Subject: [tei-council] SF FR updates In-Reply-To: <45D4F718.7060302@computing-services.oxford.ac.uk> References: <45D4F718.7060302@computing-services.oxford.ac.uk> Message-ID: <17876.64072.775222.689910@emt.wwp.brown.edu> > Could Council members please take a look at the ticket, and then > respond (to me rather than the list) with their choice from the > following: Is there a reason to keep this discussion private? > C: this is a good idea and I will send you some material to support > it by St Davids Day St David's day is 03-01, yes? From lou.burnard at computing-services.oxford.ac.uk Thu Feb 15 19:41:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 16 Feb 2007 00:41:49 +0000 Subject: [tei-council] SF FR updates In-Reply-To: <17876.64072.775222.689910@emt.wwp.brown.edu> References: <45D4F718.7060302@computing-services.oxford.ac.uk> <17876.64072.775222.689910@emt.wwp.brown.edu> Message-ID: <45D4FDCD.7070704@computing-services.oxford.ac.uk> Syd Bauman wrote: >> Could Council members please take a look at the ticket, and then >> respond (to me rather than the list) with their choice from the >> following: >> > > Is there a reason to keep this discussion private? > I will summarize the response I get to this list, obviously. I'm just trying to reduce people's email burden. > > >> C: this is a good idea and I will send you some material to support >> it by St Davids Day >> > > St David's day is 03-01, yes? > > It's the 1st March, not the 3rd January. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Feb 15 20:04:50 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 10:04:50 +0900 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D48CCF.3010402@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> Message-ID: <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > Syd Bauman wrote: >> >> Hmmm... how about att.normalizedDate? >> > sure fine >> > IF (a big "if") we mandated the "yet-to-be-agreed-upon-let-alone-specified > mechanism in the instance that points to the schema", I could > sort of go along. But for TEI P5 1.0, I just don't see this > work being completed and implemented by anyone. I will go out on a limb here and suggest a "small" solution: In the wilderness of the XML universe, there exist already a number of ways to associate an instance with a non-DTD schema: XSD uses schemaLocation oXygen uses a pi "oxygen" nxml uses a elaborated mechanism which somehow ends in processing a schemas.xml file .. there will be others. How about we just give the users a spot in the header to declare which one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without actually implementing our own? The only thing we will have to ponder is if we want to maintain a registry of values for this list -- I would say that might be the price we have to pay for this. To me, this is one of the infrastructural issues we should not lightly postpone. Now back to the topic, >> One attribute, syntax of value determines what kind of date format: >> no prefix = entire value is a simple format (i.e. W3C) date >> prefix 'i-' = remainder of value is an ISO 8601 date >> prefix 'x-' = remainder of value is a user-defined format date >> >> Thus: >> >> >> >> >> >> > I would not actually blow up Parliament in protest > if we adopted that, but I still don't like the idea > of @value sometimes being valid with standard > datatypes and sometimes not. You will need to check for the type before blindly processing them. What I like is the self-declaring and on-the-spot expandable property of this proposal. >> None of the user-created formats are ever going to have standard >> software suite support, so I don't think we should fret much over >> that. > agreed. but at least lets isolate them in their own names. Which will put a burden on you if you suddenly discover a new type of dates in your texts to go back to the schema-drawing-room called Roma for another round. >> >> So, IMHO, we are down to either class-level or all-in-one. > thats progress. I'm with you here. > as I read your message, you've more or less > persuaded yourself to agree with my class > proposal a la att.global? Except that we still have the all-in-one proposal. I might be biased since I work more or less daily with xml:lang attributes, but that solution has the advantage of being simpler technically. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Conal.Tuohy at vuw.ac.nz Thu Feb 15 20:49:18 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 16 Feb 2007 14:49:18 +1300 Subject: [tei-council] what to do with dating attributes -- VOTE! Message-ID: Here's my 2c > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X_ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X_ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: keep ? > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X_ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each > different system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > _X_ A > ___ B > ___ C > _X_ D > > I have considered issue, and disagree with proposed solution: > ___ A > _X_ B > _X_ C > ___ D > > ___ It does not matter to me which solution is chosen, so go > ahead with whatever > > _X_ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon That last one is tricky. I'm not sure, Syd and Sebastian, why you have characterised the "attribute-level" solution (A) as NOT making the easy things easy, and "just too confusing for day to day use". Could you clarify where the confusion might lie please? It seems to me that we could have this year and that this is easy. So I must be missing something. I think B and C are weaker (if I understand them correctly) in that they would prohibit mixing calendars in a document (at least, with the same element, so that date/@value would have to have a consistent type throughout a document). Is that a correct understanding? Would that be a problem for historical markup? Maybe not, in which case the objection is probably moot. However, options A and D would allow mixing calendars. In some ways I prefer D because it implies that the attributes have particular semantics which are in a sense independent of the particular calendrical "syntax" used. But on the other hand I'm not sure that it's possible to make a hard-and-fast distinction between syntax and semantics anyway (not in every case at least, since days and years are pretty standard features of calendars; weeks, months, katuns, etc are less so). The advantage of A of D would be that the attribute VALUES are kept "clean" without TEI-imposed prefixes. All in all, I feel quite ambivalent (multivalent actually!) about these options. Incidentally, if option A were favoured (whether as part of option D or otherwise), one way to implement it might be to use distinct XML namespaces for the different data types. We could have the default, W3C-typed, attributes in no namespace (as they are now), and allow customisations to add date-type attributes in other namespaces. Encoders could then use whatever namespace prefixes they wanted to e.g. either at one extreme St David's day or at the other St David's day depending on their preference. Cheers Con From Syd_Bauman at Brown.edu Thu Feb 15 21:20:43 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Feb 2007 21:20:43 -0500 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: References: Message-ID: <17877.5371.694544.449968@emt.wwp.brown.edu> > That last one is tricky. Indeed it is. > I'm not sure, Syd and Sebastian, why you have characterised the > "attribute-level" solution (A) as NOT making the easy things easy, > and "just too confusing for day to day use". Could you clarify > where the confusion might lie please? It seems to me that we could > have this year and that this is easy. So > I must be missing something. With the attribute-level solution every time any user (who hasn't removed attributes in her customization) inserts a element, her XML-aware editor would present here with a slew of possible attributes: value= value.iso= value.usr= notBefore= notBefore.iso= notBefore.usr= notAfter= notAfter.iso= notAfter.usr= from= from.iso= from.usr= to= to.iso= to.usr= dur= dur.iso= dur.usr= not to mention the non-date-specific attributes. No simple check-box style customization could change this. (Although, as I'm fond of pointing out, it isn't really that hard without the check-box simplicity.) For the vast majority of users, 2/3 of the above attributes would never be used, and would just be in the way. > I think B and C are weaker (if I understand them correctly) in that > they would prohibit mixing calendars in a document (at least, with > the same element, so that date/@value would have to have a > consistent type throughout a document). Is that a correct > understanding? Off the top of my head I think that is correct if the user is using the "simple format" date attributes, regardless of which option we choose. That's because the simple W3C format is definitionally Gregorian, and arguably proleptic Gregorian. Things are a little better with ISO 8601, which is explicitly Gregorian or proleptic Gregorian, and arguably the syntax could be used for others. I'm of a mind that, regardless of system, we should define value= and iso-value= as (proleptic) Gregorian. User-defined values could be of whatever calendar the user desired. The *content* is in whatever calendar is specified by calendar=. > In some ways I prefer D because it implies that the attributes have > particular semantics which are in a sense independent of the > particular calendrical "syntax" used. I'm sorry, I think I'm too tired (or too stupid :-) to understand this. > Incidentally, ... use distinct XML namespaces for the different > data types. ... e.g. ... St David's > day or ... St David's day Really interesting idea (that I never thought of) that yields a very nice syntactic result. But I don't think the implications -- that these attributes somehow belong to some other markup language than TEI -- are acceptable. From Conal.Tuohy at vuw.ac.nz Thu Feb 15 22:17:02 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 16 Feb 2007 16:17:02 +1300 Subject: [tei-council] what to do with dating attributes -- VOTE! Message-ID: > With the attribute-level solution every time any user (who hasn't > removed attributes in her customization) inserts a element, > her XML-aware editor would present here with a slew of possible > attributes: > value= > value.iso= > value.usr= > notBefore= > notBefore.iso= > notBefore.usr= > notAfter= > notAfter.iso= > notAfter.usr= > from= > from.iso= > from.usr= > to= > to.iso= > to.usr= > dur= > dur.iso= > dur.usr= > not to mention the non-date-specific attributes. No simple check-box > style customization could change this. (Although, as I'm fond of > pointing out, it isn't really that hard without the check-box > simplicity.) For the vast majority of users, 2/3 of the above > attributes would never be used, and would just be in the way. Would it not be simpler to make the "complex" attribute sets optional? i.e. the the default TEI schemas would not include the complex dates, and the user would have to explicitly add them, if they wanted them, rather than remove them? Since most users would be fine with just "simple" (W3) dates, for anything else it might be quite reasonable to require a customization to explicitly add them. > > I think B and C are weaker (if I understand them correctly) in that > > they would prohibit mixing calendars in a document (at least, with > > the same element, so that date/@value would have to have a > > consistent type throughout a document). Is that a correct > > understanding? > > Off the top of my head I think that is correct if the user is using > the "simple format" date attributes, regardless of which option we > choose. That's because the simple W3C format is definitionally > Gregorian, and arguably proleptic Gregorian. Things are a little > better with ISO 8601, which is explicitly Gregorian or proleptic > Gregorian, and arguably the syntax could be used for others. > I'm of a mind that, regardless of system, we should define value= and > iso-value= as (proleptic) Gregorian. User-defined values could be of > whatever calendar the user desired. The *content* is in whatever > calendar is specified by calendar=. Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian calendar in the same document (which seems to me quite reasonable), I can see how they could do that with A and D, but how to do that with B and C? If B (datatype level), then the mixed-calendar encoder would have to select the "loose" data type for all dates (the "lowest common denominator" data type), and they wouldn't get the benefit of W3C-validation of any dates which genuinely were simple Gregorian dates. If C (class level), then you suggested 2 options: C(1): classes use different attribute names, hence can be mixed (from the encoders' perspective this is the same as option A, just implemented using classes); or C(2): classes use the same attribute names, hence they can't be mixed (from the encoders' perspective this is like option B) > > In some ways I prefer D because it implies that the attributes have > > particular semantics which are in a sense independent of the > > particular calendrical "syntax" used. > > I'm sorry, I think I'm too tired (or too stupid :-) to understand > this. I just meant that it was an attractive idea to have date/@value rather than date/@iso-value and date/@w3-value (or whatever), since a date, no matter how you express it, is still just a date. > > Incidentally, ... use distinct XML namespaces for the different > > data types. ... e.g. ... St David's > > day or ... St David's day > > Really interesting idea (that I never thought of) that yields a > very nice syntactic result. But I don't think the implications -- > that these attributes somehow belong to some other markup language > than TEI -- are acceptable. I think that's a strange implication to take. cf @xml:lang and @xml:id which are inarguably (I hope?!) part of the TEI markup language, despite belonging to a distinct namespace. Remember, too, that all the other "TEI" attributes are not in fact in any namespace. An XML markup language is quite a different beast from an XML namespace. But hey, I'm not fussed about the idea ... it was just a suggestion. Con From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:13:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:13:39 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D583D3.10001@oucs.ox.ac.uk> Christian Wittern wrote: > How about we just give the users a spot in the header to declare which > one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without > actually implementing our own? The only thing we will have to ponder > is if we want to maintain a registry of values for this list -- I > would say that might be the price we have to pay for this. > > To me, this is one of the infrastructural issues we should not lightly > postpone. > I think you need to go over the whole process and explain how it will work in real life. Two simple examples a) I declare my schema to be foo.rnc, in oxygen notation. I am processing using XSL. in XSL I cannot read .rnc files (at all easily). how do I access the datatype info? b) I am moving hundreds of documents into eXist, and I pull out small fragments all the time. for each one, I laboriously find the header, find the way to referring to the schema, locate the schema, and look! I have 4 different schemas, so how now do I evaluate @value? > > You will need to check for the type before blindly processing them. how? I'm an experienced XML processing person, and I just dread the thought of considering it. Plus, I want my validation! > > Which will put a burden on you if you suddenly discover a new type of > dates in your texts to go back to the schema-drawing-room called Roma > for another round. seems a reasonable price to me! > > Except that we still have the all-in-one proposal. I might be biased > since I > work more or less daily with xml:lang attributes, but that solution > has the advantage > of being simpler technically. and I claim its not at all simple for validators and processors... sebastian From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:16:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:16:17 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: References: Message-ID: <45D58471.8000100@oucs.ox.ac.uk> Conal Tuohy wrote: > Incidentally, if option A were favoured (whether as part of option D or > otherwise), one way to implement it might be to use distinct XML > namespaces for the different data types. > I dread this, practically. namespaces are good, but they aren't half a pain in real life, having to declare them all up front and interact with them in editors. in XML schemas, of course, it means another .xsd file to carry around. It does look elegant, but since we are not currently proposing it for extensions, I'd steer clear if I could. sebastian From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 05:18:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 10:18:11 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: References: Message-ID: <45D584E3.4050205@oucs.ox.ac.uk> Conal Tuohy wrote: > > Would it not be simpler to make the "complex" attribute sets optional? > thats just what the class-based solution would do, if the non-W3C classes were in a module Sebastian From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 07:30:10 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 21:30:10 +0900 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D583D3.10001@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> Message-ID: <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > Christian Wittern wrote: >> How about we just give the users a spot in the header to declare which >> one they are using ("xsd", "oxygen", "nxml", "you-name-it"), without >> actually implementing our own? The only thing we will have to ponder >> is if we want to maintain a registry of values for this list -- I >> would say that might be the price we have to pay for this. >> >> To me, this is one of the infrastructural issues we should not lightly >> postpone. >> > I think you need to go over the whole process and explain how it will > work in real life. > > Two simple examples > > a) I declare my schema to be foo.rnc, in oxygen notation. I am > processing using XSL. > in XSL I cannot read .rnc files (at all easily). how do I access > the datatype info? > To do that, you only have a choice between XSD and RNG files, really. > b) I am moving hundreds of documents into eXist, and I pull out small > fragments all > the time. for each one, I laboriously find the header, find the way > to referring to the > schema, locate the schema, and look! I have 4 different schemas, so > how now > do I evaluate @value? > This is a usecase where most of our assumptions about files and headers fall on their face, which is reaonable IMHO, since we define a format for *interchange*. In your document repository, you are bound to want to normalize these kinds of things into one standard form, so the processing required here is done on the import and then your done with it. >> >> You will need to check for the type before blindly processing them. > how? I'm an experienced XML processing person, and I just dread the > thought of considering it. Plus, I want my validation! looking at the value of substring-before(., '-') should give you what you need to decide. And I am sure Syd will come up with a regex that gives you a reasonable validation on the @value >> >> Which will put a burden on you if you suddenly discover a new type of >> dates in your texts to go back to the schema-drawing-room called Roma >> for another round. > seems a reasonable price to me! Well, maybe. It's a week argument;-) >> >> Except that we still have the all-in-one proposal. I might be biased >> since I >> work more or less daily with xml:lang attributes, but that solution >> has the advantage >> of being simpler technically. > and I claim its not at all simple for validators and processors... > See above. I will need to give the whole thing a bit more thought, again. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 07:45:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 12:45:06 +0000 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D5A752.9060202@oucs.ox.ac.uk> Christian Wittern wrote: > >> b) I am moving hundreds of documents into eXist, and I pull out >> small fragments all >> the time. for each one, I laboriously find the header, find the >> way to referring to the >> schema, locate the schema, and look! I have 4 different schemas, >> so how now >> do I evaluate @value? >> > > This is a usecase where most of our assumptions about files and > headers fall on their face, which is reaonable IMHO, since we define a > format for *interchange*. In your document repository, you are bound > to want to normalize these kinds of things into one standard form, so > the processing required here is done on the import and then your done > with it. hmm. that looks like a barrier to me. > >> how? I'm an experienced XML processing person, and I just dread the >> thought of considering it. Plus, I want my validation! > > looking at the value of substring-before(., '-') should give you what > you need to decide. And I am sure Syd will come up with a regex that > gives you a reasonable validation on the @value but I want my editor to validate my dates... Sebastian From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 07:52:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Feb 2007 21:52:43 +0900 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A752.9060202@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> Message-ID: <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > Christian Wittern wrote: >> >>> b) I am moving hundreds of documents into eXist, and I pull out >>> small fragments all >>> the time. for each one, I laboriously find the header, find the >>> way to referring to the >>> schema, locate the schema, and look! I have 4 different schemas, >>> so how now >>> do I evaluate @value? >>> >> >> This is a usecase where most of our assumptions about files and >> headers fall on their face, which is reaonable IMHO, since we define a >> format for *interchange*. In your document repository, you are bound >> to want to normalize these kinds of things into one standard form, so >> the processing required here is done on the import and then your done >> with it. > hmm. that looks like a barrier to me. You mean the normalizing process? It seems like a fact of life to me. >>> how? I'm an experienced XML processing person, and I just dread the >>> thought of considering it. Plus, I want my validation! >> >> looking at the value of substring-before(., '-') should give you what >> you need to decide. And I am sure Syd will come up with a regex that >> gives you a reasonable validation on the @value > but I want my editor to validate my dates... Oxygen does use the datatype to validate, so that works while you are editing -- doesnt nxml do the same thing? Of course you will have to tell them about your schema in a language they understand, thus my suggestion. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Fri Feb 16 08:33:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 16 Feb 2007 08:33:59 -0500 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: References: Message-ID: <17877.45767.638704.181178@emt.wwp.brown.edu> > Would it not be simpler to make the "complex" attribute sets > optional? ... Yes, it would, and the plan you outline is quite reasonable I think. But it's basically the equivalent of C "class level". > Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian > calendar in the same document (which seems to me quite reasonable), > I can see how they could do that with A and D, but how to do that > with B and C? With B ("datatype level") the user would 1. create a datatype for the calendar of interest, 'data.myTemporal' 2. either a) add a new attribute to (or better still, att.datePart) called myValue= which is declared as data.myTemporal, or b) add a new element, , whose value= attribute is declared as data.myTemporal With C ("class level") the user would 1. create a class for the calendar of interest, 'att.datePart.mine', which declares the myValue= attribute appropriately 2. either a) add to att.datePart.mine, or b) create , and make it a member of att.datePart.mine In both cases step 1 involves messing with ODD, which some have suggested we should try hard to avoid. It is more likely that solution C step 2(a) could be done via check-box in a Roma tool than any of the other step 2 possibilities. > If B (datatype level), then the mixed-calendar encoder would have > to select the "loose" data type for all dates (the "lowest common > denominator" data type), Right, unless they created another attribute as above. This is a bit of a disadvantage of datatype level. > If C (class level), then you suggested 2 options: > C(1): classes use different attribute names, hence can be mixed (from > the encoders' perspective this is the same as option A, just implemented > using classes); or > C(2): classes use the same attribute names, hence they can't be mixed > (from the encoders' perspective this is like option B) I think that is a reasonable summary. But keep in mind that * "just implemented using classes" will be, for some users, a sizable advantage; * no one has suggested a mechanism for actually implementing C(2). > I just meant that it was an attractive idea to have date/@value > rather than date/@iso-value and date/@w3-value (or whatever), since > a date, no matter how you express it, is still just a date. Understood. > I think that's a strange implication to take. cf @xml:lang and > @xml:id which are inarguably (I hope?!) part of the TEI markup > language, despite belonging to a distinct namespace. Remember, too, > that all the other "TEI" attributes are not in fact in any > namespace. An XML markup language is quite a different beast from > an XML namespace. But hey, I'm not fussed about the idea ... it was > just a suggestion. Good points, although I would argue that xml:lang= and xml:id= are somehow different. But as long as foo:bar= is in the TEI Guidelines and TEI schemas, it is in a very real way part, albeit a separated part, of the TEI language. From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 08:40:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 13:40:27 +0000 Subject: schema association (was Re: [tei-council] date attributes: summary, problems, and some suggestions) In-Reply-To: <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D5B44B.2030908@oucs.ox.ac.uk> Christian Wittern wrote: > >> but I want my editor to validate my dates... > > Oxygen does use the datatype to validate but it can't, because the datatype will be ..... Sebastian From Syd_Bauman at Brown.edu Fri Feb 16 16:01:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 16 Feb 2007 16:01:41 -0500 Subject: [tei-council] Re: schema association In-Reply-To: <45D5B44B.2030908@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> <45D5B44B.2030908@oucs.ox.ac.uk> Message-ID: <17878.7093.457090.669596@emt.wwp.brown.edu> I think Christian's suggestion ("just give the users a spot in the header to declare which [mechanism for instance to point to schema] they are using") has the right idea in the sense of "let's do something easy and fast". However, I think it makes the situation more complicated, not less. The right thing to do, if we can swing it politically, is to get OASIS to make a recommendation. If they do, it is very likely that at least oXygen would use it, and possible that quite a few others would follow suit. I just spoke to Norm Walsh who agrees that the way forward is for me to cross-post the idea with pointers to both previous suggestions here and to rng-users. I will try to do that this weekend. From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:12:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:12:45 +0000 Subject: [tei-council] Re: schema association In-Reply-To: <17878.7093.457090.669596@emt.wwp.brown.edu> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> <45D5B44B.2030908@oucs.ox.ac.uk> <17878.7093.457090.669596@emt.wwp.brown.edu> Message-ID: <45D61E4D.8060807@oucs.ox.ac.uk> Syd Bauman wrote: > The right thing to do, if we can swing it politically, is to get > OASIS to make a recommendation. If they do, it is very likely that at > least oXygen would use it, and possible that quite a few others would > follow suit. > > that's fine, and it takes it out of our timeline. we would participate as an interested party, but would not have a dependency on it for P5. I hold the OASIS vote for Oxford if you ever need it :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:15:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:15:16 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D61EE4.1000704@oucs.ox.ac.uk> > > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > X I have considered issue, and agree with proposed solution > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > X I have considered issue, and agree with proposed solution > > Issue: keep ? > Solution: nuke it > Vote: > > X I have considered issue, and agree with proposed solution > > Issue: keep precision= of > Solution: nuke it > Vote: > > X I have considered issue, and agree with proposed solution > > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > X I have considered issue, and agree with proposed solution > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > X C > ___ D > -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 16 16:16:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Feb 2007 21:16:37 +0000 Subject: [tei-council] SF FR updates In-Reply-To: <45D4F718.7060302@computing-services.oxford.ac.uk> References: <45D4F718.7060302@computing-services.oxford.ac.uk> Message-ID: <45D61F35.6090202@oucs.ox.ac.uk> Lou Burnard wrote: > > > B: this is a good idea, but needs more work: we should charter a > workgroup to do it for P5.n I'm not happy to proceed with this unless some people who actually do mathematical texts have commented. I suggest you raise it on TEI-L, and explain that the default answer is to defer to 5.1 if no-one speaks loudly. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Feb 16 18:02:01 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 17 Feb 2007 08:02:01 +0900 Subject: [tei-council] Report of the planning committee Message-ID: <45D637E9.2010702@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, The planning committee has prepared a tracking system that we will use to work our way towards the release of P5 1.0. You will find it ready at http://tei.oucs.ox.ac.uk/trac.cgi We have tried to identify the open issues and work items that have been floating around, gathered the things from our previous attempts at organizing the work and also looked at the SF feature requests, although they are not integrated into the list at the moment. We have basically organized the tasks ("tickets" in trac-speach) by chapter; in addition to specific items relevant to the chapters, there are a number of tasks that apply to all chapters, these include * Review general structure in line with comments and write missing prose * Review datatype and class decisions * Implement or reject or postpone feature requests * Check text of prose matches specs * Proof-read text looking for references to DTDs and P4 architecture * Proof-read text in general * Review elements for missing examples (Desirable) Not all of them apply to everything, and many of the tickets can be closed pretty quickly, so don't be scared by the number of tickets open. In addition to these chapter specific tickets, there are some tickets relevant to the output formatting and other programming tasks. The trac system allows to organize the tickets by milestones, owned tickets, etc. Here is how we plan to manage the P5 development process: * We will ask Council members to take ownerships of tickets. The details of this is something we need to discuss. It might make sense to build smaller groups within the Council, who will look over groups of tasks like "proofreading", "publication process" etc. Suggestions welcome. To make changes to tickets, you will need to log in. I believe Sebastian has set it up so that your name will work for the login at both prompts. * Tickets taken should be readied within 7 days of taking ownership. If this seems impossible, please either divide up the task or disown it in time before the desaster. * Council members should get a SF account (if not yet done) and will be added as developers to the SF TEi project. We expect everybody to checkout the source using SVN (cf. P5 Howto) and commit the changes back to SF. Council members will work on a branch in SF, it will be the editors responsibility to port the changes over to the main branch. * Discussion of items and decisions will be done via the trac wiki, which is attached to all tickets. This is not a full blown voting system, but I hope it will still be easier to follow than the discussions on council-l. This will document the discussion and decision process right in place where the work is tracked as well. * New work items and discussions should take place in the trac system. It is possible, similar to the SF system, to be alerted to changes by email (Sebastian, did you set this up?) As you will see, the timing is crucial and we will need to develop a habit of keeping promises of commitment once made. The one big open issue that is not yet covered in the above system is the list of open feature requests. Lou and Syd are working through this as we speek, but it will be important that Council members also participate in the discussion. To do this, please go to http://sourceforge.net/tracker/?atid=644065&group_id=106328&func=browse look at the open issues and comment. The plan is to be done with this by 2007-03-01. The discussion is open now, suggestions for improvement welcome. If we can agree on this plan, lets implement it right away. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 05:41:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 10:41:46 +0000 Subject: [tei-council] Report of the planning committee In-Reply-To: <45D637E9.2010702@kanji.zinbun.kyoto-u.ac.jp> References: <45D637E9.2010702@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45D6DBEA.8010404@oucs.ox.ac.uk> Christian Wittern wrote: > To make changes to tickets, you will need to log in. I believe > Sebastian has set it up so that your name will work for the login at > both prompts. > if it doesn't work, contact me as soon as possible. > > * New work items and discussions should take place in the trac > system. It is possible, similar to the SF system, to be alerted to > changes by email (Sebastian, did you set this up?) > I am not sure it is working. I will be looking at this today. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 08:41:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 13:41:30 +0000 Subject: [tei-council] trac Message-ID: <45D7060A.8050602@oucs.ox.ac.uk> er, I have totally disabled access in every way tei.oucs.ox.ac.uk (by accident). I am now dependent on one my colleagues reading his/her email and being able to poke the machine. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 15:05:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 20:05:09 +0000 Subject: [tei-council] tei trac Message-ID: <45D75FF5.2000306@oucs.ox.ac.uk> back in action now. sorry for the temporary screw-up -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sat Feb 17 18:10:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 17 Feb 2007 23:10:25 +0000 Subject: [tei-council] trac usage Message-ID: <45D78B61.4030500@oucs.ox.ac.uk> just a note to say that after logging in, you should visit Settings, and put in your email address. This will let trac email notifications of ticket changes to you. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Sat Feb 17 19:15:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 17 Feb 2007 19:15:36 -0500 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <17879.39592.981034.559677@emt.wwp.brown.edu> 24 hours left, and we have votes from - Sebastian - Conal - Lou (sent directly to me) - Syd (below) > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > ___ I have considered issue, and agree with proposed solution > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > ___ I have considered issue, and agree with proposed solution > Issue: keep ? > Solution: nuke it > Vote: > ___ I have considered issue, and agree with proposed solution > Issue: keep precision= of > Solution: nuke it > Vote: > ___ I have considered issue, and agree with proposed solution But I'm happy to be swayed by use-cases that require it. > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > ___ I have considered issue, and agree with proposed solution I really don't like this, but see no other choice. > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each different system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > _X_ C > _X_ D > > I have considered issue, and disagree with proposed solution: > _X_ A > ___ B > ___ C > ___ D Currently I rank solutions as C = best, D = pretty good, B = accceptle, A = a bit nuts. From wittern at kanji.zinbun.kyoto-u.ac.jp Sat Feb 17 19:30:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sun, 18 Feb 2007 09:30:43 +0900 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D79E33.2010304@kanji.zinbun.kyoto-u.ac.jp> Well, after some more consideration, here is my vote. Syd Bauman wrote: > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: keep ? > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each different system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > _X_ C (Sebastian has somehow convinced me that D is not really feasible...) Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 07:19:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 12:19:13 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17879.39592.981034.559677@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> <17879.39592.981034.559677@emt.wwp.brown.edu> Message-ID: <45D84441.1050104@computing-services.oxford.ac.uk> Syd Bauman wrote: > 24 hours left, and we have votes from > - Sebastian > - Conal > - Lou (sent directly to me) > - Syd (below) > > > Well, you're doing slightly better than me. On my consultation concerning I got precisely three responses : two voting for option B (seek more input) and one for option C (I will provide more input by 1 March). As C doesn't exclude the possibility of B, I suspect that B is the most appropriate course of action. However, there is still an awful lot of silence on the subject from council members -- some of whom may want to vote for A (this is a daft idea which should be stopped now). So I will wait a further 48 hours before doing anything. From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 07:46:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 12:46:44 +0000 Subject: [tei-council] facsimile odd Message-ID: <45D84AB4.9040800@oucs.ox.ac.uk> according to the minutes, we were going to have a full-devevloped ODD for linking text to pages images by the end of January: finish specifications in ODD 2007-01-27 finish prose in ODD 2007-01-31 read facsimile ODD, test schemata 2007-02-08 Any sign? I added a ticket to trac about it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 07:58:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 12:58:12 +0000 Subject: [tei-council] conformance chapter overdue? Message-ID: <45D84D64.5060106@oucs.ox.ac.uk> I can't find an action about this from the last minutes, but I think I recall a fairly tight deadline for a draft being agreed to? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 08:21:02 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 13:21:02 +0000 Subject: [tei-council] conformance chapter overdue? In-Reply-To: <45D84D64.5060106@oucs.ox.ac.uk> References: <45D84D64.5060106@oucs.ox.ac.uk> Message-ID: <45D852BE.5030003@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > I can't find an action about this from the last minutes, but > I think I recall a fairly tight deadline for a draft being agreed to? Yes, this is entirely my fault. I was supposed to create a draft for people to argue more about, and I've not finished it yet. I will definitely have time to work on it more this week. -james -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 09:21:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 14:21:23 +0000 Subject: [tei-council] SF FRs update Message-ID: <45D860E3.4080601@computing-services.oxford.ac.uk> I've now closed all the SF tickets assigned to me bar two or three. Most of them are fairly trivial, though the following may be of particular interest: 1022539: make global 1551357: loosen content model of The following 2 are still open: 1007370 ] (see earlier note to Council) 1308688 A new floating embedded text element (I think I now have a proposal for resolving this one, about which I will post to TEI-L early next week) The following are now marked PENDING 1531700 Element for supplied letters within expansion (see earlier note to TEI-L) 1549974 and 1524523 : placed on agenda for Vilnius meeting next week 1550229: Waiting for input from requestor I've also had a quick glance through the one's on Syd's pile and made comments where I have anything to say. Oh, and in a slightly devious move I assigned two particularly nasty ones to Sebastian. From dporter at uky.edu Sun Feb 18 12:08:29 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 09:08:29 -0800 Subject: [tei-council] facsimile odd In-Reply-To: <45D84AB4.9040800@oucs.ox.ac.uk> References: <45D84AB4.9040800@oucs.ox.ac.uk> Message-ID: <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> I expect the hold up is on my end - I am supposed to be supplying sample texts to Conal so he can test the ODD (which is probably finished). I will get the testing materials to him this afternoon. Sorry for the hold up... Dot On 2/18/07, Sebastian Rahtz wrote: > according to the minutes, we were going to have a full-devevloped > ODD for linking text to pages images by the end of January: > > > > finish specifications in ODD > 2007-01-27 > > > finish prose in ODD > 2007-01-31 > > > > read facsimile ODD, test schemata > 2007-02-08 > > > Any sign? > > I added a ticket to trac about it. > > -- > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 12:14:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 17:14:20 +0000 Subject: [tei-council] actions from tcm28 in trac Message-ID: <45D8896C.5020603@oucs.ox.ac.uk> I have transferred, sometimes baldly, the actions from the last council telco into tickets in trac. I hope some of you are getting emails about it. Can I stress again that you all need to access the trac system, go to settings, and put in your email address. Then ticket notifications will reach you. I think we agreed, btw, that physical bibliography is unlikely to make it into 1.0? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 12:37:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 17:37:01 +0000 Subject: [tei-council] header element to reference schema Message-ID: <45D88EBD.9040305@oucs.ox.ac.uk> We have an outstanding feature request to extend the TEI header to allow a pointer in the TEI to the schema (in the loosest sense) against which this document is valid. (http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065) The requestor boldly begs " this should be able to cope with different namespaces... i.e. I should be able to reference the relaxNG schema for elements starting with rng: the tei: schema I'm using, the svg: schema I'm using, etc. I should be able just to point to an ODD, an RNG, etc. or embed my ODD etc." My inclination is to say that ISO NVDL is supposed to cope with this, and that we could simply document as a technique how to embed NVDL in its namespace in the header (much as http://www.w3.org/TR/xml-i18n-bp/#tei-modularization discusses how to add ITS to the TEI). However, YMMV. So, _another_ little survey, please. Answers by next weekend; if there is no convincing consensus, the default answer will apply. Regarding the addition of a header element (or PI or whatever) to the TEI scheme to point to a scheme, choose one of the following: A. I don't understand the issues and am content to let others decide B. I think it is really important and the TEI must deal with it by itself for 1.0 C. It is important, but best left to the industry, and we should simply encourage OASIS to pick it up D. It can be dealt with using NVDL and we should document that somewhere E. We should leave it until after 1.0, and set up a working party then F. It's not an issue, people should use whatever scheme they like Since I was handed the ticket to resolve, I choose "C" as the default answer by which I will deal with the ticket if Council does not give a direction. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 13:01:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 18:01:21 +0000 Subject: [tei-council] recording application information in the teiHeader Message-ID: <45D89471.4070809@oucs.ox.ac.uk> cf my post to TEI-L If I get no serious responses, I incline towards saying to Martin "thanks but no thanks". If there _are_ positive responses, I will propose that we put it straight in the header, and not bother with an extra module. In that case, I will take it as an action to finish drafting the new elements with Martin for review by Berlin. Obviously, this depends on y'll approving that plan of campaign. I will take silence as assent :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From arianna.ciula at kcl.ac.uk Sun Feb 18 13:22:39 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Sun, 18 Feb 2007 18:22:39 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D8996F.5020901@kcl.ac.uk> > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > > Issue: keep ? > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > _X_ C > ___ D I could have looked at this more, but after the discussion on the list, I think I am convinced it's the best solution. Arianna Syd Bauman wrote: > OK. I realize dating attributes can make your head spin -- heck, I > got so dizzy I had to take breaks while writing that last posting. > But given that we are in pedal-to-the-metal mode to get moving on P5, > I would like to avoid waiting for 2 weeks to see if anyone has > comments on it, only to find they don't. > > Christian, Daniel, and Sebastian are working on getting a working > project management system up for P5, which will hopefully include > (among other things) a voting system for Council to use to express > its wishes. But that's at least days away, so in the meantime > Christian has authorized me to use the following far cruder system. > > I really want each and every one of us to reply to this posting > within 72 hours having checked off one box for each of the following. > > > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > ___ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > ___ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: keep ? > Solution: nuke it > Vote: > > ___ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: keep precision= of > Solution: nuke it > Vote: > > ___ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > ___ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > ___ It does not matter to me which solution is chosen, so go > ahead > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each different system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > ___ C > ___ D > > I have considered issue, and disagree with proposed solution: > ___ A > ___ B > ___ C > ___ D > > ___ It does not matter to me which solution is chosen, so go > ahead with whatever > > ___ I have not yet had time to consider the issue sufficiently, > but expect to contribute soon > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 14:51:49 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 19:51:49 +0000 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <200702151603.l1FG3V2N007860@perseus.services.brown.edu> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> Message-ID: <45D8AE55.1060503@computing-services.oxford.ac.uk> Syd Bauman wrote: >>> - If we keep [1] we may wish to reconsider its class >>> membership, as value= is a bit silly on . It needs only >>> dur= from att.datePart, making two cases that benefit from >>> splitting att.datePart. (See , above.) > >> kill distance > > Is anyone in favor of keeping ? Is anyone besides me, Lou, > and Sebastian in favor of deleting it? As I stated on 2007-02-05, I am in favour of keeping distance because it is useful for spatial distance. I don't mind if temporal distance is removed from it, but as an element it should be considered completely separately from the discussion of date/times. -james -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From dporter at uky.edu Sun Feb 18 14:55:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 11:55:16 -0800 Subject: [tei-council] date attributes: summary, problems, and some suggestions In-Reply-To: <45D8AE55.1060503@computing-services.oxford.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D8AE55.1060503@computing-services.oxford.ac.uk> Message-ID: <96f3df640702181155t42a5440ag4d62262abb77d71f@mail.gmail.com> I agree with James that should be kept for spacial difference and not considered only in a discussion of date/time. Dot On 2/18/07, James Cummings wrote: > Syd Bauman wrote: > >>> - If we keep [1] we may wish to reconsider its class > >>> membership, as value= is a bit silly on . It needs only > >>> dur= from att.datePart, making two cases that benefit from > >>> splitting att.datePart. (See , above.) > > > >> kill distance > > > > Is anyone in favor of keeping ? Is anyone besides me, Lou, > > and Sebastian in favor of deleting it? > > As I stated on 2007-02-05, I am in favour of keeping distance because it is > useful for spatial distance. I don't mind if temporal distance is removed from > it, but as an element it should be considered completely separately from the > discussion of date/times. > > -james > > -- > Dr James Cummings, Oxford Text Archive, University of Oxford > James dot Cummings at oucs dot ox dot ac dot uk > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From James.Cummings at computing-services.oxford.ac.uk Sun Feb 18 15:01:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sun, 18 Feb 2007 20:01:34 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <45D8B09E.4020900@computing-services.oxford.ac.uk> Syd Bauman wrote: > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X_ I have considered issue, and agree with proposed solution > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X_ I have considered issue, and agree with proposed solution > > Issue: keep ? > Solution: nuke it > Vote: > _X_ I have considered issue, and disagree with proposed solution I think this conversation is misplaced in a conversation otherwise solely about date/time since distance is used spatially as well as temporally. > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X_ I have considered issue, and agree with proposed solution > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X_ I have considered issue, and agree with proposed solution Though I never had my comments in my message from 2007-02-05 explained viz. whether W3C gMonthDay datatype allows --25-12 for christmas. > > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > Vote: > > I have considered issue, and agree with proposed solution: > _X_ A > _x_ D I'd vote for A, with possibly a secondary vote for D, but I find both solutions less than elegant. > I have considered issue, and disagree with proposed solution: > _X_ B > _X_ C -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From dporter at uky.edu Sun Feb 18 15:21:07 2007 From: dporter at uky.edu (Dot Porter) Date: Sun, 18 Feb 2007 12:21:07 -0800 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <96f3df640702181221u327d3e5dud100066d1ed18903@mail.gmail.com> On 2/15/07, Syd Bauman wrote: > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X__ I have considered issue, and agree with proposed solution > > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X__ I have considered issue, and agree with proposed solution > > ___ I have considered issue, and disagree with proposed solution > > Issue: keep ? > Solution: nuke it > Vote: > > _X__ I have considered issue, and disagree with proposed solution > As James has already mentioned, is also used for spacial distance. > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X__ I have considered issue, and agree with proposed solution > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X__ I have considered issue, and agree with proposed solution > > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each different system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > _x__ C > ___ D Dot -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From lou.burnard at computing-services.oxford.ac.uk Sun Feb 18 18:12:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Feb 2007 23:12:08 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D89471.4070809@oucs.ox.ac.uk> References: <45D89471.4070809@oucs.ox.ac.uk> Message-ID: <45D8DD48.4070403@computing-services.oxford.ac.uk> 1. I certainly dont think it needs a new module 2. As a tool developer I can report that xaira certainly needs a place in the header to store quite a lot of data: much more than this proposal would permit (and with a more complex structure) in fact. Xaira addresses the need by defining its own additional "XairaDesc" element (if I were doing this properly it wd be in its own namespace) and adding same to the encodingDesc, which works just fine. In an earlier version, xaira also updated the revisionDesc everytime it ran: however this rapidly became so annoying I took it out again. So on balance, 3. I am unconvinced that this proposal is sufficiently general or powerful as yet Lou Sebastian Rahtz wrote: > cf my post to TEI-L > > If I get no serious responses, I incline towards saying > to Martin "thanks but no thanks". > > If there _are_ positive responses, I will propose that we put > it straight in the header, and not bother with an > extra module. In that case, I will take it as an > action to finish drafting the new elements with Martin > for review by Berlin. > > Obviously, this depends on y'll approving that > plan of campaign. I will take silence as assent :-} > From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 18 18:46:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Feb 2007 23:46:09 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8DD48.4070403@computing-services.oxford.ac.uk> References: <45D89471.4070809@oucs.ox.ac.uk> <45D8DD48.4070403@computing-services.oxford.ac.uk> Message-ID: <45D8E541.50206@oucs.ox.ac.uk> Lou Burnard wrote: > > 2. As a tool developer I can report that xaira certainly needs a place > in the header to store quite a lot of data: much more than this > proposal would permit (and with a more complex structure) in fact. > Xaira addresses the need by defining its own additional "XairaDesc" > element (if I were doing this properly it wd be in its own namespace) > and adding same to the encodingDesc, which works just fine. In an > earlier version, xaira also updated the revisionDesc everytime it ran: > however this rapidly became so annoying I took it out again. > OK, having also immediately heard from Peter Boot and Dot, the case is probably there for it to exist. The choice is between: a simple extensible mechanism which needs careful definition to let Lou use it; and a technique recommendation which says "define your own vocabulary in your own namespace". This business of "when to namespace and when not to namespace" keeps coming back to haunt us... I'll let this stew a bit on TEI-L, and then make you a proposal. Incidentally, perhaps I am over-influenced by my work for the W3C, but I like the separation there between the standard, and the "best practices" document to go with it. I suppose it is heresy to say that we could do with that too? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Sun Feb 18 22:58:01 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 18 Feb 2007 22:58:01 -0500 Subject: [tei-council] Re: schema association In-Reply-To: <45D61E4D.8060807@oucs.ox.ac.uk> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> <45D5B44B.2030908@oucs.ox.ac.uk> <17878.7093.457090.669596@emt.wwp.brown.edu> <45D61E4D.8060807@oucs.ox.ac.uk> Message-ID: <17881.8265.966631.335794@emt.wwp.brown.edu> > that's fine, and it takes it out of our timeline. we would > participate as an interested party, but would not have a dependency > on it for P5. This is not what I had in mind at all. I think we should try, very hard, to get this done such that it is included in P5 1.0. > I hold the OASIS vote for Oxford if you ever need it :-} Excellent! From Syd_Bauman at Brown.edu Sun Feb 18 23:47:08 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 18 Feb 2007 23:47:08 -0500 Subject: [tei-council] time to really allow instance to name schema? Message-ID: <17881.11212.530001.31343@emt.wwp.brown.edu> Dept: re-opening a can of worms :-) Two straw-man proposals have been put forward to two separate groups for a PI that would permit an XML document instance to name a schema or schemas against which it is (supposed to be) valid. In April 2005 I wrote a document that at the time was circulated only among the TEI Council members: http://www.tei-c.org/Drafts/edw89.xml?style=printable In July 2005 MURATA Makoto wrote a document that at the time was circulated to the new Relax NG user's mailing list: http://www.asahi-net.or.jp/~eb2m-mrt/hidden/spec.html In both cases the documents are just proposals of their authors, not position papers of the organizations they sometimes represent. In both cases the syntax of a PI that an XML document may use to point to a schema is described. In both cases the intent is that the PI itself is optional and repeatable, and that while processors may want to make use of the information, they are not required to. This issue fostered some discussion on the rng-users list back in summer 2005, with some objecting to the idea of a schema-pointing PI (Tommie Usdin I recall was among them). TEI P5 needs to be finished up soon, and it would be a good idea, I think, to have this particular issue settled well before it is published. Because TEI is so customizable, it is quite helpful for the user if an instance can point to its schema. In general, the TEI would be as happy or happier if someone else (read OASIS) came up with the specification for this process, so that TEI P5 could refer to it. My instinct is that a PI is the right place for this information, but I'm not even sure that is a given. I don't think there is really that much work to be done in this area to come up with a unified proposal. Does any one else think it is worth any effort? Is this something that comes under the jurisdiction of the OASIS Relax NG Technical Committee? From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Feb 19 03:33:09 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Feb 2007 17:33:09 +0900 Subject: [tei-council] time to really allow instance to name schema? In-Reply-To: <17881.11212.530001.31343@emt.wwp.brown.edu> References: <17881.11212.530001.31343@emt.wwp.brown.edu> Message-ID: <45D960C5.50007@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: > Dept: re-opening a can of worms :-) Ah, right. I had completely forgotten about these. > TEI P5 needs to be finished up soon, and it would be a good idea, I > think, to have this particular issue settled well before it is > published. Because TEI is so customizable, it is quite helpful for > the user if an instance can point to its schema. In general, the TEI > would be as happy or happier if someone else (read OASIS) came up > with the specification for this process, so that TEI P5 could refer > to it. My instinct is that a PI is the right place for this > information, but I'm not even sure that is a given. > > I don't think there is really that much work to be done in this area > to come up with a unified proposal. Does any one else think it is > worth any effort? Is this something that comes under the jurisdiction > of the OASIS Relax NG Technical Committee? I am all in favor for this to go to a committee outside the TEI to be considered, with the TEI providing input and also a community with a commitment to use the spec, once ready. The only concern is that this (a) should not take steam out of our effort to concentrate on the immediate issues for P5 and (b) that it becomes decoupled from P5, so that we are not being held up if this gets stranded somewhere. Christian From lou.burnard at computing-services.oxford.ac.uk Mon Feb 19 06:47:03 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Feb 2007 11:47:03 +0000 Subject: [tei-council] time to really allow instance to name schema? In-Reply-To: <17881.11212.530001.31343@emt.wwp.brown.edu> References: <17881.11212.530001.31343@emt.wwp.brown.edu> Message-ID: <45D98E37.7090700@oucs.ox.ac.uk> According to the edw89 draft the proposed mechanism * should be optional, ignorable, and over-ridable * should not be TEI-specific If the first is a serious requirement, I cannot see any point in the proposal at all. Its only possible outcome might be a suggestion that specifying a schema this way is one amongst the many things you might do with a PI (but since you might also do the same thing another way, or other things the same way, why bother to make the suggestion?) If the second is a serious requirement, then clearly there is littlethe TEI can do to achieve it! Given that the proposal has already been discussed and failed to persuade one expert forum (the rng users group), why resurrect it now? For the record, I think this is a waste of time. The most I think we should do in TEI P5 is to add a few sentences to SG (introductory chapter on XML) explaining how a schema might be associated with an instance, possibly giving the rationale for not doing it. And I'm not even sure about that. Lou Syd Bauman wrote: > Dept: re-opening a can of worms :-) > > Two straw-man proposals have been put forward to two separate groups > for a PI that would permit an XML document instance to name a schema > or schemas against which it is (supposed to be) valid. > > In April 2005 I wrote a document that at the time was circulated only > among the TEI Council members: > http://www.tei-c.org/Drafts/edw89.xml?style=printable > > In July 2005 MURATA Makoto wrote a document that at the time was > circulated to the new Relax NG user's mailing list: > http://www.asahi-net.or.jp/~eb2m-mrt/hidden/spec.html > > In both cases the documents are just proposals of their authors, not > position papers of the organizations they sometimes represent. In > both cases the syntax of a PI that an XML document may use to point > to a schema is described. In both cases the intent is that the PI > itself is optional and repeatable, and that while processors may want > to make use of the information, they are not required to. > > This issue fostered some discussion on the rng-users list back in > summer 2005, with some objecting to the idea of a schema-pointing PI > (Tommie Usdin I recall was among them). > > TEI P5 needs to be finished up soon, and it would be a good idea, I > think, to have this particular issue settled well before it is > published. Because TEI is so customizable, it is quite helpful for > the user if an instance can point to its schema. In general, the TEI > would be as happy or happier if someone else (read OASIS) came up > with the specification for this process, so that TEI P5 could refer > to it. My instinct is that a PI is the right place for this > information, but I'm not even sure that is a given. > > I don't think there is really that much work to be done in this area > to come up with a unified proposal. Does any one else think it is > worth any effort? Is this something that comes under the jurisdiction > of the OASIS Relax NG Technical Committee? > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 08:19:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 13:19:41 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45D96342.5000007@kosek.cz> References: <17881.11212.530001.31343@emt.wwp.brown.edu> <711a73df0702182353u667f1055lea5b46d9e238cea2@mail.gmail.com> <45D96342.5000007@kosek.cz> Message-ID: <45D9A3ED.8090308@oucs.ox.ac.uk> Jirka Kosek wrote: > > Since 2005 there is NVDL which can associate schema with namespace > indirectly. But this doesn't solve issue of having several different > vocabularies (read schemas) in the same namespaces -- for example full > TEI vs. TEI Lite, full DocBook vs. Simplified DocBook, XHTML 1.0 vs. > XHTML 1.1 vs. XHTML Print. > you could embed a stanza of NVDL inside the document? Sebastian From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 08:21:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 13:21:57 +0000 Subject: [tei-council] Re: schema association In-Reply-To: <17881.8265.966631.335794@emt.wwp.brown.edu> References: <200701222223.l0MMNblR024839@perseus.services.brown.edu> <45C867D4.3080206@oucs.ox.ac.uk> <200702151603.l1FG3V2N007860@perseus.services.brown.edu> <45D48CCF.3010402@oucs.ox.ac.uk> <45D50332.9070609@kanji.zinbun.kyoto-u.ac.jp> <45D583D3.10001@oucs.ox.ac.uk> <45D5A3D2.2000402@kanji.zinbun.kyoto-u.ac.jp> <45D5A752.9060202@oucs.ox.ac.uk> <45D5A91B.30206@kanji.zinbun.kyoto-u.ac.jp> <45D5B44B.2030908@oucs.ox.ac.uk> <17878.7093.457090.669596@emt.wwp.brown.edu> <45D61E4D.8060807@oucs.ox.ac.uk> <17881.8265.966631.335794@emt.wwp.brown.edu> Message-ID: <45D9A475.3080203@oucs.ox.ac.uk> Syd Bauman wrote: >> that's fine, and it takes it out of our timeline. we would >> participate as an interested party, but would not have a dependency >> on it for P5. >> > > This is not what I had in mind at all. I think we should try, very > hard, to get this done such that it is included in P5 1.0. > I hope that my request yesterday for the council to vote on this subject will deal with the issue one way or another? Note that I have only had one response..... Sebastian From James.Cummings at computing-services.oxford.ac.uk Mon Feb 19 09:13:54 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 19 Feb 2007 14:13:54 +0000 Subject: [tei-council] header element to reference schema In-Reply-To: <45D88EBD.9040305@oucs.ox.ac.uk> References: <45D88EBD.9040305@oucs.ox.ac.uk> Message-ID: <45D9B0A2.3020105@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > We have an outstanding feature > request to extend the TEI header to allow a pointer in the TEI > to the schema (in the loosest sense) against which this document is valid. > (http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065) > > > The requestor boldly begs " this should be able to cope with different > namespaces... i.e. I should be > able to reference the relaxNG schema for elements starting with rng: the > tei: schema I'm using, the svg: schema I'm using, etc. I should be able > just to point to an ODD, an RNG, etc. or embed my ODD > etc." I didn't think I was being that bold. I just felt that if we implemented a solution one should be able to embed the schema(s) or point to them. I.e. point to my ODD, embed its RNG, and point to some other publicly maintained schema (say the SVG schema). Basically I'm just looking for a point at which to do this in the header, probably under encodingDesc. > My inclination is to say that ISO NVDL is supposed to cope with this, I don't know NVDL well enough, but a quick glance at it seems like it might do what we want. > Regarding the addition of a header element (or PI or whatever) to the TEI > scheme to point to a scheme, choose one of the following: > > B. I think it is really important and the TEI must deal with it by > itself for 1.0 > D. It can be dealt with using NVDL and we should document that somewhere I don't see these two as mutually exclusive. I think it is important, and TEI should discuss it and document at least one recommendation on how to do it. I don't view 'deal with it by itself' as excluding using existing standards. It may be that NVDL should be the recommendation we choose. The only things I could find about it that bothered me were that in all the examples in the 'annexes' of the ISO publication, it uses Relax NG Annotations for its documentation...so that means declaring yet another namespace... I'm assuming that NVDL has no problem if it points to a schema language or similar that whatever is processing it doesn't understand. I.e. if I point to my ODD, then oxygen won't die, just say it doesn't know about that kind of thing. Similarly, this only partly answers the original spec. This gives us a way to point to external schemas, but no recommendation on a manner to embed the same in your instance document. (i.e. Say I want to stick my ODDs, automatically, in an instance document so that the two are inseparable.) -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Mon Feb 19 10:00:28 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 19 Feb 2007 15:00:28 +0000 Subject: [tei-council] header element to reference schema In-Reply-To: <45D88EBD.9040305@oucs.ox.ac.uk> References: <45D88EBD.9040305@oucs.ox.ac.uk> Message-ID: <45D9BB8C.4020809@kcl.ac.uk> I think it would highly desirable to have the possibility to point to a publicly maintained schema in the TeiHeader for 1.0 and, I agree with James, the encodingDesc element could be the right place. However, I don't know enough about NVDL to vote with all awareness or to know how to achieve this in collaboration with the industry. Arianna Sebastian Rahtz wrote: > We have an outstanding feature > request to extend the TEI header to allow a pointer in the TEI > to the schema (in the loosest sense) against which this document is valid. > (http://sourceforge.net/tracker/index.php?func=detail&aid=1650195&group_id=106328&atid=644065) > > > The requestor boldly begs " this should be able to cope with different > namespaces... i.e. I should be > able to reference the relaxNG schema for elements starting with rng: the > tei: schema I'm using, the svg: schema I'm using, etc. I should be able > just to point to an ODD, an RNG, etc. or embed my ODD > etc." > > My inclination is to say that ISO NVDL is supposed to cope with this, > and that we > could simply document as a technique how to embed NVDL in its namespace > in the header (much > as http://www.w3.org/TR/xml-i18n-bp/#tei-modularization discusses how to > add ITS > to the TEI). > > However, YMMV. So, _another_ little survey, please. Answers by next > weekend; > if there is no convincing consensus, the default answer will apply. > > Regarding the addition of a header element (or PI or whatever) to the TEI > scheme to point to a scheme, choose one of the following: > > A. I don't understand the issues and am content to let others decide > B. I think it is really important and the TEI must deal with it by > itself for 1.0 > C. It is important, but best left to the industry, and we should simply > encourage OASIS to pick it up > D. It can be dealt with using NVDL and we should document that somewhere > E. We should leave it until after 1.0, and set up a working party then > F. It's not an issue, people should use whatever scheme they like > > Since I was handed the ticket to resolve, I choose "C" as the default > answer > by which I will deal with the ticket if Council does not give a direction. > > -- > > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From tone.bruvik at aksis.uib.no Mon Feb 19 12:25:49 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Mon, 19 Feb 2007 18:25:49 +0100 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17876.62761.972180.960950@emt.wwp.brown.edu> References: <17876.62761.972180.960950@emt.wwp.brown.edu> Message-ID: <892343a4888f26993d00424071b68e50@aksis.uib.no> Sorry to be a bit late, but here are my vote: P? 16. feb. 2007 kl. 01.04 skrev Syd Bauman: > Issue: name of main dating attr (date= vs value=) > Solution: leave 'em as is > Vote: > > _X__ I have considered issue, and agree with proposed solution > > Issue: classes -- @dur and @value in same or different attr classes? > Solution: split 'em into separate classes > Vote: > > _X__ I have considered issue, and agree with proposed solution > > > Issue: keep ? > Solution: nuke it > Vote: > > _X__ I have considered issue, and agree with proposed solution > > Issue: keep precision= of > Solution: nuke it > Vote: > > _X__ I have considered issue, and agree with proposed solution > > > Issue: method of expressing known day & month, unknown year, or > specific possible dates within a range > Suggestion: defer to P5 1.x. > Vote: > > _X__ I have considered issue, and agree with proposed solution > Issue: constraint of date-regularization attributes: W3C, ISO, other > Suggestions: > A ("attribute level"): duplicate current attrs for each different > system > B ("datatype level"): create duplicate datatype for each different > system > C ("class level"): create classes for each set of attrs from > different systems; possibly implement with a new > module so attrs are added when that module is > loaded (like att.metrical gets added to > att.divLike when verse is loaded) > D ("all-in-one"): differentiate system by value's syntax > > Vote: > > I have considered issue, and agree with proposed solution: > ___ A > ___ B > _X__ C > ___ D > > _X_ It does not matter to me which solution is chosen, so go > ahead with whatever > Tone Merete Bruvik Lyshovden 104 5148 Fyllingsdalen 55161123 From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 12:58:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 17:58:16 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45D9A899.30500@kosek.cz> References: <17881.11212.530001.31343@emt.wwp.brown.edu> <711a73df0702182353u667f1055lea5b46d9e238cea2@mail.gmail.com> <45D96342.5000007@kosek.cz> <45D9A3ED.8090308@oucs.ox.ac.uk> <45D9A899.30500@kosek.cz> Message-ID: <45D9E538.1050300@oucs.ox.ac.uk> Jirka Kosek wrote: >> you could embed a stanza of NVDL inside the document? >> > > But this would modify "information content" of document itself it seems to me that this is what the proponents of the idea want to do, they genuinely want to enhance the document. > - you will have to ignore NVDL elements during XSLT processing > Yes, of course; I don't see that as any big deal; just like I ignore most metadata elements during daily processing. Sometimes I want them. Sometimes I also want to consult the schema, so I will read the NVDL. And of course it did not stop XSD from adding their horrible attribute.... The days when you got the "real" content of a document by stripping out all tags is surely past? > - how would you implement validation in a streaming mode if you must > lookahead NVDL snippet first > doesn't the same apply to a PI? it has to be inside the root element, so you have to open the document. and it applies to the XSD element. > I think that for situations where schema can't be specified indirectly > using NVDL or similar technology using PI is the best > solution -- easy to use, easy to implement, no side-effect in existing > toolchains. > but it does require a new ad hoc agreement, and one which cannot be checked against a schema, or contain any useful documentation. I agree it would work (if tool vendors wanted), but I don't think its as much fun as it could. Anyway, I tend to agree with Lou that I want different schemas at different times, and that I'd rather not be dictated to by the document... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 19 17:54:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Feb 2007 22:54:42 +0000 Subject: [tei-council] Re: [rng-users] time to really allow instance to name schema? In-Reply-To: <45DA22A5.6030202@kosek.cz> References: <17881.11212.530001.31343@emt.wwp.brown.edu> <711a73df0702182353u667f1055lea5b46d9e238cea2@mail.gmail.com> <45D96342.5000007@kosek.cz> <45D9A3ED.8090308@oucs.ox.ac.uk> <45D9A899.30500@kosek.cz> <45D9E538.1050300@oucs.ox.ac.uk> <45DA22A5.6030202@kosek.cz> Message-ID: <45DA2AB2.5040606@oucs.ox.ac.uk> Jirka Kosek wrote: > I think that we are not agreeing on what is "information content" of > document. I include elements/attributes/text nodes under this term, > while I take PIs and comments as something which doesn't convey primary > information of document, just some stuff which can be used by some > users/tools as a suplemental information when document is processed in a > particular way. > I probably do agree with you. But I am still prepared to use elements for metadata; after all, you and I both work on a W3C scheme (ITS) which is happy to store meta information about processing information in elements the header.... > Nope, PIs can be before root element, for example > > >
> ... >
> ah, OK. true. But you still get at that PI with an XML parser, don't you? or do you just read the first few hundred bytes and hope you find it? > OK, so then you will not use this PI. But there are still people who need this functionality. > > If OASIS or W3C want to start a workgroup to standardize a PI, that's fine, of course. I can't believe the W3C will, though, because they only recognize the existence of XSD, which already has its truly horrible attribute. So how does one start an OASIS activity to look at this? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Tue Feb 20 16:18:53 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:18:53 -0700 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8E541.50206@oucs.ox.ac.uk> References: <45D89471.4070809@oucs.ox.ac.uk> <45D8DD48.4070403@computing-services.oxford.ac.uk> <45D8E541.50206@oucs.ox.ac.uk> Message-ID: <1172006333.11553.70.camel@odonned-eng06> On Sun, 2007-18-02 at 23:46 +0000, Sebastian Rahtz wrote: > Lou Burnard wrote: > > > > 2. As a tool developer I can report that xaira certainly needs a place > > in the header to store quite a lot of data: much more than this > > proposal would permit (and with a more complex structure) in fact. > > Xaira addresses the need by defining its own additional "XairaDesc" > > element (if I were doing this properly it wd be in its own namespace) > > and adding same to the encodingDesc, which works just fine. In an > > earlier version, xaira also updated the revisionDesc everytime it ran: > > however this rapidly became so annoying I took it out again. > > > OK, having also immediately heard from Peter Boot and Dot, the case is > probably there for it to > exist. The choice is between: a simple extensible mechanism which needs > careful definition > to let Lou use it; and a technique recommendation which says "define > your own vocabulary > in your own namespace". > > This business of "when to namespace and when not to namespace" keeps > coming back > to haunt us... > > I'll let this stew a bit on TEI-L, and then make you a proposal. > > Incidentally, perhaps I am over-influenced by my work for the W3C, but I > like > the separation there between the standard, and the "best practices" > document to go with it. I suppose it is heresy to say that we could do > with that too? Doesn't that keep coming back as well? I think this is probably a post partum desideratum--though obviously we think about best practice as we discuss the final spec all the time. I.e. not quite 1.1 but post 1.0. Perhaps a separate project? > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Tue Feb 20 16:21:51 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:21:51 -0700 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <45D8DD48.4070403@computing-services.oxford.ac.uk> References: <45D89471.4070809@oucs.ox.ac.uk> <45D8DD48.4070403@computing-services.oxford.ac.uk> Message-ID: <1172006511.11553.74.camel@odonned-eng06> We've been coming up on this idea of multiple namespaces a lot as well. Was James C not dealing with this question as part of the conformance proposals? I'm happy with Sebastian's proposal for a method of working, but I'm wondering if what we aren't talking about here is not something that should be cast off as a separate namespace question--each tool will presumably have a number of different things it wants to say about itself and it seems to me to be a mugs game to predict them. -dan On Sun, 2007-18-02 at 23:12 +0000, Lou Burnard wrote: > 1. I certainly dont think it needs a new module > > 2. As a tool developer I can report that xaira certainly needs a place > in the header to store quite a lot of data: much more than this proposal > would permit (and with a more complex structure) in fact. Xaira > addresses the need by defining its own additional "XairaDesc" element > (if I were doing this properly it wd be in its own namespace) and adding > same to the encodingDesc, which works just fine. In an earlier version, > xaira also updated the revisionDesc everytime it ran: however this > rapidly became so annoying I took it out again. > > So on balance, > > 3. I am unconvinced that this proposal is sufficiently general or > powerful as yet > > Lou > > > Sebastian Rahtz wrote: > > cf my post to TEI-L > > > > If I get no serious responses, I incline towards saying > > to Martin "thanks but no thanks". > > > > If there _are_ positive responses, I will propose that we put > > it straight in the header, and not bother with an > > extra module. In that case, I will take it as an > > action to finish drafting the new elements with Martin > > for review by Berlin. > > > > Obviously, this depends on y'll approving that > > plan of campaign. I will take silence as assent :-} > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 16:24:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 21:24:42 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <1172006333.11553.70.camel@odonned-eng06> References: <45D89471.4070809@oucs.ox.ac.uk> <45D8DD48.4070403@computing-services.oxford.ac.uk> <45D8E541.50206@oucs.ox.ac.uk> <1172006333.11553.70.camel@odonned-eng06> Message-ID: <45DB671A.6020209@oucs.ox.ac.uk> Dan O'Donnell wrote: > Doesn't that keep coming back as well? I think this is probably a post > partum desideratum--though obviously we think about best practice as we > discuss the final spec all the time. I.e. not quite 1.1 but post 1.0. > Perhaps a separate project? > > I can see the counter argument, that if we know something we should put it in the Guidelines; but still I can imagine the "Big Book Of TEI Fun" as a community project where people document how they really proceed. As you say, a different project. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Tue Feb 20 16:29:50 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 14:29:50 -0700 Subject: [tei-council] actions from tcm28 in trac In-Reply-To: <45D8896C.5020603@oucs.ox.ac.uk> References: <45D8896C.5020603@oucs.ox.ac.uk> Message-ID: <1172006990.11553.79.camel@odonned-eng06> On Sun, 2007-18-02 at 17:14 +0000, Sebastian Rahtz wrote: > I have transferred, sometimes baldly, the actions from the last > council telco into tickets in trac. I hope some of you are getting emails > about it. Can I stress again that you all need to access the trac > system, go to settings, and put in your email address. Then ticket > notifications will reach you. > > I think we agreed, btw, that physical bibliography is unlikely to make > it into 1.0? This is what I remember. Unfortunately. -dan > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 16:35:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 21:35:03 +0000 Subject: [tei-council] recording application information in the teiHeader In-Reply-To: <1172006511.11553.74.camel@odonned-eng06> References: <45D89471.4070809@oucs.ox.ac.uk> <45D8DD48.4070403@computing-services.oxford.ac.uk> <1172006511.11553.74.camel@odonned-eng06> Message-ID: <45DB6987.1040502@oucs.ox.ac.uk> Dan O'Donnell wrote: > We've been coming up on this idea of multiple namespaces a lot as well. > Was James C not dealing with this question as part of the conformance > proposals? > > I'm happy with Sebastian's proposal for a method of working, but I'm > wondering if what we aren't talking about here is not something that > should be cast off as a separate namespace question--each tool will > presumably have a number of different things it wants to say about > itself and it seems to me to be a mugs game to predict them. > Yes, that's probably the path of least resistance, simply to document how to add another namespaced element to the appropriate point in the header, to give the technique a feeling of encouragement and approval, without codifying the details. If I was an RDF nut, I'd point out that you can likely do everything with that. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From daniel.odonnell at uleth.ca Tue Feb 20 17:16:12 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 20 Feb 2007 15:16:12 -0700 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <17877.5371.694544.449968@emt.wwp.brown.edu> References: <17877.5371.694544.449968@emt.wwp.brown.edu> Message-ID: <1172009772.11553.99.camel@odonned-eng06> On Thu, 2007-15-02 at 21:20 -0500, Syd Bauman wrote: On this issue I must confess, I like D better than anything presented; and think the namespace idea is sooper. We already use namespaced attributes, of course, so could we do it? -dan > > That last one is tricky. > > Indeed it is. > > > > I'm not sure, Syd and Sebastian, why you have characterised the > > "attribute-level" solution (A) as NOT making the easy things easy, > > and "just too confusing for day to day use". Could you clarify > > where the confusion might lie please? It seems to me that we could > > have this year and that this is easy. So > > I must be missing something. > > With the attribute-level solution every time any user (who hasn't > removed attributes in her customization) inserts a element, > her XML-aware editor would present here with a slew of possible > attributes: > value= > value.iso= > value.usr= > notBefore= > notBefore.iso= > notBefore.usr= > notAfter= > notAfter.iso= > notAfter.usr= > from= > from.iso= > from.usr= > to= > to.iso= > to.usr= > dur= > dur.iso= > dur.usr= > not to mention the non-date-specific attributes. No simple check-box > style customization could change this. (Although, as I'm fond of > pointing out, it isn't really that hard without the check-box > simplicity.) For the vast majority of users, 2/3 of the above > attributes would never be used, and would just be in the way. > > > > I think B and C are weaker (if I understand them correctly) in that > > they would prohibit mixing calendars in a document (at least, with > > the same element, so that date/@value would have to have a > > consistent type throughout a document). Is that a correct > > understanding? > > Off the top of my head I think that is correct if the user is using > the "simple format" date attributes, regardless of which option we > choose. That's because the simple W3C format is definitionally > Gregorian, and arguably proleptic Gregorian. Things are a little > better with ISO 8601, which is explicitly Gregorian or proleptic > Gregorian, and arguably the syntax could be used for others. > > I'm of a mind that, regardless of system, we should define value= and > iso-value= as (proleptic) Gregorian. User-defined values could be of > whatever calendar the user desired. The *content* is in whatever > calendar is specified by calendar=. > > > > In some ways I prefer D because it implies that the attributes have > > particular semantics which are in a sense independent of the > > particular calendrical "syntax" used. > > I'm sorry, I think I'm too tired (or too stupid :-) to understand > this. > > > > Incidentally, ... use distinct XML namespaces for the different > > data types. ... e.g. ... St David's > > day or ... St David's day > > Really interesting idea (that I never thought of) that yields a > very nice syntactic result. But I don't think the implications -- > that these attributes somehow belong to some other markup language > than TEI -- are acceptable. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 20 17:42:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Feb 2007 22:42:48 +0000 Subject: [tei-council] what to do with dating attributes -- VOTE! In-Reply-To: <1172009772.11553.99.camel@odonned-eng06> References: <17877.5371.694544.449968@emt.wwp.brown.edu> <1172009772.11553.99.camel@odonned-eng06> Message-ID: <45DB7968.7050408@oucs.ox.ac.uk> Dan O'Donnell wrote: > On this issue I must confess, I like D better than anything presented; > and think the namespace idea is sooper. We already use namespaced > attributes, of course, so could we do it? > Technically, yes. But if they were in the core, we'd have a choice of too many attributes; if it was in a loadable module, what's the advantage over another name, really? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Feb 20 20:10:48 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 21 Feb 2007 10:10:48 +0900 Subject: [tei-council] actions from tcm28 in trac In-Reply-To: <1172006990.11553.79.camel@odonned-eng06> References: <45D8896C.5020603@oucs.ox.ac.uk> <1172006990.11553.79.camel@odonned-eng06> Message-ID: <45DB9C18.5050308@kanji.zinbun.kyoto-u.ac.jp> Dan O'Donnell wrote: > On Sun, 2007-18-02 at 17:14 +0000, Sebastian Rahtz wrote: >> I think we agreed, btw, that physical bibliography is unlikely to make >> it into 1.0? > > This is what I remember. Unfortunately. > Right. And I guess it will fall on me to inform Murray and the group about this state of affairs. Christian From lou.burnard at computing-services.oxford.ac.uk Tue Feb 27 09:34:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 27 Feb 2007 14:34:19 +0000 Subject: [tei-council] P5 internal structure Message-ID: <45E4416B.70500@oucs.ox.ac.uk> Sebastian and I were actioned to determine what to do about the formatting problems in generating HTML from the newly vanilla-div structured P5 whilst in Lithuania. We discussed the following options: 0. Top level divs are numbered I to VIII; second level divs are numbered 1 to 39. what is currently the first chapter of part II (numbered 4) remains numbered 4. 1. Combine top and subsequent level divs: what is currently the first chapter of part II (numbered 4) becomes II.1 2. Forget about the part numbers: what is currently the first chapter of part II (numbered 4) remains numbered 4. 3. Special case the first chapter in each part so that it does something magical to produce an extra blank page, possibly with an extra heading or something. We observed that: (a) the current structure is in need of overhaul -- some of the chapters are very small and others very large; some closely related material (e.g. CH and WD) is widely separated; the distinction between "core" and "additional" tagsets is defunct. (b) the chapters that define modules should probably be separated from those which don't, both by numbering and form of title. Some of the current introductory material could move into the ; some of the current "technical material" could move into the . We concluded: We will begin by adopting option 2 above. This is by far the simplest solution if we want to get out reasonable looking and accessible HTML in the near future. It also leaves room for us to group and regroup chapters without major upheaval. The downside is that those who have got accustomed to thinking of chapter CH as chapter 4 will have to get reprogrammed. But they have quite a lot of reprogramming to endure anyway. From laurent.romary at loria.fr Tue Feb 27 09:57:06 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 27 Feb 2007 15:57:06 +0100 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> References: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: Since I missed the preceding vote (vacances...), I anticipate on this one and fully support Lou's proposal. Laurent Le 27 f?vr. 07 ? 15:34, Lou Burnard a ?crit : > Sebastian and I were actioned to determine what to do about the > formatting problems in generating HTML from the newly vanilla-div > structured P5 whilst in Lithuania. > > We discussed the following options: > > 0. Top level divs are numbered I to VIII; second level divs are > numbered 1 to 39. what is currently the first chapter of part II > (numbered 4) remains numbered 4. > > 1. Combine top and subsequent level divs: what is currently the > first chapter of part II (numbered 4) becomes II.1 > > 2. Forget about the part numbers: what is currently the first > chapter of part II (numbered 4) remains numbered 4. > > 3. Special case the first chapter in each part so that it does > something magical to produce an extra blank page, possibly with an > extra heading or something. > > We observed that: > > (a) the current structure is in need of overhaul -- some of the > chapters are very small and others very large; some closely related > material (e.g. CH and WD) is widely separated; the distinction > between "core" and "additional" tagsets is defunct. > > (b) the chapters that define modules should probably be separated > from those which don't, both by numbering and form of title. Some > of the current introductory material could move into the ; > some of the current "technical material" could move into the . > > We concluded: > > We will begin by adopting option 2 above. This is by far the > simplest solution if we want to get out reasonable looking and > accessible HTML in the near future. It also leaves room for us to > group and regroup chapters without major upheaval. > > The downside is that those who have got accustomed to thinking of > chapter CH as chapter 4 will have to get reprogrammed. But they > have quite a lot of reprogramming to endure anyway. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From arianna.ciula at kcl.ac.uk Tue Feb 27 12:39:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Feb 2007 17:39:56 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> References: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: <45E46CEC.6000203@kcl.ac.uk> It is a pity to loose the old chapters references, but if the overall HTML structure can benefit and be improved the modifications are more than welcome. Arianna Lou Burnard wrote: > Sebastian and I were actioned to determine what to do about the > formatting problems in generating HTML from the newly vanilla-div > structured P5 whilst in Lithuania. > > We discussed the following options: > > 0. Top level divs are numbered I to VIII; second level divs are numbered > 1 to 39. what is currently the first chapter of part II (numbered 4) > remains numbered 4. > > 1. Combine top and subsequent level divs: what is currently the first > chapter of part II (numbered 4) becomes II.1 > > 2. Forget about the part numbers: what is currently the first chapter of > part II (numbered 4) remains numbered 4. > > 3. Special case the first chapter in each part so that it does something > magical to produce an extra blank page, possibly with an extra heading > or something. > > We observed that: > > (a) the current structure is in need of overhaul -- some of the chapters > are very small and others very large; some closely related material > (e.g. CH and WD) is widely separated; the distinction between "core" and > "additional" tagsets is defunct. > > (b) the chapters that define modules should probably be separated from > those which don't, both by numbering and form of title. Some of the > current introductory material could move into the ; some of the > current "technical material" could move into the . > > We concluded: > > We will begin by adopting option 2 above. This is by far the simplest > solution if we want to get out reasonable looking and accessible HTML in > the near future. It also leaves room for us to group and regroup > chapters without major upheaval. > > The downside is that those who have got accustomed to thinking of > chapter CH as chapter 4 will have to get reprogrammed. But they have > quite a lot of reprogramming to endure anyway. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From dporter at uky.edu Tue Feb 27 12:58:19 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 27 Feb 2007 12:58:19 -0500 Subject: [tei-council] P5 internal structure In-Reply-To: References: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: <96f3df640702270958g76b888a3y57f6563b3fd940e@mail.gmail.com> I support this proposal as well. Dot On 2/27/07, Laurent Romary wrote: > Since I missed the preceding vote (vacances...), I anticipate on this > one and fully support Lou's proposal. > Laurent > > Le 27 f?vr. 07 ? 15:34, Lou Burnard a ?crit : > > > Sebastian and I were actioned to determine what to do about the > > formatting problems in generating HTML from the newly vanilla-div > > structured P5 whilst in Lithuania. > > > > We discussed the following options: > > > > 0. Top level divs are numbered I to VIII; second level divs are > > numbered 1 to 39. what is currently the first chapter of part II > > (numbered 4) remains numbered 4. > > > > 1. Combine top and subsequent level divs: what is currently the > > first chapter of part II (numbered 4) becomes II.1 > > > > 2. Forget about the part numbers: what is currently the first > > chapter of part II (numbered 4) remains numbered 4. > > > > 3. Special case the first chapter in each part so that it does > > something magical to produce an extra blank page, possibly with an > > extra heading or something. > > > > We observed that: > > > > (a) the current structure is in need of overhaul -- some of the > > chapters are very small and others very large; some closely related > > material (e.g. CH and WD) is widely separated; the distinction > > between "core" and "additional" tagsets is defunct. > > > > (b) the chapters that define modules should probably be separated > > from those which don't, both by numbering and form of title. Some > > of the current introductory material could move into the ; > > some of the current "technical material" could move into the . > > > > We concluded: > > > > We will begin by adopting option 2 above. This is by far the > > simplest solution if we want to get out reasonable looking and > > accessible HTML in the near future. It also leaves room for us to > > group and regroup chapters without major upheaval. > > > > The downside is that those who have got accustomed to thinking of > > chapter CH as chapter 4 will have to get reprogrammed. But they > > have quite a lot of reprogramming to endure anyway. > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 27 15:39:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Feb 2007 20:39:47 +0000 Subject: [tei-council] a chance in a million for a lucky Council member Message-ID: <45E49713.9040501@oucs.ox.ac.uk> Who would like to step up to the plate and pick one of the plum jobs from the list? The task is nothing less than to design the layout of the Guidelines. The first requirement is to do the web version, then look at print if it is going well. The input is XHTML coming an XSLT transform of P5; you can change that XSLT too, but the first task is probably just to take over the CSS and make better-looking pages. Obviously whoever takes this on has to be prepared to defend the results to a sceptical Council, so a certain amount of hard-heartedness is required. You also have to be prepared to work through the nitty grit of what information is in an ODD and how best to present it. Only one caveat - the result cannot just be a lovely HTML page, with an instruction saying "go make it look like that". Finished product required. Go on, someone on the Council wants this task. Step forward and claim it! -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Tue Feb 27 16:47:08 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 27 Feb 2007 16:47:08 -0500 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E49713.9040501@oucs.ox.ac.uk> References: <45E49713.9040501@oucs.ox.ac.uk> Message-ID: <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> Hi Council, James and I volunteer for this task. We feel that we'll be more effective working together than either of us would be separately (that and James still need to finish up an initial draft of Conformance). Dot On 2/27/07, Sebastian Rahtz wrote: > Who would like to step up to the plate > and pick one of the plum jobs from the list? > > The task is nothing less than to design the > layout of the Guidelines. The first requirement > is to do the web version, then look at print > if it is going well. > > The input is XHTML coming an XSLT > transform of P5; you can change that XSLT too, > but the first task is probably just to > take over the CSS and make better-looking pages. > > Obviously whoever takes this on has to be prepared > to defend the results to a sceptical Council, > so a certain amount of hard-heartedness is required. > You also have to be prepared to work through > the nitty grit of what information is in an ODD > and how best to present it. > > Only one caveat - the result cannot just be a lovely > HTML page, with an instruction saying "go make > it look like that". Finished product required. > > Go on, someone on the Council wants this task. > Step forward and claim it! > > -- > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Feb 27 19:30:55 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 28 Feb 2007 08:30:55 +0800 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4416B.70500@oucs.ox.ac.uk> References: <45E4416B.70500@oucs.ox.ac.uk> Message-ID: <45E4CD3F.9050305@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > Sebastian and I were actioned to determine what to do about the > formatting problems in generating HTML from the newly vanilla-div > structured P5 whilst in Lithuania. > > We discussed the following options: > > 0. Top level divs are numbered I to VIII; second level divs are numbered > 1 to 39. what is currently the first chapter of part II (numbered 4) > remains numbered 4. > > 1. Combine top and subsequent level divs: what is currently the first > chapter of part II (numbered 4) becomes II.1 > > 2. Forget about the part numbers: what is currently the first chapter of > part II (numbered 4) remains numbered 4. If I understand this correctly, this just means that we get a sequential numbering of chapters? This seems to be exactly what was up as P5 HTML up to now. On http://www.tei-c.org/release/doc/tei-p5-doc/html/ for example, there are no part numbers, at least not at some visible place, i.e. in the left sidebar. This seems to be the least intrusive option to me, so you have my support for it. > We concluded: > > We will begin by adopting option 2 above. This is by far the simplest > solution if we want to get out reasonable looking and accessible HTML in > the near future. It also leaves room for us to group and regroup > chapters without major upheaval. > > The downside is that those who have got accustomed to thinking of > chapter CH as chapter 4 will have to get reprogrammed. But they have > quite a lot of reprogramming to endure anyway. This does not seems to be a conclusion of Option 2, but rather of the further action you proposed. Since that is not spelled out here, I take it that you will present your plans on this in more details later. Christian From daniel.odonnell at uleth.ca Wed Feb 28 01:48:58 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 27 Feb 2007 23:48:58 -0700 Subject: [tei-council] P5 internal structure In-Reply-To: <45E46CEC.6000203@kcl.ac.uk> References: <45E4416B.70500@oucs.ox.ac.uk> <45E46CEC.6000203@kcl.ac.uk> Message-ID: <1172645339.11179.28.camel@localhost> I'm in favour of option 2 as well, but agree with Christian that in principle it doesn't seem to me to involve massive changes from the current output as it is visible to the user unless we start messing with the order of the chapters as well... which seems to me to be a different issue. The immediate question for the milestone is the part vs./+ chapter division, not the order of the chapters IMO. Once we know the level issue, the HTML/PDF output teams can start work on the stylesheets and design, regardless of the editorial order (which seems to me to be an editorial issue). -d On Tue, 2007-02-27 at 17:39 +0000, Arianna Ciula wrote: > It is a pity to loose the old chapters references, but if the overall > HTML structure can benefit and be improved the modifications are more > than welcome. > > Arianna > > Lou Burnard wrote: > > Sebastian and I were actioned to determine what to do about the > > formatting problems in generating HTML from the newly vanilla-div > > structured P5 whilst in Lithuania. > > > > We discussed the following options: > > > > 0. Top level divs are numbered I to VIII; second level divs are numbered > > 1 to 39. what is currently the first chapter of part II (numbered 4) > > remains numbered 4. > > > > 1. Combine top and subsequent level divs: what is currently the first > > chapter of part II (numbered 4) becomes II.1 > > > > 2. Forget about the part numbers: what is currently the first chapter of > > part II (numbered 4) remains numbered 4. > > > > 3. Special case the first chapter in each part so that it does something > > magical to produce an extra blank page, possibly with an extra heading > > or something. > > > > We observed that: > > > > (a) the current structure is in need of overhaul -- some of the chapters > > are very small and others very large; some closely related material > > (e.g. CH and WD) is widely separated; the distinction between "core" and > > "additional" tagsets is defunct. > > > > (b) the chapters that define modules should probably be separated from > > those which don't, both by numbering and form of title. Some of the > > current introductory material could move into the ; some of the > > current "technical material" could move into the . > > > > We concluded: > > > > We will begin by adopting option 2 above. This is by far the simplest > > solution if we want to get out reasonable looking and accessible HTML in > > the near future. It also leaves room for us to group and regroup > > chapters without major upheaval. > > > > The downside is that those who have got accustomed to thinking of > > chapter CH as chapter 4 will have to get reprogrammed. But they have > > quite a lot of reprogramming to endure anyway. > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From daniel.odonnell at uleth.ca Wed Feb 28 01:54:41 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 27 Feb 2007 23:54:41 -0700 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> References: <45E49713.9040501@oucs.ox.ac.uk> <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> Message-ID: <1172645681.11179.35.camel@localhost> I wonder if this might not need more than just two people: there are a number of issues here: information design, layout, output formats (HTML +/or PDF), stylesheet design, etc., etc., etc. It seems to me that this might profitably be seen as a group of people working under a lead who take complete ownership of the problem and deliver by the milestone. There are other groups/deadlines coming. You can see them at the Trac site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap If Dot and James want to lead this that would be superb. But perhaps we could put together a larger workgroup? -dan On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote: > Hi Council, > > James and I volunteer for this task. We feel that we'll be more > effective working together than either of us would be separately (that > and James still need to finish up an initial draft of Conformance). > > Dot > > On 2/27/07, Sebastian Rahtz wrote: > > Who would like to step up to the plate > > and pick one of the plum jobs from the list? > > > > The task is nothing less than to design the > > layout of the Guidelines. The first requirement > > is to do the web version, then look at print > > if it is going well. > > > > The input is XHTML coming an XSLT > > transform of P5; you can change that XSLT too, > > but the first task is probably just to > > take over the CSS and make better-looking pages. > > > > Obviously whoever takes this on has to be prepared > > to defend the results to a sceptical Council, > > so a certain amount of hard-heartedness is required. > > You also have to be prepared to work through > > the nitty grit of what information is in an ODD > > and how best to present it. > > > > Only one caveat - the result cannot just be a lovely > > HTML page, with an instruction saying "go make > > it look like that". Finished product required. > > > > Go on, someone on the Council wants this task. > > Step forward and claim it! > > > > -- > > Sebastian Rahtz > > > > Information Manager, Oxford University Computing Services > > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > > > OSS Watch: JISC Open Source Advisory Service > > http://www.oss-watch.ac.uk > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From James.Cummings at computing-services.oxford.ac.uk Wed Feb 28 03:01:01 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 28 Feb 2007 08:01:01 +0000 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <1172645681.11179.35.camel@localhost> References: <45E49713.9040501@oucs.ox.ac.uk> <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> <1172645681.11179.35.camel@localhost> Message-ID: <45E536BD.1050801@computing-services.oxford.ac.uk> Daniel O'Donnell wrote: > I wonder if this might not need more than just two people: there are a > number of issues here: information design, layout, output formats (HTML > +/or PDF), stylesheet design, etc., etc., etc. > > It seems to me that this might profitably be seen as a group of people > working under a lead who take complete ownership of the problem and > deliver by the milestone. > > There are other groups/deadlines coming. You can see them at the Trac > site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap > > If Dot and James want to lead this that would be superb. But perhaps we > could put together a larger workgroup? I think that this already is the case in some ways. The council as a whole is the larger workgroup. If Dot and I work in a focused fashion to produce something and then report back to Council, for opinions, etc., then revise what we've produced with those suggestions in mind, then that has the same effect in many ways. Rather than splintering the task amongst a larger number of people, I wanted to keep it fairly tightly-knit. As you say there are lots of other milestones that need working on, and if Dot and I take away this one, then some of the other council members can work on the more important ones! But of course we're happy to do this however council feels, or let someone else do it if there are other volunteers, etc. -James > > -dan > On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote: >> Hi Council, >> >> James and I volunteer for this task. We feel that we'll be more >> effective working together than either of us would be separately (that >> and James still need to finish up an initial draft of Conformance). >> >> Dot >> >> On 2/27/07, Sebastian Rahtz wrote: >>> Who would like to step up to the plate >>> and pick one of the plum jobs from the list? >>> >>> The task is nothing less than to design the >>> layout of the Guidelines. The first requirement >>> is to do the web version, then look at print >>> if it is going well. >>> >>> The input is XHTML coming an XSLT >>> transform of P5; you can change that XSLT too, >>> but the first task is probably just to >>> take over the CSS and make better-looking pages. >>> >>> Obviously whoever takes this on has to be prepared >>> to defend the results to a sceptical Council, >>> so a certain amount of hard-heartedness is required. >>> You also have to be prepared to work through >>> the nitty grit of what information is in an ODD >>> and how best to present it. >>> >>> Only one caveat - the result cannot just be a lovely >>> HTML page, with an instruction saying "go make >>> it look like that". Finished product required. >>> >>> Go on, someone on the Council wants this task. >>> Step forward and claim it! >>> >>> -- >>> Sebastian Rahtz >>> >>> Information Manager, Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> OSS Watch: JISC Open Source Advisory Service >>> http://www.oss-watch.ac.uk >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 28 06:02:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Feb 2007 11:02:58 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <1172645339.11179.28.camel@localhost> References: <45E4416B.70500@oucs.ox.ac.uk> <45E46CEC.6000203@kcl.ac.uk> <1172645339.11179.28.camel@localhost> Message-ID: <45E56162.30901@oucs.ox.ac.uk> Daniel O'Donnell wrote: > I'm in favour of option 2 as well, but agree with Christian that in > principle it doesn't seem to me to involve massive changes from the > current output as it is visible to the user unless we start messing with > the order of the chapters as well... which seems to me to be a different > issue. > I think it is almost inconceivable that the list of chapters will remain the same as it is today, and very likely the order will change too. It only takes 5 minutes staring at the current TOC to see it can be bettered.... > The immediate question for the milestone is the part vs./+ chapter > division I have not yet heard a dissenting voice which wants to keep the "Part" structure. anyway, whatever happens, the chapter is the main unit, for design purposes. Sebastian From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 28 06:04:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Feb 2007 11:04:19 +0000 Subject: [tei-council] P5 internal structure In-Reply-To: <45E4CD3F.9050305@kanji.zinbun.kyoto-u.ac.jp> References: <45E4416B.70500@oucs.ox.ac.uk> <45E4CD3F.9050305@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45E561B3.60407@oucs.ox.ac.uk> Christian Wittern wrote: > > This does not seems to be a conclusion of Option 2, but rather of the > further action you proposed. Since that is not spelled out here, I > take it that you will present your plans on this in more details later. since we have already deleted chapters, it is foregone conclusion that chapter numbering will not be the same as P4... Sebasstian From daniel.odonnell at uleth.ca Wed Feb 28 14:45:46 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 28 Feb 2007 12:45:46 -0700 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E536BD.1050801@computing-services.oxford.ac.uk> References: <45E49713.9040501@oucs.ox.ac.uk> <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> <1172645681.11179.35.camel@localhost> <45E536BD.1050801@computing-services.oxford.ac.uk> Message-ID: <1172691946.12701.27.camel@odonned-eng06> Sounds fine. If I've learned anything it's not to get between tasks and volunteers ;) -dan On Wed, 2007-28-02 at 08:01 +0000, James Cummings wrote: > Daniel O'Donnell wrote: > > I wonder if this might not need more than just two people: there are a > > number of issues here: information design, layout, output formats (HTML > > +/or PDF), stylesheet design, etc., etc., etc. > > > > It seems to me that this might profitably be seen as a group of people > > working under a lead who take complete ownership of the problem and > > deliver by the milestone. > > > > There are other groups/deadlines coming. You can see them at the Trac > > site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap > > > > If Dot and James want to lead this that would be superb. But perhaps we > > could put together a larger workgroup? > > I think that this already is the case in some ways. The council as a whole is > the larger workgroup. If Dot and I work in a focused fashion to produce > something and then report back to Council, for opinions, etc., then revise what > we've produced with those suggestions in mind, then that has the same effect in > many ways. Rather than splintering the task amongst a larger number of people, > I wanted to keep it fairly tightly-knit. As you say there are lots of other > milestones that need working on, and if Dot and I take away this one, then some > of the other council members can work on the more important ones! But of course > we're happy to do this however council feels, or let someone else do it if there > are other volunteers, etc. > > -James > > > > > > -dan > > On Tue, 2007-02-27 at 16:47 -0500, Dot Porter wrote: > >> Hi Council, > >> > >> James and I volunteer for this task. We feel that we'll be more > >> effective working together than either of us would be separately (that > >> and James still need to finish up an initial draft of Conformance). > >> > >> Dot > >> > >> On 2/27/07, Sebastian Rahtz wrote: > >>> Who would like to step up to the plate > >>> and pick one of the plum jobs from the list? > >>> > >>> The task is nothing less than to design the > >>> layout of the Guidelines. The first requirement > >>> is to do the web version, then look at print > >>> if it is going well. > >>> > >>> The input is XHTML coming an XSLT > >>> transform of P5; you can change that XSLT too, > >>> but the first task is probably just to > >>> take over the CSS and make better-looking pages. > >>> > >>> Obviously whoever takes this on has to be prepared > >>> to defend the results to a sceptical Council, > >>> so a certain amount of hard-heartedness is required. > >>> You also have to be prepared to work through > >>> the nitty grit of what information is in an ODD > >>> and how best to present it. > >>> > >>> Only one caveat - the result cannot just be a lovely > >>> HTML page, with an instruction saying "go make > >>> it look like that". Finished product required. > >>> > >>> Go on, someone on the Council wants this task. > >>> Step forward and claim it! > >>> > >>> -- > >>> Sebastian Rahtz > >>> > >>> Information Manager, Oxford University Computing Services > >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > >>> > >>> OSS Watch: JISC Open Source Advisory Service > >>> http://www.oss-watch.ac.uk > >>> > >>> _______________________________________________ > >>> tei-council mailing list > >>> tei-council at lists.village.Virginia.EDU > >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > >>> > >> > > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Feb 28 19:41:18 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 01 Mar 2007 08:41:18 +0800 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E536BD.1050801@computing-services.oxford.ac.uk> References: <45E49713.9040501@oucs.ox.ac.uk> <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> <1172645681.11179.35.camel@localhost> <45E536BD.1050801@computing-services.oxford.ac.uk> Message-ID: <45E6212E.5090907@kanji.zinbun.kyoto-u.ac.jp> James Cummings wrote: > Daniel O'Donnell wrote: >> I wonder if this might not need more than just two people: there are a >> number of issues here: information design, layout, output formats (HTML >> +/or PDF), stylesheet design, etc., etc., etc. >> >> It seems to me that this might profitably be seen as a group of people >> working under a lead who take complete ownership of the problem and >> deliver by the milestone. >> >> There are other groups/deadlines coming. You can see them at the Trac >> site: http://tei.oucs.ox.ac.uk/trac.cgi/roadmap >> >> If Dot and James want to lead this that would be superb. But perhaps we >> could put together a larger workgroup? > > I think that this already is the case in some ways. The council as a > whole is the larger workgroup. If Dot and I work in a focused fashion > to produce something and then report back to Council, for opinions, > etc., then revise what we've produced with those suggestions in mind, > then that has the same effect in many ways. Rather than splintering the > task amongst a larger number of people, I wanted to keep it fairly > tightly-knit. As you say there are lots of other milestones that need > working on, and if Dot and I take away this one, then some of the other > council members can work on the more important ones! But of course > we're happy to do this however council feels, or let someone else do it > if there are other volunteers, etc. Well said. Now, the next step would be to go to trac http://tei.oucs.ox.ac.uk/trac.cgi/ and take ownership of the relevant tickets. At this point, "Milestone Decide on final output format (especially for reference section)" looks like the right one to me, but you might check that with Sebastian. If you have a more detailed plan of the issues involved, and the way you want to proceed, we would appreciate if you also tell trac about it and let us see it. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From James.Cummings at computing-services.oxford.ac.uk Thu Mar 1 04:18:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 01 Mar 2007 09:18:48 +0000 Subject: [tei-council] a chance in a million for a lucky Council member In-Reply-To: <45E6212E.5090907@kanji.zinbun.kyoto-u.ac.jp> References: <45E49713.9040501@oucs.ox.ac.uk> <96f3df640702271347od8d0b67k73bbf757355e2d7f@mail.gmail.com> <1172645681.11179.35.camel@localhost> <45E536BD.1050801@computing-services.oxford.ac.uk> <45E6212E.5090907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45E69A78.3060209@computing-services.oxford.ac.uk> Christian Wittern wrote: > Now, the next step would be to go to trac > http://tei.oucs.ox.ac.uk/trac.cgi/ and take ownership of the relevant > tickets. > At this point, > "Milestone Decide on final output format (especially for reference > section)" looks like the right one to me, but you might check that with > Sebastian. If you have a more detailed plan of the issues involved, > and the way you want to proceed, we would appreciate if you also tell > trac about it and let us see it. I've reassigned that one to me for now. No detailed plan of attack yet. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 05:59:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 10:59:16 +0000 Subject: [tei-council] release 0.6 looming Message-ID: <45E6B204.8040008@oucs.ox.ac.uk> I'd like to make a new release of P5 in a couple of weeks. If anyone feels this would be a bad idea, or is desparate to finish something off to get it in now, please speak now. Sebastian From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 07:30:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 12:30:32 +0000 Subject: [tei-council] work for March Message-ID: <45E6C768.1080400@oucs.ox.ac.uk> Happy St David's Day. Looking at the plan of work scheduled for March, it goes as follows: * (end of tasks relating to feature requests, 12 hours to go) * design output format (JC and DP now on case) * review datatype and class decisions * proofread text looking for DTD and P4 language the latter two involve taking each chapter, looking for problems and ideally dealing with them. In most cases it will just a matter of someone signing off a chapter as having a clean bill of health. If something comes out which cannot be dealt with in (say) an hours work rewriting a paragraph, or making a simple decision about a datatype, then it should be broken out to a new task which can assigned its own deadline and so on. I think its "adopt a chapter" day again. Sebastian From Syd_Bauman at Brown.edu Thu Mar 1 15:51:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 15:51:57 -0500 Subject: [tei-council] data.multipleEnumerated Message-ID: <17895.15597.17871.698362@emt.wwp.brown.edu> Sebastian -- Is there any chance of implementing a repeatable enumeration? This would be a change to ODD such that there is some mechanism (e.g., a 'repeatable="yes"' attribute on ) to define an enumeration of possible attribute values which could be repeated, i.e. instead of boiling down to ( "list" | "of" | "valItem" | "idents" ) would boil down to list { ( "list" | "of" | "valItem" | "idents")+ } This would permit one or more of the listed values to be specified (with repetition possible), but still flag as invalid any value not in the list. Thus, given the above declarations the values "idents" "valItem idents" "of list of idents" are valid, but "valitem" "List of" "1724" are not. This mechanism would be very useful in the declaration of several attributes. E.g., type= of , which currently has a fragment of Relax NG in the , could be re-written declaratively: Although TEI would not use it for vanilla P5, one could well imagine users creating ODDs for their projects taking advantage of this mechanism for their local constraint of rend=: italics boldface small caps larger than surrounding text smaller than surrounding text Council -- Is there any reason to avoid doing so? From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 16:14:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 21:14:22 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.15597.17871.698362@emt.wwp.brown.edu> References: <17895.15597.17871.698362@emt.wwp.brown.edu> Message-ID: <45E7422E.1080304@oucs.ox.ac.uk> Syd Bauman wrote: > Is there any chance of implementing a repeatable enumeration? > from my point of view, no real problem (though surely repeatable='true' not repeatable='yes'?) > would boil down to > > list { ( "list" | "of" | "valItem" | "idents")+ } > though I note that this _isnt_ the implementation you use in the example. Have you experimented to see what happens when you run trang on such an RNG to make an XSD? Does XSD support the idea? Why don't you send me a self-contained .odd using the feature, and we can see what happens. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Thu Mar 1 16:41:33 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 16:41:33 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E7422E.1080304@oucs.ox.ac.uk> References: <17895.15597.17871.698362@emt.wwp.brown.edu> <45E7422E.1080304@oucs.ox.ac.uk> Message-ID: <17895.18573.501993.355439@emt.wwp.brown.edu> > from my point of view, no real problem (though surely repeatable='true' not > repeatable='yes'?) Sure. I don't care. Whatever data.truthValue uses. > > would boil down to > > list { ( "list" | "of" | "valItem" | "idents")+ } > though I note that this _isnt_ the implementation > you use in the example. It isn't? (I thought the example did not provide an implementation, just a fragment of ODD; the current element specification does exactly this with a fragment of Relax NG, I thought.) > Have you experimented to see what happens when you run trang on > such an RNG to make an XSD? Does XSD support the idea? No, and I don't know. > Why don't you send me a self-contained .odd > using the feature, and we can see what happens. Just to double-check that I understand what you mean -- you want an ODD file that pretends repeatable="true" is available? From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 1 17:00:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 01 Mar 2007 22:00:24 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.18573.501993.355439@emt.wwp.brown.edu> References: <17895.15597.17871.698362@emt.wwp.brown.edu> <45E7422E.1080304@oucs.ox.ac.uk> <17895.18573.501993.355439@emt.wwp.brown.edu> Message-ID: <45E74CF8.80709@oucs.ox.ac.uk> Syd Bauman wrote: >> though I note that this _isnt_ the implementation >> you use in the example. >> > > It isn't? (I thought the example did not provide an > implementation, just a fragment of ODD; the current element > specification does exactly this with a fragment of Relax NG, I > thought.) > I may be misunderstanding. You want me to generate RELAXNG comparable to that in ? I vaguely thought you want a relaxng-specific lists of lists. > Just to double-check that I understand what you mean -- you want an > ODD file that pretends repeatable="true" is available? > yes, and a test file so that we can see if it fires. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Thu Mar 1 21:33:00 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 1 Mar 2007 21:33:00 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E74CF8.80709@oucs.ox.ac.uk> References: <17895.15597.17871.698362@emt.wwp.brown.edu> <45E7422E.1080304@oucs.ox.ac.uk> <17895.18573.501993.355439@emt.wwp.brown.edu> <45E74CF8.80709@oucs.ox.ac.uk> Message-ID: <17895.36060.877962.886648@emt.wwp.brown.edu> > I may be misunderstanding. You want me to generate RELAXNG > comparable to that in ? I vaguely thought you want a > relaxng-specific lists of lists. I don't know if it's Relax NG specific or not, but it's a list of alternate values (repeatable), not a list of lists. Yes, I think it is exactly like what has. > > Just to double-check that I understand what you mean -- you want an > > ODD file that pretends repeatable="true" is available? > > > yes, and a test file so that we can see if it fires. OK. The file http://bauman.zapto.org/~syd/temp/multipleEnumerated.tgz contains: multipleEnumerated/tei_rep_enu.odd: ODD file with repeatable="true" on type= of multipleEnumerated/tei_rep_enu.xml XML instance that should be valid against schemas generated from the above ODD *except* for those elements that have "invalid" in their type= values. Plus the following two schemas, which were generated from command-line roma[1] without repeatable="true" and then tweaked by hand to do the right thing: multipleEnumerated/tei_rep_enu.rnc multipleEnumerated/tei_rep_enu.rng Note ---- [1] When I tried to use web-Roma to generate output schemas by uploading the ODD, I got Fatal error: Call to a member function hasChildNodes() on a non-object in /usr/share/tei-roma/roma/romadom.php on line 1851 as soon as I clicked "Submit" on the "Set your parameters" page. From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 2 04:39:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 02 Mar 2007 09:39:45 +0000 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <17895.36060.877962.886648@emt.wwp.brown.edu> References: <17895.15597.17871.698362@emt.wwp.brown.edu> <45E7422E.1080304@oucs.ox.ac.uk> <17895.18573.501993.355439@emt.wwp.brown.edu> <45E74CF8.80709@oucs.ox.ac.uk> <17895.36060.877962.886648@emt.wwp.brown.edu> Message-ID: <45E7F0E1.3000202@oucs.ox.ac.uk> Duly implemented and minimally tested; XSD and RELAXNG give right result, DTD falls back to CDATA See new P5/Test/testmultenu.* files changes to XSL committed to Subversion. Am running full test now. Assuming no backlash or problem, Syd, you'll need to hack the ODD to add the new attribute -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Fri Mar 2 09:41:51 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 2 Mar 2007 09:41:51 -0500 Subject: [tei-council] data.multipleEnumerated In-Reply-To: <45E7F0E1.3000202@oucs.ox.ac.uk> References: <17895.15597.17871.698362@emt.wwp.brown.edu> <45E7422E.1080304@oucs.ox.ac.uk> <17895.18573.501993.355439@emt.wwp.brown.edu> <45E74CF8.80709@oucs.ox.ac.uk> <17895.36060.877962.886648@emt.wwp.brown.edu> <45E7F0E1.3000202@oucs.ox.ac.uk> Message-ID: <17896.14255.131808.963811@emt.wwp.brown.edu> > Duly implemented and minimally tested; XSD and RELAXNG give right > result, DTD falls back to CDATA > See new P5/Test/testmultenu.* files > changes to XSL committed to Subversion. > Am running full test now. Excellent, thank you Sebastian. So if anyone has any objection to this, the time to speak up is NOW. I'm running `make dist` in Stylesheets now, will test shortly. > Assuming no backlash or problem, Syd, you'll need to hack the > ODD to add the new attribute OK. From arianna.ciula at kcl.ac.uk Mon Mar 5 07:51:33 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 05 Mar 2007 12:51:33 +0000 Subject: [tei-council] Digital Diplomatics conference Message-ID: <45EC1255.1060303@kcl.ac.uk> Dear council, For whom is interested, I just wanted to report briefly on the conference I came back from on Saturday: Digital Diplomatics http://www.cei.uni-muenchen.de/DigDipl07/index_en.html The international attendance was quite good with a majority of Germans of course. The majority of presented projects deal with a combination of relational database and use of XML (lots of TEI!). Few things to mention as far as TEI regards: Interesting presentations - good work done by two Italian students using TEI P5 (poster: Viviana Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza del 1264) - presentation of ODD by Gautier Poupeau - integration TEI-CIDOC presented by Christian-Emil Ore TEI/CEI As you may know already, the objective of the conference was to give a glimpse on digital projects related to medieval documents (it succeeded on this) and to work on the improvements of the CEI (Charter Encoding Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) standard to encode these documents in XML. Unfortunately, despite the good work of synthesis and conceptual modelling done by Patrick Sahle and Gautier Poupeau, we didn't go very far on the latter, but it seems to me that - despite some more or less funded complains on the inability of TEI to represented the archival community and its objectives, all the CEI recommendations as they stand could easily been translated and/or represented in TEI P5 - I will keep an eye on how the community is going to develop the standard and see what comes up Happy to give more details to whom is interested. All the best, Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Mon Mar 5 13:03:58 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 05 Mar 2007 11:03:58 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45EC1255.1060303@kcl.ac.uk> References: <45EC1255.1060303@kcl.ac.uk> Message-ID: <1173117838.11758.7.camel@odonned-eng06> Thank you very much for this, Arianna. These kind of reports are always very interesting. -dan On Mon, 2007-05-03 at 12:51 +0000, Arianna Ciula wrote: > Dear council, > > For whom is interested, I just wanted to report briefly on the > conference I came back from on Saturday: Digital Diplomatics > http://www.cei.uni-muenchen.de/DigDipl07/index_en.html > > The international attendance was quite good with a majority of Germans > of course. > > The majority of presented projects deal with a combination of relational > database and use of XML (lots of TEI!). > > Few things to mention as far as TEI regards: > > Interesting presentations > - good work done by two Italian students using TEI P5 (poster: Viviana > Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza > del 1264) > - presentation of ODD by Gautier Poupeau > - integration TEI-CIDOC presented by Christian-Emil Ore > > TEI/CEI > As you may know already, the objective of the conference was to give a > glimpse on digital projects related to medieval documents (it succeeded > on this) and to work on the improvements of the CEI (Charter Encoding > Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) > standard to encode these documents in XML. Unfortunately, despite the > good work of synthesis and conceptual modelling done by Patrick Sahle > and Gautier Poupeau, we didn't go very far on the latter, but it seems > to me that > - despite some more or less funded complains on the inability of TEI to > represented the archival community and its objectives, all the CEI > recommendations as they stand could easily been translated and/or > represented in TEI P5 > - I will keep an eye on how the community is going to develop the > standard and see what comes up > > Happy to give more details to whom is interested. > All the best, > > Arianna -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Mon Mar 5 18:03:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 05 Mar 2007 23:03:35 +0000 Subject: [tei-council] SFFR 1007370 Theorem Message-ID: <45ECA1C7.9080000@computing-services.oxford.ac.uk> I believe I have already asked for input from Council about this item. On the one hand, I think the proposal has some interesting merits. On the other, I am not sure that the proposal is sufficiently mature and worked out to be easily integrated into P5 1.0 -- which means that I need guidance from the Council as to whether or not it should be prioritized above (say) floating texts, ms abbreviations/expansions, or the generic place element. Unless I hear otherwise within the next 48 hours therefore, I will close this ticket off with a note to the effect that it's scheduled for consideration at release 1.1 but not before. From dporter at uky.edu Mon Mar 5 18:42:41 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 5 Mar 2007 15:42:41 -0800 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45EC1255.1060303@kcl.ac.uk> References: <45EC1255.1060303@kcl.ac.uk> Message-ID: <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> Hi Arianna, At the TEI member's meeting, you and I and a few other people were talking about reviving the Transcription SIG, which seems to have faded a way for a while. Are you interested? The CEI might be a good point to start off on - will you be at the DH conference this summer? Dot On 3/5/07, Arianna Ciula wrote: > Dear council, > > For whom is interested, I just wanted to report briefly on the > conference I came back from on Saturday: Digital Diplomatics > http://www.cei.uni-muenchen.de/DigDipl07/index_en.html > > The international attendance was quite good with a majority of Germans > of course. > > The majority of presented projects deal with a combination of relational > database and use of XML (lots of TEI!). > > Few things to mention as far as TEI regards: > > Interesting presentations > - good work done by two Italian students using TEI P5 (poster: Viviana > Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza > del 1264) > - presentation of ODD by Gautier Poupeau > - integration TEI-CIDOC presented by Christian-Emil Ore > > TEI/CEI > As you may know already, the objective of the conference was to give a > glimpse on digital projects related to medieval documents (it succeeded > on this) and to work on the improvements of the CEI (Charter Encoding > Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) > standard to encode these documents in XML. Unfortunately, despite the > good work of synthesis and conceptual modelling done by Patrick Sahle > and Gautier Poupeau, we didn't go very far on the latter, but it seems > to me that > - despite some more or less funded complains on the inability of TEI to > represented the archival community and its objectives, all the CEI > recommendations as they stand could easily been translated and/or > represented in TEI P5 > - I will keep an eye on how the community is going to develop the > standard and see what comes up > > Happy to give more details to whom is interested. > All the best, > > Arianna > -- > Dr Arianna Ciula > Research Associate > Centre for Computing in the Humanities > King's College London > Strand > London WC2R 2LS (UK) > Tel: +44 (0)20 78481945 > http://www.kcl.ac.uk/cch > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Mar 6 02:33:43 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 06 Mar 2007 15:33:43 +0800 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ECA1C7.9080000@computing-services.oxford.ac.uk> References: <45ECA1C7.9080000@computing-services.oxford.ac.uk> Message-ID: <45ED1957.501@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > I believe I have already asked for input from Council about this item. > On the one hand, I think the proposal has some interesting merits. On > the other, I am not sure that the proposal is sufficiently mature and > worked out to be easily integrated into P5 1.0 -- which means that I > need guidance from the Council as to whether or not it should be > prioritized above (say) floating texts, ms abbreviations/expansions, or > the generic place element. in my book, theorem would come after the above mentioned in terms of priority. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 6 04:37:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 6 Mar 2007 09:37:29 +0000 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ECA1C7.9080000@computing-services.oxford.ac.uk> References: <45ECA1C7.9080000@computing-services.oxford.ac.uk> Message-ID: <20070306093729.GD31263@raven.linux.ox.ac.uk> > worked out to be easily integrated into P5 1.0 -- which means that I > need guidance from the Council as to whether or not it should be > prioritized above (say) floating texts, ms abbreviations/expansions, or > the generic place element. no contest. put theorem on the backburner Sebastian From arianna.ciula at kcl.ac.uk Tue Mar 6 04:57:28 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 06 Mar 2007 09:57:28 +0000 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> References: <45EC1255.1060303@kcl.ac.uk> <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> Message-ID: <45ED3B08.8090107@kcl.ac.uk> Hi Dot, I remember talking about the Manuscript SIG. Is this what you mean by Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about the former and I gave a sort of availability in case nobody was prepared to chair it. Should we discuss this out of list with Roberto as well and see what we could do and report back? Arianna Dot Porter wrote: > Hi Arianna, > > At the TEI member's meeting, you and I and a few other people were > talking about reviving the Transcription SIG, which seems to have > faded a way for a while. Are you interested? The CEI might be a good > point to start off on - will you be at the DH conference this summer? > > Dot > > On 3/5/07, Arianna Ciula wrote: >> Dear council, >> >> For whom is interested, I just wanted to report briefly on the >> conference I came back from on Saturday: Digital Diplomatics >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html >> >> The international attendance was quite good with a majority of Germans >> of course. >> >> The majority of presented projects deal with a combination of relational >> database and use of XML (lots of TEI!). >> >> Few things to mention as far as TEI regards: >> >> Interesting presentations >> - good work done by two Italian students using TEI P5 (poster: Viviana >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza >> del 1264) >> - presentation of ODD by Gautier Poupeau >> - integration TEI-CIDOC presented by Christian-Emil Ore >> >> TEI/CEI >> As you may know already, the objective of the conference was to give a >> glimpse on digital projects related to medieval documents (it succeeded >> on this) and to work on the improvements of the CEI (Charter Encoding >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) >> standard to encode these documents in XML. Unfortunately, despite the >> good work of synthesis and conceptual modelling done by Patrick Sahle >> and Gautier Poupeau, we didn't go very far on the latter, but it seems >> to me that >> - despite some more or less funded complains on the inability of TEI to >> represented the archival community and its objectives, all the CEI >> recommendations as they stand could easily been translated and/or >> represented in TEI P5 >> - I will keep an eye on how the community is going to develop the >> standard and see what comes up >> >> Happy to give more details to whom is interested. >> All the best, >> >> Arianna >> -- >> Dr Arianna Ciula >> Research Associate >> Centre for Computing in the Humanities >> King's College London >> Strand >> London WC2R 2LS (UK) >> Tel: +44 (0)20 78481945 >> http://www.kcl.ac.uk/cch >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From James.Cummings at computing-services.oxford.ac.uk Tue Mar 6 05:19:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 06 Mar 2007 10:19:21 +0000 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <20070306093729.GD31263@raven.linux.ox.ac.uk> References: <45ECA1C7.9080000@computing-services.oxford.ac.uk> <20070306093729.GD31263@raven.linux.ox.ac.uk> Message-ID: <45ED4029.7000403@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: >> worked out to be easily integrated into P5 1.0 -- which means that I >> need guidance from the Council as to whether or not it should be >> prioritized above (say) floating texts, ms abbreviations/expansions, or >> the generic place element. > > no contest. put theorem on the backburner Ditto what Sebastian and Christian said. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From dporter at uky.edu Tue Mar 6 06:06:13 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 6 Mar 2007 03:06:13 -0800 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <45ED3B08.8090107@kcl.ac.uk> References: <45EC1255.1060303@kcl.ac.uk> <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> <45ED3B08.8090107@kcl.ac.uk> Message-ID: <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> Hi Arianna, Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my "TEI Chapter on Transcription of Primary Sources"). Any objections if Arianna and I take our discussion off-list? Any other takers? Dot On 3/6/07, Arianna Ciula wrote: > Hi Dot, > > I remember talking about the Manuscript SIG. Is this what you mean by > Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about > the former and I gave a sort of availability in case nobody was prepared > to chair it. > > Should we discuss this out of list with Roberto as well and see what we > could do and report back? > > Arianna > > Dot Porter wrote: > > Hi Arianna, > > > > At the TEI member's meeting, you and I and a few other people were > > talking about reviving the Transcription SIG, which seems to have > > faded a way for a while. Are you interested? The CEI might be a good > > point to start off on - will you be at the DH conference this summer? > > > > Dot > > > > On 3/5/07, Arianna Ciula wrote: > >> Dear council, > >> > >> For whom is interested, I just wanted to report briefly on the > >> conference I came back from on Saturday: Digital Diplomatics > >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html > >> > >> The international attendance was quite good with a majority of Germans > >> of course. > >> > >> The majority of presented projects deal with a combination of relational > >> database and use of XML (lots of TEI!). > >> > >> Few things to mention as far as TEI regards: > >> > >> Interesting presentations > >> - good work done by two Italian students using TEI P5 (poster: Viviana > >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza > >> del 1264) > >> - presentation of ODD by Gautier Poupeau > >> - integration TEI-CIDOC presented by Christian-Emil Ore > >> > >> TEI/CEI > >> As you may know already, the objective of the conference was to give a > >> glimpse on digital projects related to medieval documents (it succeeded > >> on this) and to work on the improvements of the CEI (Charter Encoding > >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) > >> standard to encode these documents in XML. Unfortunately, despite the > >> good work of synthesis and conceptual modelling done by Patrick Sahle > >> and Gautier Poupeau, we didn't go very far on the latter, but it seems > >> to me that > >> - despite some more or less funded complains on the inability of TEI to > >> represented the archival community and its objectives, all the CEI > >> recommendations as they stand could easily been translated and/or > >> represented in TEI P5 > >> - I will keep an eye on how the community is going to develop the > >> standard and see what comes up > >> > >> Happy to give more details to whom is interested. > >> All the best, > >> > >> Arianna > >> -- > >> Dr Arianna Ciula > >> Research Associate > >> Centre for Computing in the Humanities > >> King's College London > >> Strand > >> London WC2R 2LS (UK) > >> Tel: +44 (0)20 78481945 > >> http://www.kcl.ac.uk/cch > >> _______________________________________________ > >> tei-council mailing list > >> tei-council at lists.village.Virginia.EDU > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > >> > > > > > > -- > Dr Arianna Ciula > Research Associate > Centre for Computing in the Humanities > King's College London > Strand > London WC2R 2LS (UK) > Tel: +44 (0)20 78481945 > http://www.kcl.ac.uk/cch > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 07:25:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 12:25:11 +0000 Subject: [tei-council] Berlin meeting Message-ID: <45EEAF27.8000402@oucs.ox.ac.uk> Two quick timetabling questions: (a) Will the Council meeting also be held in the Harnackhaus ("Zentrum des "deutschen Oxford" :-))? if not, where? (b) When do we expect that the Council meeting will end? I am mostly concerned about the latter, as I need to book train tickets soonish, either for the Friday or for the Saturday afternoon. From laurent.romary at loria.fr Wed Mar 7 07:32:34 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 7 Mar 2007 13:32:34 +0100 Subject: [tei-council] Berlin meeting In-Reply-To: <45EEAF27.8000402@oucs.ox.ac.uk> References: <45EEAF27.8000402@oucs.ox.ac.uk> Message-ID: <0F2BA1EB-05EC-402C-B1EE-2A5F1F7AD48B@loria.fr> The council meeting will take place at the BBAW, that is in the center of Berlin. I will disseminate a list of hotels soon (I have a flight in a few minutes, please be all patient until Friday...). Laurent Le 7 mars 07 ? 13:25, Lou Burnard a ?crit : > Two quick timetabling questions: > > (a) Will the Council meeting also be held in the Harnackhaus > ("Zentrum des "deutschen Oxford" :-))? if not, where? > > (b) When do we expect that the Council meeting will end? > > I am mostly concerned about the latter, as I need to book train > tickets soonish, either for the Friday or for the Saturday afternoon. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 08:00:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 13:00:12 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] Message-ID: <45EEB75C.4010608@oucs.ox.ac.uk> This response from Laurent seems to have been bounced by the server for some reason: > Dear all, > OK. I take a few extra minutes... here's a hotel list for our > meetings in Berlin. I would suggest to try to pack all issues on > Thu-Fri. > Best, > Laurent > > > Hotel > Lage > EZ-Preis > DZ-Preis > Sonstiges > Albrechtshof/Allegra*** > > Albrechtstr. 8/17 > Hotels liegen vis ? vis > U-/S-Bahn Friedrichstr. 2min, > > 15min zu Fu? zur BBAW > 95/89 EUR > > 115/105 EUR > > inkl. Fr?hst?ck > > http://www.hotel-albrechtshof.de/ > > http://www.hotel-allegra.de/ > > Angleterre**** > > Friedrichstra?e 31 > > > > U-Bhf. Kochstr. > > 12min zu Fu? zur BBAW > > 80 EUR > > 104 EUR > > inkl. Fr?hst?ck > > http://www.gold-inn.de/ > > Dietrich-Bonhoeffer-Haus*** > > Ziegelstr. 30 > > U6 Oranienburger Tor ca. 3min, > U-/S-Bahn Friedrichstr. 5min > > 75 EUR > > 115 EUR > > inkl. Fr?hst?ck > > http://www.hotel-dbh.de/ > > G?stehaus der Humboldt-Uni > > Ziegelstr. 13 a/b > U6 Oranienburger Tor ca. 3min, > U-/S-Bahn Friedrichstr. 5min > > 30 ? 35 EUR > > 60 EUR > > exkl. Fr?hst?ck > > Gendarm**** > > Charlottenstr. 60/61 > U6 Stadtmitte 2min, > > U2 Stadtmitte 3min, > 4min zu Fu? > 112 EUR > > 132 EUR > > inkl. Fr?hst?ck > > http://www.hotel-gendarm-berlin.de/ > > Mercure*** > > Sch?tzenstr. 11 > > U6 Kochstr. 4min, > > U6 Stadtmitte 5min > 82 EUR > > 112 EUR > > inkl. Fr?hst?ck > > http://www.mercure.de/ > NH-Hotel**** (ehem. Astron) > > Leipziger Str. 106-111 > U6 Stadtmitte 2min, > > U2 Stadtmitte 4min, > 8min zu Fu? > 86 EUR > > 102 EUR > > inkl. Fr?hst?ck > > http://www.nh-hotels.com/ > > Novotel*** > > Fischerinsel 12 > U2 Spittelmarkt 3min, > > 15min zu Fu? > 82 EUR > > > > 112 EUR > > > > inkl. Fr?hst?ck > > http://www.novotel.de/ > From dporter at uky.edu Wed Mar 7 08:12:44 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 7 Mar 2007 05:12:44 -0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEB75C.4010608@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> Message-ID: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> Is there interest in coordinating hotel arrangements? I not terribly keen on trying to make it around Berlin all on my lonesome :-) Dot On 3/7/07, Lou Burnard wrote: > This response from Laurent seems to have been bounced by the server for > some reason: > > > > > Dear all, > > OK. I take a few extra minutes... here's a hotel list for our > > meetings in Berlin. I would suggest to try to pack all issues on > > Thu-Fri. > > Best, > > Laurent > > > > > > Hotel > > Lage > > EZ-Preis > > DZ-Preis > > Sonstiges > > Albrechtshof/Allegra*** > > > > Albrechtstr. 8/17 > > Hotels liegen vis ? vis > > U-/S-Bahn Friedrichstr. 2min, > > > > 15min zu Fu? zur BBAW > > 95/89 EUR > > > > 115/105 EUR > > > > inkl. Fr?hst?ck > > > > http://www.hotel-albrechtshof.de/ > > > > http://www.hotel-allegra.de/ > > > > Angleterre**** > > > > Friedrichstra?e 31 > > > > > > > > U-Bhf. Kochstr. > > > > 12min zu Fu? zur BBAW > > > > 80 EUR > > > > 104 EUR > > > > inkl. Fr?hst?ck > > > > http://www.gold-inn.de/ > > > > Dietrich-Bonhoeffer-Haus*** > > > > Ziegelstr. 30 > > > > U6 Oranienburger Tor ca. 3min, > > U-/S-Bahn Friedrichstr. 5min > > > > 75 EUR > > > > 115 EUR > > > > inkl. Fr?hst?ck > > > > http://www.hotel-dbh.de/ > > > > G?stehaus der Humboldt-Uni > > > > Ziegelstr. 13 a/b > > U6 Oranienburger Tor ca. 3min, > > U-/S-Bahn Friedrichstr. 5min > > > > 30 ? 35 EUR > > > > 60 EUR > > > > exkl. Fr?hst?ck > > > > Gendarm**** > > > > Charlottenstr. 60/61 > > U6 Stadtmitte 2min, > > > > U2 Stadtmitte 3min, > > 4min zu Fu? > > 112 EUR > > > > 132 EUR > > > > inkl. Fr?hst?ck > > > > http://www.hotel-gendarm-berlin.de/ > > > > Mercure*** > > > > Sch?tzenstr. 11 > > > > U6 Kochstr. 4min, > > > > U6 Stadtmitte 5min > > 82 EUR > > > > 112 EUR > > > > inkl. Fr?hst?ck > > > > http://www.mercure.de/ > > NH-Hotel**** (ehem. Astron) > > > > Leipziger Str. 106-111 > > U6 Stadtmitte 2min, > > > > U2 Stadtmitte 4min, > > 8min zu Fu? > > 86 EUR > > > > 102 EUR > > > > inkl. Fr?hst?ck > > > > http://www.nh-hotels.com/ > > > > Novotel*** > > > > Fischerinsel 12 > > U2 Spittelmarkt 3min, > > > > 15min zu Fu? > > 82 EUR > > > > > > > > 112 EUR > > > > > > > > inkl. Fr?hst?ck > > > > http://www.novotel.de/ > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From arianna.ciula at kcl.ac.uk Wed Mar 7 08:27:00 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 07 Mar 2007 13:27:00 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> Message-ID: <45EEBDA4.4040900@kcl.ac.uk> I was going to ask the same. Arianna Dot Porter wrote: > Is there interest in coordinating hotel arrangements? I not terribly > keen on trying to make it around Berlin all on my lonesome :-) > > Dot > > On 3/7/07, Lou Burnard wrote: >> This response from Laurent seems to have been bounced by the server for >> some reason: >> >> >> >> > Dear all, >> > OK. I take a few extra minutes... here's a hotel list for our >> > meetings in Berlin. I would suggest to try to pack all issues on >> > Thu-Fri. >> > Best, >> > Laurent >> > >> > >> > Hotel >> > Lage >> > EZ-Preis >> > DZ-Preis >> > Sonstiges >> > Albrechtshof/Allegra*** >> > >> > Albrechtstr. 8/17 >> > Hotels liegen vis ? vis >> > U-/S-Bahn Friedrichstr. 2min, >> > >> > 15min zu Fu? zur BBAW >> > 95/89 EUR >> > >> > 115/105 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-albrechtshof.de/ >> > >> > http://www.hotel-allegra.de/ >> > >> > Angleterre**** >> > >> > Friedrichstra?e 31 >> > >> > >> > >> > U-Bhf. Kochstr. >> > >> > 12min zu Fu? zur BBAW >> > >> > 80 EUR >> > >> > 104 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.gold-inn.de/ >> > >> > Dietrich-Bonhoeffer-Haus*** >> > >> > Ziegelstr. 30 >> > >> > U6 Oranienburger Tor ca. 3min, >> > U-/S-Bahn Friedrichstr. 5min >> > >> > 75 EUR >> > >> > 115 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-dbh.de/ >> > >> > G?stehaus der Humboldt-Uni >> > >> > Ziegelstr. 13 a/b >> > U6 Oranienburger Tor ca. 3min, >> > U-/S-Bahn Friedrichstr. 5min >> > >> > 30 ? 35 EUR >> > >> > 60 EUR >> > >> > exkl. Fr?hst?ck >> > >> > Gendarm**** >> > >> > Charlottenstr. 60/61 >> > U6 Stadtmitte 2min, >> > >> > U2 Stadtmitte 3min, >> > 4min zu Fu? >> > 112 EUR >> > >> > 132 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-gendarm-berlin.de/ >> > >> > Mercure*** >> > >> > Sch?tzenstr. 11 >> > >> > U6 Kochstr. 4min, >> > >> > U6 Stadtmitte 5min >> > 82 EUR >> > >> > 112 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.mercure.de/ >> > NH-Hotel**** (ehem. Astron) >> > >> > Leipziger Str. 106-111 >> > U6 Stadtmitte 2min, >> > >> > U2 Stadtmitte 4min, >> > 8min zu Fu? >> > 86 EUR >> > >> > 102 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.nh-hotels.com/ >> > >> > Novotel*** >> > >> > Fischerinsel 12 >> > U2 Spittelmarkt 3min, >> > >> > 15min zu Fu? >> > 82 EUR >> > >> > >> > >> > 112 EUR >> > >> > >> > >> > inkl. Fr?hst?ck >> > >> > http://www.novotel.de/ >> > >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 08:35:24 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 13:35:24 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEBDA4.4040900@kcl.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <45EEBDA4.4040900@kcl.ac.uk> Message-ID: <45EEBF9C.20207@oucs.ox.ac.uk> I propose the http://www.hotel-albrechtshof.de/ -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From tone.bruvik at aksis.uib.no Wed Mar 7 08:58:01 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Wed, 7 Mar 2007 14:58:01 +0100 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> Message-ID: <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> A coordinating hotel arrangements would be nice, or at leased would it be nice to stay at the same hotel as some of you (nice to have company at the way back at night). I like to stay somewhere in walking distance from the meeting, but most of Laurent's suggestions seams to meet that criteria, so any suggestion on which hotel to choose would be welcome. I need to book my tickets in a few days. I guess that we have to arrive on the afternoon of April 24, but as Lou also mentioned, I need to know when the meeting will end on Friday, as I have an option to leave Friday night. Tone Merete Den 7. mar. 2007 kl. 14.12 skrev Dot Porter: > Is there interest in coordinating hotel arrangements? I not terribly > keen on trying to make it around Berlin all on my lonesome :-) > > Dot > > On 3/7/07, Lou Burnard services.oxford.ac.uk> wrote: >> This response from Laurent seems to have been bounced by the >> server for >> some reason: >> >> >> >> > Dear all, >> > OK. I take a few extra minutes... here's a hotel list for our >> > meetings in Berlin. I would suggest to try to pack all issues on >> > Thu-Fri. >> > Best, >> > Laurent >> > >> > >> > Hotel >> > Lage >> > EZ-Preis >> > DZ-Preis >> > Sonstiges >> > Albrechtshof/Allegra*** >> > >> > Albrechtstr. 8/17 >> > Hotels liegen vis ? vis >> > U-/S-Bahn Friedrichstr. 2min, >> > >> > 15min zu Fu? zur BBAW >> > 95/89 EUR >> > >> > 115/105 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-albrechtshof.de/ >> > >> > http://www.hotel-allegra.de/ >> > >> > Angleterre**** >> > >> > Friedrichstra?e 31 >> > >> > >> > >> > U-Bhf. Kochstr. >> > >> > 12min zu Fu? zur BBAW >> > >> > 80 EUR >> > >> > 104 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.gold-inn.de/ >> > >> > Dietrich-Bonhoeffer-Haus*** >> > >> > Ziegelstr. 30 >> > >> > U6 Oranienburger Tor ca. 3min, >> > U-/S-Bahn Friedrichstr. 5min >> > >> > 75 EUR >> > >> > 115 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-dbh.de/ >> > >> > G?stehaus der Humboldt-Uni >> > >> > Ziegelstr. 13 a/b >> > U6 Oranienburger Tor ca. 3min, >> > U-/S-Bahn Friedrichstr. 5min >> > >> > 30 ? 35 EUR >> > >> > 60 EUR >> > >> > exkl. Fr?hst?ck >> > >> > Gendarm**** >> > >> > Charlottenstr. 60/61 >> > U6 Stadtmitte 2min, >> > >> > U2 Stadtmitte 3min, >> > 4min zu Fu? >> > 112 EUR >> > >> > 132 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.hotel-gendarm-berlin.de/ >> > >> > Mercure*** >> > >> > Sch?tzenstr. 11 >> > >> > U6 Kochstr. 4min, >> > >> > U6 Stadtmitte 5min >> > 82 EUR >> > >> > 112 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.mercure.de/ >> > NH-Hotel**** (ehem. Astron) >> > >> > Leipziger Str. 106-111 >> > U6 Stadtmitte 2min, >> > >> > U2 Stadtmitte 4min, >> > 8min zu Fu? >> > 86 EUR >> > >> > 102 EUR >> > >> > inkl. Fr?hst?ck >> > >> > http://www.nh-hotels.com/ >> > >> > Novotel*** >> > >> > Fischerinsel 12 >> > U2 Spittelmarkt 3min, >> > >> > 15min zu Fu? >> > 82 EUR >> > >> > >> > >> > 112 EUR >> > >> > >> > >> > inkl. Fr?hst?ck >> > >> > http://www.novotel.de/ >> > >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > > -- > *************************************** > Dot Porter, University of Kentucky > ##### > Program Coordinator > Collaboratory for Research in Computing for Humanities > dporter at uky.edu 859-257-9549 > ##### > Editorial Assistant, REVEAL Project > Center for Visualization and Virtual Environments > porter at vis.uky.edu > *************************************** > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Wed Mar 7 09:03:31 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 7 Mar 2007 15:03:31 +0100 Subject: !SPAM? Re: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEBF9C.20207@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <45EEBDA4.4040900@kcl.ac.uk> <45EEBF9C.20207@oucs.ox.ac.uk> Message-ID: <457A2C60-56CC-40EE-85C6-F1D06079049E@loria.fr> Dear all, You may also interested on having a pointer to the online map of Berlin: see http://www.berlin.de/stadtplan/_html/index.html Best, Laurent Le 7 mars 07 ? 14:35, Sebastian Rahtz a ?crit : > I propose the http://www.hotel-albrechtshof.de/ > > > -- > Sebastian Rahtz Information Manager, Oxford University > Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:12:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:12:29 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> Message-ID: <45EEC84D.6020409@computing-services.oxford.ac.uk> I suggest we appoint a hotel booking workgroup, and propose Ariana and Dot as co-chairs! From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:14:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:14:09 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEC84D.6020409@computing-services.oxford.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> Message-ID: <45EEC8B1.8080705@oucs.ox.ac.uk> Lou Burnard wrote: > I suggest we appoint a hotel booking workgroup, and propose Ariana and > Dot as co-chairs! > with a rider that anything which is an international chain like Novotel is ruled out....? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:27:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:27:29 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEC8B1.8080705@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> Message-ID: <45EECBD1.7030308@oucs.ox.ac.uk> Sebastian Rahtz wrote: > Lou Burnard wrote: >> I suggest we appoint a hotel booking workgroup, and propose Ariana and >> Dot as co-chairs! >> > with a rider that anything which is an international chain like Novotel > is ruled out....? > How about international chains like Accor/Mercure etc. ? (I have a loyalty card with them) From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:29:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:29:13 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECBD1.7030308@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> Message-ID: <45EECC39.2000001@oucs.ox.ac.uk> Lou Burnard wrote: > >>> I suggest we appoint a hotel booking workgroup, and propose Ariana >>> and Dot as co-chairs! >>> >> with a rider that anything which is an international chain like >> Novotel is ruled out....? >> > > How about international chains like Accor/Mercure etc. ? (I have a > loyalty card with them) > pah. have you no shame? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From lou.burnard at computing-services.oxford.ac.uk Wed Mar 7 09:32:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 07 Mar 2007 14:32:10 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECC39.2000001@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> Message-ID: <45EECCEA.8050400@oucs.ox.ac.uk> Sebastian Rahtz wrote: > Lou Burnard wrote: >> >>>> I suggest we appoint a hotel booking workgroup, and propose Ariana >>>> and Dot as co-chairs! >>>> >>> with a rider that anything which is an international chain like >>> Novotel is ruled out....? >>> >> >> How about international chains like Accor/Mercure etc. ? (I have a >> loyalty card with them) >> > pah. have you no shame? > > They made me do it (and it got me discounted wifi). But seriously, if we are going to delegate this task, I propose we let the Hotel Booking WorkGroup decide TEI policy on the matter. My criteria are simple: easy access to the Hauptbahnhof and the Meeting Location; wifi; price. From dporter at uky.edu Wed Mar 7 09:38:02 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 7 Mar 2007 09:38:02 -0500 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECCEA.8050400@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> <45EECCEA.8050400@oucs.ox.ac.uk> Message-ID: <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> I'm happy to co-chair, I guess that's what I get for being the first to speak up :-) Dot On 3/7/07, Lou Burnard wrote: > Sebastian Rahtz wrote: > > Lou Burnard wrote: > >> > >>>> I suggest we appoint a hotel booking workgroup, and propose Ariana > >>>> and Dot as co-chairs! > >>>> > >>> with a rider that anything which is an international chain like > >>> Novotel is ruled out....? > >>> > >> > >> How about international chains like Accor/Mercure etc. ? (I have a > >> loyalty card with them) > >> > > pah. have you no shame? > > > > > > They made me do it (and it got me discounted wifi). But seriously, if we > are going to delegate this task, I propose we let the Hotel Booking > WorkGroup decide TEI policy on the matter. > > My criteria are simple: easy access to the Hauptbahnhof and the Meeting > Location; wifi; price. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 09:48:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 14:48:52 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EECCEA.8050400@oucs.ox.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> <45EECCEA.8050400@oucs.ox.ac.uk> Message-ID: <45EED0D4.2010005@oucs.ox.ac.uk> Lou Burnard wrote: > > My criteria are simple: easy access to the Hauptbahnhof and the > Meeting Location; wifi; price. and I just want somewhere cute. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From arianna.ciula at kcl.ac.uk Wed Mar 7 12:45:54 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 07 Mar 2007 17:45:54 +0000 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> <45EECCEA.8050400@oucs.ox.ac.uk> <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> Message-ID: <45EEFA52.4040000@kcl.ac.uk> I am happy to co-chair as well, but need to add another criterion: - if I need to book we have to decide before Friday, because after that I'll be on holiday for a week. Arianna Dot Porter wrote: > I'm happy to co-chair, I guess that's what I get for being the first > to speak up :-) > > Dot > > On 3/7/07, Lou Burnard wrote: >> Sebastian Rahtz wrote: >> > Lou Burnard wrote: >> >> >> >>>> I suggest we appoint a hotel booking workgroup, and propose Ariana >> >>>> and Dot as co-chairs! >> >>>> >> >>> with a rider that anything which is an international chain like >> >>> Novotel is ruled out....? >> >>> >> >> >> >> How about international chains like Accor/Mercure etc. ? (I have a >> >> loyalty card with them) >> >> >> > pah. have you no shame? >> > >> > >> >> They made me do it (and it got me discounted wifi). But seriously, if we >> are going to delegate this task, I propose we let the Hotel Booking >> WorkGroup decide TEI policy on the matter. >> >> My criteria are simple: easy access to the Hauptbahnhof and the Meeting >> Location; wifi; price. >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Wed Mar 7 13:25:44 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 11:25:44 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> References: <45EC1255.1060303@kcl.ac.uk> <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> <45ED3B08.8090107@kcl.ac.uk> <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> Message-ID: <1173291945.20729.54.camel@odonned-eng06> I'd made a couple of steps towards moving this forward. I was asked to contact Fotis Jannis about this but heard nothing back from him. I'll bug him again. -dan On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote: > Hi Arianna, > > Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my > "TEI Chapter on Transcription of Primary Sources"). Any objections if > Arianna and I take our discussion off-list? Any other takers? > > Dot > > On 3/6/07, Arianna Ciula wrote: > > Hi Dot, > > > > I remember talking about the Manuscript SIG. Is this what you mean by > > Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about > > the former and I gave a sort of availability in case nobody was prepared > > to chair it. > > > > Should we discuss this out of list with Roberto as well and see what we > > could do and report back? > > > > Arianna > > > > Dot Porter wrote: > > > Hi Arianna, > > > > > > At the TEI member's meeting, you and I and a few other people were > > > talking about reviving the Transcription SIG, which seems to have > > > faded a way for a while. Are you interested? The CEI might be a good > > > point to start off on - will you be at the DH conference this summer? > > > > > > Dot > > > > > > On 3/5/07, Arianna Ciula wrote: > > >> Dear council, > > >> > > >> For whom is interested, I just wanted to report briefly on the > > >> conference I came back from on Saturday: Digital Diplomatics > > >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html > > >> > > >> The international attendance was quite good with a majority of Germans > > >> of course. > > >> > > >> The majority of presented projects deal with a combination of relational > > >> database and use of XML (lots of TEI!). > > >> > > >> Few things to mention as far as TEI regards: > > >> > > >> Interesting presentations > > >> - good work done by two Italian students using TEI P5 (poster: Viviana > > >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza > > >> del 1264) > > >> - presentation of ODD by Gautier Poupeau > > >> - integration TEI-CIDOC presented by Christian-Emil Ore > > >> > > >> TEI/CEI > > >> As you may know already, the objective of the conference was to give a > > >> glimpse on digital projects related to medieval documents (it succeeded > > >> on this) and to work on the improvements of the CEI (Charter Encoding > > >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) > > >> standard to encode these documents in XML. Unfortunately, despite the > > >> good work of synthesis and conceptual modelling done by Patrick Sahle > > >> and Gautier Poupeau, we didn't go very far on the latter, but it seems > > >> to me that > > >> - despite some more or less funded complains on the inability of TEI to > > >> represented the archival community and its objectives, all the CEI > > >> recommendations as they stand could easily been translated and/or > > >> represented in TEI P5 > > >> - I will keep an eye on how the community is going to develop the > > >> standard and see what comes up > > >> > > >> Happy to give more details to whom is interested. > > >> All the best, > > >> > > >> Arianna > > >> -- > > >> Dr Arianna Ciula > > >> Research Associate > > >> Centre for Computing in the Humanities > > >> King's College London > > >> Strand > > >> London WC2R 2LS (UK) > > >> Tel: +44 (0)20 78481945 > > >> http://www.kcl.ac.uk/cch > > >> _______________________________________________ > > >> tei-council mailing list > > >> tei-council at lists.village.Virginia.EDU > > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > >> > > > > > > > > > > -- > > Dr Arianna Ciula > > Research Associate > > Centre for Computing in the Humanities > > King's College London > > Strand > > London WC2R 2LS (UK) > > Tel: +44 (0)20 78481945 > > http://www.kcl.ac.uk/cch > > > > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Wed Mar 7 13:29:18 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 11:29:18 -0700 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <1173291945.20729.54.camel@odonned-eng06> References: <45EC1255.1060303@kcl.ac.uk> <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> <45ED3B08.8090107@kcl.ac.uk> <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> <1173291945.20729.54.camel@odonned-eng06> Message-ID: <1173292158.20729.57.camel@odonned-eng06> Apologies for a public email to the list. And spelling Fotis Jannidis's name wrong. On Wed, 2007-07-03 at 11:25 -0700, Dan O'Donnell wrote: > I'd made a couple of steps towards moving this forward. I was asked to > contact Fotis Jannis about this but heard nothing back from him. I'll > bug him again. > > -dan > > On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote: > > Hi Arianna, > > > > Yes, that's what I meant (I was confusing my "Manuscripts SIG" with my > > "TEI Chapter on Transcription of Primary Sources"). Any objections if > > Arianna and I take our discussion off-list? Any other takers? > > > > Dot > > > > On 3/6/07, Arianna Ciula wrote: > > > Hi Dot, > > > > > > I remember talking about the Manuscript SIG. Is this what you mean by > > > Transcription SIG? Dan and Roberto Rosselli del Turco contacted me about > > > the former and I gave a sort of availability in case nobody was prepared > > > to chair it. > > > > > > Should we discuss this out of list with Roberto as well and see what we > > > could do and report back? > > > > > > Arianna > > > > > > Dot Porter wrote: > > > > Hi Arianna, > > > > > > > > At the TEI member's meeting, you and I and a few other people were > > > > talking about reviving the Transcription SIG, which seems to have > > > > faded a way for a while. Are you interested? The CEI might be a good > > > > point to start off on - will you be at the DH conference this summer? > > > > > > > > Dot > > > > > > > > On 3/5/07, Arianna Ciula wrote: > > > >> Dear council, > > > >> > > > >> For whom is interested, I just wanted to report briefly on the > > > >> conference I came back from on Saturday: Digital Diplomatics > > > >> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html > > > >> > > > >> The international attendance was quite good with a majority of Germans > > > >> of course. > > > >> > > > >> The majority of presented projects deal with a combination of relational > > > >> database and use of XML (lots of TEI!). > > > >> > > > >> Few things to mention as far as TEI regards: > > > >> > > > >> Interesting presentations > > > >> - good work done by two Italian students using TEI P5 (poster: Viviana > > > >> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di Vicenza > > > >> del 1264) > > > >> - presentation of ODD by Gautier Poupeau > > > >> - integration TEI-CIDOC presented by Christian-Emil Ore > > > >> > > > >> TEI/CEI > > > >> As you may know already, the objective of the conference was to give a > > > >> glimpse on digital projects related to medieval documents (it succeeded > > > >> on this) and to work on the improvements of the CEI (Charter Encoding > > > >> Initiative: funded three years ago - http://www.cei.lmu.de/index.htm) > > > >> standard to encode these documents in XML. Unfortunately, despite the > > > >> good work of synthesis and conceptual modelling done by Patrick Sahle > > > >> and Gautier Poupeau, we didn't go very far on the latter, but it seems > > > >> to me that > > > >> - despite some more or less funded complains on the inability of TEI to > > > >> represented the archival community and its objectives, all the CEI > > > >> recommendations as they stand could easily been translated and/or > > > >> represented in TEI P5 > > > >> - I will keep an eye on how the community is going to develop the > > > >> standard and see what comes up > > > >> > > > >> Happy to give more details to whom is interested. > > > >> All the best, > > > >> > > > >> Arianna > > > >> -- > > > >> Dr Arianna Ciula > > > >> Research Associate > > > >> Centre for Computing in the Humanities > > > >> King's College London > > > >> Strand > > > >> London WC2R 2LS (UK) > > > >> Tel: +44 (0)20 78481945 > > > >> http://www.kcl.ac.uk/cch > > > >> _______________________________________________ > > > >> tei-council mailing list > > > >> tei-council at lists.village.Virginia.EDU > > > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > >> > > > > > > > > > > > > > > -- > > > Dr Arianna Ciula > > > Research Associate > > > Centre for Computing in the Humanities > > > King's College London > > > Strand > > > London WC2R 2LS (UK) > > > Tel: +44 (0)20 78481945 > > > http://www.kcl.ac.uk/cch > > > > > > > > -- > Daniel Paul O'Donnell, PhD > Chair, Text Encoding Initiative > Director, Digital Medievalist Project > Associate Professor and Chair of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox: +1 403 329 2378 > Fax: +1 403 382-7191 > Homepage: http://people.uleth.ca/~daniel.odonnell/ > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Wed Mar 7 14:06:25 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 07 Mar 2007 12:06:25 -0700 Subject: [tei-council] work for March In-Reply-To: <45E6C768.1080400@oucs.ox.ac.uk> References: <45E6C768.1080400@oucs.ox.ac.uk> Message-ID: <1173294385.20729.89.camel@odonned-eng06> Sebastian, I'm about to sign up for my chapters. Are you actively working on any of the ones assigned to you? Do you have a recommendation for how many each member of council should take? I was thinking of signing up for five to start and see what I could do over the weekend. Howzat sound? -dan On Thu, 2007-01-03 at 12:30 +0000, Sebastian Rahtz wrote: > Happy St David's Day. > > Looking at the plan of work scheduled for March, it goes as follows: > > * (end of tasks relating to feature requests, 12 hours to go) > * design output format (JC and DP now on case) > * review datatype and class decisions > * proofread text looking for DTD and P4 language > > the latter two involve taking each chapter, looking > for problems and ideally dealing with them. In most > cases it will just a matter of someone signing off a > chapter as having a clean bill of health. If something > comes out which cannot be dealt with in (say) > an hours work rewriting a paragraph, or making > a simple decision about a datatype, then it should > be broken out to a new task which can assigned its > own deadline and so on. > > I think its "adopt a chapter" day again. > > Sebastian > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 7 14:12:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 07 Mar 2007 19:12:10 +0000 Subject: [tei-council] work for March In-Reply-To: <1173294385.20729.89.camel@odonned-eng06> References: <45E6C768.1080400@oucs.ox.ac.uk> <1173294385.20729.89.camel@odonned-eng06> Message-ID: <45EF0E8A.4030300@oucs.ox.ac.uk> Daniel, I am getting daniel.odonnell at uleth.ca SMTP error from remote mail server after RCPT TO:: host bellatrix.uleth.ca [142.66.3.43]: 550 Refused: Unknown local recipient maybe this list one will get through to warn you? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Syd_Bauman at Brown.edu Wed Mar 7 19:49:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 7 Mar 2007 19:49:42 -0500 Subject: [tei-council] SFFR 1007370 Theorem In-Reply-To: <45ED4029.7000403@computing-services.oxford.ac.uk> References: <45ECA1C7.9080000@computing-services.oxford.ac.uk> <20070306093729.GD31263@raven.linux.ox.ac.uk> <45ED4029.7000403@computing-services.oxford.ac.uk> Message-ID: <17903.23974.159737.236505@emt.wwp.brown.edu> I think since users can, if necessary, make use of and to encode theorems for now, this can safely be deferred to 1.1. From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 00:45:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 13:45:11 +0800 Subject: [tei-council] Berlin meeting In-Reply-To: <45EEAF27.8000402@oucs.ox.ac.uk> References: <45EEAF27.8000402@oucs.ox.ac.uk> Message-ID: <45EFA2E7.5090308@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > Two quick timetabling questions: > > (a) Will the Council meeting also be held in the Harnackhaus ("Zentrum > des "deutschen Oxford" :-))? if not, where? > Im "Zentrum des deutschen Berlin", apparently:-) > (b) When do we expect that the Council meeting will end? > Judging from previous years' experience, I would think we need full 2 days 9 to 5; it seems unlikely that we are done before 5 pm on Friday. I also do not think a meeting is productive, where half the participants have to run to a train midway through. I would recommend therefore to book for the late evening or Saturday. We used to keep Saturday 'just in case' but never made use of it, so I am prepared to get rid of that part. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 00:48:03 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 13:48:03 +0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EEFA52.4040000@kcl.ac.uk> References: <45EEB75C.4010608@oucs.ox.ac.uk> <96f3df640703070512l6c0023c2mabd6551aa45fee40@mail.gmail.com> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> <45EECCEA.8050400@oucs.ox.ac.uk> <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> <45EEFA52.4040000@kcl.ac.uk> Message-ID: <45EFA393.9060407@kanji.zinbun.kyoto-u.ac.jp> Arianna Ciula wrote: > I am happy to co-chair as well, but need to add another criterion: > > - if I need to book we have to decide before Friday, because after that > I'll be on holiday for a week. > Not sure if trying to do the booking would be effective; you would need to trac(k) everybody's schedule etc. Maybe you can just figure out what seems to be reasonable given our preferences and post it to the list? Participants could then make their own informed decisions. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Mar 8 03:53:30 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Thu, 08 Mar 2007 16:53:30 +0800 Subject: [tei-council] work for March In-Reply-To: <1173294385.20729.89.camel@odonned-eng06> References: <45E6C768.1080400@oucs.ox.ac.uk> <1173294385.20729.89.camel@odonned-eng06> Message-ID: <45EFCF0A.4080807@kanji.zinbun.kyoto-u.ac.jp> Dan O'Donnell wrote: > Sebastian, > > I'm about to sign up for my chapters. Are you actively working on any of > the ones assigned to you? > > Do you have a recommendation for how many each member of council should > take? I was thinking of signing up for five to start and see what I > could do over the weekend. Howzat sound? That's great. You will submit your changes to the P5-Council branch, I hope? Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From dporter at uky.edu Thu Mar 8 06:56:28 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 8 Mar 2007 03:56:28 -0800 Subject: [tei-council] [Fwd: Fwd: Hotels in Berlin] In-Reply-To: <45EFA393.9060407@kanji.zinbun.kyoto-u.ac.jp> References: <45EEB75C.4010608@oucs.ox.ac.uk> <01DAC665-DB88-4415-8514-FEECEA2C1A0C@aksis.uib.no> <45EEC84D.6020409@computing-services.oxford.ac.uk> <45EEC8B1.8080705@oucs.ox.ac.uk> <45EECBD1.7030308@oucs.ox.ac.uk> <45EECC39.2000001@oucs.ox.ac.uk> <45EECCEA.8050400@oucs.ox.ac.uk> <96f3df640703070638w63828e3ct4a1aef81b7519bc2@mail.gmail.com> <45EEFA52.4040000@kcl.ac.uk> <45EFA393.9060407@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <96f3df640703080356v15f041deh9bc59cc10f93809f@mail.gmail.com> Arianna, I agree with Christian. There's no need to book a group of rooms together, but we can make a recommendation. I just want to make sure I'm not alone in my hotel, don't want to get lost getting to and from the meetings. Of course folks are free to choose another hotel if the one we recommend isn't cute enough. Dot On 3/7/07, Christian Wittern wrote: > Arianna Ciula wrote: > > I am happy to co-chair as well, but need to add another criterion: > > > > - if I need to book we have to decide before Friday, because after that > > I'll be on holiday for a week. > > > > Not sure if trying to do the booking would be effective; you would need > to trac(k) everybody's schedule etc. Maybe you can just figure out what > seems to be reasonable given our preferences and post it to the list? > > Participants could then make their own informed decisions. > > Christian > > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From laurent.romary at loria.fr Thu Mar 8 07:58:05 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 8 Mar 2007 13:58:05 +0100 Subject: [tei-council] Digital Diplomatics conference In-Reply-To: <1173292158.20729.57.camel@odonned-eng06> References: <45EC1255.1060303@kcl.ac.uk> <96f3df640703051542v17ed5778v1eaea41e409a8a0b@mail.gmail.com> <45ED3B08.8090107@kcl.ac.uk> <96f3df640703060306s1ae65334i4c103b86304c38f4@mail.gmail.com> <1173291945.20729.54.camel@odonned-eng06> <1173292158.20729.57.camel@odonned-eng06> Message-ID: <101D63BA-1E66-4869-B4ED-431387C90D59@loria.fr> Never mind. I actually see Fotis next week and czn put pressure on him if you want. Laurent Le 7 mars 07 ? 19:29, Dan O'Donnell a ?crit : > Apologies for a public email to the list. And spelling Fotis > Jannidis's > name wrong. > > On Wed, 2007-07-03 at 11:25 -0700, Dan O'Donnell wrote: >> I'd made a couple of steps towards moving this forward. I was >> asked to >> contact Fotis Jannis about this but heard nothing back from him. I'll >> bug him again. >> >> -dan >> >> On Tue, 2007-06-03 at 03:06 -0800, Dot Porter wrote: >>> Hi Arianna, >>> >>> Yes, that's what I meant (I was confusing my "Manuscripts SIG" >>> with my >>> "TEI Chapter on Transcription of Primary Sources"). Any >>> objections if >>> Arianna and I take our discussion off-list? Any other takers? >>> >>> Dot >>> >>> On 3/6/07, Arianna Ciula wrote: >>>> Hi Dot, >>>> >>>> I remember talking about the Manuscript SIG. Is this what you >>>> mean by >>>> Transcription SIG? Dan and Roberto Rosselli del Turco contacted >>>> me about >>>> the former and I gave a sort of availability in case nobody was >>>> prepared >>>> to chair it. >>>> >>>> Should we discuss this out of list with Roberto as well and see >>>> what we >>>> could do and report back? >>>> >>>> Arianna >>>> >>>> Dot Porter wrote: >>>>> Hi Arianna, >>>>> >>>>> At the TEI member's meeting, you and I and a few other people were >>>>> talking about reviving the Transcription SIG, which seems to have >>>>> faded a way for a while. Are you interested? The CEI might be a >>>>> good >>>>> point to start off on - will you be at the DH conference this >>>>> summer? >>>>> >>>>> Dot >>>>> >>>>> On 3/5/07, Arianna Ciula wrote: >>>>>> Dear council, >>>>>> >>>>>> For whom is interested, I just wanted to report briefly on the >>>>>> conference I came back from on Saturday: Digital Diplomatics >>>>>> http://www.cei.uni-muenchen.de/DigDipl07/index_en.html >>>>>> >>>>>> The international attendance was quite good with a majority of >>>>>> Germans >>>>>> of course. >>>>>> >>>>>> The majority of presented projects deal with a combination of >>>>>> relational >>>>>> database and use of XML (lots of TEI!). >>>>>> >>>>>> Few things to mention as far as TEI regards: >>>>>> >>>>>> Interesting presentations >>>>>> - good work done by two Italian students using TEI P5 (poster: >>>>>> Viviana >>>>>> Salardi, Luigi Siciliano: L`edizione digitale dello Statuto di >>>>>> Vicenza >>>>>> del 1264) >>>>>> - presentation of ODD by Gautier Poupeau >>>>>> - integration TEI-CIDOC presented by Christian-Emil Ore >>>>>> >>>>>> TEI/CEI >>>>>> As you may know already, the objective of the conference was >>>>>> to give a >>>>>> glimpse on digital projects related to medieval documents (it >>>>>> succeeded >>>>>> on this) and to work on the improvements of the CEI (Charter >>>>>> Encoding >>>>>> Initiative: funded three years ago - http://www.cei.lmu.de/ >>>>>> index.htm) >>>>>> standard to encode these documents in XML. Unfortunately, >>>>>> despite the >>>>>> good work of synthesis and conceptual modelling done by >>>>>> Patrick Sahle >>>>>> and Gautier Poupeau, we didn't go very far on the latter, but >>>>>> it seems >>>>>> to me that >>>>>> - despite some more or less funded complains on the inability >>>>>> of TEI to >>>>>> represented the archival community and its objectives, all the >>>>>> CEI >>>>>> recommendations as they stand could easily been translated and/or >>>>>> represented in TEI P5 >>>>>> - I will keep an eye on how the community is going to develop the >>>>>> standard and see what comes up >>>>>> >>>>>> Happy to give more details to whom is interested. >>>>>> All the best, >>>>>> >>>>>> Arianna >>>>>> -- >>>>>> Dr Arianna Ciula >>>>>> Research Associate >>>>>> Centre for Computing in the Humanities >>>>>> King's College London >>>>>> Strand >>>>>> London WC2R 2LS (UK) >>>>>> Tel: +44 (0)20 78481945 >>>>>> http://www.kcl.ac.uk/cch >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Dr Arianna Ciula >>>> Research Associate >>>> Centre for Computing in the Humanities >>>> King's College London >>>> Strand >>>> London WC2R 2LS (UK) >>>> Tel: +44 (0)20 78481945 >>>> http://www.kcl.ac.uk/cch >>>> >>> >>> >> -- >> Daniel Paul O'Donnell, PhD >> Chair, Text Encoding Initiative >> Director, Digital Medievalist Project > www.digitalmedievalist.org/> >> Associate Professor and Chair of English >> University of Lethbridge >> Lethbridge AB T1K 3M4 >> Vox: +1 403 329 2378 >> Fax: +1 403 382-7191 >> Homepage: http://people.uleth.ca/~daniel.odonnell/ >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- > Daniel Paul O'Donnell, PhD > Chair, Text Encoding Initiative > Director, Digital Medievalist Project www.digitalmedievalist.org/> > Associate Professor and Chair of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox: +1 403 329 2378 > Fax: +1 403 382-7191 > Homepage: http://people.uleth.ca/~daniel.odonnell/ > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 9 04:39:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 09 Mar 2007 09:39:22 +0000 Subject: [tei-council] TEI P5 trac server Message-ID: <45F12B4A.3080902@oucs.ox.ac.uk> this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5, instead of http://tei.oucs.ox.ac.uk/trac.cgi This lets me support multiple projects, and do it properly with mod_python. Shout at me if anything is not working -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Fri Mar 9 17:30:38 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 9 Mar 2007 17:30:38 -0500 Subject: [tei-council] Hotels Message-ID: <96f3df640703091430u7574ace0pc0d52701431c6de5@mail.gmail.com> Hi Everyone, I've checked out the hotel list that Laurent sent and I'm drawn to the Angleterre (http://www.gold-inn.de). Room charge for a single ranges from 100-124 EUR (472 EUR for April 25-29), 10 EUR more per night for a double. DSL connections in each room appear to be included in the price. Breakfast is not included (15 EUR/day, which seems steep) neither is the fitness area (9.50 EUR/day). 12 minute walk to the BBAW. And it's cute! http://www.gold-inn.de/angleterre/galerie_hotel.php This is a good choice especially if you expect to take breakfast some days outside the hotel, and/or if you don't exercise. So, this one is my recommendation. To the others... ****** The Albrechtshof and Allegra in Mitte both look nice, too (http://www.hotel-albrechtshof.de/; http://www.hotel-allegra.de/). I couldn't find anything on the websites about Internet access, I've written messages to both and I'll report back what I find. I checked the online booking system to see what the costs would be for April 25-29 and both claim to be unavailable. That seemed kind of strange so I've contacted the hotels about that as well. Actually I don't have much to say about these two until I hear back from them. 15 minute walk to the BBAW. The Dietrich-Bonhoeffer-Hotel (http://www.hotel-dbh.de/) is less expensive but not as attractive as the first three. Room charge for a single is 105 EUR, for a double 145 EUR. This includes Internet connection and breakfast. The website is entirely in German which I haven't studied in a long, long time, but I think I have the correct information. The online booking system is not working. Pictures here: http://www.dietrich-bonhoeffer-hotel.de/galerie.html. Short ride to the BBAW. The Hotel Gendarm is quite nice and private (only 21 rooms), but more expensive at 135 EUR for a single and 160 EUR for double. Breakfast buffet is 13 EUR; I've sent them a message asking about Internet access. http://www.hotel-gendarm-berlin.de/. It's very close to the BBAW, just a 4 minute walk. On to the chains... ****** Mercure Checkpoint Charlie (http://www.mercure.com/mercure/fichehotel/gb/mer/3120/fiche_hotel.shtml) has both wifi access and highspeed Internet connections in the room, though "extra charges may apply". Room rates range from 92-122 EUR for a single (rate depends on whether you pay at time of booking or wait until you get to the hotel). Breakfast is 16 EUR/day. Short ride to the BBAW. Hotel NH Berlin-Mitte is 124-134 EUR average per night for a single. Wireless Internet is available in-room but it isn't clear whether an extra cost is involved. Breakfast is 13 EUR/day. 8 minute walk to BBAW. Hotel Dorint Novotel Berlin Mitte (http://www.nh-hotels.com/) averages 139 EUR per night for a single. Wireless Internet is available but watch for those extra charges. Breakfast is 15 EUR. 15 minute walk to BBAW. And finally... ***** Then there is the Humboldt University guest housing (http://www.ta.hu-berlin.de/index.php4?fd=502). These are small apartments including small kitchens, ranging from 35 EUR for a single, 60 EUR for a double (sharing a bedroom), 25 EUR/person for a triple (three bedrooms) and 30/35 EUR for a double (two bedrooms). The multiple-bedroom apartments can only be shared by people of the same gender. Breakfast is not included or available on-site. Short ride to the BBAW. Hope this information is helpful. I think I'll be booking at Angleterre. Have a good weekend! Dot -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From daniel.odonnell at uleth.ca Mon Mar 12 13:30:16 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 12 Mar 2007 12:30:16 -0600 Subject: [tei-council] TEI P5 trac server In-Reply-To: <45F12B4A.3080902@oucs.ox.ac.uk> References: <45F12B4A.3080902@oucs.ox.ac.uk> Message-ID: <1173724216.28369.69.camel@odonned-eng06> Seems O.K. I'd asked about whether we could just grab chapters for reviewing for reference to DTDs and P4--I'm not sure if there was a policy, but I assigned myself five for this week. Let me encourage others on council to do the same so we can hit this deadline. -dan On Fri, 2007-09-03 at 09:39 +0000, Sebastian Rahtz wrote: > this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5, > instead of http://tei.oucs.ox.ac.uk/trac.cgi > > This lets me support multiple projects, and do it properly > with mod_python. > > Shout at me if anything is not working > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 12 15:22:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 12 Mar 2007 20:22:30 +0000 Subject: [tei-council] p5 release 0.6 Message-ID: <45F5B686.9010604@oucs.ox.ac.uk> If any of you have some energy to look at http://tei.oucs.ox.ac.uk/Roma/, you'll find it delivers a pre-release of 0.6. Please report any funnies to me. If you feel strong, you'll see that you can now specify a min and max for the space-separated values of an attribute. Roma supports this, but it is not much tested. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 21:54:15 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 10:54:15 +0800 Subject: [tei-council] facsimile odd In-Reply-To: <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> References: <45D84AB4.9040800@oucs.ox.ac.uk> <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> Message-ID: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> Dot Porter wrote: > I expect the hold up is on my end - I am supposed to be supplying > sample texts to Conal so he can test the ODD (which is probably > finished). I will get the testing materials to him this afternoon. > Sorry for the hold up... > Dot, any news about this? > Sebastian Rahtz wrote: >> Any sign? >> >> I added a ticket to trac about it. >> I can't find the ticket in trac, neither by looking at active tickets by owner, nor by searching globally. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 21:28:08 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 10:28:08 +0800 Subject: [tei-council] TEI P5 trac server In-Reply-To: <45F12B4A.3080902@oucs.ox.ac.uk> References: <45F12B4A.3080902@oucs.ox.ac.uk> Message-ID: <45F60C38.3070000@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > this has now moved to http://tei.oucs.ox.ac.uk/trac/TEIP5, > Shout at me if anything is not working Thanks, this works excellent, the response time is much better than the previous version. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 22:06:29 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 11:06:29 +0800 Subject: [tei-council] editing the guidelines Message-ID: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, The way we (the planning committee) are imaging changes necessary in the proofreading and foolproofing process about to commence is that 1) Every Council member checks out a branch (P5-Council) from the SF repository. 2) She then marks the Chapters she wants to work with in trac, and 3) goes about editing them in the working copy. 4) Occasionally, she commits this back to the repository. 5) When done, she does the last commit and ticks the ticket in trac off. 6) The editors look over this and merge the stuff with the trunk. I would like to see if we can agree to this procedure and put it in effect as soon as possible. Comments welcome. Please speak up soon if you find problems with this procedure, I would like to start using it after the telecon next week. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 12 22:09:55 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 13 Mar 2007 11:09:55 +0800 Subject: [tei-council] call for agenda items (cfa) for the teleconference next monday, march 19 at 1200 gmt Message-ID: <45F61603.9070804@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, another telecon is dragging closer, giving us an opportunity with catching up on ourselves with regard to the various work items we are obsessed with. As usual, this is a wake-up call, please look at http://www.tei-c.org/Council/tcm28.xml?style=printable to find out what work items assigned to you might yet be open. Our main task on this telecon will again be the workplan for the next months, this time we would try to iron out the procedures in a way that we can start doing the necessary work immediately. Before the conference, please look at the trac pages at http://tei.oucs.ox.ac.uk/trac/TEIP5/ and see if you find any flaws with the overall plan, especially with respect for the timeline of items you are involved with. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 04:50:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 09:50:54 +0000 Subject: [tei-council] facsimile odd In-Reply-To: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> References: <45D84AB4.9040800@oucs.ox.ac.uk> <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45F673FE.4070103@oucs.ox.ac.uk> Christian Wittern wrote: > > I can't find the ticket in trac, neither by looking at active tickets > by owner, nor by searching globally. > > Christian > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/291 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 13:58:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 18:58:56 +0000 Subject: [tei-council] editing the guidelines In-Reply-To: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> References: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45F6F470.2090102@oucs.ox.ac.uk> Christian Wittern wrote: > 1) Every Council member checks out a branch (P5-Council) from the SF > repository. > > 2) She then marks the Chapters she wants to work with in trac, and > > 3) goes about editing them in the working copy. > > 4) Occasionally, she commits this back to the repository. > > 5) When done, she does the last commit and ticks the ticket in trac off. > > 6) The editors look over this and merge the stuff with the trunk. > that's just how I imagined things would work. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 13 18:07:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 13 Mar 2007 23:07:36 +0000 Subject: [tei-council] Hotels In-Reply-To: <96f3df640703091430u7574ace0pc0d52701431c6de5@mail.gmail.com> References: <96f3df640703091430u7574ace0pc0d52701431c6de5@mail.gmail.com> Message-ID: <45F72EB8.5010302@oucs.ox.ac.uk> Just for the record, Lou and I are booked in the Angleterre for Wed, Thur and Fri night; arriving by train 8.30 am Wednesday. Both leaving after lunch on Saturday (so allowing for an overrun on Saturday am if needed). -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Tue Mar 13 19:34:51 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 13 Mar 2007 16:34:51 -0800 Subject: [tei-council] editing the guidelines In-Reply-To: <45F6F470.2090102@oucs.ox.ac.uk> References: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> <45F6F470.2090102@oucs.ox.ac.uk> Message-ID: <96f3df640703131734p4f3b6a7eqcede9a5a93bacbde@mail.gmail.com> In order to check out the P5-Council branch from the Subversion, it looks like we need to be Developers - at least, I can get into SF and view the SVN, but I can't check the branch out. It's also possible that I just don't know what I'm doing. Can someone help, please? Thanks, Dot On 3/13/07, Sebastian Rahtz wrote: > Christian Wittern wrote: > > 1) Every Council member checks out a branch (P5-Council) from the SF > > repository. > > > > 2) She then marks the Chapters she wants to work with in trac, and > > > > 3) goes about editing them in the working copy. > > > > 4) Occasionally, she commits this back to the repository. > > > > 5) When done, she does the last commit and ticks the ticket in trac off. > > > > 6) The editors look over this and merge the stuff with the trunk. > > > that's just how I imagined things would work. > > > -- > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > OSS Watch: JISC Open Source Advisory Service > http://www.oss-watch.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From Syd_Bauman at Brown.edu Tue Mar 13 19:50:03 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 13 Mar 2007 20:50:03 -0400 Subject: [tei-council] editing the guidelines In-Reply-To: <96f3df640703131734p4f3b6a7eqcede9a5a93bacbde@mail.gmail.com> References: <45F61535.6020405@kanji.zinbun.kyoto-u.ac.jp> <45F6F470.2090102@oucs.ox.ac.uk> <96f3df640703131734p4f3b6a7eqcede9a5a93bacbde@mail.gmail.com> Message-ID: <17911.18107.984674.355574@emt.wwp.brown.edu> > In order to check out the P5-Council branch from the Subversion, it > looks like we need to be Developers - at least, I can get into SF > and view the SVN, but I can't check the branch out. It's also > possible that I just don't know what I'm doing. Can someone help, > please? >From a Mac OS X or GNU/Linux commandline issue: svn co https://tei.svn.sourceforge.net/svnroot/tei/branches/P5-Council and a new directory named "P5-Council/" will be crated and populated. Checking in is a different story. From daniel.odonnell at uleth.ca Thu Mar 15 13:35:02 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 15 Mar 2007 12:35:02 -0600 Subject: [tei-council] Test Message-ID: <1173983702.25173.15.camel@odonned-eng06> I think this might be working now. -dan -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu Mar 15 15:25:13 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 15 Mar 2007 14:25:13 -0600 Subject: [tei-council] Re: TEI Council: temporary mail list/ conformance draft In-Reply-To: <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> References: <45F92E3C.6040505@oucs.ox.ac.uk> <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1173990313.3745.0.camel@odonned-eng06> I'm guessing this is now an hour earlier (4 am, gulp, for me) for North Americans due to the earlier DST? -dan On Thu, 2007-15-03 at 19:53 +0800, Christian Wittern wrote: > Lou Burnard wrote: > > Since we have a Council telecon scheduled for next week, and the > > weekend is upon us, I've repurposed the tei-chars mailing list here as a > > temporary substitute. All members of the council are now signed up to > > this list, and should also be able to send mail to it. > > Thanks for taking care of this. I will be sending out the draft agenda > tomorrow. > > > This enables me to announce that James has just delivered a preliminary > > draft for the Conformance chapter of P5, which should be on our agenda > > for next week. You can read the draft at > > > > http://www.tei-c.org/Council/conformance-draft.pdf > > Thanks to James as well. > > Christian > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Thu Mar 15 18:16:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 15 Mar 2007 19:16:20 -0400 Subject: [tei-council] Berlin airports Message-ID: <17913.54212.273809.344367@emt.wwp.brown.edu> Sorry if this has gone by and I've missed it -- * Which airport should we use, or does it matter? * When & where are we expected to be on Wed 25 Apr? From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Mar 16 03:16:53 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Mar 2007 16:16:53 +0800 Subject: [tei-council] Test In-Reply-To: <1173983702.25173.15.camel@odonned-eng06> References: <1173983702.25173.15.camel@odonned-eng06> Message-ID: <45FA5275.9060705@kanji.zinbun.kyoto-u.ac.jp> Dan O'Donnell wrote: > I think this might be working now. > It does. Thanks for clearing the roadblock. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Mar 16 03:18:59 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 16 Mar 2007 16:18:59 +0800 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Message-ID: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Dear Council members, Here is the draft agenda. The time is still 1200 UTC, but your local time may have changed relative to it, so please pay attention. DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC Expected to participate: Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern ============================================================ How to connect: We will use the highspeedconferencing.com service again (hopefully the tennis player will take his day off). Participants can use their skype account (www.skype.com) or regular phones to call. When calling via skype, *please use a headset*. If in doubt, it might be better to call via regular phone. Numbers as follow: >From Skype call +99008278525675 In the US, call 1-712-432-4000 Calling from Europe, call In Austria: 0820 400 01562 In Belgium: 0703 59 984 In France: 0826 100 266 In Germany 01805 00 7620 In UK: 0870 119 2350 other places: call to US:-( Enter Conference Room Number : 5326922 (this is Sebastians Conference room) ============================================================ Please read through the following. Wherever a report is requested, a brief note to the list before the call is much appreciated and will help us use the time during the call more effectively. ============================================================ 1) Minutes, work items, progress since last meeting: http://www.tei-c.org.uk/Council/tcm28.xml?style=printable Please look at the action items and report progress here before the meeting! ============================================================ 2) Reports & Documents PERS Matthew, please give us an update on the outcoming of the meeting etc. CONFORMANCE James has the draft up here. http://www.tei-c.org/Council/conformance-draft.pdf (I think we can only do a brief review here and will have it on the table for further scrutiny in Berlin) ============================================================ 3) Road to P5: The roadmap on trac is here: http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap We need to discuss how we want to share work on the items on the table ============================================================ 4) Meetings Council 2007: Berlin, preparations? What do we need to discuss there? ============================================================ 5) Other business TBA ============================================================ -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From tone.bruvik at aksis.uib.no Fri Mar 16 04:06:04 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Fri, 16 Mar 2007 10:06:04 +0100 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Message-ID: The link to the minutes from last meeting does not work (error at the server in Oxford?), but it looks like the server in Charlottesville is up running: http://www.tei-c.org/Council/tcm28.xml?style=printable Tone Merete Den 16. mar. 2007 kl. 09.18 skrev Christian Wittern: > Dear Council members, > > Here is the draft agenda. The time is still 1200 UTC, but your local > time may have changed relative to it, so please pay attention. > > > DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at > 1200 UTC > > > Expected to participate: > > Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna > Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, > Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian > Wittern > > > ============================================================ > How to connect: > > We will use the highspeedconferencing.com service again (hopefully > the tennis player will take his day off). > > Participants can use their skype account (www.skype.com) or regular > phones to call. When calling via skype, *please use a headset*. If > in doubt, it might be better to call via regular phone. Numbers as > follow: > >> From Skype call +99008278525675 > In the US, call 1-712-432-4000 > Calling from Europe, call > In Austria: 0820 400 01562 > In Belgium: 0703 59 984 > In France: 0826 100 266 > In Germany 01805 00 7620 > In UK: 0870 119 2350 > other places: call to US:-( > Enter Conference Room Number : 5326922 > (this is Sebastians Conference room) > ============================================================ > > Please read through the following. Wherever a report is requested, a > brief note to the list before the call is much appreciated and will > help us use the time during the call more effectively. > > ============================================================ > > 1) Minutes, work items, progress since last meeting: > http://www.tei-c.org.uk/Council/tcm28.xml?style=printable > Please look at the action items and report progress here before the > meeting! > > ============================================================ > 2) Reports & Documents > > PERS > > Matthew, please give us an update on the outcoming of the meeting etc. > > CONFORMANCE > James has the draft up here. > http://www.tei-c.org/Council/conformance-draft.pdf > (I think we can only do a brief review here and will have it on the > table for further scrutiny in Berlin) > > ============================================================ > 3) Road to P5: > > The roadmap on trac is here: > http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap > > We need to discuss how we want to share work on the items on the table > > > ============================================================ > > 4) Meetings > > Council 2007: Berlin, preparations? What do we need to discuss there? > > > ============================================================ > 5) Other business TBA > > > ============================================================ > > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Fri Mar 16 04:46:59 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 16 Mar 2007 10:46:59 +0100 Subject: [tei-council] Berlin airports In-Reply-To: <17913.54212.273809.344367@emt.wwp.brown.edu> References: <17913.54212.273809.344367@emt.wwp.brown.edu> Message-ID: Le 16 mars 07 ? 00:16, Syd Bauman a ?crit : > Sorry if this has gone by and I've missed it -- > > * Which airport should we use, or does it matter? Not really. I guess most of you would arrive at Tegel. > * When & where are we expected to be on Wed 25 Apr? I am planning to have the workshop start at 10.30 Best wishes, Laurent From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 16 05:22:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 16 Mar 2007 10:22:08 +0000 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC In-Reply-To: References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FA6FD0.3090208@oucs.ox.ac.uk> Tone Merete Bruvik wrote: > The link to the minutes from last meeting does not work (error at the > server in Oxford?) restarted. hitting out of memory problems for some reason -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From dporter at uky.edu Fri Mar 16 08:52:33 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 16 Mar 2007 09:52:33 -0400 Subject: [tei-council] facsimile odd In-Reply-To: <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> References: <45D84AB4.9040800@oucs.ox.ac.uk> <96f3df640702180908v42486cb5s71464fee18abe47a@mail.gmail.com> <45F61257.7060801@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <96f3df640703160652j45a8e138wbbd5e4577785a914@mail.gmail.com> Hi Christian and all, On 3/12/07, Christian Wittern wrote: > Dot Porter wrote: > > I expect the hold up is on my end - I am supposed to be supplying > > sample texts to Conal so he can test the ODD (which is probably > > finished). I will get the testing materials to him this afternoon. > > Sorry for the hold up... > > > > Dot, any news about this? > Conal is currently working on an instance document for testing the ODD, based on the sample projects I sent him last month. The ODD is currently on the TEI wiki: http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD It lacks documentation and is unchanged from the last conference call. Conal and I expect that once the test instance is complete there will be a certain amount of back-and-forthing, modifying the ODD and then the instance to make sure it all does what we want it to do. Earlier this week, Conal thought that the instance would be finished by the end of this week, but I don't know how much we will have done before the call on Monday. Dot > > Sebastian Rahtz wrote: > >> Any sign? > >> > >> I added a ticket to trac about it. > >> > > I can't find the ticket in trac, neither by looking at active tickets by > owner, nor by searching globally. > > Christian > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From mjd at hum.ku.dk Sun Mar 18 05:58:36 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Sun, 18 Mar 2007 11:58:36 +0100 Subject: [tei-council] Report on Vilnius meeting Message-ID: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> TEI Place-name meeting, Vilnius, 23-24 February In attendance were: Lou Burnard, Matthew Driscoll, ?yvind Eide, Richard Light, Tadeusz Piotrowski, Tatjana Timchenko and Sebastian Rahtz. The first day we were at the Institute of Lithuanian language (http://www.lki.lt/indexeng.php), part of the Lithuanian Academy of Sciences, and on the second day the Faculty of Philology (http://www.flf.vu.lt/) at Vilnius University; we are grateful to both institutions for acting as hosts. 1. Names and nyms We began by tackling one bit of business outstanding from the Personography meeting last year in Oxford, viz. the development of a mechanism for pointing from actual name instances to the canonical form of that name, thus addressing the needs of onomasticians (who are interested in names per se), in addition to those of prosopographers (who are interested in people). If, for example, the names Tony Blair and Tony Benn occur in a text it should be possible to tag them in such a way that they both point to information about these respective gentlemen and are flagged as instances of the name "Tony". It should further be possible to indicate that "Tony" is a (pet-)form of "Anthony", which is itself a member of a family of names containing forms such as "Antonio", "Anton", "Antoine" and so on. We propose doing this by means of a new element, called , which contains the definition for a canonical name or name-part of any kind. In addition to global attributes and those inherited from att.typed it can take a @parts attribute, which points to constituent nyms. The attribute @nymKey is available on any element which is a member of the att.naming class in order to point to the nym with which it corresponds. Thus, to take our example, the name "Tony Blair" in running prose could be tagged as follows: Tony Blair The @key attribute on would point to a element giving information about Tony Blair, while @nymKey on points to the relevant . A element may also combine a number of other elements together, where it is intended to show that one is a pet form or diminutive of another, or that different nyms are to be regarded as variants of the same base nym, using the element (from the model.entryParts class); orthographic variants are dealt with using , while can be used for information on the origin of the name: Antonius From the Roman family name Antonius, which is of unknown, presumably Etruscan, origin. It has been commonly, but incorrectly, associated with Greek ανθος flower, which resulted in spellings with th in some languages.
Anthony Antony
Tony
Antonio
Tonio
 This mechanism could also be used for place-names and place-name elements (e.g. thorp, caster). 2. Place-names Our principal task at this meeting was to develop mechanisms for encoding place-names, analogous to those which were developed for personal names at the meeting in Oxford last year, which would allow for the recording of abstracted information about a place, such as map coordinate, GIS information etc., as well as variant forms of the name, in different languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g. Lundunum, London). On the analogy with , we propose a element, which will usually contain at least one, and possibly several, elements, followed by one or more elements to provide geographical and/or geo-political information about the location of the place. The existing element is available to provide a brief informal description of the nature of a place. In addition, three new elements have been proposed: , and , which all have similar content models to their counterparts within . To take a fairly simple example: Iceland ?sland 65 00 N, 18 00 W 103,000 sq km Constitutional republic Previously part of the kingdom of Denmark, Iceland became independent on 17 June 1944. 3. Events There was also some discussion on the feasibility (and desirability) of developing a generic tagset for encoding assertions about events, although no real conclusion was reached. M. J. Driscoll From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Mar 18 07:20:50 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sun, 18 Mar 2007 20:20:50 +0800 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> Message-ID: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Thanks Matthew. I have one quick question below Matthew James Driscoll wrote: > > does that mean you also proposa a listNym for TEI? > Our principal task at this meeting was to develop mechanisms for encoding > place-names, analogous to those which were developed for personal names at > the meeting in Oxford last year, which would allow for the recording of > abstracted information about a place, such as map coordinate, GIS > information etc., as well as variant forms of the name, in different > languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g. > Lundunum, London). On the analogy with , we propose a > element, which will usually contain at least one, and possibly several, > elements, followed by one or more elements to provide > geographical and/or geo-political information about the location of the > place. Why would you need more than one ? I had the impression that the place is what stays constant? Is it because it also stands in for the geopolitical information? However, if we talk about administrative geography here, you will also have to account for changes in the size and super/sub components of a place and a way to link this to coordinates defining the polygon. Would the tagset be up to this task? And I guess you would need to say something about how the coordinates are expressed, otherwise your fancy GPS equipment (or Google Maps for that matter) wouldn't be able to do anything with it. > > Iceland > ?sland > 65 00 N, 18 00 W > 103,000 sq km Here you seem to point to a point with the extension of 103 000 sq km?! > Constitutional > republic > Previously part of the kingdom of > Denmark, Iceland became independent > on 17 June 1944. > best, chw -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Sun Mar 18 11:13:44 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 18 Mar 2007 16:13:44 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD6538.1060002@computing-services.oxford.ac.uk> Christian Wittern wrote: > Matthew James Driscoll wrote: >> >> > > does that mean you also proposa a listNym for TEI? > > Yes. Matthew's report doesn't mention that there is a draft ODD, probably because I have not yet got round to putting it anywhere where Council members can see it easily. But if you look in the P5/Test directory on sourceforge, you will see a file called testndextra.odd, which contains the current state of the draft. I've just put a copy of the HTML generated from this by Roma on the website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep this up to date as the draft progresses >> Our principal task at this meeting was to develop mechanisms for >> encoding >> place-names, analogous to those which were developed for personal >> names at >> the meeting in Oxford last year, which would allow for the recording of >> abstracted information about a place, such as map coordinate, GIS >> information etc., as well as variant forms of the name, in different >> languages (e.g. Praha, Prague, Praga) and/or different forms over >> time (e.g. >> Lundunum, London). On the analogy with , we propose a >> element, which will usually contain at least one, and possibly several, >> elements, followed by one or more elements to >> provide >> geographical and/or geo-political information about the location of the >> place. > > Why would you need more than one ? I had the impression > that the place is what stays constant? Is it because it also stands in > for the geopolitical information? Because a place might be located in more than one way (e.g. by its geopolitical status, or by its co-ordinates), and may also move its location over time. > However, if we talk about administrative geography here, you will also > have to account for changes in the size and super/sub components of a > place and a way to link this to coordinates defining the polygon. > Would the tagset be up to this task? probably... because we embed GML! From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 18 11:21:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Mar 2007 16:21:19 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD66FF.7060805@oucs.ox.ac.uk> Christian Wittern wrote: > However, if we talk about administrative geography here, you will > also have to account for changes in the size and super/sub components > of a place and a way to link this to coordinates defining the > polygon. Would the tagset be up to this task? > And I guess you would need to say something about how the coordinates > are expressed, otherwise your fancy GPS equipment (or Google Maps for > that matter) wouldn't be able to do anything with it. the testndextra.xml file, which is the test file for testndextra.odd (Matthew, Lou - don't forget that important file) has an example of GML: 41.876143755230956 12.479267120361328 This describes a point, but obviously a polygon would be just as easy (!) to encode. Translating that to KML for eg Google Maps / Earth would be trivial. It was clear at the meeting that we could not (must not) think out a TEI scheme for serious GIS work, and GML seemed the likeliest contender as the drop in. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 18 11:44:44 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Mar 2007 16:44:44 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FD6C7C.1040109@oucs.ox.ac.uk> to follow up, http://www.ogleearth.com/2005/11/convert_gml_to.html has pointers to a "real" GML file, and notes on converting that to KML. perhaps important to say that I at least imagine this is is like using RELAXNG in ODD - it is what we use, but it is not mandated. You could equally embed KML in the element. The assumption is that you will switch to a special namespace if you want to play scientific data with the big boys. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Sun Mar 18 19:05:19 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 08:05:19 +0800 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD66FF.7060805@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> <45FD66FF.7060805@oucs.ox.ac.uk> Message-ID: <45FDD3BF.4020209@kanji.zinbun.kyoto-u.ac.jp> Sebastian Rahtz wrote: > > > srsName="urn:ogc:def:crs:EPSG:6.6:4326"> > 41.876143755230956 12.479267120361328 > > > > This describes a point, but obviously a polygon would be just > as easy (!) to encode. Thanks. That looks good enough for a start. > It was clear at the meeting that we could not (must not) think out a TEI > scheme > for serious GIS work, and GML seemed the likeliest contender as the drop > in. Thats what I expected :-) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 19 04:33:31 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 17:33:31 +0800 Subject: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> Christian Wittern wrote: > Dear Council members, > > Here is the draft agenda. The time is still 1200 UTC, but your local > time may have changed relative to it, so please pay attention. > > > DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at > 1200 UTC I got the date wrong, sorry: The telecon is *today* Monday March 19! Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From mjd at hum.ku.dk Mon Mar 19 05:50:59 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 19 Mar 2007 11:50:59 +0100 Subject: [tei-council] Physical bibliography Message-ID: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk> I was asked (or volunteered, I can't remember) many moons ago to look at the draft proposal for marking up the physical structure of books and manuscripts (PB), and propose alternative solutions in cases where I found the markup unnecessarily verbose. Having now finally done so, I see that my alternative solutions are essentially the same as those proposed by Dot in a posting to the council on 2 August 2006, viz. replacing the bulk of the elements with attributes. So, according to Dot and me, instead of: A C 4 one could have I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be acoommodated through the magic of Unicode. The insertion and cancellation of leaves should also be easily dealt with, e.g. The same applies to . Format, signature alphabet and other things where there is a finite number of possibilities could also be dealt with using attributes. Matthew From laurent.romary at loria.fr Mon Mar 19 06:16:13 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 19 Mar 2007 12:16:13 +0100 Subject: !SPAM? Re: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <06315B31-C224-49A1-8BD0-31DF97DE588C@loria.fr> Then I cannit make it... I would have been free on 23rd, but I give a talk exactly at that time (entitled: "do we need librarians?" for those of you who want to send tomatoes at me. Laurent Le 19 mars 07 ? 10:33, Christian Wittern a ?crit : > Christian Wittern wrote: >> Dear Council members, >> >> Here is the draft agenda. The time is still 1200 UTC, but your local >> time may have changed relative to it, so please pay attention. >> >> >> DRAFT Agenda for the TEI Council teleconference on January 23, >> 2007 at >> 1200 UTC > > I got the date wrong, sorry: The telecon is *today* Monday March 19! > > Christian > > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Mar 19 06:25:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 19 Mar 2007 19:25:11 +0800 Subject: [tei-council] Re: !SPAM? Re: telecon today (March 19)! In-Reply-To: <06315B31-C224-49A1-8BD0-31DF97DE588C@loria.fr> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> <06315B31-C224-49A1-8BD0-31DF97DE588C@loria.fr> Message-ID: <45FE7317.4020508@kanji.zinbun.kyoto-u.ac.jp> Laurent Romary wrote: > Then I cannit make it... I would have been free on 23rd, but I give a > talk exactly at that time (entitled: "do we need librarians?" for those > of you who want to send tomatoes at me. > Laurent That was the 23rd of January, when we decided on the date for today -- you had no conflicts at that time. It would be helpful if you could post directions etc. for the Berlin meeting asap. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From dporter at uky.edu Mon Mar 19 06:36:06 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 07:36:06 -0400 Subject: [tei-council] Physical bibliography In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk> References: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk> Message-ID: <96f3df640703190436w49e7447cnd2daf5e70305bb3d@mail.gmail.com> Matthew and Council, After posting my PB suggestions to the council list, Lou and I raised a discussion on the PB workgroup listserv about modifying their recommendations to incorporate some of our suggestions. The workgroup chair, Murray McGillivray, expressed his disapproval of replacing the elements with attributes and I don't think anyone else in the workgroup had anything to contribute. We didn't get much farther than this. At the last council call we decided to table PB for now, should we consider putting it back on the table for the Berlin meeting? Dot On 3/19/07, Matthew James Driscoll wrote: > I was asked (or volunteered, I can't remember) many moons ago to look at the > draft proposal for marking up the physical structure of books and > manuscripts (PB), and propose alternative solutions in cases where I found > the markup unnecessarily verbose. Having now finally done so, I see that my > alternative solutions are essentially the same as those proposed by Dot in a > posting to the council on 2 August 2006, viz. replacing the bulk of the > elements with attributes. So, according to Dot and me, instead of: > > > A > C > 4 > > > one could have > > > > I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be > acoommodated through the magic of Unicode. > > The insertion and cancellation of leaves should also be easily dealt with, > e.g. > > missing="C2"/> > > The same applies to . Format, signature alphabet and other things > where there is a finite number of possibilities could also be dealt with > using attributes. > > Matthew > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From lou.burnard at computing-services.oxford.ac.uk Mon Mar 19 06:43:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Mar 2007 11:43:17 +0000 Subject: [tei-council] Physical bibliography In-Reply-To: <96f3df640703190436w49e7447cnd2daf5e70305bb3d@mail.gmail.com> References: <5FA95E40EE2AD51190380090272724BB0EF4744B@humxsrv1.hum.ku.dk> <96f3df640703190436w49e7447cnd2daf5e70305bb3d@mail.gmail.com> Message-ID: <45FE7755.6080801@oucs.ox.ac.uk> This is my recollection too. The problem, as noted before, is that this is effectively a workgroup of one member. Someone should nevertheless revisit Murray's counter arguments to see whether they have any substance. I assume they're still accessible from the Brown listserv archive Syd? Dot Porter wrote: > Matthew and Council, > > After posting my PB suggestions to the council list, Lou and I raised > a discussion on the PB workgroup listserv about modifying their > recommendations to incorporate some of our suggestions. The workgroup > chair, Murray McGillivray, expressed his disapproval of replacing the > elements with attributes and I don't think anyone else in the > workgroup had anything to contribute. We didn't get much farther than > this. At the last council call we decided to table PB for now, should > we consider putting it back on the table for the Berlin meeting? > > Dot > > On 3/19/07, Matthew James Driscoll wrote: >> I was asked (or volunteered, I can't remember) many moons ago to look >> at the >> draft proposal for marking up the physical structure of books and >> manuscripts (PB), and propose alternative solutions in cases where I >> found >> the markup unnecessarily verbose. Having now finally done so, I see >> that my >> alternative solutions are essentially the same as those proposed by >> Dot in a >> posting to the council on 2 August 2006, viz. replacing the bulk of the >> elements with attributes. So, according to Dot and me, instead of: >> >> >> A >> C >> 4 >> >> >> one could have >> >> >> >> I'm assuming non-Latin, e.g. Greek and Hebrew, signatures can easily be >> acoommodated through the magic of Unicode. >> >> The insertion and cancellation of leaves should also be easily dealt >> with, >> e.g. >> >> > missing="C2"/> >> >> The same applies to . Format, signature alphabet and other >> things >> where there is a finite number of possibilities could also be dealt with >> using attributes. >> >> Matthew >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > From dporter at uky.edu Mon Mar 19 07:06:23 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 08:06:23 -0400 Subject: [tei-council] Council phone # for US Message-ID: <96f3df640703190506g40887785k114883ffa7cadf97@mail.gmail.com> Council members in the US, The call in number for the highspeedconferencing.com has changed. Instead of the phone number in the draft agenda message, please call 605-475-8500 If you call the number in the email, they'll give you this phone #... Dot -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From Conal.Tuohy at vuw.ac.nz Mon Mar 19 07:10:12 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 20 Mar 2007 00:10:12 +1200 Subject: [tei-council] conformance draft Message-ID: I have read JC's "conformance" draft and I like it very much. Thanks James! I have one comment there about the use of namespaces in "renaming" schemas. There is a kind of "loophole" there which I think should be tightened. Renaming subset schema is defined on page 4 http://www.tei-c.org/Council/conformance-draft.pdf#page=4 The section on namespaces is on page 6 http://www.tei-c.org/Council/conformance-draft.pdf#page=6 If I read it correctly it seems to imply that Renaming Subset Schemas should have a special exemption to allow them to define new names in the TEI namespace, if it does so using to relate them to existing elements. TEI-Conformant documents must not extend the TEI Namespace with additional elements and attributes except by means of a TEI Renaming Subset Schema produced from a TEI ODD file which properly documents the renamed elements or attributes through the use of the element. It seems to me that a schema which renames an existing TEI element should do so in a new namespace. The semantics of the renamed element are the same as before, of course, but I'm not sure that automatically implies that the new element should belong to the TEI namespace. The issue to me is whether we should allow anyone to add names to the TEI namespace, and the question of whether those names are just new names for old elements or new names for new elements is not really relevant. The relevant question, to my mind, is whether those names are defined by someone independently of the official TEI schema development process. My rule of thumb is: if multiple people are defining names in the same namespace, then they should be coordinated; if they are not coordinated, then they should use distinct namespaces, otherwise there is a risk of collision. e.g. if I rename tei:div1 to tei:book, and someone else renames tei:text to tei:book, then we have a name collision. Whereas if I rename tei:div1 to my:book, and someone else renames tei:text to their:book then there's no conflation (assuming that my: and their: are prefixes bound to distinct namespace URIs, of course). It is true that by using the ODD, it should be possible to convert an instance of a Renaming Subset Schema to regular TEI, and this is a way around the issue. NB this does require that the instance documents are linked to their ODD in some way, and we'd also need to actually have such an equiv-based translator (I assume this would be quite an easy task? has it been done?). NB if different namespaces were used, it would be possible to perform such translations on an instance document, even if they had no link to their ODD file, since it would be possible to recognise my:book and their:book by their namespace URIs, without having to refer to "my.odd" amd "their.odd". On a similar subject: shouldn't the official TEI translations of element names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for the Spanish translation? Cheers Con From dporter at uky.edu Mon Mar 19 07:13:04 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 08:13:04 -0400 Subject: [tei-council] facsimile ODD Message-ID: <96f3df640703190513s7468e833s6f7675345fc14ca6@mail.gmail.com> Facsimile ODD is on the wiki: http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 07:20:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 12:20:19 +0000 Subject: [tei-council] Council phone # for US In-Reply-To: <96f3df640703190506g40887785k114883ffa7cadf97@mail.gmail.com> References: <96f3df640703190506g40887785k114883ffa7cadf97@mail.gmail.com> Message-ID: <45FE8003.1020801@oucs.ox.ac.uk> Is anyone trying to get in and failing? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From Conal.Tuohy at vuw.ac.nz Mon Mar 19 08:00:33 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 20 Mar 2007 01:00:33 +1200 Subject: [tei-council] text and image encoding Message-ID: I'm sorry to report that Dot and I have not made as much progress as we should have on this work item: http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/291 After the last teleconference I posted the ODD to the Wiki: http://www.tei-c.org.uk/wiki/index.php/FacsimileMarkupODD Since then we've been working on it sporadically, but we haven't yet updated the Wiki with anything new. I have mostly integrated the discursive text into the ODD (locally), and I expect to have finished that tomorrow-ish, and upload it. I've also been working on making test instance documents by generating them from PDF using the open source pdftohtml tool. We have been looking at the Image Markup Tool and looking at the Edition Production Technology system, to see how they relate to the draft. The current draft has two mechanisms each of which correspond pretty well to these two different schemes. The IMT schema essentially defines regions of images (using svg) and uses div elements as annotations of those regions, linking from the div/@n to the svg:rect/@id. This is a bit implicit and informal, but structurally it maps closely to our draft: we have a region element which is the equivalent of a rect. In our schema, an annotation could be done as a note linking to the region. The EPT system is more about linking text to graphical images of the text, and that also maps pretty well, using the @left, @right, etc attributes. From lou.burnard at computing-services.oxford.ac.uk Mon Mar 19 10:35:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 19 Mar 2007 15:35:42 +0000 Subject: [tei-council] Notes from this morning's call Message-ID: <45FEADCE.8000003@oucs.ox.ac.uk> Brief notes from this morning's call are now up at http://www.tei-c.org/Council/tcm29.xml?style=printable L From James.Cummings at oucs.ox.ac.uk Mon Mar 19 10:56:07 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 19 Mar 2007 15:56:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: References: Message-ID: <45FEB297.1000906@oucs.ox.ac.uk> Conal Tuohy wrote: > I have read JC's "conformance" draft and I like it very much. Thanks James! You're welcome, but I'm sure not everyone will be so positive. :-) I know for a fact that a number of people don't like this moral high ground of namespaces. > I have one comment there about the use of namespaces in "renaming" schemas. > There is a kind of "loophole" there which I think should be tightened. I think I understand the loophole to which you refer, but might wish to tighten it in a different way. > If I read it correctly it seems to imply that Renaming Subset Schemas should > have a special exemption to allow them to define new names in the TEI > namespace, if it does so using to relate them to existing elements. I'd say that these aren't 'new' elements, they are simply 'renamed' elements, syntactic sugar if you like. > TEI-Conformant documents must not extend the TEI Namespace with > additional elements and attributes except by means of a TEI Renaming Subset > Schema produced from a TEI ODD file which properly documents the renamed > elements or attributes through the use of the element. It > seems to me that a schema which renames an existing TEI element should do so > in a new namespace. The semantics of the renamed element are the same as > before, of course, but I'm not sure that automatically implies that the new > element should belong to the TEI namespace. The issue to me is whether we > should allow anyone to add names to the TEI namespace, and the question of > whether those names are just new names for old elements or new names for new > elements is not really relevant. The relevant question, to my mind, is > whether those names are defined by someone independently of the official TEI > schema development process. My rule of thumb is: if multiple people are > defining names in the same namespace, then they should be coordinated; if > they are not coordinated, then they should use distinct namespaces, otherwise > there is a risk of collision. Ok, I understand that. Perhaps we should be distinguishing here between local processing documents and those for 'interchange'. We could say that a document which validates against a TEI Renaming Subset schema should only be interchanged with others when the changes have been reversed? > > e.g. if I rename tei:div1 to tei:book, and someone else renames tei:text to > tei:book, then we have a name collision. Whereas if I rename tei:div1 to > my:book, and someone else renames tei:text to their:book then there's no > conflation (assuming that my: and their: are prefixes bound to distinct > namespace URIs, of course). I don't think there is an assumption that documents validating against different TEI Renaming Subsets are in any way compatible or interoperable. Perhaps we should tighten up the language to make sure. Documents validating against any individual TEI Renaming Subset schema don't have this problem, do they? This only occurs when I try to combine your documents with my documents? Conformance shouldn't imply interoperability... but two people with documents that validate against a TEI Renaming Subset *can* interchange documents as long as they convert them back to TEI Pure Subset first. > On a similar subject: shouldn't the official TEI translations of element > names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for > the Spanish translation? I'll leave that one to Sebastian, he wot knows internationalisation. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Mon Mar 19 11:57:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 19 Mar 2007 12:57:57 -0400 Subject: telecon today (March 19)! (was: Re: [tei-council] DRAFT Agenda for the TEI Council teleconference on January 23, 2007 at 1200 UTC) In-Reply-To: <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17918.49429.959292.434527@emt.wwp.brown.edu> Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got duped by the incorrect date, and didn't read Christian's correction until after the call was over. (I found out by desperately trying to dial in 1st one Skype number, then the other, then the direct US number, inadvertantly dialing Dan directly someplace in there ... ah, well. :-) Again, my apologies, and thanks to those who did make it for carrying on, and to Lou for a nice and rapid job on the minutes. From djbpitt+tei at pitt.edu Mon Mar 19 12:08:35 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 19 Mar 2007 13:08:35 -0400 Subject: [tei-council] Re: telecon today (March 19)! In-Reply-To: <17918.49429.959292.434527@emt.wwp.brown.edu> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> <17918.49429.959292.434527@emt.wwp.brown.edu> Message-ID: <45FEC393.4090102@pitt.edu> Dear Council, Sorry here, too. Still stranded this morning in the Philadelphia airport by the ice storm that had shut everything down on Saturday (home now, but hour too late). Best, David Syd Bauman wrote: > Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got > duped by the incorrect date, and didn't read Christian's correction > until after the call was over. (I found out by desperately trying to > dial in 1st one Skype number, then the other, then the direct US > number, inadvertantly dialing Dan directly someplace in there ... ah, > well. :-) > > Again, my apologies, and thanks to those who did make it for carrying > on, and to Lou for a nice and rapid job on the minutes. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From daniel.odonnell at uleth.ca Mon Mar 19 12:10:28 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Mon, 19 Mar 2007 11:10:28 -0600 Subject: [tei-council] Re: telecon today (March 19)! In-Reply-To: <45FEC393.4090102@pitt.edu> References: <45FA52F3.4020501@kanji.zinbun.kyoto-u.ac.jp> <45FE58EB.1030802@kanji.zinbun.kyoto-u.ac.jp> <17918.49429.959292.434527@emt.wwp.brown.edu> <45FEC393.4090102@pitt.edu> Message-ID: <1174324228.19319.0.camel@odonned-eng06> Wait till you guys see the action items we assigned you ;) -dan On Mon, 2007-19-03 at 13:08 -0400, David J Birnbaum wrote: > Dear Council, > > Sorry here, too. Still stranded this morning in the Philadelphia airport > by the ice storm that had shut everything down on Saturday (home now, > but hour too late). > > Best, > > David > > Syd Bauman wrote: > > Oh, man. Really sorry, guys. In my jet-lagged and head-cold fog I got > > duped by the incorrect date, and didn't read Christian's correction > > until after the call was over. (I found out by desperately trying to > > dial in 1st one Skype number, then the other, then the direct US > > number, inadvertantly dialing Dan directly someplace in there ... ah, > > well. :-) > > > > Again, my apologies, and thanks to those who did make it for carrying > > on, and to Lou for a nice and rapid job on the minutes. > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From dporter at uky.edu Mon Mar 19 13:36:16 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 19 Mar 2007 14:36:16 -0400 Subject: [tei-council] Notes from this morning's call In-Reply-To: <45FEADCE.8000003@oucs.ox.ac.uk> References: <45FEADCE.8000003@oucs.ox.ac.uk> Message-ID: <96f3df640703191136y74004ceay9bf25f7d5adf5822@mail.gmail.com> Hi Lou, Thanks for posting the minutes so quickly. Just a small note - I wasn't responsible in any way for the Conformance draft, that's all James' work. Dot On 3/19/07, Lou Burnard wrote: > Brief notes from this morning's call are now up at > http://www.tei-c.org/Council/tcm29.xml?style=printable > > L > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From djbpitt+tei at pitt.edu Mon Mar 19 15:47:59 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Mon, 19 Mar 2007 16:47:59 -0400 Subject: [tei-council] conformance draft In-Reply-To: <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> References: <45F92E3C.6040505@oucs.ox.ac.uk> <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <45FEF6FF.9040800@pitt.edu> Dear Council, > >> This enables me to announce that James has just delivered a >> preliminary draft for the Conformance chapter of P5, which should be >> on our agenda for next week. You can read the draft at >> >> http://www.tei-c.org/Council/conformance-draft.pdf Thanks, James; this looks very good! Just a few minor details (some of which may reflect my ignorance of British English): Section 1.2.5: extra "a" in "the TEI provides a web-based tools and scripts" Section 1.3.1 (under tei_allPlus): spurious "the" in "but also the demonstrates" Section 1.3.1 (under tei_bare): "the very basic ... possible" in "provides the very basic minimum TEI possible" is bad in American English. If it's okay in British English, so be it, but if it's bad there too, you might want to change it to "the most basic ... possible." Section 1.3.1 (under teilite): "It can be a useful starting point for those who want to add or remove only a few aspects to TEI Lite." There's nothing wrong with this, but because we spent many years telling people "don't customize TEI Lite" and feeling exasperated when they didn't listen that we might want to add a footnote explaining why it's a new world now. Section 1.3.1 (under tei_odds): "This includes not only the TEI module for documentation elements, but the external Relax NG schema." American English requires an "also" after the "but." If British English doesn't, so be it. Section 1.3.1 (under tei_svg): "the minimum basic four TEI modules" is the first time we mention that there are four basic modules. Should we list them here, on first reference, in a footnote? Section 1.3.1 (under tei_xinclude): "set up" in "This example has been setup ..." should be two words. This whole sentence is a bit awkward; "has been set up ... and allows" is nonparallel and there's a comma splice at the end. Section 1.3.2 (under TEI Extension Schema): Comma splice in "The relationship of any extensions to the TEI should be documented in a TEI ODD file, additionally all renamings of existing TEI elements and attributes should be documented with an element to an existing TEI Pure Subset schema equivalent for them." Section 1.3.3.3: missing space in "customization is" Section 1.4: "It is a requirement of TEI Conformance that, in a TEI-Conformant document, all existing TEI elements and attributes are in the TEI Namespace" should read "be" instead of "are" Section 1.4: Hyphenate the attributive adjective "user-defined" in "a user-defined one". It is hyphenated correctly later in the same paragraph: "In choosing user-defined namespaces ..." Throughout: Failure to distinguish restrictive and nonrestrictive clauses (use of commas and use of which/that). I'm a pedant about such matters; if you don't care, just ignore me and I'll try not to rant. Cheers, David From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 17:15:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 22:15:59 +0000 Subject: [tei-council] cleaning up trac Message-ID: <45FF0B9F.5090100@oucs.ox.ac.uk> As per council meeting action today, I have checked the tracker, moved some tickets, closed some tickets, and clarified some tickets. In summary: * 6 tickets now outstanding in the "left over from SF" category. these are all assigned to Lou or Syd, and really need knocking on the head ASAP. * 3 items in "make last minute technical proposals", for Conal on facsimile markup and for Lou on personography. We can expect more items to get into the "make last minute technical proposals" section; this forms an important part of the Berlin agenda; so anything which involves non-trivial changes or additions needs to have a ticket in there, and an owner, who will propose and defend it in Berlin. As a result of that, there can be 3 outcomes: a) transfer to //"Solve remaining technical issues" for resolution; b) assign to new ticket// under P5.1; or c) abandon it. This affects the editors most. The rest of the Council should be looking forward with excitement to their assigned review chapters ("first pass technical review"). I have entirely dropped a milestone which said "review datatype and class decisions". This will be merged into "first pass technical review", for simplicity. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 18:04:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 23:04:16 +0000 Subject: [tei-council] easter presents for everyone Message-ID: <45FF16F0.7080301@oucs.ox.ac.uk> As per council action today, I have made a first pass through the chapters, and assigned all the chapters to people. I have _not_ included Lou and Syd in this, as they have other tasks to complete before Berlin. I have vaguely balanced the workload depending on what else people are committed to, but not necessarily fairly; so feel free to horse trade, and complain, and wriggle. If you genuinely can't do the job at all, say so now! You can even volunteer to take on more. The assignments are made in trac. A more detailed spec of the task will follow shortly, but the essence of it is that you will read the chapter, and make a first pass review looking for stuff which is unclear, undated, or broken. So, opening the envelope, this is what you get: ariana SG: Gentle intro ariana DS: Default Text Structure ariana ND: Names and Dates christian TE: Terminological Databases christian CE: Certainty and Responsibility christian FD: Feature System Declaration conal AI: Simple Analytic Mechanisms conal FT: Tables, Formulae, and Graphics daniel DEDICATION daniel AB: About the guidelines daniel MS: The Manuscript Description Element daniel PH: Transcription of Primary Sources daniel TC: Critical Apparatus david ST: Structure of the TEI Document Type Definition david CO: Elements Available in All TEI Documents david TD: Documentation Elements dot TS: Transcriptions of Speech dot SA: Linking, Segmentation, and Alignment dot CC: Language Corpora james FM1: Preface james DR: Base Tag Set for Drama james CF: Conformance john HD: The TEI Header john VE: Base Tag Set for Verse john FS: Feature Structures laurent SH: The Independent Header laurent WD: Writing System Declaration matthew HD: The TEI Header matthew PR: Base Tag Set for Prose matthew DI: Print Dictionaries rahtz GD: Graphs, Networks, and Trees rahtz MD: Modifying and Customizing the TEI DTD rahtz IN: Rules for Interchange rahtz DT: Obtaining the TEI DTD tone CH: Languages and Character Sets tone NH: Multiple Hierarchies -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From James.Cummings at computing-services.oxford.ac.uk Mon Mar 19 18:19:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 19 Mar 2007 23:19:53 +0000 Subject: [tei-council] conformance draft In-Reply-To: <45FEF6FF.9040800@pitt.edu> References: <45F92E3C.6040505@oucs.ox.ac.uk> <45F933C3.2050400@kanji.zinbun.kyoto-u.ac.jp> <45FEF6FF.9040800@pitt.edu> Message-ID: <45FF1A99.7010003@computing-services.oxford.ac.uk> Thanks David, I'm sure you are right about almost all those. > Section 1.3.1 (under teilite): "It can be a useful starting point for > those who want to add or remove only a few aspects to TEI Lite." There's > nothing wrong with this, but because we spent many years telling people > "don't customize TEI Lite" and feeling exasperated when they didn't > listen that we might want to add a footnote explaining why it's a new > world now. Good point. > Section 1.3.1 (under tei_svg): "the minimum basic four TEI modules" is > the first time we mention that there are four basic modules. Should we > list them here, on first reference, in a footnote? Or should this have been explained elsewhere, prior to this chapter? (For example in Modification which precedes it? > Throughout: Failure to distinguish restrictive and nonrestrictive > clauses (use of commas and use of which/that). I'm a pedant about such > matters; if you don't care, just ignore me and I'll try not to rant. Yes, Canadians tend to use 'that' for restrictive relative clauses and I've always been fairly bad about distinguishing them overall. Thanks for all the grammatical corrections; I'd assumed that I'd tidy up grammar once people had agreed to the concepts, but that still should not be an excuse. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 19 18:41:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 19 Mar 2007 23:41:19 +0000 Subject: [tei-council] conformance draft In-Reply-To: <45FEB297.1000906@oucs.ox.ac.uk> References: <45FEB297.1000906@oucs.ox.ac.uk> Message-ID: <45FF1F9F.3030101@oucs.ox.ac.uk> James Cummings wrote: > >> On a similar subject: shouldn't the official TEI translations of element >> names also use distinct namespaces? e.g. "http://www.tei-c.org/ns/1.0#es" for >> the Spanish translation? >> > > I'll leave that one to Sebastian, he wot knows internationalisation. > the translations are simply a convenience canned example of a "TEI Renaming Subset", so I don't think they need special treatment. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 OSS Watch: JISC Open Source Advisory Service http://www.oss-watch.ac.uk From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Mar 20 02:27:11 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 20 Mar 2007 15:27:11 +0800 Subject: [tei-council] Notes from this morning's call In-Reply-To: <45FEADCE.8000003@oucs.ox.ac.uk> References: <45FEADCE.8000003@oucs.ox.ac.uk> Message-ID: <45FF8CCF.2050506@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > Brief notes from this morning's call are now up at > http://www.tei-c.org/Council/tcm29.xml?style=printable Great. They look complete to me. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 06:13:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 11:13:52 +0000 Subject: [tei-council] New draft editorial guidelines Message-ID: <46011370.4070608@oucs.ox.ac.uk> As a preliminary to unwrapping the easter egg Sebastian has just offered you all, Council members might like to have a quick read through the document on Editorial Guidelines which I posted on the web yesterday. It's at http://www.tei-c.org/Drafts/editorial.xml The document is an updating of sage advice prepared by the TEI Editors in days of yore (i.e. about 9 years ago) and still accessible in the Vault as edw55.tei if you don't believe me. I have added a little about how I think we ought to do things now, and removed anything which is definitely superannuated, but the important parts of the "house rules" for writing P5 are unchanged. Please bear them in mind as you review your chapters! I'd be grateful for suggestions as to (a) rules missing from the document which should be added (b) rules which we no longer believe in. Note that a biggish chunk of the document is taken from one of the chapters of the Guidelines (AB), so the two need to be kept in step. From wittern at kanji.zinbun.kyoto-u.ac.jp Wed Mar 21 07:15:47 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 21 Mar 2007 20:15:47 +0800 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46011370.4070608@oucs.ox.ac.uk> References: <46011370.4070608@oucs.ox.ac.uk> Message-ID: <460121F3.4030103@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > As a preliminary to unwrapping the easter egg Sebastian has just offered > you all, Council members might like to have a quick read through the > document on Editorial Guidelines which I posted on the web yesterday. > It's at http://www.tei-c.org/Drafts/editorial.xml Ahem, trying to look at this gives me: The content of elements must consist of well-formed character data or markup. org.apache.cocoon.ProcessingException: Error executing pipeline.: file:/home12/tei/web/Drafts/editorial.xml:463:35:org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From daniel.odonnell at uleth.ca Wed Mar 21 09:17:42 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 08:17:42 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46011370.4070608@oucs.ox.ac.uk> References: <46011370.4070608@oucs.ox.ac.uk> Message-ID: <1174486662.32123.7.camel@caedmon> Gettinng a different cocoon error than the one Christian reported, but a cocoon error none the less. On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote: > As a preliminary to unwrapping the easter egg Sebastian has just offered > you all, Council members might like to have a quick read through the > document on Editorial Guidelines which I posted on the web yesterday. > It's at http://www.tei-c.org/Drafts/editorial.xml > > The document is an updating of sage advice prepared by the TEI Editors > in days of yore (i.e. about 9 years ago) and still accessible in the > Vault as edw55.tei if you don't believe me. I have added a little about > how I think we ought to do things now, and removed anything which is > definitely superannuated, but the important parts of the "house rules" > for writing P5 are unchanged. Please bear them in mind as you review > your chapters! > > I'd be grateful for suggestions as to (a) rules missing from the > document which should be added (b) rules which we no longer believe in. > > Note that a biggish chunk of the document is taken from one of the > chapters of the Guidelines (AB), so the two need to be kept in step. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 09:23:46 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 14:23:46 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> Message-ID: <46013FF2.9030806@oucs.ox.ac.uk> Sorry -- my error. I introduced a typo making some other fixes spotted by Sebastian this morning. Shd be ok now. Daniel O'Donnell wrote: > Gettinng a different cocoon error than the one Christian reported, but a > cocoon error none the less. > > On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote: >> As a preliminary to unwrapping the easter egg Sebastian has just offered >> you all, Council members might like to have a quick read through the >> document on Editorial Guidelines which I posted on the web yesterday. >> It's at http://www.tei-c.org/Drafts/editorial.xml >> From laurent.romary at loria.fr Wed Mar 21 09:23:21 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 21 Mar 2007 15:23:21 +0100 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> Message-ID: <6DA197E5-A179-4BA8-996E-DB471A15E940@loria.fr> No error on my side... I have printed and read the document all right. Cheers, Laurent Le 21 mars 07 ? 15:17, Daniel O'Donnell a ?crit : > Gettinng a different cocoon error than the one Christian reported, > but a > cocoon error none the less. > > On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote: >> As a preliminary to unwrapping the easter egg Sebastian has just >> offered >> you all, Council members might like to have a quick read through >> the >> document on Editorial Guidelines which I posted on the web yesterday. >> It's at http://www.tei-c.org/Drafts/editorial.xml >> >> The document is an updating of sage advice prepared by the TEI >> Editors >> in days of yore (i.e. about 9 years ago) and still accessible in the >> Vault as edw55.tei if you don't believe me. I have added a little >> about >> how I think we ought to do things now, and removed anything which is >> definitely superannuated, but the important parts of the "house >> rules" >> for writing P5 are unchanged. Please bear them in mind as you review >> your chapters! >> >> I'd be grateful for suggestions as to (a) rules missing from the >> document which should be added (b) rules which we no longer >> believe in. >> >> Note that a biggish chunk of the document is taken from one of the >> chapters of the Guidelines (AB), so the two need to be kept in step. >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- > Daniel Paul O'Donnell, PhD > Department Chair and Associate Professor of English > Director, Digital Medievalist Project http:// > www.digitalmedievalist.org/ > Chair, Text Encoding Initiative http://www.tei-c.org/ > > Department of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Vox +1 403 329-2377 > Fax +1 403 382-7191 > Email: daniel.odonnell at uleth.ca > WWW: http://people.uleth.ca/~daniel.odonnell/ > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From daniel.odonnell at uleth.ca Wed Mar 21 10:18:26 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 09:18:26 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174486662.32123.7.camel@caedmon> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> Message-ID: <1174490306.32123.72.camel@caedmon> http://www.tei-c.org/Drafts/editorial.xml: 503: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. On Wed, 2007-03-21 at 08:17 -0600, Daniel O'Donnell wrote: > Gettinng a different cocoon error than the one Christian reported, but a > cocoon error none the less. > > On Wed, 2007-03-21 at 11:13 +0000, Lou Burnard wrote: > > As a preliminary to unwrapping the easter egg Sebastian has just offered > > you all, Council members might like to have a quick read through the > > document on Editorial Guidelines which I posted on the web yesterday. > > It's at http://www.tei-c.org/Drafts/editorial.xml > > > > The document is an updating of sage advice prepared by the TEI Editors > > in days of yore (i.e. about 9 years ago) and still accessible in the > > Vault as edw55.tei if you don't believe me. I have added a little about > > how I think we ought to do things now, and removed anything which is > > definitely superannuated, but the important parts of the "house rules" > > for writing P5 are unchanged. Please bear them in mind as you review > > your chapters! > > > > I'd be grateful for suggestions as to (a) rules missing from the > > document which should be added (b) rules which we no longer believe in. > > > > Note that a biggish chunk of the document is taken from one of the > > chapters of the Guidelines (AB), so the two need to be kept in step. > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 10:27:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 15:27:35 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <1174490306.32123.72.camel@caedmon> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> <1174490306.32123.72.camel@caedmon> Message-ID: <46014EE7.8060601@oucs.ox.ac.uk> Nothing to do with me guvnor. That's a virginian problem affecting the whole website (which was OK about 15 minutes ago...) Still, it's better than the (lack of) messages we were getting last time someone fell over the power cable or spilled coffee into the disk array or whatever their problem is. Daniel O'Donnell wrote: > http://www.tei-c.org/Drafts/editorial.xml: > > 503: Service Temporarily Unavailable > The server is temporarily unable to service your request due to > maintenance downtime or capacity problems. Please try again later. > -council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From arianna.ciula at kcl.ac.uk Wed Mar 21 10:57:54 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 21 Mar 2007 15:57:54 +0000 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46014EE7.8060601@oucs.ox.ac.uk> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> <1174490306.32123.72.camel@caedmon> <46014EE7.8060601@oucs.ox.ac.uk> Message-ID: <46015602.4070600@kcl.ac.uk> If we continue to get the error could you please make the document available in some other ways? Thanks, Arianna Lou Burnard wrote: > Nothing to do with me guvnor. That's a virginian problem affecting the > whole website (which was OK about 15 minutes ago...) > > Still, it's better than the (lack of) messages we were getting last time > someone fell over the power cable or spilled coffee into the disk array > or whatever their problem is. > > Daniel O'Donnell wrote: >> http://www.tei-c.org/Drafts/editorial.xml: >> >> 503: Service Temporarily Unavailable >> The server is temporarily unable to service your request due to >> maintenance downtime or capacity problems. Please try again later. >> > -council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Wed Mar 21 12:10:44 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 21 Mar 2007 11:10:44 -0600 Subject: [tei-council] New draft editorial guidelines In-Reply-To: <46015602.4070600@kcl.ac.uk> References: <46011370.4070608@oucs.ox.ac.uk> <1174486662.32123.7.camel@caedmon> <1174490306.32123.72.camel@caedmon> <46014EE7.8060601@oucs.ox.ac.uk> <46015602.4070600@kcl.ac.uk> Message-ID: <1174497044.5280.4.camel@caedmon> I've contacted the powers that be to get it fixed. On Wed, 2007-03-21 at 15:57 +0000, Arianna Ciula wrote: > If we continue to get the error could you please make the document > available in some other ways? > > Thanks, > Arianna > > Lou Burnard wrote: > > Nothing to do with me guvnor. That's a virginian problem affecting the > > whole website (which was OK about 15 minutes ago...) > > > > Still, it's better than the (lack of) messages we were getting last time > > someone fell over the power cable or spilled coffee into the disk array > > or whatever their problem is. > > > > Daniel O'Donnell wrote: > >> http://www.tei-c.org/Drafts/editorial.xml: > >> > >> 503: Service Temporarily Unavailable > >> The server is temporarily unable to service your request due to > >> maintenance downtime or capacity problems. Please try again later. > >> > > -council at lists.village.Virginia.EDU > >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 12:25:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 17:25:19 +0000 Subject: [tei-council] Re: 503 error on tei-c In-Reply-To: <1174496976.5280.2.camel@caedmon> References: <1174496976.5280.2.camel@caedmon> Message-ID: <46016A7F.7000501@oucs.ox.ac.uk> As there appear to be problems with the Virginia site again this afternoon, council members may wish to access the UK mirror instead http://www.tei-c.org.uk/Drafts/editorial.xml (there was a brief hiatus here this afternoon while we did some local updating but it's back now) Lou Daniel O'Donnell wrote: > Hi Shayne, > > There's a 503 error on the tei site: > http://www.tei-c.org/Drafts/editorial.xml > > The council is using this as a guideline for review in preparation for > our upcoming meeting, so we will need to get it back up. > > -dan From lou.burnard at computing-services.oxford.ac.uk Wed Mar 21 18:22:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 21 Mar 2007 23:22:05 +0000 Subject: [tei-council] Witness proposal Message-ID: <4601BE1D.3010403@computing-services.oxford.ac.uk> In early november last year, Gautier Poupeau whom several of you will recall from his presentation at the Members meeting, sent me a document outlining a proposal to address the inconsistency currently subsisting in the Guidelines about how manuscript (or print) witnesses should be documented. I owe him, and the Council, a major apology for having not done anything with it -- it simply got mislaid and then forgotten. Fortunately, he's a persevering kind of chap, and I have now recovered the draft and placed it somewhere you can see it, viz: http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml It's in French, so I will summarize briefly the proposal here (I will also translate the document fully if so requested) * create a new class called model.witnessPart. which is a subclass of model.phrasel; use this class in the content model of * add to this class a number of elements currently specific to msDescription, specifically: origDate, material, physDesc, seal, dimensions, filiation,msIdentifier, msContents, rubric; * re-introduce the "sigil" attribute as a new element * add a "class" attribute to The suggestion is based on Gautier's extensive experience in adapting TEI to the description of cartularies and similar documents, with due regard to practice in German, Italian, and French collections. I think the work is sufficiently straightforward to do quite quickly (i.e. it can be done for P5); I also suspect that it would be a very smart political move to be seen to be doing something in this area. Initial comments? (It occurs to me also that this might be something the newly revived mss SIG would like to kick around -- but that could happen independently of plumbing his suggestion into P5) From dporter at uky.edu Wed Mar 21 18:47:09 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 21 Mar 2007 15:47:09 -0800 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> References: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <96f3df640703211647q3f44a6e7k7dafe343624cb704@mail.gmail.com> This sounds like an interesting proposal, but I would like to know a bit more. Lou, if you could provide a translation I would appreciate it. Thanks, Dot On 3/21/07, Lou Burnard wrote: > In early november last year, Gautier Poupeau whom several of you will > recall from his presentation at the Members meeting, sent me a document > outlining a proposal to address the inconsistency currently subsisting > in the Guidelines about how manuscript (or print) witnesses should be > documented. I owe him, and the Council, a major apology for having not > done anything with it -- it simply got mislaid and then forgotten. > Fortunately, he's a persevering kind of chap, and I have now recovered > the draft and placed it somewhere you can see it, viz: > > http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml > > It's in French, so I will summarize briefly the proposal here (I will > also translate the document fully if so requested) > > * create a new class called model.witnessPart. which is a subclass of > model.phrasel; use this class in the content model of > * add to this class a number of elements currently specific to > msDescription, specifically: > origDate, material, physDesc, seal, dimensions, > filiation,msIdentifier, msContents, rubric; > * re-introduce the "sigil" attribute as a new element > * add a "class" attribute to > > The suggestion is based on Gautier's extensive experience in adapting > TEI to the description of cartularies and similar documents, with due > regard to practice in German, Italian, and French collections. > > I think the work is sufficiently straightforward to do quite quickly > (i.e. it can be done for P5); I also suspect that it would be a very > smart political move to be seen to be doing something in this area. > > Initial comments? > > (It occurs to me also that this might be something the newly revived mss > SIG would like to kick around -- but that could happen independently of > plumbing his suggestion into P5) > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From mjd at hum.ku.dk Thu Mar 22 05:16:06 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Thu, 22 Mar 2007 11:16:06 +0100 Subject: [tei-council] SV: Witness proposal Message-ID: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk> In terms of revamping , which was never a terribly sophisticated element, this proposal makes perfect sense. It is not clear to me, however, whether the newly redefined element is intended as an alternative to or whether there are situations in which one would use both. Neither appeals much to me, I must say, especially as I can't see that what is being proposed can't be done with as it is. The original idea behind , in any case, was very much that it should be able to be used for more than just cataloguing (our insistence on this was what led to the bulk of the disagreements with "TEI-MMSS"), and it was indeed my understanding that and were now to be deprecated as redundant. If there are things which Gautier, representing German, Italian and French practice, genuinely can't do using the current mechanism it would be far more useful, it seems to me, for us to try and adapt the existing mechanism, rather than coming up with a parallel one. Looking at his proposal, the chief lack seems to be a means of indicating the sigla, for which he proposes a new element; these can easily appear within as , which takes a type attribute. Otherwise the elements are largely from the module, suggesting that perhaps we aren't so far off the mark after all. Matthew -----Oprindelig meddelelse----- Fra: Lou Burnard [mailto:lou.burnard at computing-services.oxford.ac.uk] Sendt: 22 March 2007 00:22 Til: Matthew James Driscoll; TEI Council; gotpoupeau at infonie.fr Emne: Witness proposal In early november last year, Gautier Poupeau whom several of you will recall from his presentation at the Members meeting, sent me a document outlining a proposal to address the inconsistency currently subsisting in the Guidelines about how manuscript (or print) witnesses should be documented. I owe him, and the Council, a major apology for having not done anything with it -- it simply got mislaid and then forgotten. Fortunately, he's a persevering kind of chap, and I have now recovered the draft and placed it somewhere you can see it, viz: http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml It's in French, so I will summarize briefly the proposal here (I will also translate the document fully if so requested) * create a new class called model.witnessPart. which is a subclass of model.phrasel; use this class in the content model of * add to this class a number of elements currently specific to msDescription, specifically: origDate, material, physDesc, seal, dimensions, filiation,msIdentifier, msContents, rubric; * re-introduce the "sigil" attribute as a new element * add a "class" attribute to The suggestion is based on Gautier's extensive experience in adapting TEI to the description of cartularies and similar documents, with due regard to practice in German, Italian, and French collections. I think the work is sufficiently straightforward to do quite quickly (i.e. it can be done for P5); I also suspect that it would be a very smart political move to be seen to be doing something in this area. Initial comments? (It occurs to me also that this might be something the newly revived mss SIG would like to kick around -- but that could happen independently of plumbing his suggestion into P5) From dporter at uky.edu Thu Mar 22 05:40:57 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 22 Mar 2007 02:40:57 -0800 Subject: [tei-council] SV: Witness proposal In-Reply-To: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk> References: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk> Message-ID: <96f3df640703220340v2b42b2e8s4517b8b6ca52feac@mail.gmail.com> Hi Matthew and council, On 3/22/07, Matthew James Driscoll wrote: > In terms of revamping , which was never a terribly sophisticated > element, this proposal makes perfect sense. It is not clear to me, however, > whether the newly redefined element is intended as an alternative > to or whether there are situations in which one would use > both. Neither appeals much to me, I must say, especially as I can't see that > what is being proposed can't be done with as it is. This is my concern as well. Since I can't read French, I was hoping that the proposal includes some reasoning for basically placing in , rather just using (multiple instances, if need be) and linking them to the es. Thanks, Dot The > original idea behind , in any case, was very much that it > should be able to be used for more than just cataloguing (our insistence on > this was what led to the bulk of the disagreements with "TEI-MMSS"), and it > was indeed my understanding that and were now to be > deprecated as redundant. If there are things which Gautier, representing > German, Italian and French practice, genuinely can't do using the current > mechanism it would be far more useful, it seems to me, for > us to try and adapt the existing mechanism, rather than coming up with a > parallel one. > > Looking at his proposal, the chief lack seems to be a means of indicating > the sigla, for which he proposes a new element; these can easily > appear within as , which takes a type > attribute. Otherwise the elements are largely from the > module, suggesting that perhaps we aren't so far off the mark after all. > > Matthew > > > > > -----Oprindelig meddelelse----- > Fra: Lou Burnard [mailto:lou.burnard at computing-services.oxford.ac.uk] > Sendt: 22 March 2007 00:22 > Til: Matthew James Driscoll; TEI Council; gotpoupeau at infonie.fr > Emne: Witness proposal > > In early november last year, Gautier Poupeau whom several of you will > recall from his presentation at the Members meeting, sent me a document > outlining a proposal to address the inconsistency currently subsisting > in the Guidelines about how manuscript (or print) witnesses should be > documented. I owe him, and the Council, a major apology for having not > done anything with it -- it simply got mislaid and then forgotten. > Fortunately, he's a persevering kind of chap, and I have now recovered > the draft and placed it somewhere you can see it, viz: > > http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml > > It's in French, so I will summarize briefly the proposal here (I will > also translate the document fully if so requested) > > * create a new class called model.witnessPart. which is a subclass of > model.phrasel; use this class in the content model of > * add to this class a number of elements currently specific to > msDescription, specifically: > origDate, material, physDesc, seal, dimensions, > filiation,msIdentifier, msContents, rubric; > * re-introduce the "sigil" attribute as a new element > * add a "class" attribute to > > The suggestion is based on Gautier's extensive experience in adapting > TEI to the description of cartularies and similar documents, with due > regard to practice in German, Italian, and French collections. > > I think the work is sufficiently straightforward to do quite quickly > (i.e. it can be done for P5); I also suspect that it would be a very > smart political move to be seen to be doing something in this area. > > Initial comments? > > (It occurs to me also that this might be something the newly revived mss > SIG would like to kick around -- but that could happen independently of > plumbing his suggestion into P5) > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 05:57:45 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 22 Mar 2007 10:57:45 +0000 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> References: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <46026129.6030503@computing-services.oxford.ac.uk> Lou Burnard wrote: > Fortunately, he's a persevering kind of chap, and I have now recovered > the draft and placed it somewhere you can see it, viz: > > http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml > > It's in French, so I will summarize briefly the proposal here (I will > also translate the document fully if so requested) While I'm able to get the general sense from the document, I'm sure a translation would help me as well, so I'd second Dot's request. > * create a new class called model.witnessPart. which is a subclass of > model.phrasel; use this class in the content model of > * add to this class a number of elements currently specific to > msDescription, specifically: > origDate, material, physDesc, seal, dimensions, > filiation,msIdentifier, msContents, rubric; Why can't the witness instead link to an msDescription? > * re-introduce the "sigil" attribute as a new element If I'm understanding the French, the complaint is that the suggested use of xml:id is to constricting since people may wish to use existing sigla well-known in the community, but that simultaneously is too vague and generic but also won't allow some useful elements. Am I understanding that correctly? I still think I'd favour a linking mechanism from witness to msIdentifier if someone needs a more detailed identification. Maybe I'm misunderstanding the proposal though. > * add a "class" attribute to I was unable to get up the "Appendix A Liste des ?l?ments de la classe witnessPart", but if I'm understanding the prose description correctly, this attribute would be used to indicate a taxonomy used to classify that witness. Which again seems like something which should be off in msDescription I'm probably just mistranslating things though, so I look forward to Lou's translation which I know is in hand. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Thu Mar 22 05:58:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 22 Mar 2007 10:58:12 +0000 Subject: [tei-council] SV: Witness proposal In-Reply-To: <96f3df640703220340v2b42b2e8s4517b8b6ca52feac@mail.gmail.com> References: <5FA95E40EE2AD51190380090272724BB0F02F407@humxsrv1.hum.ku.dk> <96f3df640703220340v2b42b2e8s4517b8b6ca52feac@mail.gmail.com> Message-ID: <46026144.6070004@oucs.ox.ac.uk> A hasty English translation, not yet checked by Goto, is at http://www.tei-c.org/Drafts/witnessPart/index.xml?style=printable My own comments will follow... Dot Porter wrote: > Hi Matthew and council, > > On 3/22/07, Matthew James Driscoll wrote: >> In terms of revamping , which was never a terribly sophisticated >> element, this proposal makes perfect sense. It is not clear to me, >> however, >> whether the newly redefined element is intended as an >> alternative >> to or whether there are situations in which one would use >> both. Neither appeals much to me, I must say, especially as I can't >> see that >> what is being proposed can't be done with as it is. > > This is my concern as well. Since I can't read French, I was hoping > that the proposal includes some reasoning for basically placing > in , rather just using > (multiple instances, if need be) and linking them to the es. > > Thanks, > Dot > > The >> original idea behind , in any case, was very much that it >> should be able to be used for more than just cataloguing (our >> insistence on >> this was what led to the bulk of the disagreements with "TEI-MMSS"), >> and it >> was indeed my understanding that and were now to be >> deprecated as redundant. If there are things which Gautier, representing >> German, Italian and French practice, genuinely can't do using the current >> mechanism it would be far more useful, it seems to me, >> for >> us to try and adapt the existing mechanism, rather than coming up with a >> parallel one. >> >> Looking at his proposal, the chief lack seems to be a means of indicating >> the sigla, for which he proposes a new element; these can easily >> appear within as , which takes a type >> attribute. Otherwise the elements are largely from the >> module, suggesting that perhaps we aren't so far off the mark after all. >> >> Matthew >> >> >> >> >> -----Oprindelig meddelelse----- >> Fra: Lou Burnard [mailto:lou.burnard at computing-services.oxford.ac.uk] >> Sendt: 22 March 2007 00:22 >> Til: Matthew James Driscoll; TEI Council; gotpoupeau at infonie.fr >> Emne: Witness proposal >> >> In early november last year, Gautier Poupeau whom several of you will >> recall from his presentation at the Members meeting, sent me a document >> outlining a proposal to address the inconsistency currently subsisting >> in the Guidelines about how manuscript (or print) witnesses should be >> documented. I owe him, and the Council, a major apology for having not >> done anything with it -- it simply got mislaid and then forgotten. >> Fortunately, he's a persevering kind of chap, and I have now recovered >> the draft and placed it somewhere you can see it, viz: >> >> http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml >> >> It's in French, so I will summarize briefly the proposal here (I will >> also translate the document fully if so requested) >> >> * create a new class called model.witnessPart. which is a subclass of >> model.phrasel; use this class in the content model of >> * add to this class a number of elements currently specific to >> msDescription, specifically: >> origDate, material, physDesc, seal, dimensions, >> filiation,msIdentifier, msContents, rubric; >> * re-introduce the "sigil" attribute as a new element >> * add a "class" attribute to >> >> The suggestion is based on Gautier's extensive experience in adapting >> TEI to the description of cartularies and similar documents, with due >> regard to practice in German, Italian, and French collections. >> >> I think the work is sufficiently straightforward to do quite quickly >> (i.e. it can be done for P5); I also suspect that it would be a very >> smart political move to be seen to be doing something in this area. >> >> Initial comments? >> >> (It occurs to me also that this might be something the newly revived mss >> SIG would like to kick around -- but that could happen independently of >> plumbing his suggestion into P5) >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > From dporter at uky.edu Thu Mar 22 06:08:26 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 22 Mar 2007 03:08:26 -0800 Subject: [tei-council] Witness proposal In-Reply-To: <46026129.6030503@computing-services.oxford.ac.uk> References: <4601BE1D.3010403@computing-services.oxford.ac.uk> <46026129.6030503@computing-services.oxford.ac.uk> Message-ID: <96f3df640703220408x2021978j694e59ec60206518@mail.gmail.com> I agree with James here - why not link multiple msDescriptions to witnesses? Gautier (in Lou's translation) says: "The second solution would be to place a list containing a description of each witness used by the critical edition in the header of the file. This solution is quite feasible, and even advisable in the case of an edition of one text, such as a literary edition, for example. But where the critical edition is a collection of texts, for example a collection of charters, exempla or even "farces", it would be preferable to use a precise description of each witness in each text." This could be multiple msDescriptions in the header. "Moreover, the witness list will include not only manuscripts (archives, or books) but also printed material: the description of witnesses therefore involves more than msdescriptions." List both multiple s (for printed material) and multiple s (for manuscript/archives) in the sourceDesc? Dot On 3/22/07, James Cummings wrote: > Lou Burnard wrote: > > Fortunately, he's a persevering kind of chap, and I have now recovered > > the draft and placed it somewhere you can see it, viz: > > > > http://www.tei-c.org/Drafts/witnessPart/proposal-witness.xml > > > > It's in French, so I will summarize briefly the proposal here (I will > > also translate the document fully if so requested) > > While I'm able to get the general sense from the document, I'm sure a > translation would help me as well, so I'd second Dot's request. > > > * create a new class called model.witnessPart. which is a subclass of > > model.phrasel; use this class in the content model of > > * add to this class a number of elements currently specific to > > msDescription, specifically: > > origDate, material, physDesc, seal, dimensions, > > filiation,msIdentifier, msContents, rubric; > > Why can't the witness instead link to an msDescription? > > > * re-introduce the "sigil" attribute as a new element > > If I'm understanding the French, the complaint is that the suggested use of > xml:id is to constricting since people may wish to use existing sigla well-known > in the community, but that simultaneously is too vague and generic but > also won't allow some useful elements. Am I understanding that correctly? I > still think I'd favour a linking mechanism from witness to msIdentifier if > someone needs a more detailed identification. Maybe I'm misunderstanding the > proposal though. > > > > * add a "class" attribute to > > I was unable to get up the "Appendix A Liste des ?l?ments de la classe > witnessPart", but if I'm understanding the prose description correctly, this > attribute would be used to indicate a taxonomy used to classify that witness. > Which again seems like something which should be off in msDescription > > I'm probably just mistranslating things though, so I look forward to Lou's > translation which I know is in hand. > > -James > > -- > Dr James Cummings, Oxford Text Archive, University of Oxford > James dot Cummings at oucs dot ox dot ac dot uk > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 06:29:56 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 22 Mar 2007 11:29:56 +0000 Subject: [tei-council] Witness proposal In-Reply-To: <4601BE1D.3010403@computing-services.oxford.ac.uk> References: <4601BE1D.3010403@computing-services.oxford.ac.uk> Message-ID: <460268B4.4040705@computing-services.oxford.ac.uk> Lou Burnard wrote: > * re-introduce the "sigil" attribute as a new element I'm still not sure I understand this...I must be missing something. What is wrong with xml:id values of 'A1', 'a1', 'A2', 'b5' etc? If you then want to indicate that the numerical portion is superscript, that seems like additional information to be included in the (or ?) or to which that witness relates (and I assume points). I've always thought that msDescription could have a more general role than just manuscripts. But I'm happy to receive correction from Gautier on the intention behind this. > * add a "class" attribute to Ok, based on the translation, it seems to me that this class attribute sort of does the same thing as @type on altIdentifier? I.e. this identifier refers to a copy, this one to an original, this one to a fragment? (Or is my understanding abusing altIdentifier/@type ?) I think I would have an msDescription for each non-printed witness and have the witList point in turn to each of these. Most additional material, I feel shouldn't be in the at all, but the msDescription. I guess I'm just still to be convinced, but I'm receptive to more explanation. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Thu Mar 22 12:44:38 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 22 Mar 2007 17:44:38 +0000 Subject: [tei-council] TEI meeting 2008 Message-ID: <4602C086.6000102@kcl.ac.uk> Dear all, is anybody aware of which is deadline to submit proposals to host the next TEI meeting (2008)? Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Thu Mar 22 13:49:31 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 14:49:31 -0400 Subject: [tei-council] conformance draft Message-ID: <17922.53179.482722.150943@emt.wwp.brown.edu> I have finally gotten to reading James' draft (http://www.tei-c.org/Council/conformance-draft.pdf). Thanks to James for doing this work. Overall I think it looks quite good. However, I have lots of nit-picks (some of which others may have noted already), two procedural issues, and a few major points to raise. I am going to skip the nit-picks for now, mostly because all of Council need not be bothered. I will post the procedural issues separately, as they are less important, and may be uninteresting to many Council members. So, on with my main issues with the draft conformance chapter. One: ODD validate against which schema? ---- --- -------- ------- ----- ------- At several points the chapter refers to the need for a "valid TEI ODD" file. This is well and good, but valid against what? I don't think it will be particularly difficult to come up with a statement against which schema such an ODD should be valid, but such a statement is, I think, necessary. And it isn't trivial. E.g., Roma-the-web-app often produces ODD files that are invalid with respect to the schema that I would expect them to be valid against. (Currently the 0.6 version of P5/p5odds.rnc, available at http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/p5odds.rnc.) Two: Exemplars ---- --------- I feel that too much weight is placed on the TEI Customization Exemplars, although I don't have specific suggestions for improvement at the moment. These exemplars are primarily intended to be examples of how to perform specific kinds of customizations (e.g., including SVG) or to be good starting points for customization, but are not intended to generate schemas that are useful for encoding, and indeed, they don't. Most obviously, they do not provide controlled vocabularies for data.enumerated attributes. Three: Schemas ------ ------- I think it is important to make it clearer that validation against a schema is a necessary, but insufficient, condition of conformance -- that there are constraints required by the Guidelines that are not schema-enforced. (E.g., that a hand= attribute point to a element, not an inside a .) Furthermore, I think it is important to explain that DTD validation will not inform a user about as many constraints as will Relax NG validation. (E.g., many attribute values have datatypes that provide useful constraints in RelaxNG-land, but are just CDATA in DTD-land.) Four: namespace of new elements ----- --------- -- --- -------- I am not at all sure it is a good idea that TEI require that new elements be in a separate namespace. I think that doing so * creates a higher barrier to actual use of the customization mechanism * makes instances harder to read by humans * sends the wrong message politically -- that if you create a new element, somehow you're not a member of the same TEI club for an extremely limited technical gain. Rather than make this a condition of conformance, I would like to see the definitions of the various categories of TEI-Conformant schemas (& documents) differentiate based on use of namespaces. So, e.g., rename "Extension Schema" to "Pure Extension Schema", and create a new category "Extension Schema", which permits the addition of new elements in the TEI namespace. Again, thanks to James for doing the footwork, here. From Syd_Bauman at Brown.edu Thu Mar 22 14:09:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 15:09:52 -0400 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <17922.54400.512473.511195@emt.wwp.brown.edu> > ... I have ... two procedural issues, [which] I will post ... > separately, Alright, only 1 is procedural, the other is really technical. The formatting of the PDF is lovely, and it is very nice to read something pretty for a change. But why only the PDF? While I agree that it is too early to check this draft into the development trunk on Sourceforge, it certainly could at least have been made available as on ODD with the associated fscicule output (e.g. HTML & PDF), if not checked into a separate branch. But I'm also having a technical problem with Perforce. I don't know exactly when, but some point between the files' check-in (03-15) and today I synched my laptop and it dutifully downloaded the file. When I issue `p4 sync` on my laptop I am told 'File(s) up-to-date.'. On my desktop at work I issued `p4 sync` both yesterday and today. When I issue `p4 sync` right now I am told 'File(s) up-to-date.'. But the file //TEI/web/Council/conformance-draft.pdf does not exist on my desktop! I am quite confident I did not erase it, and even if I had, wouldn't Perforce replace it on a `sync`? Anyone have any idea as to what might be going on? From Syd_Bauman at Brown.edu Thu Mar 22 15:24:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 22 Mar 2007 16:24:02 -0400 Subject: [tei-council] TEI meeting 2008 In-Reply-To: <4602C086.6000102@kcl.ac.uk> References: <4602C086.6000102@kcl.ac.uk> Message-ID: <17922.58850.549094.932187@emt.wwp.brown.edu> > is anybody aware of which is deadline to submit proposals to host > the next TEI meeting (2008)? I don't believe that the call for bids has gone out yet. Proposals for time and place of each members meeting should be solicited in the spring of the previous year (e.g. April 2005 for the members' meeting of 2006) so that the venue can be announced at the members' meeting a year in advance. From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 22 15:32:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 22 Mar 2007 20:32:41 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <4602E7E9.8040701@oucs.ox.ac.uk> Syd Bauman wrote: > statement is, I think, necessary. And it isn't trivial. E.g., > Roma-the-web-app often produces ODD files that are invalid with > respect to the schema that I would expect them to be valid against. > (Currently the 0.6 version of P5/p5odds.rnc, available at > http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/p5odds.rnc.) > if you get an ODD which is not valid, I need to know! that would be a bug. the Exemplar "tei_odds" is the expected target for validation/ > > Two: Exemplars > ---- --------- > I feel that too much weight is placed on the TEI Customization > Exemplars, i kind of agree that they come over too prominent. > SVG) or to be good starting points for customization, but are not > intended to generate schemas that are useful for encoding, and > indeed, they don't. Most obviously, they do not provide controlled > vocabularies for data.enumerated attributes. > bit like TEI P1, P2, P3, and P4, then....? > > Furthermore, I think it is important to explain that DTD validation > will not inform a user about as many constraints as will Relax NG > validation. (E.g., many attribute values have datatypes that provide > useful constraints in RelaxNG-land, but are just CDATA in DTD-land.) > thats very true; wording this will not be easy, I think. > > Four: namespace of new elements > ----- --------- -- --- -------- > I am not at all sure it is a good idea that TEI require that new > elements be in a separate namespace. I tend to agree, though I quite see the argument of James. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 22 15:36:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 22 Mar 2007 20:36:29 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.54400.512473.511195@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <17922.54400.512473.511195@emt.wwp.brown.edu> Message-ID: <4602E8CD.8040103@oucs.ox.ac.uk> Syd Bauman wrote: > > > The formatting of the PDF is lovely, and it is very nice to read > something pretty for a change. But why only the PDF? While I agree > that it is too early to check this draft into the development trunk > on Sourceforge, it certainly could at least have been made available > as on ODD with the associated fscicule output (e.g. HTML & PDF), if > not checked into a separate branch. > my bad, partly. "make fascicule" was broken when James did it, then he got sick, so I lashed up the PDF while he lay a-weepin'. might as well check it straight into the trunk, no? after all, Subversion will remember the previous versions OK. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Thu Mar 22 19:31:07 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 00:31:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: <46031FCB.90304@computing-services.oxford.ac.uk> Syd Bauman wrote: > I am going to > skip the nit-picks for now, mostly because all of Council need not be > bothered. Do feel free to pass on the nit-picks privately. That which doesn't kill us... > One: ODD validate against which schema? > ---- --- -------- ------- ----- ------- > At several points the chapter refers to the need for a "valid TEI > ODD" file. This is well and good, but valid against what? Make sense, agreed that this should be more specific. > Two: Exemplars > ---- --------- > I feel that too much weight is placed on the TEI Customization > Exemplars, although I don't have specific suggestions for improvement > at the moment. My suggestion is that the discussion here should lessened, but that they be discussed in more depth in the chapter on customisation/modification. > > Three: Schemas > ------ ------- > I think it is important to make it clearer that validation against a > schema is a necessary, but insufficient, condition of conformance -- > that there are constraints required by the Guidelines that are not > schema-enforced. (E.g., that a hand= attribute point to a > element, not an inside a .) Yes, that should be stated more clearly. > Furthermore, I think it is important to explain that DTD validation > will not inform a user about as many constraints as will Relax NG > validation. While DTD validation may not provide as many constraints, if the document instance validates against a DTD generated from a TEI ODD is the document instance somehow less conformant than if it is validated against a Relax NG schema generated from the same ODD? Either DTDs are acceptable to validate TEI Conformant documents against or they are not. I admit that I have a little niggle worrying in the back of my head about someone creating an ODD for a schema which would be considered in one of those categories of TEI Conformance, but that the lack of constraints in DTD means that document instances which validate against the DTD are non-conformant because they don't include certain constraints in the Relax NG version generated from the same ODD. (Can someone invent an occasion where this might happen that simultaneously breaks conformance?) Maybe we should think about that more. > > Four: namespace of new elements > ----- --------- -- --- -------- > I am not at all sure it is a good idea that TEI require that new > elements be in a separate namespace. I think that doing so > * creates a higher barrier to actual use of the customization > mechanism > * makes instances harder to read by humans > * sends the wrong message politically -- that if you create a new > element, somehow you're not a member of the same TEI club > for an extremely limited technical gain. I think I'm still going to try and take the moral high ground...I recognise that it creates a barrier to use of the customisation mechanism. I'm not entirely convinced that it truly impairs human readability. Having a few namespace prefixes might actually clarify things more. I'm entirely used to xml:id now as an attribute. I don't think it sends the wrong message politically either...or at least you can view that in two ways. When you create a new element you get the privilege of putting it in your own project's namespace, and the comforting knowledge that the TEI namespace is kept pure. When you use other TEI documents you know the elements and their semantics because they are in the TEI namespace. I will admit that I am torn...I understand how much of a pain it is to do things in multiple namespaces even just in writing XSLT stylesheets, never mind full-blown applications. As an elected member of the council I feel I'm here to support the interests of the members. However, I'm torn between doing what I feel is right and doing what is easier. Would the membership want me to make life easy on them, or really make use of namespaces in the way I feel we should? The only real objection anyone has made so far concerning the use-your-own-namespace-for-new-elements idea is that it is difficult. Does anyone have any other arguments against this idea? While I unquestioningly accept that the use of namespaces in this way means that it will be more difficult to use the customisation mechanism, it might not pose an insurmountable difficulty or dissuade people from customisation as much as we might expect. Partly that depends on front-end applications like webRoma. If when I add a new element it is also prompting me for the namespace (perhaps with a previously-used suggestion) or something, then the barrier to use is lessened. Couple that with some XSLT examples handling multiple namespaces and a lot of the fear is reduced. > Rather than make this a > condition of conformance, I would like to see the definitions of the > various categories of TEI-Conformant schemas (& documents) > differentiate based on use of namespaces. > > So, e.g., rename "Extension Schema" to "Pure Extension Schema", and > create a new category "Extension Schema", which permits the addition > of new elements in the TEI namespace. This is certainly a possibility. Would the lack of namespace only occur in this category of schema? And even if the current conformance draft was the final chapter, this is something I think many people would probably do. If we persist with this use of namespaces I think there will be an increase in local encoding formats with transformations to multi-namespaced TEI Conformant documents only for interchange/deposit-with-archives/pleasing-the-funders, and such. But if using multiple namespaces is still the 'right' thing to do...then should this dissuade us? No one has said anything about the section 1.7 'TEI Conformance and Funding Bodies', since the claim of TEI Conformance is something that is often added to funding applications (since I read scores of them for the AHRC) in hopes of people saying "look how good we are, please, please fund us", I thought that we should say something about Conformance in no way indicating quality. However, I wasn't quite sure how far we should go along that road or other appropriate messages, etc. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:09:17 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:09:17 +1200 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: Syd Bauman wrote: > Four: namespace of new elements > ----- --------- -- --- -------- > I am not at all sure it is a good idea that TEI require that new > elements be in a separate namespace. I think that doing so > * creates a higher barrier to actual use of the customization > mechanism > * makes instances harder to read by humans > * sends the wrong message politically -- that if you create a new > element, somehow you're not a member of the same TEI club > for an extremely limited technical gain. I tend to disagree with all these points, actually, but for the moment I will just make the strongest claim I can: It is bad practice for the TEI Council to licence others to define new names within the TEI namespace, under ANY circumstances. Why do I think it's a bad idea to licence others to pollute the TEI namespace? Well, why do TEI elements use a namespace at all? The point of namespaces is to "avoid clashes between names from different markup vocabularies" ... "by assigning 'expanded names' to elements and attributes".[1] These "clashes" or "collisions" could otherwise occur in documents which contain markup from multiple XML vocabularies, since the same name might be defined in multiple vocabularies (e.g. "p" in TEI and HTML, "seg" in TEI and DocBook). Let me first describe how namespaces work to avoid such collisions: To distinguish similar names from distinct vocabularies, names are each associated with a URI which identifies the vocabulary from which it is drawn. e.g. TEI elements are associated with the TEI namespace URI http://www.tei-c.org/ns/1.0 which is the name of the TEI vocabulary - the "namespace URI" or "namespace name". Because URIs can be quite long, the XML namespaces specification provided a way to use short prefixes in place of those URIs, and also provided a way to specify a "default" namespace URI which can apply to an entire document or a section of a document. Using a namespace prefix or a "default" namespace is just shorthand syntax, though; the real ("expanded") name of a tei:p element is actually a pair of values: the TEI namespace URI, and the "local" name "p": {"http://www.tei-c.org/ns/1.0", "p"} Whereas an html:p has an "expanded name" with a different namespace URI and the same "local" name: {"http://www.w3.org/1999/xhtml/", "p"}. Now, the reason that URIs were used to identify vocabularies was that URIs are a globally distributed naming scheme in which anyone can easily define a URI which is unique, and use that URI as the name of their vocabulary. If vocabulary names were not unique, then we would still have the problem of name collision, since e.g. we might call our vocabulary "TEI", and the Tax Executives Institute might also define a vocabulary with the same name. There can be no dispute as to who is responsible for the TEI namespace URI "http://www.tei-c.org/ns/1.0" - it's owned by the TEI Consortium, and it is up to us, the Council, to declare that it is the name of the TEI vocabulary, and not the name of some OTHER vocabulary. If we say to TEI encoders that they may use the "http://www.tei-c.org/ns/1.0" name to identify OTHER vocabularies, then we have effectively negated the purpose of using a namespace, because some "extension" vocabularies will contain names which collide with names in other "extension" vocabularies. Now, do we want to avoid name collisions or don't we? If we don't care about name collisions, what is the TEI namespace for? Why have we added it? I don't see that using multiple namespaces in text encoding is really a serious barrier, but if other people think it is, then we need to find ways to help people use multiple namespaces, rather than pollute the TEI namespace. In the meantime, if using multiple namespaces is too great a barrier for some people, then they can use P4. P5 is namespaced, and customisers should get used to it. Cheers Con 1. "Namespaces in XML 1.0 (Second Edition)" http://www.w3.org/TR/REC-xml-names/#sec-intro From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:39:58 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:39:58 +1200 Subject: [tei-council] conformance draft In-Reply-To: <46031FCB.90304@computing-services.oxford.ac.uk> Message-ID: James Cummings wrote: > I recognise that > it creates a barrier to use of the customisation mechanism. That's perhaps true, in the first instance. However, it can also make customisation much easier. If a customisation has been made using a namespace then it will be easier to combine with other customisations. I envisage a situation where encoders may pick a set of 2 or 3 existing customisations want to combine them together. Perhaps an "image-annotation" customisation might be mixed with a "CIDOC-ontology" customisation, an "AppInfo" customisation, or whatever. If these customisations used namespaces, then they could be combined more or less just by sticking them together. Whereas if they did not use namespaces, they might produce name collisions, and it would be necessary to resolve the conflicts, and define a new customisation independently. In summary, the non-use of namespaces tends to make customisations non-reusable, and makes document interchange harder. > I'm not entirely > convinced that it truly impairs human readability. Having a > few namespace > prefixes might actually clarify things more. I'm entirely > used to xml:id now as > an attribute. I agree. It may be seen as added clutter, but it may also be seen as a useful visual hint: if an encoding project has defined a new attribute, it's because they have some special requirement. Having a namespace prefix may help to draw their attention to the attribute, making it easier to find when reading the TEI. This is certainly my own experience. In any case, if namespace prefixes are seen as a barrier, then a customisation can rename ALL the TEI elements into a new namespace, and then add new elements to that namespace. Instance documents could then use a default namespace to qualify names, so there'd be no need for namespace prefixes. e.g. ... ... i.e. a "renaming extension" schema. Cheers Con From Conal.Tuohy at vuw.ac.nz Thu Mar 22 21:55:14 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Fri, 23 Mar 2007 14:55:14 +1200 Subject: [tei-council] conformance draft In-Reply-To: <17922.53179.482722.150943@emt.wwp.brown.edu> Message-ID: Syd Bauman wrote: > I am not at all sure it is a good idea that TEI require that new > elements be in a separate namespace. I think that doing so > * sends the wrong message politically -- that if you create a new > element, somehow you're not a member of the same TEI club I am not sure I understand the "politics" there. Will people be discouraged from using TEI if we ask them not to add new names in the TEI namespace? Is that what you're implying? Will they think we are arrogant to delimit the official TEI vocabulary? Perhaps requiring a separate namespace for additions will actually encourage customisers to harmonise and unify their customisations with other similar customisations, so that the customisation may eventually be accepted into the TEI and moved into the TEI namespace. To my mind that would be a very good political message to send. Con From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 04:25:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 09:25:40 +0000 Subject: [tei-council] conformance issues Message-ID: <46039D14.3050805@oucs.ox.ac.uk> "If we say to TEI encoders that they may use the "http://www.tei-c.org/ns/1.0" name to identify OTHER vocabularies, then we have effectively negated the purpose of using a namespace, because some "extension" vocabularies will contain names which collide with names in other "extension" vocabularies." This is a knock-down argument as far as I am concerned. I agree with Conal 100%. From dporter at uky.edu Fri Mar 23 04:57:48 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 01:57:48 -0800 Subject: [tei-council] conformance draft In-Reply-To: References: <46031FCB.90304@computing-services.oxford.ac.uk> Message-ID: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> Conal, you've made a great deal of sense in all your comments. Thanks for taking the time to argue your points so clearly. On 3/22/07, Conal Tuohy wrote: > James Cummings wrote: > > > I recognise that > > it creates a barrier to use of the customisation mechanism. > > That's perhaps true, in the first instance. > Everyone, after the call earlier this week I volunteered privately to James to take an existing customization that I've been working on and have it "namespaced" by the council meeting, just to see how much of a barrier this actually is to people (like me) with middle-of-the-road tech skills. This particular customization is designed to be plugged into a METS file, so there is another layer to contend with there as well. Dot > However, it can also make customisation much easier. > > If a customisation has been made using a namespace then it will be > easier to combine with other customisations. > > I envisage a situation where encoders may pick a set of 2 or 3 existing > customisations want to combine them together. Perhaps an > "image-annotation" customisation might be mixed with a "CIDOC-ontology" > customisation, an "AppInfo" customisation, or whatever. If these > customisations used namespaces, then they could be combined more or less > just by sticking them together. > > Whereas if they did not use namespaces, they might produce name > collisions, and it would be necessary to resolve the conflicts, and > define a new customisation independently. > > In summary, the non-use of namespaces tends to make customisations > non-reusable, and makes document interchange harder. > > > I'm not entirely > > convinced that it truly impairs human readability. Having a > > few namespace > > prefixes might actually clarify things more. I'm entirely > > used to xml:id now as > > an attribute. > > I agree. It may be seen as added clutter, but it may also be seen as a > useful visual hint: if an encoding project has defined a new attribute, > it's because they have some special requirement. Having a namespace > prefix may help to draw their attention to the attribute, making it > easier to find when reading the TEI. This is certainly my own > experience. > > In any case, if namespace prefixes are seen as a barrier, then a > customisation can rename ALL the TEI elements into a new namespace, and > then add new elements to that namespace. Instance documents could then > use a default namespace to qualify names, so there'd be no need for > namespace prefixes. e.g. > > > > > ... > > > > > > ... > > > i.e. a "renaming extension" schema. > > Cheers > > Con > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:09:17 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:09:17 +0000 Subject: [tei-council] conformance draft In-Reply-To: References: Message-ID: <4603A74D.9000602@computing-services.oxford.ac.uk> Conal Tuohy wrote: > It is bad practice for the TEI Council to licence others to define new > names within the TEI namespace, under ANY circumstances. Agreed. In principle this is bad practice. > Now, do we want to avoid name collisions or don't we? If we don't care > about name collisions, what is the TEI namespace for? Why have we added > it? See, that is what I *should* have said! Thanks Conal! > I don't see that using multiple namespaces in text encoding is really a > serious barrier, but if other people think it is, then we need to find > ways to help people use multiple namespaces, rather than pollute the TEI > namespace. In the meantime, if using multiple namespaces is too great a > barrier for some people, then they can use P4. P5 is namespaced, and > customisers should get used to it. I do feel it is a bit of a barrier, but that this is a barrier which should be negated through application interface (Roma), numerous examples, and education. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:13:07 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:13:07 +0000 Subject: [tei-council] conformance draft In-Reply-To: References: Message-ID: <4603A833.2000401@computing-services.oxford.ac.uk> Conal Tuohy wrote: > James Cummings wrote: >> I recognise that >> it creates a barrier to use of the customisation mechanism. > That's perhaps true, in the first instance. > However, it can also make customisation much easier. I take that point, it will make merging micro-extensions easier. Though, that said, I still imagine having to deal with 20 namespaces all in one document would be a 'barrier'. (A not insurmountable one... but still a barrier.) > In summary, the non-use of namespaces tends to make customisations > non-reusable, and makes document interchange harder. Good point. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 05:15:38 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 10:15:38 +0000 Subject: [tei-council] conformance draft In-Reply-To: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> References: <46031FCB.90304@computing-services.oxford.ac.uk> <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> Message-ID: <4603A8CA.9050100@computing-services.oxford.ac.uk> Dot Porter wrote: > Everyone, after the call earlier this week I volunteered privately to > James to take an existing customization that I've been working on and > have it "namespaced" by the council meeting, just to see how much of a > barrier this actually is to people (like me) with middle-of-the-road > tech skills. This particular customization is designed to be plugged > into a METS file, so there is another layer to contend with there as > well. And while this will be useful, and just plain good for Dot (like any medicine), we should remember that what we hopefully will add is interfaces in Roma, lots of examples, documentation, and training. So that while Dot has little support in this now, those who come after her will not be so bad off in comparison. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From dporter at uky.edu Fri Mar 23 05:51:37 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 02:51:37 -0800 Subject: [tei-council] conformance draft In-Reply-To: <4603A8CA.9050100@computing-services.oxford.ac.uk> References: <46031FCB.90304@computing-services.oxford.ac.uk> <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> <4603A8CA.9050100@computing-services.oxford.ac.uk> Message-ID: <96f3df640703230351g2df7d7b0k7027be751989670@mail.gmail.com> > And while this will be useful, and just plain good for Dot (like any medicine), Okay, I admit, this is just an excuse for me to try something new! On 3/23/07, James Cummings wrote: > Dot Porter wrote: > > > Everyone, after the call earlier this week I volunteered privately to > > James to take an existing customization that I've been working on and > > have it "namespaced" by the council meeting, just to see how much of a > > barrier this actually is to people (like me) with middle-of-the-road > > tech skills. This particular customization is designed to be plugged > > into a METS file, so there is another layer to contend with there as > > well. > > we should remember that what we hopefully will add is interfaces in Roma, lots > of examples, documentation, and training. So that while Dot has little support > in this now, those who come after her will not be so bad off in comparison. > > -James > > -- > Dr James Cummings, Oxford Text Archive, University of Oxford > James dot Cummings at oucs dot ox dot ac dot uk > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From arianna.ciula at kcl.ac.uk Fri Mar 23 06:18:58 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 11:18:58 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD6538.1060002@computing-services.oxford.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> <45FD6538.1060002@computing-services.oxford.ac.uk> Message-ID: <4603B7A2.4050604@kcl.ac.uk> The resource at http://www.tei-c.org/Drafts/ndextra.html is not available any more and the proposal made accessible for the TEI list at http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new examples for Places but just the Nym section. Any idea where I can find the former examples that have disappeared? Arianna Lou Burnard wrote: > Christian Wittern wrote: >> Matthew James Driscoll wrote: >>> >>> >> >> does that mean you also proposa a listNym for TEI? >> >> > > Yes. Matthew's report doesn't mention that there is a draft ODD, > probably because I have not yet got round to putting it anywhere where > Council members can see it easily. But if you look in the P5/Test > directory on sourceforge, you will see a file called testndextra.odd, > which contains the current state of the draft. > > I've just put a copy of the HTML generated from this by Roma on the > website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep > this up to date as the draft progresses > > >>> Our principal task at this meeting was to develop mechanisms for >>> encoding >>> place-names, analogous to those which were developed for personal >>> names at >>> the meeting in Oxford last year, which would allow for the recording of >>> abstracted information about a place, such as map coordinate, GIS >>> information etc., as well as variant forms of the name, in different >>> languages (e.g. Praha, Prague, Praga) and/or different forms over >>> time (e.g. >>> Lundunum, London). On the analogy with , we propose a >>> element, which will usually contain at least one, and possibly several, >>> elements, followed by one or more elements to >>> provide >>> geographical and/or geo-political information about the location of the >>> place. >> >> Why would you need more than one ? I had the impression >> that the place is what stays constant? Is it because it also stands in >> for the geopolitical information? > > Because a place might be located in more than one way (e.g. by its > geopolitical status, or by its co-ordinates), and may also move its > location over time. >> However, if we talk about administrative geography here, you will also >> have to account for changes in the size and super/sub components of a >> place and a way to link this to coordinates defining the polygon. >> Would the tagset be up to this task? > > probably... because we embed GML! > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Fri Mar 23 06:25:19 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 11:25:19 +0000 Subject: [tei-council] conformance draft In-Reply-To: <46031FCB.90304@computing-services.oxford.ac.uk> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <46031FCB.90304@computing-services.oxford.ac.uk> Message-ID: <4603B91F.5070903@kcl.ac.uk> > While I unquestioningly accept that the use of namespaces in this way > means that it will be more difficult to use the customisation mechanism, > it might not pose an insurmountable difficulty or dissuade people from > customisation as much as we might expect. Partly that depends on > front-end applications like webRoma. If when I add a new element it is > also prompting me for the namespace (perhaps with a previously-used > suggestion) or something, then the barrier to use is lessened. Couple > that with some XSLT examples handling multiple namespaces and a lot of > the fear is reduced. Totally agree with James on this and with Conan on the rest. Arianna James Cummings wrote: > Syd Bauman wrote: >> I am going to >> skip the nit-picks for now, mostly because all of Council need not be >> bothered. > > Do feel free to pass on the nit-picks privately. That which doesn't > kill us... > >> One: ODD validate against which schema? >> ---- --- -------- ------- ----- ------- >> At several points the chapter refers to the need for a "valid TEI >> ODD" file. This is well and good, but valid against what? > > Make sense, agreed that this should be more specific. > >> Two: Exemplars >> ---- --------- >> I feel that too much weight is placed on the TEI Customization >> Exemplars, although I don't have specific suggestions for improvement >> at the moment. > > My suggestion is that the discussion here should lessened, but that they > be discussed in more depth in the chapter on customisation/modification. > >> >> Three: Schemas >> ------ ------- >> I think it is important to make it clearer that validation against a >> schema is a necessary, but insufficient, condition of conformance -- >> that there are constraints required by the Guidelines that are not >> schema-enforced. (E.g., that a hand= attribute point to a >> element, not an inside a .) > > Yes, that should be stated more clearly. > > >> Furthermore, I think it is important to explain that DTD validation >> will not inform a user about as many constraints as will Relax NG >> validation. > > While DTD validation may not provide as many constraints, if the > document instance validates against a DTD generated from a TEI ODD is > the document instance somehow less conformant than if it is validated > against a Relax NG schema generated from the same ODD? Either DTDs are > acceptable to validate TEI Conformant documents against or they are > not. I admit that I have a little niggle worrying in the back of my > head about someone creating an ODD for a schema which would be > considered in one of those categories of TEI Conformance, but that the > lack of constraints in DTD means that document instances which validate > against the DTD are non-conformant because they don't include certain > constraints in the Relax NG version generated from the same ODD. (Can > someone invent an occasion where this might happen that simultaneously > breaks conformance?) Maybe we should think about that more. > >> >> Four: namespace of new elements >> ----- --------- -- --- -------- >> I am not at all sure it is a good idea that TEI require that new >> elements be in a separate namespace. I think that doing so >> * creates a higher barrier to actual use of the customization >> mechanism >> * makes instances harder to read by humans >> * sends the wrong message politically -- that if you create a new >> element, somehow you're not a member of the same TEI club >> for an extremely limited technical gain. > > I think I'm still going to try and take the moral high ground...I > recognise that it creates a barrier to use of the customisation > mechanism. I'm not entirely convinced that it truly impairs human > readability. Having a few namespace prefixes might actually clarify > things more. I'm entirely used to xml:id now as an attribute. I don't > think it sends the wrong message politically either...or at least you > can view that in two ways. When you create a new element you get the > privilege of putting it in your own project's namespace, and the > comforting knowledge that the TEI namespace is kept pure. When you use > other TEI documents you know the elements and their semantics because > they are in the TEI namespace. I will admit that I am torn...I > understand how much of a pain it is to do things in multiple namespaces > even just in writing XSLT stylesheets, never mind full-blown > applications. As an elected member of the council I feel I'm here to > support the interests of the members. However, I'm torn between doing > what I feel is right and doing what is easier. Would the membership > want me to make life easy on them, or really make use of namespaces in > the way I feel we should? > > The only real objection anyone has made so far concerning the > use-your-own-namespace-for-new-elements idea is that it is difficult. > Does anyone have any other arguments against this idea? > > While I unquestioningly accept that the use of namespaces in this way > means that it will be more difficult to use the customisation mechanism, > it might not pose an insurmountable difficulty or dissuade people from > customisation as much as we might expect. Partly that depends on > front-end applications like webRoma. If when I add a new element it is > also prompting me for the namespace (perhaps with a previously-used > suggestion) or something, then the barrier to use is lessened. Couple > that with some XSLT examples handling multiple namespaces and a lot of > the fear is reduced. > >> Rather than make this a >> condition of conformance, I would like to see the definitions of the >> various categories of TEI-Conformant schemas (& documents) >> differentiate based on use of namespaces. >> >> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and >> create a new category "Extension Schema", which permits the addition >> of new elements in the TEI namespace. > > This is certainly a possibility. Would the lack of namespace only occur > in this category of schema? And even if the current conformance draft > was the final chapter, this is something I think many people would > probably do. If we persist with this use of namespaces I think there > will be an increase in local encoding formats with transformations to > multi-namespaced TEI Conformant documents only for > interchange/deposit-with-archives/pleasing-the-funders, and such. But > if using multiple namespaces is still the 'right' thing to do...then > should this dissuade us? > > No one has said anything about the section 1.7 'TEI Conformance and > Funding Bodies', since the claim of TEI Conformance is something that is > often added to funding applications (since I read scores of them for the > AHRC) in hopes of people saying "look how good we are, please, please > fund us", I thought that we should say something about Conformance in no > way indicating quality. However, I wasn't quite sure how far we should > go along that road or other appropriate messages, etc. > > -James > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From dporter at uky.edu Fri Mar 23 06:29:52 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 23 Mar 2007 03:29:52 -0800 Subject: [tei-council] conformance draft In-Reply-To: <4603B91F.5070903@kcl.ac.uk> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <46031FCB.90304@computing-services.oxford.ac.uk> <4603B91F.5070903@kcl.ac.uk> Message-ID: <96f3df640703230429j3ba5e377rf3befa7bef3580f4@mail.gmail.com> On 3/23/07, Arianna Ciula wrote: > Totally agree with James on this and with Conan on the rest. > TEI barbarians! > Arianna > > James Cummings wrote: > > Syd Bauman wrote: > >> I am going to > >> skip the nit-picks for now, mostly because all of Council need not be > >> bothered. > > > > Do feel free to pass on the nit-picks privately. That which doesn't > > kill us... > > > >> One: ODD validate against which schema? > >> ---- --- -------- ------- ----- ------- > >> At several points the chapter refers to the need for a "valid TEI > >> ODD" file. This is well and good, but valid against what? > > > > Make sense, agreed that this should be more specific. > > > >> Two: Exemplars > >> ---- --------- > >> I feel that too much weight is placed on the TEI Customization > >> Exemplars, although I don't have specific suggestions for improvement > >> at the moment. > > > > My suggestion is that the discussion here should lessened, but that they > > be discussed in more depth in the chapter on customisation/modification. > > > >> > >> Three: Schemas > >> ------ ------- > >> I think it is important to make it clearer that validation against a > >> schema is a necessary, but insufficient, condition of conformance -- > >> that there are constraints required by the Guidelines that are not > >> schema-enforced. (E.g., that a hand= attribute point to a > >> element, not an inside a .) > > > > Yes, that should be stated more clearly. > > > > > >> Furthermore, I think it is important to explain that DTD validation > >> will not inform a user about as many constraints as will Relax NG > >> validation. > > > > While DTD validation may not provide as many constraints, if the > > document instance validates against a DTD generated from a TEI ODD is > > the document instance somehow less conformant than if it is validated > > against a Relax NG schema generated from the same ODD? Either DTDs are > > acceptable to validate TEI Conformant documents against or they are > > not. I admit that I have a little niggle worrying in the back of my > > head about someone creating an ODD for a schema which would be > > considered in one of those categories of TEI Conformance, but that the > > lack of constraints in DTD means that document instances which validate > > against the DTD are non-conformant because they don't include certain > > constraints in the Relax NG version generated from the same ODD. (Can > > someone invent an occasion where this might happen that simultaneously > > breaks conformance?) Maybe we should think about that more. > > > >> > >> Four: namespace of new elements > >> ----- --------- -- --- -------- > >> I am not at all sure it is a good idea that TEI require that new > >> elements be in a separate namespace. I think that doing so > >> * creates a higher barrier to actual use of the customization > >> mechanism > >> * makes instances harder to read by humans > >> * sends the wrong message politically -- that if you create a new > >> element, somehow you're not a member of the same TEI club > >> for an extremely limited technical gain. > > > > I think I'm still going to try and take the moral high ground...I > > recognise that it creates a barrier to use of the customisation > > mechanism. I'm not entirely convinced that it truly impairs human > > readability. Having a few namespace prefixes might actually clarify > > things more. I'm entirely used to xml:id now as an attribute. I don't > > think it sends the wrong message politically either...or at least you > > can view that in two ways. When you create a new element you get the > > privilege of putting it in your own project's namespace, and the > > comforting knowledge that the TEI namespace is kept pure. When you use > > other TEI documents you know the elements and their semantics because > > they are in the TEI namespace. I will admit that I am torn...I > > understand how much of a pain it is to do things in multiple namespaces > > even just in writing XSLT stylesheets, never mind full-blown > > applications. As an elected member of the council I feel I'm here to > > support the interests of the members. However, I'm torn between doing > > what I feel is right and doing what is easier. Would the membership > > want me to make life easy on them, or really make use of namespaces in > > the way I feel we should? > > > > The only real objection anyone has made so far concerning the > > use-your-own-namespace-for-new-elements idea is that it is difficult. > > Does anyone have any other arguments against this idea? > > > > While I unquestioningly accept that the use of namespaces in this way > > means that it will be more difficult to use the customisation mechanism, > > it might not pose an insurmountable difficulty or dissuade people from > > customisation as much as we might expect. Partly that depends on > > front-end applications like webRoma. If when I add a new element it is > > also prompting me for the namespace (perhaps with a previously-used > > suggestion) or something, then the barrier to use is lessened. Couple > > that with some XSLT examples handling multiple namespaces and a lot of > > the fear is reduced. > > > >> Rather than make this a > >> condition of conformance, I would like to see the definitions of the > >> various categories of TEI-Conformant schemas (& documents) > >> differentiate based on use of namespaces. > >> > >> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and > >> create a new category "Extension Schema", which permits the addition > >> of new elements in the TEI namespace. > > > > This is certainly a possibility. Would the lack of namespace only occur > > in this category of schema? And even if the current conformance draft > > was the final chapter, this is something I think many people would > > probably do. If we persist with this use of namespaces I think there > > will be an increase in local encoding formats with transformations to > > multi-namespaced TEI Conformant documents only for > > interchange/deposit-with-archives/pleasing-the-funders, and such. But > > if using multiple namespaces is still the 'right' thing to do...then > > should this dissuade us? > > > > No one has said anything about the section 1.7 'TEI Conformance and > > Funding Bodies', since the claim of TEI Conformance is something that is > > often added to funding applications (since I read scores of them for the > > AHRC) in hopes of people saying "look how good we are, please, please > > fund us", I thought that we should say something about Conformance in no > > way indicating quality. However, I wasn't quite sure how far we should > > go along that road or other appropriate messages, etc. > > > > -James > > > > -- > Dr Arianna Ciula > Research Associate > Centre for Computing in the Humanities > King's College London > Strand > London WC2R 2LS (UK) > Tel: +44 (0)20 78481945 > http://www.kcl.ac.uk/cch > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 07:41:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 12:41:49 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <4603B7A2.4050604@kcl.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> <45FD6538.1060002@computing-services.oxford.ac.uk> <4603B7A2.4050604@kcl.ac.uk> Message-ID: <4603CB0D.8070900@oucs.ox.ac.uk> Apologies -- I am still hoping to get the material on places back online by the weekend -- it got pushed off by other committments. The ndextra document is still accessible at www.tei-c.org/oldDrafts/ndextra.html (along with all the other old junk that used to be in Drafts) if you're desperate... Arianna Ciula wrote: > The resource at http://www.tei-c.org/Drafts/ndextra.html is not > available any more and the proposal made accessible for the TEI list at > http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new > examples for Places but just the Nym section. > > Any idea where I can find the former examples that have disappeared? > > Arianna > > Lou Burnard wrote: >> Christian Wittern wrote: >>> Matthew James Driscoll wrote: >>>> >>>> >>> >>> does that mean you also proposa a listNym for TEI? >>> >>> >> >> Yes. Matthew's report doesn't mention that there is a draft ODD, >> probably because I have not yet got round to putting it anywhere where >> Council members can see it easily. But if you look in the P5/Test >> directory on sourceforge, you will see a file called testndextra.odd, >> which contains the current state of the draft. >> >> I've just put a copy of the HTML generated from this by Roma on the >> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to >> keep this up to date as the draft progresses >> >> >>>> Our principal task at this meeting was to develop mechanisms for >>>> encoding >>>> place-names, analogous to those which were developed for personal >>>> names at >>>> the meeting in Oxford last year, which would allow for the recording of >>>> abstracted information about a place, such as map coordinate, GIS >>>> information etc., as well as variant forms of the name, in different >>>> languages (e.g. Praha, Prague, Praga) and/or different forms over >>>> time (e.g. >>>> Lundunum, London). On the analogy with , we propose a >>>> element, which will usually contain at least one, and possibly several, >>>> elements, followed by one or more elements to >>>> provide >>>> geographical and/or geo-political information about the location of the >>>> place. >>> >>> Why would you need more than one ? I had the impression >>> that the place is what stays constant? Is it because it also stands >>> in for the geopolitical information? >> >> Because a place might be located in more than one way (e.g. by its >> geopolitical status, or by its co-ordinates), and may also move its >> location over time. >>> However, if we talk about administrative geography here, you will >>> also have to account for changes in the size and super/sub components >>> of a place and a way to link this to coordinates defining the >>> polygon. Would the tagset be up to this task? >> >> probably... because we embed GML! >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 09:42:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 14:42:26 +0000 Subject: [tei-council] conformance draft In-Reply-To: References: Message-ID: <4603E752.5010806@oucs.ox.ac.uk> I have to confess, the cogent arguments from the far side of the world are convincing me. Namespaced extensions it is. I would propose that Roma suggests a namespace for each element you add - based on the name of the customization? if not, i need somewhere else to store it in the odd. Given that this is the most contentious part of James' draft (in my mind) is this section, -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 09:59:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 14:59:50 +0000 Subject: [tei-council] conformance draft In-Reply-To: <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> References: <46031FCB.90304@computing-services.oxford.ac.uk> <96f3df640703230257w6b1f52b8w532200f637bf6ada@mail.gmail.com> Message-ID: <4603EB66.5010706@oucs.ox.ac.uk> Dot Porter wrote: > > James to take an existing customization that I've been working on and > have it "namespaced" by the council meeting, just to see how much of a > barrier this actually is to people (like me) with middle-of-the-road > tech skills. This particular customization is designed to be plugged > into a METS file, so there is another layer to contend with there as > well. it should be said that the true integration with METS is a far far bigger challenge than a few added elements in or out of namespaces. And it is not something lots of separate people should or will undertake. IMHO. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 10:06:31 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 15:06:31 +0000 Subject: [tei-council] conformance draft In-Reply-To: <4603E752.5010806@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> Message-ID: <4603ECF7.5060608@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > I have to confess, the cogent arguments from > the far side of the world are convincing me. > Namespaced extensions it is. > > I would propose that Roma suggests a namespace > for each element you add - based on the name > of the customization? if not, i need somewhere > else to store it in the odd. > > Given that this is the most contentious > part of James' draft (in my mind) is this section, Am I alone in thinking that Sebastian's train of thought was interrupted at this point and he meant to say something more? There seem to be more people accepting namespaces-for-new-elements so far (with some wanting an extra schema category of 'extension-without-the-namespace'). Any other arguments against this? One of the reasons I want us to be sure that this is the change we want to make is because I think it is one we will have to actively and committedly sell to the community (even if it is the right decision and in their own interest), so I want to flush out the arguments against it. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Fri Mar 23 10:15:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 23 Mar 2007 11:15:24 -0400 Subject: [tei-council] conformance draft In-Reply-To: <4603A74D.9000602@computing-services.oxford.ac.uk> References: <4603A74D.9000602@computing-services.oxford.ac.uk> Message-ID: <17923.61196.153165.470900@emt.wwp.brown.edu> Wow, excellent discussion thread. I am sorry I don't have a chance to really dive into deeply right now: Conal's "political" questions are worth pondering, and I am very interested in Dot's experiments. I will take the time to address two arguments, though. jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly jc:impairs jc:human jc:readability. jc:Having jc:a jc:few jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things jc:more. sb:I sb:find sb:this sb:pretty sb:hard sb:to sb:swallow, sb:at sb:least sb:keeping sb:in sb:mind sb:that sb:the sb:target sb:audience sb:we're sb:talking sb:about sb:here sb:are sb:relative sb:beginners. CT> Now, do we want to avoid name collisions or don't we? Yes, of course, name collision is annoying, and we'd prefer to avoid it. But on the scale of problems someone has merging TEI vocabularies or getting one project's files to be interoperable with another project's software, name collision is extremely low on the list of difficulties. (And it's quite rare, to boot.) Let's say you and I both have rich TEI vocabularies for encoding early modern printed books, and we each have added elements with different semantics. If you want to suck some of my files into your system, you are going to have deal with a *lot* worse than the fact that is a name collision. * The fact that I record the idealized page number on n= of , whereas you store it as the content of fw[@type='pageNum']/choice/corr. * The fact that your software expects quotations in , but I've encoded both quotations and direct speech in . * The fact that our value lists for type= of
and are different. * The fact that I record rhyme scheme on rhyme= of , whereas you indicate rhyme using inside . * The fact that I handle overlapping speeches and metrical lines using part= of , and you use next= & prev=. * The fact that you encode the author in .../titleStmt/author regardless, whereas I put it in .../titleStmt/author/persName, .../ittleStmt/author/orgName, or .../titleStmt/author, depending on whether (I think) the author was a person, an organization, or is neither (e.g., "unknown"). * The fact that you've used 2-letter ISO 639 language codes, but I've used 3-letter codes. * The fact that your software expects an whenever there is a line-break, but my encoding presumes that certain elements (,

, ) imply a line-break, so I haven't encoded an . * The fact that I've recorded my sources in .../sourceDesc/biblStruct, but you've used .../sourceDesc/bibl. * The fact that I make use of default renditions, but you don't, so your software doesn't know about them. * Oh, and while we're on rendition, I use CSS2 in my rend= attributes, but you use a home-grown solution. * We've used different classification schemes for our s. You get the idea. The list goes on and on and on even when two different projects are applying "vanilla" TEI to similar kinds of documents. Thus the gain of having one fewer problem (our s needing to be put in a row) when trying to do something that is a rare activity at the expense of making day-to-day activities a little harder and (more importantly) raising the bar for entry into the land of TEI seems like a bod idea to me. Remember the words of the song (sung to the tune of "Jesus Christ Superstar"): T-E-I, Wendell notes, Must remain easy for newer folks. [http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0007&L=TEI-L&P=R969, although you have to have read the entire thread to get some of the jokes, and I can't spend the time to track it down now ... besides, IIRC one or two of the exchanges were off-list.] CT> If we don't care about name collisions, what is the TEI namespace CT> for? Why have we added it? For several reasons, but mostly so that one *can* import other vocabularies into TEI, TEI into other vocabularies, or avoid namespace collisions with your extensions. Remember, I am not for a moment saying we should force people to stick their added elements into the TEI namespace. (One of the main reasons namespaces exist and are useful, not spelled out in the Spec, IIRC, is that even without name collisions, it makes processing much easier when everything is clearly labeled such that a software package can divide all the elements into "those I am supposed to process" and "others" with almost no effort.) So I see these as reasons to permit a user to separate her additions via namespace, perhaps even to encourage her to do so. But to insist that the lone scholar studying Hispanic rhyming patterns in 17th-century manuscripts create his own namespace and deal with multiple namespace issues for the one element he wants to add to enhance his research (or lose the funding-helpful claim to "TEI Conformance"); or worse yet, to risk having an administrator worry that, like copyright infringement, it's illegal to add elements in the TEI namespace ... all for a limited technical gain that may never occur, seems like a bad idea. From James.Cummings at computing-services.oxford.ac.uk Fri Mar 23 11:18:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 23 Mar 2007 16:18:48 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17923.61196.153165.470900@emt.wwp.brown.edu> References: <4603A74D.9000602@computing-services.oxford.ac.uk> <17923.61196.153165.470900@emt.wwp.brown.edu> Message-ID: <4603FDE8.8050505@computing-services.oxford.ac.uk> Syd Bauman wrote: > jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly > jc:impairs jc:human jc:readability. jc:Having jc:a jc:few > jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things > jc:more. Surely that would be more accurate as: I'm not entirely convinced that it truly impairs human TEI beginners readability . :-) I actually found the example quite readable, maybe I'm weird. > Yes, of course, name collision is annoying, and we'd prefer to avoid > it. But on the scale of problems someone has merging TEI vocabularies > or getting one project's files to be interoperable with another > project's software, name collision is extremely low on the list of > difficulties. (And it's quite rare, to boot.) I agree. Worries over namespace collisions isn't the only reason to be doing this. Yes, they might be a problem, but I'm more convinced of the fact that we are choosing to put TEI in a namespace. If we are choosing to do that, then we should use them properly, and I don't think allowing anyone to add new elements to that namespace is really using them properly. > So I see these as reasons to permit a user to separate her additions > via namespace, perhaps even to encourage her to do so. But to insist > that the lone scholar studying Hispanic rhyming patterns in > 17th-century manuscripts create his own namespace and deal with > multiple namespace issues for the one element he wants to add to > enhance his research (or lose the funding-helpful claim to "TEI > Conformance"); or worse yet, to risk having an administrator worry > that, like copyright infringement, it's illegal to add elements in > the TEI namespace ... all for a limited technical gain that may never > occur, seems like a bad idea. Firstly, let's not make 'create his own namespace' into more than it is... if Roma were edited as Sebastian suggests to provide a namespace, etc., then the barrier isn't that high. Ok, there is still a barrier on 'deal with multiple namespace issues' for his one element. On the phone it has been suggested to me that a compromise might be something like this: a) Remove mentions of namespaces from the definition of TEI Conformance. b) Include that the document must validate against one of the schema categories listed in order to be conformant. c) Add a new category which is 'extension-but-doesn't-use-TEI-namespace-for-new-elements'. d) Add new-elements-in-new-namespace-requirement to a definition of 'TEI Interchange Format' An alternative possibility is to leave namespace-for-new-elements as a concept, but not a requirement for conformance, and instead make it a requirement for 'TEI Interchange Format', but provide users an easy route to gain this to show their funding bodies. I.e. Roma or a Roma-like tool reads an ODD and will generate non-colliding schemas that use no-namespace for local processing, and one which uses namespaces and an XSLT which will transform document instances that validate against the no-namespace version into documents with namespaces. While I think we should be providing as much help in this area as possible, I am not sure this promotes best practice. Part of the problem is that funding bodies want to see funded projects using 'the best' method possible. While often this sense of 'best' is based entirely on misunderstandings, if we have TEI Conformance, and then TEI Conformance+TEI Interchange Format, they'll probably just view that as better and require it. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 11:27:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2007 16:27:29 +0000 Subject: [tei-council] What to do with an easter egg Message-ID: <4603FFF1.90002@oucs.ox.ac.uk> I haven't seen any comment here on the document about editorial practice which I posted here a couple of days ago, so I'm assuming that everyone is reasonably happy with it. Which means that I can now circulate the following slightly more detailed description of how I at least would like council members to proceed when reviewing the chapters assigned to them by Sebastian's note at the start of the week. First however something we do NOT want: at this stage, we are not asking you to undertake detailed proof-reading; we'll have another pass at that later. What we DO want is for you to read the material carefully and ask yourself: * is this expressed clearly * is this actually not a sensible recommendation (for whatever reason) * is this inadequate -- e.g. because it is out of date or incomplete If you find something which doesn't pass all three of these tests, you should do one of the following (a) get the XML source out of the subversion repository (see James's notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); improve the text and either put the results back in the Council's branch of the Subversion repository, or just email it to an editor. (b) add a comment to the TRAC ticket for this chapter in this task, leaving the ticket open for someone else to complete the required action (c) create a completely new TRAC ticket identifying the issue for other people to pick up and work on. Choose option (a) if what needs doing is obvious and easily accomplished. Choose option (b) if it looks straightforward but you're not sure how (or don't have time) to fix the problem. Choose option (c) if it doesn't look straightforward, you're not sure how to fix it, and you think it needs a closer look. The editorial guidelines mentions a number of stylistic things to look out for (e.g. rhetorical style in new sections, references to DTDs, additional or base tag sets in old sections, etc). You should also be looking for unanticipated consequences of pervasive changes in P5 (e.g. class work, datatyping of attributes, introduction of xml:id etc). And please remember that after Berlin there will be *no* opportunity to introduce further technical changes in 1.0 ! Excelsior! Lou From arianna.ciula at kcl.ac.uk Fri Mar 23 12:51:07 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 23 Mar 2007 17:51:07 +0000 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> Message-ID: <4604138B.4040000@kcl.ac.uk> I think we were supposed to comments on Matthew's draft about additions to Places and Names and Nyms by giving some encoding examples today. I would have like to have had the time to do this more extensively, but here are my examples/comments for places for now and, even more briefly, for nym. *Places: examples* An example of hierarchy among places expressed by using only nesting and not relation and variants of place names (I suppose that this could be expressed better using now): Wales Wallie Wallia Wall Le Waleis Carmarthenshire Carmarthen Kaermerdin Caerfyrddin castle of Carmarthen An example of a place that is unidentified, but that may be in Wales: Hendy ...? ...? If I wanted to encode that the person Ranulf de Blundeville has been earl of Chester, how would I encode this within the place tag for Chester? as a placeEvent? e.g. ... Ranulf de Blundeville was earl of Chester from 1118 to 1132. ... Indeed, I wouldn't mind to use placeEvent for this type of information, but its description would then need to be expanded and say that it could be used for facts involving a place actively as well as passively (well...relatively passively, since the place is actually "witnessing" a fact here). *Places: comments* Prose errors: There are some errors related to missing words, punctuation etc., but given the state of the draft I don't think it's necessary to report on this at this stage and, in any case, no to the entire list. Reification of placeName: I find a bit confusing the use of the type attribute for the placeName vs. place in the given examples. e.g. Brasserie George Shouldn't this be type of the place element instead? Same for the use of bloc within placeName in another example. Place Description: placeDesc is not described. *Nym general* I think this addition has lots of potential uses. The segmentation of a person surname into components which are, for instance, toponymics and therefore place names in its own right could be one of these. I could also see a possible combination between the use of nym and relations between person names for patronymics or similar. So, for now, thanks to the people who have worked on this in Vilnius. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch Matthew James Driscoll wrote: > TEI Place-name meeting, Vilnius, 23-24 February > > In attendance were: Lou Burnard, Matthew Driscoll, ?yvind Eide, Richard > Light, Tadeusz Piotrowski, Tatjana Timchenko and Sebastian Rahtz. > > The first day we were at the Institute of Lithuanian language > (http://www.lki.lt/indexeng.php), part of the Lithuanian Academy of > Sciences, and on the second day the Faculty of Philology > (http://www.flf.vu.lt/) at Vilnius University; we are grateful to both > institutions for acting as hosts. > > 1. Names and nyms > > We began by tackling one bit of business outstanding from the Personography > meeting last year in Oxford, viz. the development of a mechanism for > pointing from actual name instances to the canonical form of that name, thus > addressing the needs of onomasticians (who are interested in names per se), > in addition to those of prosopographers (who are interested in people). If, > for example, the names Tony Blair and Tony Benn occur in a text it should be > possible to tag them in such a way that they both point to information about > these respective gentlemen and are flagged as instances of the name "Tony". > It should further be possible to indicate that "Tony" is a (pet-)form of > "Anthony", which is itself a member of a family of names containing forms > such as "Antonio", "Anton", "Antoine" and so on. We propose doing this by > means of a new element, called , which contains the definition for a > canonical name or name-part of any kind. In addition to global attributes > and those inherited from att.typed it can take a @parts attribute, which > points to constituent nyms. The attribute @nymKey is available on any > element which is a member of the att.naming class in order to point to the > nym with which it corresponds. Thus, to take our example, the name "Tony > Blair" in running prose could be tagged as follows: > > > Tony > Blair > > > The @key attribute on would point to a element giving > information about Tony Blair, while @nymKey on points to the > relevant . A element may also combine a number of other > elements together, where it is intended to show that one is a pet form or > diminutive of another, or that different nyms are to be regarded as variants > of the same base nym, using the

element (from the model.entryParts > class); orthographic variants are dealt with using , while can > be used for information on the origin of the name: > > > > Antonius > From the Roman family name Antonius, > which is of unknown, presumably Etruscan, origin. It has been > commonly, but incorrectly, associated with Greek xml:lang="gr">ανθος > flower, which resulted in spellings with th in some > languages. > >
> Anthony > Antony >
> >
Tony
> > > >
Antonio
> >
Tonio
> > > > > > > > > This mechanism could also be used for place-names and place-name elements > (e.g. thorp, caster). > > 2. Place-names > > Our principal task at this meeting was to develop mechanisms for encoding > place-names, analogous to those which were developed for personal names at > the meeting in Oxford last year, which would allow for the recording of > abstracted information about a place, such as map coordinate, GIS > information etc., as well as variant forms of the name, in different > languages (e.g. Praha, Prague, Praga) and/or different forms over time (e.g. > Lundunum, London). On the analogy with , we propose a > element, which will usually contain at least one, and possibly several, > elements, followed by one or more elements to provide > geographical and/or geo-political information about the location of the > place. The existing element is available to provide a brief > informal description of the nature of a place. In addition, three new > elements have been proposed: , and , > which all have similar content models to their counterparts within . > > To take a fairly simple example: > > > Iceland > ?sland > 65 00 N, 18 00 W > 103,000 sq km > Constitutional > republic > Previously part of the kingdom of > Denmark, Iceland became independent > on 17 June 1944. > > > > 3. Events > > There was also some discussion on the feasibility (and desirability) of > developing a generic tagset for encoding assertions about events, although > no real conclusion was reached. > > M. J. Driscoll > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 14:21:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 19:21:23 +0000 Subject: [tei-council] conformance draft In-Reply-To: <4603ECF7.5060608@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> Message-ID: <460428B3.6050304@oucs.ox.ac.uk> James Cummings wrote: > >> Given that this is the most contentious >> part of James' draft (in my mind) is this section, >> > > Am I alone in thinking that Sebastian's train of thought was interrupted at this > point and he meant to say something more? > er, um. yes. I meant to say I am relieved we are discussing just this in some detail, as it implies the rest is generally accepted. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 23 15:16:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 23 Mar 2007 20:16:22 +0000 Subject: [tei-council] conformance draft In-Reply-To: <17923.61196.153165.470900@emt.wwp.brown.edu> References: <4603A74D.9000602@computing-services.oxford.ac.uk> <17923.61196.153165.470900@emt.wwp.brown.edu> Message-ID: <46043596.9010603@oucs.ox.ac.uk> Syd Bauman wrote: > sb:I sb:find sb:this sb:pretty sb:hard sb:to sb:swallow, sb:at > sb:least sb:keeping sb:in sb:mind sb:that sb:the sb:target > sb:audience sb:we're sb:talking sb:about sb:here sb:are sb:relative > sb:beginners. > I question this. A "relative beginner", if we have done our job right, does NOT need to add new elements. Yes, many projects will need to; yes, it is not evil; but I still claim that it is not something to undertake casually. The TEI out of the box should be able to encode mainstream texts. I would also claim that anyone doing text encoding using XML is not a beginner. You can't go from no experience at all in markup and XML to TEI customization involving new elements in one stage. > If you want to suck some of my files into > your system, you are going to have deal with a *lot* worse than the > fact that is a name collision. > your list is amusing and instructive :-} Maybe we should get you to deliver a "why the TEI is rubbish" talk at the MM! ..... > But to insist > that the lone scholar studying Hispanic rhyming patterns in > 17th-century manuscripts create his own namespace and deal with > multiple namespace issues for the one element he wants to add to > enhance his research (or lose the funding-helpful claim to "TEI > Conformance") I am coming around to believing that having to write match="mytei:duck" instead of match="tei:duck" is positively useful for maintenance purposes (I can quickly spot where my code is for my elements only) and really not that hard after all. your scholar has to learn to deal with the xml namespace already, after all, and quite possibly XInclude and xlink as well; better get the pain over sooner. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Fri Mar 23 16:38:29 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 23 Mar 2007 15:38:29 -0600 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <4603CB0D.8070900@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> <45FD6538.1060002@computing-services.oxford.ac.uk> <4603B7A2.4050604@kcl.ac.uk> <4603CB0D.8070900@oucs.ox.ac.uk> Message-ID: <1174685910.6064.1.camel@localhost> Can we have an extension on this then? I'd started encoding Lethbridge guessing a procedure on analogy with person and Matthew's email, but I see now there is a lot to digest--especially since my other idea was to encode the Old Man River. Would 03-25 be good for us all? On Fri, 2007-03-23 at 12:41 +0000, Lou Burnard wrote: > Apologies -- I am still hoping to get the material on places back online > by the weekend -- it got pushed off by other committments. The ndextra > document is still accessible at www.tei-c.org/oldDrafts/ndextra.html > (along with all the other old junk that used to be in Drafts) if you're > desperate... > > > Arianna Ciula wrote: > > The resource at http://www.tei-c.org/Drafts/ndextra.html is not > > available any more and the proposal made accessible for the TEI list at > > http://www.tei-c.org/Drafts/testnym.html doesn't contain all the new > > examples for Places but just the Nym section. > > > > Any idea where I can find the former examples that have disappeared? > > > > Arianna > > > > Lou Burnard wrote: > >> Christian Wittern wrote: > >>> Matthew James Driscoll wrote: > >>>> > >>>> > >>> > >>> does that mean you also proposa a listNym for TEI? > >>> > >>> > >> > >> Yes. Matthew's report doesn't mention that there is a draft ODD, > >> probably because I have not yet got round to putting it anywhere where > >> Council members can see it easily. But if you look in the P5/Test > >> directory on sourceforge, you will see a file called testndextra.odd, > >> which contains the current state of the draft. > >> > >> I've just put a copy of the HTML generated from this by Roma on the > >> website at http://www.tei-c.org/Drafts/ndextra.html -- will try to > >> keep this up to date as the draft progresses > >> > >> > >>>> Our principal task at this meeting was to develop mechanisms for > >>>> encoding > >>>> place-names, analogous to those which were developed for personal > >>>> names at > >>>> the meeting in Oxford last year, which would allow for the recording of > >>>> abstracted information about a place, such as map coordinate, GIS > >>>> information etc., as well as variant forms of the name, in different > >>>> languages (e.g. Praha, Prague, Praga) and/or different forms over > >>>> time (e.g. > >>>> Lundunum, London). On the analogy with , we propose a > >>>> element, which will usually contain at least one, and possibly several, > >>>> elements, followed by one or more elements to > >>>> provide > >>>> geographical and/or geo-political information about the location of the > >>>> place. > >>> > >>> Why would you need more than one ? I had the impression > >>> that the place is what stays constant? Is it because it also stands > >>> in for the geopolitical information? > >> > >> Because a place might be located in more than one way (e.g. by its > >> geopolitical status, or by its co-ordinates), and may also move its > >> location over time. > >>> However, if we talk about administrative geography here, you will > >>> also have to account for changes in the size and super/sub components > >>> of a place and a way to link this to coordinates defining the > >>> polygon. Would the tagset be up to this task? > >> > >> probably... because we embed GML! > >> > >> > >> _______________________________________________ > >> tei-council mailing list > >> tei-council at lists.village.Virginia.EDU > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From lou.burnard at computing-services.oxford.ac.uk Fri Mar 23 19:11:47 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 24 Mar 2007 00:11:47 +0000 Subject: [tei-council] Place draft In-Reply-To: <45E7F824.8070600@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0ED43D6F@humxsrv1.hum.ku.dk> <45E7F824.8070600@oucs.ox.ac.uk> Message-ID: <46046CC3.5070309@computing-services.oxford.ac.uk> Still some way to go on this one, I fear -- keep those examples flooding in chaps -- but I have now checked in a revised odd at P5/Test/testplace.odd and you can see the HTML it generates at http://www.tei-c.org/Drafts/testplace.html goodnite Lou From James.Cummings at oucs.ox.ac.uk Sat Mar 24 20:14:16 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 25 Mar 2007 02:14:16 +0100 Subject: [tei-council] testplace.odd Message-ID: <4605CCE8.3010601@oucs.ox.ac.uk> Hiya, I generated an .rnc from the testplace.odd found in sourceforge P5/Test/testplace.odd and this seems to work fine except that I don't seem to be offered inside even though the examples do. Am I meant to be using a different odd? Or did I do something wrong? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Sun Mar 25 03:43:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 25 Mar 2007 09:43:39 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <4605CCE8.3010601@oucs.ox.ac.uk> References: <4605CCE8.3010601@oucs.ox.ac.uk> Message-ID: <4606363B.2030607@computing-services.oxford.ac.uk> James Cummings wrote: > > Hiya, > > I generated an .rnc from the testplace.odd found in sourceforge > P5/Test/testplace.odd and this seems to work fine except that I don't > seem to be offered inside even though the examples do. > > Am I meant to be using a different odd? Or did I do something wrong? > > -James Nope to both -- I just forgot to add the corpus module into the mix. Will fix after breakfast! Intermodule dependency rides again. From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 04:08:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2007 10:08:17 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <4606363B.2030607@computing-services.oxford.ac.uk> References: <4605CCE8.3010601@oucs.ox.ac.uk> <4606363B.2030607@computing-services.oxford.ac.uk> Message-ID: <46063C01.5060809@oucs.ox.ac.uk> Lou Burnard wrote: > Nope to both -- I just forgot to add the corpus module into the mix. > Will fix after breakfast! > > Intermodule dependency rides again. no, it means that is in the wrong module.... but it also shows that modules work - you dont see some elements unless you load a module, but it works without. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Sun Mar 25 15:06:05 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 14:06:05 -0600 Subject: [tei-council] testplace.odd In-Reply-To: <4606363B.2030607@computing-services.oxford.ac.uk> References: <4605CCE8.3010601@oucs.ox.ac.uk> <4606363B.2030607@computing-services.oxford.ac.uk> Message-ID: <1174853165.9661.3.camel@localhost> If I've build my rng correction, locale is still not working. Also many of our examples have text inside location, where I suspect this should either be inside rs (e.g. Junction of Park Street and Charlotte Street) or measure (e.g. 41.687142 -74.870109). On Sun, 2007-03-25 at 09:43 +0100, Lou Burnard wrote: > James Cummings wrote: > > > > Hiya, > > > > I generated an .rnc from the testplace.odd found in sourceforge > > P5/Test/testplace.odd and this seems to work fine except that I don't > > seem to be offered inside even though the examples do. > > > > Am I meant to be using a different odd? Or did I do something wrong? > > > > -James > Nope to both -- I just forgot to add the corpus module into the mix. > Will fix after breakfast! > Intermodule dependency rides again. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 15:45:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2007 21:45:52 +0100 Subject: [tei-council] testplace.odd In-Reply-To: <1174853165.9661.3.camel@localhost> References: <4605CCE8.3010601@oucs.ox.ac.uk> <4606363B.2030607@computing-services.oxford.ac.uk> <1174853165.9661.3.camel@localhost> Message-ID: <4606DF80.6040504@oucs.ox.ac.uk> Daniel O'Donnell wrote: > If I've build my rng correction, locale is still not working. On inspection, I think Lou is talking porkies with his in testplace.odd. We never mentioned in Vilnius, and there is no reason why it should ever work inside (since its just a member of model.settingPart). > Also many > of our examples have text inside location, where I suspect this should > either be inside rs (e.g. Junction of Park Street and Charlotte Street) > or measure (e.g. 41.687142 -74.870109). > "should", or "could"? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Sun Mar 25 17:48:24 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 16:48:24 -0600 Subject: [tei-council] testplace.odd In-Reply-To: <4606DF80.6040504@oucs.ox.ac.uk> References: <4605CCE8.3010601@oucs.ox.ac.uk> <4606363B.2030607@computing-services.oxford.ac.uk> <1174853165.9661.3.camel@localhost> <4606DF80.6040504@oucs.ox.ac.uk> Message-ID: <1174862904.9661.4.camel@localhost> On Sun, 2007-03-25 at 21:45 +0100, Sebastian Rahtz wrote: > Daniel O'Donnell wrote: > > If I've build my rng correction, locale is still not working. > On inspection, I think Lou is talking porkies > with his in testplace.odd. We never > mentioned in Vilnius, and there is > no reason why it should ever work inside > (since its just a member of model.settingPart). > > Also many > > of our examples have text inside location, where I suspect this should > > either be inside rs (e.g. Junction of Park Street and Charlotte Street) > > or measure (e.g. 41.687142 -74.870109). > > > "should", or "could"? "Should" according to the ODD. We're not allow text inside location. -dan, who just lost a very detailed example, O'Donnell > > -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From daniel.odonnell at uleth.ca Mon Mar 26 00:06:10 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 25 Mar 2007 23:06:10 -0600 Subject: [tei-council] Some place tests Message-ID: <1174885570.9661.16.camel@localhost> My tests are below. I tried a place that was destroyed and rebuilt as a museum somewhere else (Fort Hamilton/Fort Whoop Up); a place that has a huge number of names and is in a district that changed names (Coalbanks/Lethbridge/Sikohktoks), and a river (Belly/Old Man). I've added some comments on issues that arose interlinealy in the code. I also ran all the examples against an rng schema produced from this afternoon's ODD: the problems are indicated by comments. All the ones that did not have any problems have been cut back out. (I'm reproducing it here in case attachments aren't allowed). -dan P.S. a problem independent of place came up: if I want to encode the orgName North West Mounted Police (NWMP)/Royal Canadian Mounted Police (RCMP), the "Mounties" How does one do that? I original wanted to do North West Mounted Police NWMP Mounties But soCalled wasn't allowed in the choice. I'm wondering if there is a way of getting all three or five names, nicknames, and abbreviations into a single ancestor element while indicating the connection between them in a fashion similar to my typography above. ----------------- Place Test

Sample test

Born electronic

 Fort Hamilton Fort Whoop Up Trading fort and later museum/interpretative centre. Canada Alberta Confluence of the St. Mary's and Old Man (Belly) rivers 49.626502,-112.886925 49.714491,-112.861862 Canada Alberta City of Lethbridge Indan Battle Park

Established as a trading fort by J.J. Healy and A.B. Hamilton

Policed by the North West Mounted Police NWMP

Abandoned sometime between 1890 and 1892.

Washed away in flood of the Oldman river

Recreated as a Centenial project in a new location.

Fort Hamilton/Fort Whoop Up was established as a trading fort at the confluence of the St. Mary's and Belly (now Oldman) rivers in 1869 by J.J. Healy and A.B. Hamilton, American traders from Montana. The fort was established in large part in response to the enactment of laws forbidding the sale of alcohol on the nearby Montana Reserves that same year. Although the fort carried out legitimate trade, the fort also rapidly became one of the more notorious Whiskey trading posts in the Canadian North West. Prompted in part by the threat these forts posed to good order (Whiskey traders massacred a number of Assiniboine in the nearby Cyprus Hills in 1873) and in part by the threat to sovereinty posed by the largely American-run Whiskey trade (Fort Whoop Up used a flag that closely resembled the U.S. Stars and Stripes), in 1874 the government of the new Dominion of Canada established the North West Mounted Police NWMP (later the Royal Canadian Mounted Police RCMP ) to police the new territories. By the fall of 1874, the NWMP had established a presence in the area (they even rented barack space from Healy and Hamilton at the fort), and brought the whiskey trade under control. The fort continued as a legitimate trading post until it was abandoned in the early 1890s. The last remnants of the original structures were washed away in a flood of the Oldman (formerly Belly) river in 1915.

The fort was recreated as a museum and interpretative centre approximately 7 km downstream (NW) of the original site in Indian Battle Park, an urban park of the City of Lethbridge, as a Centennial project in 1967.

 Lethbridge Coalbanks Sikohkotoks Black Rocks Sikokotoks Black Rocks Sikoohkotoks Black Rocks Aksaysim Steep Banks Aksiiksahko Steep Banks Mek-kio-towaghs Painted Rock, Red Painted Rock, Medicine Stone Miiksskoowa Painted Rock, Red Painted Rock, Medicine Stone Assini-etomochi Where We Slaughtered the Crees Asinaawaiitomottsaawa Where We Slaughtered the Crees Chadish-kashi Black Rocks Kuskusukisay-guni Black Rocks Ipubin-saba-akabin Digging coal LA Lethbridge, Alberta Canada Alberta 49.7000, -112.8330

67,374

63,053

121.83

121.83

553.0

3,050

3,270

3,670

1,820

1,850

27,090

The first European activity occurred in the early 1870s when a coal mine was established by Nicolas Sheran to supply Fort Hamilton NWMP posts in the area.

The first significant European settlement was established in 1882 when Sir Alexander Galt and the North West Coal and Navigation Company NWC&NC opened a more significant mine across the river. This settlement was initially known as Coalbanks (a calque of the Blackfoot name for the area).

The town was renamed Lethbridge after the then president of the NWC&NC, William Lethbridge.

Lethbridge is incorporated as a town with proclaimation of Ordinance No. 24.

Lethbridge is incorporated as a city by an act of the Alberta Legislature.

 Oldman River Belly River Mount Gass 50.120578,-114.674263 49.600698,-114.048729 Oldman Reservoir Fort Macleod 49.756651,-113.362427 49.626502,-112.886925 Lethbridge 49.886451,-112.474937 49.931887,-111.692505

209 241

25,100

The mountainous region of the watershed serves as the headwaters for the Oldman River and its tributaries. Headwaters for the Belly, Waterton, and St. Marys rivers begin in Montana. The coldwater streams of the mountain and foothill regions support a large sport fishery. This region is largely forested with stands of aspen and lodgepole pine. The stands become more continuous with elevation, and include white spruce, douglas fir, engelmann spruce, alpine fir, and alpine larch.

The foothills region is characterised by rolling hills, and a fragile foothills fescue vegetation ecosystem that is threatened by introduction of non-native vegetation and extensive cattle grazing. The foothills are a result of uplifting of the Rocky Mountains in the Cenozoic era (65 million years to present), when shale and sandstone deposits were broken and pushed eastward in ripples

The plains region comprises approximately 80 percent of the watershed. The area is characterised by dark brown chernozemic soils that are well suited to agriculture. The conversion of natural prairie vegetation to agricultural crop production and cattle grazing has resulted in the natural prairie ecosystem being the most threatened ecosystem in Alberta. The most urbanised section of the watershed is the eastern portion, around the City of Lethbridge, and the towns of Coaldale and Taber. Here the landscape is fragmented by multiple land uses. The Oldman River above Lethbridge supports some coldwater and warmwater fisheries, while the area downstream of Lethbridge is a warmwater fishery.

The climate of Southern Alberta is semi-arid with extremes of weather, and great day-to-day potential variation in local climate. Climate conditions in the Oldman River watershed vary across two climatic regions. The Rocky Mountains in the western portion of the watershed are part of the Cordillera climatic region. This region is characterized by short, cool summers and highly variable weather. The Prairie region is characterized by warm-to-hot summers, extreme seasonal temperature variations, dry artic winter air, rain shadow effects, and moisture deficits. Precipitation in the region also follows a gradient whereby the mountains receive up to 110 cm per year, compared to 35 cm near Taber, in the eastern portion of the watershed.

Approximately 60 percent of the annual discharge of the Oldman River and its tributaries flows between April and June, due to snow melt in the mountains. In addition to high streamflows from spring melting, flooding is often caused by high intensity rainfall events occurring in early- to mid-summer. This was the case on June 5, 1995, when flooding caused $88,000,000 in damages in the watershed. Streamflows are typically the lowest during the months of August and September, making low water levels a particular concern in the late summer and fall. Drought conditions in 2000 and 2001 highlighted the susceptibility of the region to drought. It is expected that given future climate change and variability there will be more intense and numerous periods of drought.

The Oldman river has its headwaters near Mt. Gass, Alberta. It is also fed by the Mt. Lyall glacier.

The Oldman river ends when it combines with the Bow to form the South Saskatchewan river

 Lyon Lugdunum 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8 -109.2 45.256 -110.45 city Lyon Lugdunum EU France city Brasserie Georges Lyon Perrache Rue de la Charit? Restaurant Lyon Lugdunum 45.1 -110.23 46.48 -99.08 31.74 -108.86 45.3 -78.2 42.25 -103.45 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8 -109.2 45.256 -110.45 Junction of Park Street and Charlotte Street fire hydrant Atlantis Unknown Yasgur's Farm Woodstock Festival Site one mile north west of Bethel New York 41.687142 -74.870109 Lithuania Lietuva Vilnius Kaunas -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From Syd_Bauman at Brown.edu Mon Mar 26 08:46:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 26 Mar 2007 09:46:40 -0400 (EDT) Subject: [tei-council] webRoma (was "Re: conformance draft") In-Reply-To: <4602E7E9.8040701@oucs.ox.ac.uk> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> Message-ID: <200703261346.l2QDkeKC022450@draco.services.brown.edu> SR> if you get an ODD which is not valid, I need to know! SR> that would be a bug. * webRoma spits out elements where it means * webRoma will stick an after the and of an (sometimes this has happened even when there is no reason for an at all -- the content of matches the value of ident= of parent ) I'm also quite sure I had some problem with an attribute last week, but for the life of me I can't remember what it was. It may not have been a webRoma-produced invalidity. E.g., it may have been a webRoma passed-on invalidity. (I.e., what happens when user enters invalid value, like "hi Mom!" as the value for the 'prefix' field.) From daniel.odonnell at uleth.ca Mon Mar 26 09:37:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 26 Mar 2007 08:37:33 -0600 Subject: [tei-council] Place followup Message-ID: <1174919853.11966.29.camel@localhost> I'd been too tired to add some additional comments on the place name test when I submitted my example last night. But here they are now. I found a couple of minor inconsistencies in the ODD: notBefore and notAfter failing to be available in places where the examples say they should be, examples that should text data in elements that the ODD requires child elements for. I also wonder if we shouldn't have someway of indicating point-in-time for all elements that have from/to/notBefore/notAfter elements: like birthdays (where we use @date), acts of incorporation or census data are valid only for specific points in time and it felt silly using either from or from/to with the same date to indicate that Lethbridge changed its name on 1885-10-15 or had 1850 women in common law relationships in the 2001 census. The main issues I had, however, were the inability to create structures within groups of the main elements (i.e. placeName or placeTrait) and, in the case of the river, to express parts of the place (this last is not too hard, I suspect though). So, to give an example, in the case of Lethbridge, various online sources supply quite a number of Native American names for the city in various spellings. I went and checked with an elder from the local Peigan community, and not all of these are equally valid or acceptable, even though all are out there in sources somewhere. There were at least three spellings for the most common semi-official name of Lethbridge among the Blackfoot--sikohkitoks, sik-oki-toks, and sik-ooh-kitoks--of which the first is the correct current spelling and the others probably formulated by non-speakers. The other terms all refer to the specific area in which Lethbridge is, but not all are used to refer to the city. The one that means "place where we slaughtered the crees" refers to a major battle that took place here in the very early 1870s just as the first European settlers started establishing themselves on the townsite. I don't believe it is current and if it was, I doubt it is polite. It would be nice to be able first of all to qualify names (something I guess you can do with type), and secondly somehow group and distinguish among alternatives, commenting on mistakes if applicable. Also, almost every source I saw glossed the Native names the first time they came up. I did this by using foreign within placeName, but I can see that causing problems if you only gloss "unusual" foreign names: so I could see in the case of something like Rome using placeName xml:lang="en" for Rome, and placeName xml:lang="it" for Roma but wanting to gloss whatever the Blackfoot word for the city is. Secondly, in the case of Lethbridge I went to Census Canada, where there were a number of newly released placeTraits. But there is no way of keeping the internal (tabular) structure Census Canada or even group them as a subsection of the placeTrait. Leaving aside the ability to introduce tables--though these are commonly used by geographers--it would be nice to be able to do something like this at least: 20 19 Finally, in the case of the Oldman river, I wanted to be able both to group locations (some places on the river are both lat-long, confluences, and towns and it would nice to indicate their relationship to each other--a similar problem to the above) and discuss the river in terms of the different geographical areas it went through--mountainous, foothills, and plains. Here I was getting my information from a study of the river and they tended to discuss the river in this way. One option for this would have been to divide the river into multiple places, one each for each region: Oldman river Mountainous region Foothills region Plains region The trouble with this, though, is that the same source discussed the climate in two regions--mountains and plains (which affected foothills and plains). I thought I'd then try to tie placeTraits to location ranges, but there is no corresp or targets att available. -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 26 16:03:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 26 Mar 2007 22:03:06 +0100 Subject: [tei-council] webRoma (was "Re: conformance draft") In-Reply-To: <200703261346.l2QDkeKC022450@draco.services.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> <200703261346.l2QDkeKC022450@draco.services.brown.edu> Message-ID: <4608350A.3000204@oucs.ox.ac.uk> Syd Bauman wrote: > * webRoma spits out elements where it means > I can see this one, and I think its fixed > * webRoma will stick an after the and > of an (sometimes this has happened even when there is no > reason for an at all -- the content of > matches the value of ident= of parent ) > > I can see this, but I am having trouble understanding how to fix it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Mar 27 11:09:50 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 27 Mar 2007 12:09:50 -0400 Subject: [tei-council] Re: webRoma In-Reply-To: <89553718@toto.iv> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> Message-ID: <17929.16846.916660.924189@emt.wwp.brown.edu> > I'm also quite sure I had some problem with an attribute last week, > but for the life of me I can't remember what it was. Ah! That's what it was. webRoma will generate elements that do not have (the required) type= attribute. While we're talking about webRoma, one of the things I really feel needs to be improved is the interface to & data.enumerated. At the very least when an ODD is read in, the "List of values" field on the "Add a new attribute" page (which is often used for changing attributes) should be pre-populated with the values found in the existing . Also the "Closed list" question should probably include all three possibilities, no? ("closed", "open", and "semi"). Lastly, although to my knowledge we have still not entirely straightened the data.enumerated vs. valItem/@ident issue, I think (perhaps incorrectly) that we are still of the opinion that should only be used in combination with certain datatypes[1]. If there are datatypes with which we feel a value list should not be specified (data.count jumps to mind), I think the webRoma front-end should reflect this. Note ---- [1] The GLs currently use in conjunction with: 13 data.truthValue 1 data.xTruthValue 1 data.certainty (not including precision= of , which is about to be removed) 70 data.enumerated 1 data.name, w/ maxOccurs=5, which is for generate= of , and which I claim is in error: should be data.enumerated. Are there any other datatypes with which makes a lot of sense? (To be honest, I'm not very convinced of truthValue, xTruthValue, and certainty -- seems to leave open the possibility for discrepancy.) From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 11:18:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 17:18:20 +0100 Subject: [tei-council] Re: webRoma In-Reply-To: <17929.16846.916660.924189@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> <17929.16846.916660.924189@emt.wwp.brown.edu> Message-ID: <460943CC.2000800@oucs.ox.ac.uk> Syd Bauman wrote: > Ah! That's what it was. webRoma will generate elements > that do not have (the required) type= attribute. > ok, have made a trac ticket to remind me > > While we're talking about webRoma, one of the things I really feel > needs to be improved is the interface to & data.enumerated. > At the very least when an ODD is read in, the "List of values" field > on the "Add a new attribute" page (which is often used for changing > attributes) should be pre-populated with the values found in the > existing . Also the "Closed list" question should probably > include all three possibilities, no? ("closed", "open", and "semi"). > ok, agreed, ditto. > Lastly, although to my knowledge we have still not entirely > straightened the data.enumerated vs. valItem/@ident issue, I think > (perhaps incorrectly) that we are still of the opinion that > should only be used in combination with certain datatypes[1]. If > there are datatypes with which we feel a value list should not be > specified (data.count jumps to mind), I think the webRoma front-end > should reflect this. > how is it to know, though? where will these rules be expressed. I agree its not quite nice as it is. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Mar 27 11:25:47 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 27 Mar 2007 12:25:47 -0400 Subject: [tei-council] Re: webRoma In-Reply-To: <460943CC.2000800@oucs.ox.ac.uk> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> <17929.16846.916660.924189@emt.wwp.brown.edu> <460943CC.2000800@oucs.ox.ac.uk> Message-ID: <17929.17803.358253.328215@emt.wwp.brown.edu> > ok, have made a trac ticket to remind me > ok, agreed, ditto. Check, thanks. > how is it to know, though? where will these rules be expressed. Really good question. When Lou dreamed this concept up I was initially under the (perhaps false) impression that attributes of datatype data.enumerated had to have s, and those of other datatypes had to *not* have s. This is why I thought should be a child of . But if we're not to follow some simple algorithm like this, then we would have to either: * build rules not described in the Guidelines into the logic of webRoma, realizing they could be over-ridden by an ODD author if she wanted, OR * make it explicit which datatypes may have s and which may not. Perhaps by putting an attribute on the which defines the datatype? (Or a different value for type=?) I think we should open a Trac ticket to tackle this and solve it. From arianna.ciula at kcl.ac.uk Tue Mar 27 11:26:21 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Mar 2007 17:26:21 +0100 Subject: [tei-council] HTML output of guidelines Message-ID: <460945AD.9080407@kcl.ac.uk> While starting the proofreading on the chapters I have been assigned, I have noticed that some content of elements is either not rendered or, more importantly, not output in the html of the guidelines. I wander whether this is because James and Dot are working on the new output model right now and therefore changing things as I write. I can of course collect this details in a ticket while I do the checking, but the fact the any content within is lost in translation alerted me a bit. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 11:29:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 17:29:04 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <460945AD.9080407@kcl.ac.uk> References: <460945AD.9080407@kcl.ac.uk> Message-ID: <46094650.4080204@oucs.ox.ac.uk> Arianna Ciula wrote: > While starting the proofreading on the chapters I have been assigned, > I have noticed that some content of elements is either not rendered > or, more importantly, not output in the html of the guidelines. thats a bit serious. give me chapter and verse and I'll deal with it immediately. > I wander whether this is because James and Dot are working on the new > output model right now and therefore changing things as I write. no, James and Dot have not started committting code yet -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Tue Mar 27 11:34:17 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 27 Mar 2007 17:34:17 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094650.4080204@oucs.ox.ac.uk> References: <460945AD.9080407@kcl.ac.uk> <46094650.4080204@oucs.ox.ac.uk> Message-ID: <46094789.4040502@kcl.ac.uk> SG: Gentle intro: Proof-read text looking for references to DTDs and P4 architecture
....red is #PCDATA, as in this example. This is an abbreviation for parsed character data That the text within gloss doesn't show up. Arianna Sebastian Rahtz wrote: > Arianna Ciula wrote: >> While starting the proofreading on the chapters I have been assigned, >> I have noticed that some content of elements is either not rendered >> or, more importantly, not output in the html of the guidelines. > thats a bit serious. give me chapter and verse and > I'll deal with it immediately. >> I wander whether this is because James and Dot are working on the new >> output model right now and therefore changing things as I write. > no, James and Dot have not started committting code yet > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 12:57:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 18:57:16 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094789.4040502@kcl.ac.uk> References: <460945AD.9080407@kcl.ac.uk> <46094650.4080204@oucs.ox.ac.uk> <46094789.4040502@kcl.ac.uk> Message-ID: <46095AFC.2080402@oucs.ox.ac.uk> Arianna Ciula wrote: > SG: Gentle intro: Proof-read text looking for references to DTDs and > P4 architecture > >
....red is #PCDATA, as in > this example. > This is an abbreviation for parsed character data amazing that has not come up before, its a glaring great bug! I have found the hole, plugged it, will now test and then put new HTML in place on web site by hand. please report any other funnies like this as soon as you see them. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Tue Mar 27 14:09:27 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 27 Mar 2007 13:09:27 -0600 Subject: [tei-council] conformance draft In-Reply-To: <4603FDE8.8050505@computing-services.oxford.ac.uk> References: <4603A74D.9000602@computing-services.oxford.ac.uk> <17923.61196.153165.470900@emt.wwp.brown.edu> <4603FDE8.8050505@computing-services.oxford.ac.uk> Message-ID: <1175022567.27266.85.camel@odonned-eng06> Picking this up by reading backwards--I'm still with the draft on this: -This seems to me to be how we are supposed to do it, in keeping with the proper use of namespaces -If we can modify roma, we have a relatively painless way of dealing with it -Anybody who is in a position to be adding new elements is not a novice and is going to be in a state to think up ways of making the task of adding them to the relevant elements easier. On Fri, 2007-23-03 at 16:18 +0000, James Cummings wrote: > Syd Bauman wrote: > > > jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly > > jc:impairs jc:human jc:readability. jc:Having jc:a jc:few > > jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things > > jc:more. > > Surely that would be more accurate as: > > I'm not entirely convinced that it truly impairs human TEI > beginners readability . :-) > > I actually found the example quite readable, maybe I'm weird. > > > Yes, of course, name collision is annoying, and we'd prefer to avoid > > it. But on the scale of problems someone has merging TEI vocabularies > > or getting one project's files to be interoperable with another > > project's software, name collision is extremely low on the list of > > difficulties. (And it's quite rare, to boot.) > > I agree. Worries over namespace collisions isn't the only reason to be doing > this. Yes, they might be a problem, but I'm more convinced of the fact that we > are choosing to put TEI in a namespace. If we are choosing to do that, then we > should use them properly, and I don't think allowing anyone to add new elements > to that namespace is really using them properly. > > > So I see these as reasons to permit a user to separate her additions > > via namespace, perhaps even to encourage her to do so. But to insist > > that the lone scholar studying Hispanic rhyming patterns in > > 17th-century manuscripts create his own namespace and deal with > > multiple namespace issues for the one element he wants to add to > > enhance his research (or lose the funding-helpful claim to "TEI > > Conformance"); or worse yet, to risk having an administrator worry > > that, like copyright infringement, it's illegal to add elements in > > the TEI namespace ... all for a limited technical gain that may never > > occur, seems like a bad idea. > > Firstly, let's not make 'create his own namespace' into more than it is... if > Roma were edited as Sebastian suggests to provide a namespace, etc., then the > barrier isn't that high. Ok, there is still a barrier on 'deal with multiple > namespace issues' for his one element. > > On the phone it has been suggested to me that a compromise might be something > like this: > > a) Remove mentions of namespaces from the definition of TEI Conformance. > b) Include that the document must validate against one of the schema categories > listed in order to be conformant. > c) Add a new category which is > 'extension-but-doesn't-use-TEI-namespace-for-new-elements'. > d) Add new-elements-in-new-namespace-requirement to a definition of 'TEI > Interchange Format' > > An alternative possibility is to leave namespace-for-new-elements as a concept, > but not a requirement for conformance, and instead make it a requirement for > 'TEI Interchange Format', but provide users an easy route to gain this to show > their funding bodies. I.e. Roma or a Roma-like tool reads an ODD and will > generate non-colliding schemas that use no-namespace for local processing, and > one which uses namespaces and an XSLT which will transform document instances > that validate against the no-namespace version into documents with namespaces. > While I think we should be providing as much help in this area as possible, I am > not sure this promotes best practice. > > Part of the problem is that funding bodies want to see funded projects using > 'the best' method possible. While often this sense of 'best' is based entirely > on misunderstandings, if we have TEI Conformance, and then TEI Conformance+TEI > Interchange Format, they'll probably just view that as better and require it. > > -James > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at computing-services.oxford.ac.uk Tue Mar 27 15:07:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 27 Mar 2007 21:07:34 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46094650.4080204@oucs.ox.ac.uk> References: <460945AD.9080407@kcl.ac.uk> <46094650.4080204@oucs.ox.ac.uk> Message-ID: <46097986.7080105@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: >> I wander whether this is because James and Dot are working on the new >> output model right now and therefore changing things as I write. > no, James and Dot have not started committting code yet Nope, Dot and I still haven't started this yet. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 27 17:11:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Mar 2007 23:11:13 +0100 Subject: [tei-council] Re: webRoma In-Reply-To: <17929.16846.916660.924189@emt.wwp.brown.edu> References: <17922.53179.482722.150943@emt.wwp.brown.edu> <4602E7E9.8040701@oucs.ox.ac.uk> <17929.16846.916660.924189@emt.wwp.brown.edu> Message-ID: <46099681.2060109@oucs.ox.ac.uk> Syd Bauman wrote: > > Ah! That's what it was. webRoma will generate elements > that do not have (the required) type= attribute. > > fixed on Sourceforge, albeit untested :-{ -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Wed Mar 28 03:40:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 28 Mar 2007 09:40:15 +0100 Subject: [tei-council] HTML output of guidelines In-Reply-To: <46095AFC.2080402@oucs.ox.ac.uk> References: <460945AD.9080407@kcl.ac.uk> <46094650.4080204@oucs.ox.ac.uk> <46094789.4040502@kcl.ac.uk> <46095AFC.2080402@oucs.ox.ac.uk> Message-ID: <460A29EF.3070105@kcl.ac.uk> will do Thanks, Arianna Sebastian Rahtz wrote: > Arianna Ciula wrote: >> SG: Gentle intro: Proof-read text looking for references to DTDs and >> P4 architecture >> >>
....red is #PCDATA, as in >> this example. >> This is an abbreviation for parsed character data > amazing that has not come up before, its a glaring great bug! > > I have found the hole, plugged it, will now test and then > put new HTML in place on web site by hand. > > please report any other funnies like this as soon as you see them. > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Thu Mar 29 02:04:40 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 29 Mar 2007 08:04:40 +0100 Subject: [tei-council] Re: Fwd: TEI Workshop - 25 Apr. 2007 In-Reply-To: <311C7571-9285-407E-B419-7925710FAB27@loria.fr> References: <25908656-3FB2-4366-BA39-6D62FF6DD96D@loria.fr> <311C7571-9285-407E-B419-7925710FAB27@loria.fr> Message-ID: <20070329070440.F3DA930001@webmail217.herald.ox.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20070329/edc74e4c/attachment.ksh From James.Cummings at computing-services.oxford.ac.uk Thu Mar 29 03:59:22 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 29 Mar 2007 09:59:22 +0100 Subject: [tei-council] Place draft In-Reply-To: <46046CC3.5070309@computing-services.oxford.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0ED43D6F@humxsrv1.hum.ku.dk> <45E7F824.8070600@oucs.ox.ac.uk> <46046CC3.5070309@computing-services.oxford.ac.uk> Message-ID: <460B7FEA.90306@computing-services.oxford.ac.uk> Lou's Laptop wrote: > Still some way to go on this one, I fear -- keep those examples flooding > in chaps -- Ok, find below my sample, which validated against an rnc generated from the testplace.odd. I'm not entirely sure I've done things correctly, and happy to hear where I've gone wrong. I chose the "Regional Municipality of Waterloo" in Ontario, Canada. Dat is where I done growed up! This regional municipality used to be called 'Waterloo County', and comprises a number of cities including Kitchener-Waterloo. K-W, as everyone calls it, is officially two separate cities which have grown together in a conurbation, but their governments are entirely separate. Kitchener, up until 1916, used to be called 'Berlin' when a (much derided) vote was held to change its name. I've not included the other cities and townships which make up the regional municipality for brevity. Find my below. ========= Waterloo County Regional Municipality of Waterloo Canada Ontario 1,382 km²

Area is created as Waterloo County

Regional Municipality

Reorganisation from County to Regional Municipality

 Kitchener-Waterloo K-W KW Twin Cities Berlin Kitchener 136.89 km²

Recognised as a Hamlet

Incorporation as a City

In 1916 as a result of the first world war, and given the large percentage of people of German background living in Canada's German capital, it was decided by ballot to change the name from Berlin to Kitchener after Lord Kitchener. Although Berlin's population ridiculed the proposed name change and refused to vote. Although it had a populate of well over 15,000 only 892 people voted. The name Kitchener with 346 votes won by 81 votes. Many Berliners supported maintaining the name of the city, as it reflected a proud tradition of growth and prosperity for German, and non-German, Canadians alike. Those citizens who supported the status quo were immediately perceived, by those who wanted change, as being unpatriotic and sympathizers with the enemy. Violence, riots and intimidation, often instigated by imperialistic members of the 118th Battalion, were not uncommon in the months leading up to the May 1916 referendum on the issue. See What?s In a Name? Berlin to Kitchener

See also http://en.wikipedia.org/wiki/Berlin_to_Kitchener_name_change Waterloo 64.1 km²

Recognised as a village

Officially a town

Incorporated as a city

 Kitchener-Waterloo (K-W) is an unofficial but ubiquitous name for the area in Ontario, Canada consisting of the twin cities of Kitchener and Waterloo, approximately 100 kilometres west of Toronto. The two cities grew into each other decades ago and their shared boundary cuts through streets, backyards and houses. While the term is used by local residents, Kitchener and Waterloo are separate cities and not a single municipal entity. ========= -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Thu Mar 29 09:56:11 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 15:56:11 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <4603FFF1.90002@oucs.ox.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> Message-ID: <460BD38B.2010200@kcl.ac.uk> A quick question: if identifiers are missing for divisions of @type div3 e.g.
Declaring attributes should we add them (possibly following the existing model if consistent in that chapter, otherwise following the editorial guidelines) or we can/should leave it? Thanks, Arianna Lou Burnard wrote: > I haven't seen any comment here on the document about editorial practice > which I posted here a couple of days ago, so I'm assuming that everyone > is reasonably happy with it. Which means that I can now circulate the > following slightly more detailed description of how I at least would > like council members to proceed when reviewing the chapters assigned to > them by Sebastian's note at the start of the week. > > First however something we do NOT want: at this stage, we are not asking > you to undertake detailed proof-reading; we'll have another pass at that > later. > > What we DO want is for you to read the material carefully and ask yourself: > * is this expressed clearly > * is this actually not a sensible recommendation (for whatever reason) > * is this inadequate -- e.g. because it is out of date or incomplete > > If you find something which doesn't pass all three of these tests, you > should do one of the following > > (a) get the XML source out of the subversion repository (see James's > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); > improve the text and either put the results back in the Council's branch > of the Subversion repository, or just email it to an editor. > > (b) add a comment to the TRAC ticket for this chapter in this task, > leaving the ticket open for someone else to complete the required action > > (c) create a completely new TRAC ticket identifying the issue for other > people to pick up and work on. > > Choose option (a) if what needs doing is obvious and easily > accomplished. Choose option (b) if it looks straightforward but you're > not sure how (or don't have time) to fix the problem. Choose option > (c) if it doesn't look straightforward, you're not sure how to fix it, > and you think it needs a closer look. > > The editorial guidelines mentions a number of stylistic things to look > out for (e.g. rhetorical style in new sections, references to DTDs, > additional or base tag sets in old sections, etc). You should also be > looking for unanticipated consequences of pervasive changes in P5 (e.g. > class work, datatyping of attributes, introduction of xml:id etc). And > please remember that after Berlin there will be *no* opportunity to > introduce further technical changes in 1.0 ! > > Excelsior! > > Lou > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 29 10:00:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 29 Mar 2007 16:00:11 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD38B.2010200@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460BD38B.2010200@kcl.ac.uk> Message-ID: <460BD47B.4010007@oucs.ox.ac.uk> Arianna Ciula wrote: > A quick question: > if identifiers are missing for divisions of @type div3 > > e.g.
xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes > > should we add them (possibly following the existing model if > consistent in that chapter, otherwise following the editorial > guidelines) or we can/should leave it? the type attribute on
has (currently) no effect at all. it was put in there to test the conversion from numbered divs to unnumbered. ignore it.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Thu Mar 29 10:11:35 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 16:11:35 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD47B.4010007@oucs.ox.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460BD38B.2010200@kcl.ac.uk> <460BD47B.4010007@oucs.ox.ac.uk> Message-ID: <460BD727.3030902@kcl.ac.uk> May I didn't explain myself properly;what I meant is that some divisions have identifiers (so we can link to them) while others don't. Should we add identifiers where they don't exists? e.g.
An example DTD This div has an identifier probably because whoever edited the XML wanted to have the possibility to create a link to it, but other divs don't. Arianna Sebastian Rahtz wrote: > Arianna Ciula wrote: >> A quick question: >> if identifiers are missing for divisions of @type div3 >> >> e.g.
> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes >> >> should we add them (possibly following the existing model if >> consistent in that chapter, otherwise following the editorial >> guidelines) or we can/should leave it? > the type attribute on
has (currently) no effect at all. it was put in > there to test the conversion from numbered divs to unnumbered. > > ignore it.... > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Thu Mar 29 10:13:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 29 Mar 2007 16:13:54 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD38B.2010200@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460BD38B.2010200@kcl.ac.uk> Message-ID: <20070329151354.982F530001@webmail217.herald.ox.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20070329/fec15785/attachment.ksh From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 29 10:16:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 29 Mar 2007 16:16:35 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460BD727.3030902@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460BD38B.2010200@kcl.ac.uk> <460BD47B.4010007@oucs.ox.ac.uk> <460BD727.3030902@kcl.ac.uk> Message-ID: <460BD853.4090100@oucs.ox.ac.uk> Arianna Ciula wrote: > May I didn't explain myself properly no, I was being an idiot. sorry. Lou is correct. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Thu Mar 29 10:31:01 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 29 Mar 2007 16:31:01 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <20070329151354.982F530001@webmail217.herald.ox.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460BD38B.2010200@kcl.ac.uk> <20070329151354.982F530001@webmail217.herald.ox.ac.uk> Message-ID: <460BDBB5.3030006@kcl.ac.uk> Lou Burnard wrote: > Sections at that level only get an identifier if they have something pointing at > them. So you shouldn't need add them, in my opinion. Unless of course you're > adding a reference to one of them! Thought so, but checking just in case, thank-you. Arianna > > > In message <460BD38B.2010200 at kcl.ac.uk> Arianna Ciula > writes: >> A quick question: >> if identifiers are missing for divisions of @type div3 >> >> e.g.
> xmlns="http://www.tei-c.org/ns/1.0">Declaring attributes >> >> should we add them (possibly following the existing model if consistent >> in that chapter, otherwise following the editorial guidelines) or we >> can/should leave it? >> >> Thanks, >> Arianna >> >> -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Fri Mar 30 11:08:09 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 30 Mar 2007 17:08:09 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <4603FFF1.90002@oucs.ox.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> Message-ID: <460D35E9.7030501@kcl.ac.uk> > (a) get the XML source out of the subversion repository (see James's > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); > improve the text and either put the results back in the Council's branch > of the Subversion repository, or just email it to an editor. I don't have access to commit stuff to subversion. Should I just send the revised SG chapter to you Lou? Arianna Lou Burnard wrote: > I haven't seen any comment here on the document about editorial practice > which I posted here a couple of days ago, so I'm assuming that everyone > is reasonably happy with it. Which means that I can now circulate the > following slightly more detailed description of how I at least would > like council members to proceed when reviewing the chapters assigned to > them by Sebastian's note at the start of the week. > > First however something we do NOT want: at this stage, we are not asking > you to undertake detailed proof-reading; we'll have another pass at that > later. > > What we DO want is for you to read the material carefully and ask yourself: > * is this expressed clearly > * is this actually not a sensible recommendation (for whatever reason) > * is this inadequate -- e.g. because it is out of date or incomplete > > If you find something which doesn't pass all three of these tests, you > should do one of the following > > (a) get the XML source out of the subversion repository (see James's > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); > improve the text and either put the results back in the Council's branch > of the Subversion repository, or just email it to an editor. > > (b) add a comment to the TRAC ticket for this chapter in this task, > leaving the ticket open for someone else to complete the required action > > (c) create a completely new TRAC ticket identifying the issue for other > people to pick up and work on. > > Choose option (a) if what needs doing is obvious and easily > accomplished. Choose option (b) if it looks straightforward but you're > not sure how (or don't have time) to fix the problem. Choose option > (c) if it doesn't look straightforward, you're not sure how to fix it, > and you think it needs a closer look. > > The editorial guidelines mentions a number of stylistic things to look > out for (e.g. rhetorical style in new sections, references to DTDs, > additional or base tag sets in old sections, etc). You should also be > looking for unanticipated consequences of pervasive changes in P5 (e.g. > class work, datatyping of attributes, introduction of xml:id etc). And > please remember that after Berlin there will be *no* opportunity to > introduce further technical changes in 1.0 ! > > Excelsior! > > Lou > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 30 11:47:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 30 Mar 2007 17:47:20 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D35E9.7030501@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460D35E9.7030501@kcl.ac.uk> Message-ID: <460D3F18.8050705@oucs.ox.ac.uk> Arianna Ciula wrote: > > (a) get the XML source out of the subversion repository (see James's > > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); > > improve the text and either put the results back in the Council's > branch > > of the Subversion repository, or just email it to an editor. > > I don't have access to commit stuff to subversion. Should I just send > the revised SG chapter to you Lou? > If you have a sourceforge account, send me the name and I will give you commit rights. otherwise send XML to me or Lou or Syd to check in. if your changes are controversial, they could go in Council branch. are they? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Fri Mar 30 15:52:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 30 Mar 2007 21:52:56 +0100 Subject: [tei-council] floating texts Message-ID: <460D78A8.6070107@computing-services.oxford.ac.uk> Following up on SFFR 1308688, I have now checked in a preliminary attempt at defining a new floatingText element, and made a number of minor changes in the wording of some other chapters (mostly DS and DR) to explain what it is and how it's different from the existing I *really really* need some real examples though. Anyone care to volunteer some? Julia, are you there? Lou From lou.burnard at computing-services.oxford.ac.uk Fri Mar 30 16:27:22 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 30 Mar 2007 22:27:22 +0100 Subject: [tei-council] witness lists again Message-ID: <460D80BA.3080600@computing-services.oxford.ac.uk> I had the opportunity to discuss Gautier's ideas about witness lists (see mail of 21st and 22nd) with the man himself, over several beers in Paris earlier this week. I won't try to repeat all the discussion now (and not just because of the beers), but I would like to ask those who confidently assert that it can all be done with existing elements to take a look at a real live example, such as the following. Put yourself in the place of the downtrodden archivist trying to produce a reliable edition of gazillions of charters each of which has a complicated witness list associated with it, like this: /A. Original sur parchemin, larg. 280 mm x haut. 720/755 mm, partie droite d?un chirographe avec, ? gauche, la partie droite des lettres composant le mot CYROGRAPHUM, jadis scell? d?un sceau comtal, sur courroie. Arc//h. d?p. Somme, 9 H 337, n? ^ 1 / /B/. Copie dans le vidimus de Baudouin IX, comte de Flandre, en date du 13 octobre 1201 aujourd?hui perdu, d?apr?s ^ /C/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de Fr., lat. 17759, fol. 70v, sous la rubrique : ? Carta Roberti comitis Flandrie super nemore de Walnosia. LXXXV ?, d?apr?s /A/. /D/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Moreau 38, fol. 100, avec r?f?rences ? /A/. /E/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie 237, fol. 115, avec r?f?rences ? /A/. /F/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de Fr., lat. 17759, fol. 67v, sous la rubrique : ? Carta Balduini comitis Flandrie de Walnoisie nemore. LXXXI ?, sans doute d?apr?s /B/. /G/. Copie de 1295, Cartulaire noir, Bibl. nat. de Fr., lat. 17758, fol. 207 (livre XXIV, n? XVI), sans doute d?apr?s /B/. /H./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie 79, fol. 138, avec r?f?rences ? /C/. /I./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie 79, fol. 163, avec r?f?rences ? /C/. /a/. Chan. [F.-J] R[ay]m[ae]r[kers], /Donation faite en faveur de l?abbaye de Corbie (France) par Robert, comte de Flandre, en 1096/, dans /Analectes pour servir ? l?histoire eccl?siastique de la Belgique/, t. II, 1865, p. 268, d?apr?s /A/. /b/. E. Van den Bussche, /Recherches sur la for?t d?Houthulst/, dans /La Flandre/, t. V, 1873-1874, p. 331, d?apr?s /a/ et une copie de /B/. /c/. Godefroy Menilglaise (Marquis de), /Accord entre le comte de Flandre et l?abbaye de Corbie pour le partage de la for?t de Wouthulst et de terres vagues adjacentes?/, dans /Bulletin de la Soci?t? des antiquaires de Picardie/, t. II, 1874, p. 76, d?apr?s une copie de /B/. /d/. A. Wauters, dans /Bulletin de la Commission royale d?histoire/, t. II, 1874, p. 178, d?apr?s /D/. /e/. Th. de Limburg Stirum, /Cartulaire de Louis de Male, comte de Flandre/, t. I, Bruges, 1898, n? 559, p. 506, d?apr?s une copie issue de la tradition de /B/. /f/. Huyghebaert et Six, /La for?t/, p. 245, d?apr?s /A/. /g/. Prevenier, /De oorkonden/, n?^ 165, p. 357 (?dition du vidimus de 1201 suivie de celle de l?acte de 1096), d?apr?s /ACD/ et une copie prise sur /B/. Indiqu? : /R?pertoire du chartrier/ (1421), Bibl. nat. de Fr., fr. 24143, fol. 29 : ? Item une lettre du comte Robert de Flandres qui recongnoist que toute le forest de le Warnoise fu a l?eglise, et l?eglise lui en donna le moiti? par indivis reserv? le cacher et le voler que le comte y a et l?eglise a le miel. Sign? g 111 ?. ? Wauters, /Table chronologique/, t. VII/1, p. 179. ? Bormans et Halkin, /Table chronologique/, t. XI, p. 92 et 343. ? Vercauteren, /Actes/, p. CXIII-CXIV. ? Huyghebaert, /Ad villam/. ? Huyghebaert, /Houlthulst/, p. 186. ? Zoller-Devroey, /Le domaine/, p. 444. ? Morelle, /L?histoire/, p. 650. Do you really want to produce a full blown msDescription for all of these things and stash it away in the header? From dporter at uky.edu Fri Mar 30 17:03:50 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 30 Mar 2007 18:03:50 -0400 Subject: [tei-council] witness lists again In-Reply-To: <460D80BA.3080600@computing-services.oxford.ac.uk> References: <460D80BA.3080600@computing-services.oxford.ac.uk> Message-ID: <96f3df640703301503o459f7357w22f7c34420eece58@mail.gmail.com> Hi All, I'm willing to revisit this. I opened up my oXygen and attempted to build an msDescription based on Gautier's requests (as translated here: http://www.tei-c.org/Drafts/witnessPart/index.xml?style=printable) and indeed I had some trouble. But it's not a problem of in the header vs. in the witness list - I think that is a red herring. The problem is that this does not validate: manuscript filiation

seal description

More physical description

wxh

parchment

 1145 So, yes, in order to get some of these in you need to include their parent elements as well (to have we need , to have we need to have and ) but that's not such a big deal. The big deal, as I see it, is that we can't mix

s up with the specialized elements from the model.physDescPart class. So if our intrepid archivist wants to include a general physical description in his

s, plus a more detailed description of the seal (taking advantage of the element), he can't do it. He'd need to use the other specialized elements as well, and that indeed could be a burden. I don't suppose we'd want to allow as a member of model.pPart.msdesc, so it could occur within

? I really think this is the big issue. Other than that, the example above is valid and, I'd argue, not very burdensome. And whether it appears in the header or in the witness list, it'll look about the same. Dot On 3/30/07, Lou Burnard wrote: > I had the opportunity to discuss Gautier's ideas about witness lists > (see mail of 21st and 22nd) with the man himself, over several beers in > Paris earlier this week. I won't try to repeat all the discussion now > (and not just because of the beers), but I would like to ask those who > confidently assert that it can all be done with existing elements to > take a look at a real live example, such as the following. Put yourself > in the place of the downtrodden archivist trying to produce a reliable > edition of gazillions of charters each of which has a complicated > witness list associated with it, like this: > > /A. Original sur parchemin, larg. 280 mm x haut. 720/755 mm, partie > droite d'un chirographe avec, ? gauche, la partie droite des lettres > composant le mot CYROGRAPHUM, jadis scell? d'un sceau comtal, sur > courroie. Arc//h. d?p. Somme, 9 H 337, n? ^ 1 / > > /B/. Copie dans le vidimus de Baudouin IX, comte de Flandre, en date du > 13 octobre 1201 aujourd'hui perdu, d'apr?s ^ > /C/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de > Fr., lat. 17759, fol. 70v, sous la rubrique : ? Carta Roberti comitis > Flandrie super nemore de Walnosia. LXXXV ?, d'apr?s /A/. > > /D/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Moreau 38, > fol. 100, avec r?f?rences ? /A/. > > /E/. Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie > 237, fol. 115, avec r?f?rences ? /A/. > > /F/. Copie du XIII^e s., vers 1229, /Cartulaire blanc/, Bibl. nat. de > Fr., lat. 17759, fol. 67v, sous la rubrique : ? Carta Balduini comitis > Flandrie de Walnoisie nemore. LXXXI ?, sans doute d'apr?s /B/. > > /G/. Copie de 1295, Cartulaire noir, Bibl. nat. de Fr., lat. 17758, fol. > 207 (livre XXIV, n? XVI), sans doute d'apr?s /B/. > > /H./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie > 79, fol. 138, avec r?f?rences ? /C/. > > /I./ Copie du XVIII^e s., par Dom Grenier, Bibl. nat. de Fr., Picardie > 79, fol. 163, avec r?f?rences ? /C/. > > > /a/. Chan. [F.-J] R[ay]m[ae]r[kers], /Donation faite en faveur de > l'abbaye de Corbie (France) par Robert, comte de Flandre, en 1096/, dans > /Analectes pour servir ? l'histoire eccl?siastique de la Belgique/, t. > II, 1865, p. 268, d'apr?s /A/. > > /b/. E. Van den Bussche, /Recherches sur la for?t d'Houthulst/, dans /La > Flandre/, t. V, 1873-1874, p. 331, d'apr?s /a/ et une copie de /B/. > > /c/. Godefroy Menilglaise (Marquis de), /Accord entre le comte de > Flandre et l'abbaye de Corbie pour le partage de la for?t de Wouthulst > et de terres vagues adjacentes?/, dans /Bulletin de la Soci?t? des > antiquaires de Picardie/, t. II, 1874, p. 76, d'apr?s une copie de /B/. > > /d/. A. Wauters, dans /Bulletin de la Commission royale d'histoire/, t. > II, 1874, p. 178, d'apr?s /D/. > > /e/. Th. de Limburg Stirum, /Cartulaire de Louis de Male, comte de > Flandre/, t. I, Bruges, 1898, n? 559, p. 506, d'apr?s une copie issue de > la tradition de /B/. > > /f/. Huyghebaert et Six, /La for?t/, p. 245, d'apr?s /A/. > > /g/. Prevenier, /De oorkonden/, n?^ 165, p. 357 (?dition du vidimus de > 1201 suivie de celle de l'acte de 1096), d'apr?s /ACD/ et une copie > prise sur /B/. > > > Indiqu? : /R?pertoire du chartrier/ (1421), Bibl. nat. de Fr., fr. > 24143, fol. 29 : ? Item une lettre du comte Robert de Flandres qui > recongnoist que toute le forest de le Warnoise fu a l'eglise, et > l'eglise lui en donna le moiti? par indivis reserv? le cacher et le > voler que le comte y a et l'eglise a le miel. Sign? g 111 ?. ? Wauters, > /Table chronologique/, t. VII/1, p. 179. ? Bormans et Halkin, /Table > chronologique/, t. XI, p. 92 et 343. ? Vercauteren, /Actes/, p. > CXIII-CXIV. ? Huyghebaert, /Ad villam/. ? Huyghebaert, /Houlthulst/, p. > 186. ? Zoller-Devroey, /Le domaine/, p. 444. ? Morelle, /L'histoire/, p. > 650. > > > Do you really want to produce a full blown msDescription for all of > these things and stash it away in the header? > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From arianna.ciula at kcl.ac.uk Sat Mar 31 05:00:53 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Sat, 31 Mar 2007 11:00:53 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D3F18.8050705@oucs.ox.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460D35E9.7030501@kcl.ac.uk> <460D3F18.8050705@oucs.ox.ac.uk> Message-ID: <460E3155.704@kcl.ac.uk> I sent the XML to Lou. There shouldn't be anything controversial in my changes: some evident mistakes/omissions in the prose or examples, some other minor things related to what's called "Positioning" in the editorial guidelines and so on. I have some suggestions for things to add to those guidelines, but it's probably better to wait until I have done all the three chapters. > If you have a sourceforge account, send me the name and I > will give you commit rights. I don't think I do. I have downloaded all the repository to edit the relevant XML file, but that doesn't require an account as far as I know. Sorry my comments on Trac are not styled...copied them quickly and didn't realise I could edit them as Wiki style. Arianna Sebastian Rahtz wrote: > Arianna Ciula wrote: >> > (a) get the XML source out of the subversion repository (see James's >> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); >> > improve the text and either put the results back in the Council's >> branch >> > of the Subversion repository, or just email it to an editor. >> >> I don't have access to commit stuff to subversion. Should I just send >> the revised SG chapter to you Lou? >> > If you have a sourceforge account, send me the name and I > will give you commit rights. otherwise send XML to me > or Lou or Syd to check in. > > if your changes are controversial, they could go > in Council branch. are they? > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Sat Mar 31 11:42:00 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 31 Mar 2007 17:42:00 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460E3155.704@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460D35E9.7030501@kcl.ac.uk> <460D3F18.8050705@oucs.ox.ac.uk> <460E3155.704@kcl.ac.uk> Message-ID: <460E8F58.6090605@computing-services.oxford.ac.uk> I did a bit of quick reformatting of Arianna's version to make it easier to edit in emacs, and then checked it in. Her comments on the WIKI are very helpful too, but I haven't done anything about most of them yet. The main thing that worries me about this chapter is that it really doesn't give RelaxNG and DTD language equal time. If it just used DTD language as a vehicle to explain basic XML concepts that would be OK, but it goes into a lot more detail than necessary for that job. So I can't decide whether the best course is to add a comparable amount of detail about RELAXNG, or cut the chapter down drastically. Either way would require quite a lot of editorial time. The goal of the original was to explain enough of SGML for the user of the TEI to understand how the DTDs worked, and I think that's probably still a good goal. I'm just not sure that we have time to do the job equally well now that the the technical basis for the Guidelines has changed so much. Arianna Ciula wrote: > I sent the XML to Lou. > There shouldn't be anything controversial in my changes: some evident > mistakes/omissions in the prose or examples, some other minor things > related to what's called "Positioning" in the editorial guidelines and > so on. > > I have some suggestions for things to add to those guidelines, but > it's probably better to wait until I have done all the three chapters. > > > If you have a sourceforge account, send me the name and I > > will give you commit rights. > I don't think I do. I have downloaded all the repository to edit the > relevant XML file, but that doesn't require an account as far as I know. > > Sorry my comments on Trac are not styled...copied them quickly and > didn't realise I could edit them as Wiki style. > > Arianna > > Sebastian Rahtz wrote: >> Arianna Ciula wrote: >>> > (a) get the XML source out of the subversion repository (see James's >>> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); >>> > improve the text and either put the results back in the Council's >>> branch >>> > of the Subversion repository, or just email it to an editor. >>> >>> I don't have access to commit stuff to subversion. Should I just >>> send the revised SG chapter to you Lou? >>> >> If you have a sourceforge account, send me the name and I >> will give you commit rights. otherwise send XML to me >> or Lou or Syd to check in. >> >> if your changes are controversial, they could go >> in Council branch. are they? >> > From Syd_Bauman at Brown.edu Sun Apr 1 21:08:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 1 Apr 2007 21:08:55 -0400 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460D35E9.7030501@kcl.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460D35E9.7030501@kcl.ac.uk> Message-ID: <17936.22439.193898.662593@emt.wwp.brown.edu> I think, as a general rule, revised chapters should be checked into the Council branch or sent to editors at tei-c.org. From arianna.ciula at kcl.ac.uk Mon Apr 2 04:56:07 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 02 Apr 2007 09:56:07 +0100 Subject: [tei-council] What to do with an easter egg In-Reply-To: <460E8F58.6090605@computing-services.oxford.ac.uk> References: <4603FFF1.90002@oucs.ox.ac.uk> <460D35E9.7030501@kcl.ac.uk> <460D3F18.8050705@oucs.ox.ac.uk> <460E3155.704@kcl.ac.uk> <460E8F58.6090605@computing-services.oxford.ac.uk> Message-ID: <4610C527.6050005@kcl.ac.uk> > I did a bit of quick reformatting of Arianna's version to make it easier > to edit in emacs, and then checked it in. I am sorry for a likely dull question: but what does "checked in" mean here? I can't see my changed added to the Source and not even online. > The main thing that worries me about this chapter is that it really > doesn't give RelaxNG and DTD language equal time. Indeed, even if I didn't give weight to my comments, I think this is probably the only serious editorial issue of this chapter. > If it just used DTD > language as a vehicle to explain basic XML concepts that would be OK, > but it goes into a lot more detail than necessary for that job. So I > can't decide whether the best course is to add a comparable amount of > detail about RELAXNG, or cut the chapter down drastically. Either way > would require quite a lot of editorial time. If cutting would be quicker, for the sake of a realistic roadmap, I would say that taking out the additional details on DTDs would be good enough for now. But if you say that adding information on RelaxNG may be as time consuming may be it is worth going this way instead, unless the editors think there is a better place than the Gentle introduction where details on how to write a schema could be included. Arianna Lou Burnard wrote: > I did a bit of quick reformatting of Arianna's version to make it easier > to edit in emacs, and then checked it in. > > Her comments on the WIKI are very helpful too, but I haven't done > anything about most of them yet. > > The main thing that worries me about this chapter is that it really > doesn't give RelaxNG and DTD language equal time. If it just used DTD > language as a vehicle to explain basic XML concepts that would be OK, > but it goes into a lot more detail than necessary for that job. So I > can't decide whether the best course is to add a comparable amount of > detail about RELAXNG, or cut the chapter down drastically. Either way > would require quite a lot of editorial time. > > The goal of the original was to explain enough of SGML for the user of > the TEI to understand how the DTDs worked, and I think that's probably > still a good goal. I'm just not sure that we have time to do the job > equally well now that the the technical > basis for the Guidelines has changed so much. > > > Arianna Ciula wrote: >> I sent the XML to Lou. >> There shouldn't be anything controversial in my changes: some evident >> mistakes/omissions in the prose or examples, some other minor things >> related to what's called "Positioning" in the editorial guidelines and >> so on. >> >> I have some suggestions for things to add to those guidelines, but >> it's probably better to wait until I have done all the three chapters. >> >> > If you have a sourceforge account, send me the name and I >> > will give you commit rights. >> I don't think I do. I have downloaded all the repository to edit the >> relevant XML file, but that doesn't require an account as far as I know. >> >> Sorry my comments on Trac are not styled...copied them quickly and >> didn't realise I could edit them as Wiki style. >> >> Arianna >> >> Sebastian Rahtz wrote: >>> Arianna Ciula wrote: >>>> > (a) get the XML source out of the subversion repository (see James's >>>> > notes on how to do that at http://www.tei-c.org/Council/tcw06.xml); >>>> > improve the text and either put the results back in the Council's >>>> branch >>>> > of the Subversion repository, or just email it to an editor. >>>> >>>> I don't have access to commit stuff to subversion. Should I just >>>> send the revised SG chapter to you Lou? >>>> >>> If you have a sourceforge account, send me the name and I >>> will give you commit rights. otherwise send XML to me >>> or Lou or Syd to check in. >>> >>> if your changes are controversial, they could go >>> in Council branch. are they? >>> >> > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Apr 2 04:24:49 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Mon, 02 Apr 2007 17:24:49 +0900 Subject: [tei-council] Can't find my easter egg! Message-ID: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> I was assigned three easter eggs, one of which I can't find! #103: TE: Terminological Databases: The file is at SF, but it says only:

This chapter has been temporarily removed, pending a complete revision. The work described here in earlier versions of the Guidelines has since been superceded by a number of related and emerging ISO standards, in particular ISO 12200: 1999 Computer applications in Terminology -- Machine-readable terminology interchange format (MARTIF) -- negotiated interchange and more recently ISO 16642: 2003 Computer applications in terminology - Terminological Markup Framework, which defines a familly of formats to be used in combination with descriptors provided by ISO CD 12620:1999 Computer applications in terminology - Data categories (under revision). The revised chapter will specify a core terminological model, conformant with ISO 16642

So, what is the plan for this in P5 1.0? Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 05:23:09 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 10:23:09 +0100 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> References: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4610CB7D.1060604@computing-services.oxford.ac.uk> Christian Wittern wrote: > I was assigned three easter eggs, one of which I can't find! > #103: TE: Terminological Databases: > > The file is at SF, but it says only: > >

> This chapter has been temporarily removed, pending a complete > revision. The work described here in earlier versions of the > Guidelines has since been superceded by a number of related and > emerging ISO standards, in particular ISO 12200: 1999 Computer > applications in Terminology -- Machine-readable terminology interchange > format (MARTIF) -- negotiated interchange and more recently ISO > 16642: 2003 Computer applications in terminology - > Terminological Markup Framework, which defines a familly of > formats to be used in combination with descriptors provided by ISO CD > 12620:1999 Computer applications in terminology - Data > categories (under revision). The revised chapter will specify > a core terminological model, conformant with ISO 16642 >

> So, what is the plan for this in P5 1.0? > > Christian > > Well, we were rather hoping that you, as reviewer, might come up with an answer to that question! I dont know why it was assigned to you rather than Laurent though. From laurent.romary at loria.fr Mon Apr 2 05:27:03 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 2 Apr 2007 11:27:03 +0200 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610CB7D.1060604@computing-services.oxford.ac.uk> References: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> <4610CB7D.1060604@computing-services.oxford.ac.uk> Message-ID: <4EC3B16F-2948-4561-9790-417EEEBA9DED@loria.fr> The answer is obviously no, but as we are currently establishing a working plan with our colleagues from Lisa to synchronise with TBX, we can plan it for a 1.x release. Best, Laurent Le 2 avr. 07 ? 11:23, Lou Burnard a ?crit : > Christian Wittern wrote: >> I was assigned three easter eggs, one of which I can't find! >> #103: TE: Terminological Databases: >> >> The file is at SF, but it says only: >> >>

>> This chapter has been temporarily removed, pending a complete >> revision. The work described here in earlier versions of the >> Guidelines has since been superceded by a number of related and >> emerging ISO standards, in particular ISO 12200: 1999 Computer >> applications in Terminology ? Machine-readable terminology >> interchange >> format (MARTIF) ? negotiated interchange and more recently >> ISO >> 16642: 2003 Computer applications in terminology - >> Terminological Markup Framework, which defines a familly of >> formats to be used in combination with descriptors provided by ISO CD >> 12620:1999 Computer applications in terminology - Data >> categories (under revision). The revised chapter will specify >> a core terminological model, conformant with ISO 16642 >>

>> So, what is the plan for this in P5 1.0? >> >> Christian >> >> > Well, we were rather hoping that you, as reviewer, might come up > with an > answer to that question! > > I dont know why it was assigned to you rather than Laurent though. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 05:49:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 10:49:27 +0100 Subject: [tei-council] Can't find my easter egg! In-Reply-To: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> References: <4610BDD1.2070201@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4610D1A7.5020702@oucs.ox.ac.uk> Christian Wittern wrote: > I was assigned three easter eggs, one of which I can't find! > #103: TE: Terminological Databases: > > The file is at SF, but it says only: > >

> This chapter has been temporarily removed, you got lucky. one of your eggs needs no eating -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 14:25:50 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 19:25:50 +0100 Subject: [tei-council] Conformance draft: namespace purity Message-ID: <46114AAE.1030100@computing-services.oxford.ac.uk> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have all expressed support for James's proposal that (inter alia) conformance in a TEI document implies that the TEI namespace remains unpolluted by user-defined elements. Does any of those who have remained silent on the topic wish to speak up before we move on to the next drafting phase of this document, or can I assume that the argument in favour of TEI purity is carried? Re-reading the thread again, there does seem to be a strong consensus, but I am also aware that not everyone is sure about how far this extends. Personally, I would like to see a bit more text at the start of this chapter explaining what conformance is for and what it means. This ought to explain the distinction between formal validation (against a specific schema) and usage of a namespace, and what each buys you in terms of interoperability. It should make clear the reasoning behind insisting that elements which are not defined by the TEI (i.e. not in the Guidelines) cannot be in the TEI namespace. And of course it should make clear what this means in practice for TEI-schema-developers. I have a couple of other points about the draft, which I will make in separate notes. From Syd_Bauman at Brown.edu Mon Apr 2 15:35:54 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 15:35:54 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46114AAE.1030100@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> Message-ID: <17937.23322.362024.862804@emt.wwp.brown.edu> > Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have > all expressed support for James's proposal that (inter alia) > conformance in a TEI document implies that the TEI namespace > remains unpolluted by user-defined elements. I had thought that perhaps James (and someone else?) now believed that namespace-purity be in the realm of the definition of "TEI Interchange Format", rather than of "TEI Conformance". I certainly do. From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 15:57:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 20:57:56 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.23322.362024.862804@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> Message-ID: <46116044.2040709@computing-services.oxford.ac.uk> That was certainly a minority view which has been expressed. And certainly the material on the interchange format (formerly IN, now 24.2) is in need of substantial revision. Maybe a good way forward would be to see how far we can get with that first? Certainly the two are closely related! Syd Bauman wrote: >> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have >> all expressed support for James's proposal that (inter alia) >> conformance in a TEI document implies that the TEI namespace >> remains unpolluted by user-defined elements. >> > > I had thought that perhaps James (and someone else?) now believed > that namespace-purity be in the realm of the definition of "TEI > Interchange Format", rather than of "TEI Conformance". I certainly > do. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:14:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:14:36 +0100 Subject: [tei-council] outstanding SF requests Message-ID: <4611642C.3010508@oucs.ox.ac.uk> Looking at SF, I see 3 tickets still open under feature requests 1. pointer to schema in header. I have closed this, and relegated it to 1.1. My sense of the discussion on here and on the RELAXNG list is that there is insufficient consensus to reasonably proceed at this stage. 2. a header element to hold application data. My sense is that there is enough genuine interest in this that we must discuss a proposal in Berlin. I have closed the SF ticket and created a new one in trac for it. 3. 1019594 Manuscript encoding . Lou, can you polish that one off in some way? There are, delightfully, no open bug requests in Sourceforge. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:22:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:22:45 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116044.2040709@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> Message-ID: <46116615.3080101@oucs.ox.ac.uk> Regardless of the letter of the law, we can influence a good many TEI customizers by what Roma does. Is it the Feeling Of The Meeting that I should change web-Roma to make new elements be by default in a non-TEI namespace? My suggestion would be to put them in http://www.tei-c.org/ns/$NAME, where $NAME is the name given to the ODD, which dictates the name of the output schema file. I know that's not ideal, so if you have a better suggestion, let me know. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:27:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:27:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116044.2040709@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> Message-ID: <46116735.3090806@computing-services.oxford.ac.uk> While I think that Namespace Purity should be a requirement for any form of Interchange Format, I'm am not yet unconvinced that it should not be a requirement for Conformance as well. I.e. if we are going to do namespaces, we owe it to our users and place as a standard to do so properly. I do agree that including more discussion on the benefits of namespaces, their relationship to conformance and schemas, will benefit the Conformance chapter section (since it is no longer a chapter by itself). I had not included such because I was not sure that the council would agree to the principle of TEI Namespace purity. I think there should be more discussion, in the Non-Conformant section, on those schemas which otherwise would be Conformant, but simply lack the namespace differentiation required by Conformance. I don't think we should view such documents as *bad* in any way, simply not Conformant nor in Interchange Format. i.e., I see Syd's point, but am not convinced that we should back down from Namespace Purity. I have not yet done any of the changes or corrections suggested to me (I had timetabled it for starting at the end of this week), and am happy for Lou to add any of his changes in the meantime. -James Lou Burnard wrote: > That was certainly a minority view which has been expressed. And > certainly the material on the interchange format (formerly IN, now 24.2) > is in need of substantial revision. Maybe a good way forward would be to > see how far we can get with that first? Certainly the two are closely > related! > > > Syd Bauman wrote: >>> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have >>> all expressed support for James's proposal that (inter alia) >>> conformance in a TEI document implies that the TEI namespace >>> remains unpolluted by user-defined elements. >>> >> >> I had thought that perhaps James (and someone else?) now believed >> that namespace-purity be in the realm of the definition of "TEI >> Interchange Format", rather than of "TEI Conformance". I certainly >> do. >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:31:26 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:31:26 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116615.3080101@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> Message-ID: <4611681E.3040604@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Regardless of the letter of the law, we can influence a good many TEI > customizers by what Roma does. Is it the Feeling Of The Meeting > that I should change web-Roma to make new elements > be by default in a non-TEI namespace? > > My suggestion would be > to put them in http://www.tei-c.org/ns/$NAME, where $NAME > is the name given to the ODD, which dictates the name of the > output schema file. I know that's not ideal, so if you have a > better suggestion, let me know. I believe when I suggested this earlier a number of people argued against it because having it have the appearance of being part of the TEI NS URI might imply approval or condoning of these changes. I can see how some would abuse this, or how it might be confusing. Maybe something like http://www.ProjectName.info/ns/$VersionNumber ? Not sure. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:37:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:37:58 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4611681E.3040604@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> Message-ID: <461169A6.9080707@oucs.ox.ac.uk> James Cummings wrote: > > I believe when I suggested this earlier a number of people argued > against it because having it have the appearance of being part of the > TEI NS URI might imply approval or condoning of these changes. I can't say I buy that. By using the TEI NS URI, we are saying that these are intended to be used with the TEI, but are not the TEI. But I don't mind if there is an alternative algorithm. > I can see how some would abuse this, or how it might be confusing. > > Maybe something like http://www.ProjectName.info/ns/$VersionNumber ? where does $VersionNumber come from? the problem with http://www.ProjectName.info/ns is that people have a minimal expectation of namespaces being human readable (for good or bad). If I had a "ProjectName" to hand, I could use it, I agree. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 16:43:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 21:43:08 +0100 Subject: [tei-council] conformance draft In-Reply-To: <460428B3.6050304@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> Message-ID: <46116ADC.2020106@computing-services.oxford.ac.uk> Sebastian said > er, um. yes. I meant to say I am relieved we are > discussing just this in some detail, as it implies > the rest is generally accepted. > Not so fast Red Baron... 1. The definition of "recommended practice" used to have a third point: "all textual features which the guidelines recommend be captured are in fact encoded. " which James removed presumably because he could think of no case where the Guidelines actually makes recommendations about the level of encoding to be applied (i.e. where it suggests that you really ought to mark up paragraphs, say, or lines in verse) 2. The original draft distinguishes two formats for a conformant document: "A document is /TEI-conformant/ if it is either in /TEI local processing format/ or in /TEI interchange format/. A full description of the document should specify which format it is in." The new draft does not make this distinction up front, although it is discussed later on at 1.3.3.2. Was this a deliberate decision or an oversight? Should we not make the distinction earlier? I can see that the case for a third possible format originally discussed ("TEI packed interchange format") is hard to maintain with the availability of XML, but maybe we ought to preserve the other two? 3. The discussion of a "TEI derived schema" (1.2.2 in the current draft) talks about ODD-derived schemas and about exemplars, but does not mention the feasibility of constructing a TEI schema by combining either DTD fragments or RelaxNG fragments. Are we specifically outlawing that approach, or are we just passing over it in silence? I don't think either approach will win us any friends. 4. The suggestion that a sourceDesc element is no longer required seems unwise to me. If a document is "born digital" the fact should be stated, and the sourceDesc is the place to do it. 5. 1.2.5 introduces a new term "TEI compliant" but does not seem to define it anywhere: is it meant to be synonymous with "TEI conformant"? 6. As others have suggested, the list of exemplars should probably move somewhere else. Except that the definition of tei_all is important, since it's used in the following section to define varieties of conformant schemas. 7. I am a bit unclear about the purpose of a "TEI Supported Extension Schema". Can anyone suggest one? what does "is supported (to some degree) by the TEI" mean? 8. The last bullet point in the list at the start of 1.3.3 (requiring the existence of an ODD to document the schema used by a non conformant customization) while I agree with it in principle is (a) not a property of a document (b) somewhat at variance with my point 3 above. 9. I don't like section 1.7 much: it makes me feel uneasy. We are not in a position to tell funding bodies what they should or shouldn't think, and even if we were it shouldn't be a topic for this chapter. We ought to be clear first about what *we* mean by TEI conformance, and although I think this discussion is clarifying that quite a lot, we ain't there yet. Issues of "superior quality" and "greater academic scrutiny" surely relate to matters which are out of scope here (see for example my point 1 above) Let me repeat that I think this draft is definitely going in the right direction, despite these somewhat picky comments! I think it's really important to get a good version of this chapter into draft 1.0 so I hope we can focus on that for a while.. From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 16:44:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 21:44:27 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461169A6.9080707@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> Message-ID: <46116B2B.6030609@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> >> I believe when I suggested this earlier a number of people argued >> against it because having it have the appearance of being part of the >> TEI NS URI might imply approval or condoning of these changes. > I can't say I buy that. By using the TEI NS URI, we are saying that these > are intended to be used with the TEI, but are not the TEI. But I don't > mind if there is an alternative algorithm. I could be convinced by that argument. It also means that http://www.tei-c.org/ns/$NAME is under our control and we can put a page at http://www.tei-c.org/ns/* (that isn't 1.0) saying that it is a user-defined namespace and the TEI is not responsible for it. >> Maybe something like http://www.ProjectName.info/ns/$VersionNumber ? > where does $VersionNumber come from? Was assuming they'd add it just as they add ProjectName (as the name of the file) -James > > the problem with http://www.ProjectName.info/ns is that people have > a minimal expectation of namespaces being human readable > (for good or bad). If I had a "ProjectName" to hand, I could use it, > I agree. > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 16:49:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 21:49:47 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116B2B.6030609@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <46116B2B.6030609@computing-services.oxford.ac.uk> Message-ID: <46116C6B.7060000@oucs.ox.ac.uk> James Cummings wrote: > > Was assuming they'd add it just as they add ProjectName (as the name > of the file) > nowhere to store it, tho. I need a place in an ODD file to record anything which should be restored next time. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 16:50:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 21:50:42 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116B2B.6030609@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <46116B2B.6030609@computing-services.oxford.ac.uk> Message-ID: <46116CA2.6090004@computing-services.oxford.ac.uk> James Cummings wrote: > Sebastian Rahtz wrote: >> James Cummings wrote: >>> >>> I believe when I suggested this earlier a number of people argued >>> against it because having it have the appearance of being part of >>> the TEI NS URI might imply approval or condoning of these changes. >> I can't say I buy that. By using the TEI NS URI, we are saying that >> these >> are intended to be used with the TEI, but are not the TEI. But I >> don't mind if there is an alternative algorithm. > > I could be convinced by that argument. It also means that > http://www.tei-c.org/ns/$NAME is under our control and we can put a > page at > http://www.tei-c.org/ns/* (that isn't 1.0) saying that it is a > user-defined namespace and the TEI is not responsible for it. > I can probably be persuaded to like this eventually, but it does rather raise the spectre of "TEI approved extensions" vs "TEI not approved extensions". And how on earth can we guarantee that $NAME is going to be unique? In which case all the arguments about namespace pollution reappear, though at a higher level. From Syd_Bauman at Brown.edu Mon Apr 2 16:53:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 16:53:14 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461169A6.9080707@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> Message-ID: <17937.27962.620536.39642@emt.wwp.brown.edu> If we're going to do this (and I'm still agin it), my instinct is that webRoma should have a text field for the user to fill in. If you want to put in a default, why not put in a URI that points to the IP address of the user? Thus a default value might be something like http://128.148.123.321/TEIP5Customization/$ns where $ns is the value of the Filename or the Prefix pattern field. From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 17:00:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 22:00:52 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116ADC.2020106@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> Message-ID: <46116F04.8030100@computing-services.oxford.ac.uk> Lou Burnard wrote: > 1. The definition of "recommended practice" used to have a third point: > > "all textual features which the guidelines recommend be captured are in > fact encoded. " > which James removed presumably because he could think of no case where > the Guidelines actually makes recommendations about the level of > encoding to be applied (i.e. where it suggests that you really ought to > mark up paragraphs, say, or lines in verse) To be honest, I think Sebastian commented that one out, not me, but I agreed with him that I couldn't think of a place where the TEI Guidelines (strongly at least) recommend to what level encoding should be applied. I.e. if I'm doing a poem it is fine if I do rather than , never mind that I'm not marking up . > 2. The original draft distinguishes two formats for a conformant document: > "A document is /TEI-conformant/ if it is either in /TEI local processing > format/ or in /TEI interchange format/. A full description of the > document should specify which format it is in." > > The new draft does not make this distinction up front, although it is > discussed later on at 1.3.3.2. Was this a deliberate decision or an > oversight? Should we not make the distinction earlier? I can see that > the case for a third possible format originally discussed ("TEI packed > interchange format") is hard to maintain with the availability of XML, > but maybe we ought to preserve the other two? It was deliberate. My TEI is in TEI Interchange Format and is TEI Local Processing Format. I thought we should keep the distinction to make those who are not-fully-Conformant because of local processing needs, realise that this is an acceptable thing to do even if not strictly Conformant. > 3. The discussion of a "TEI derived schema" (1.2.2 in the current draft) > talks about ODD-derived schemas and about exemplars, but does not > mention the feasibility of constructing a TEI schema by combining either > DTD fragments or RelaxNG fragments. Are we specifically outlawing that > approach, or are we just passing over it in silence? I don't think > either approach will win us any friends. I was wondering who would raise that first -- that is before Wendell sees it -- I was intentionally being hard-line dictatorial and stating that TEI Conformance requires there to have been an ODD at some point to generate the schema. I think we should outlaw that approach for TEI Conformance. I'm happy for people to do it, but think we should have a No-ODD, No-Conformance, approach. I don't feel that people who will be doing that will be as concerned about Conformance in any case. > 4. The suggestion that a sourceDesc element is no longer required seems > unwise to me. If a document is "born digital" the fact should be > stated, and the sourceDesc is the place to do it. Yes, and that is the suggestion made. I just wondered about making it a requirement for *any* TEI document (which is what the old description did). > 5. 1.2.5 introduces a new term "TEI compliant" but does not seem to > define it anywhere: is it meant to be synonymous with "TEI conformant"? Typo. > 6. As others have suggested, the list of exemplars should probably move > somewhere else. Except that the definition of tei_all is important, > since it's used in the following section to define varieties of > conformant schemas. Since Modification is now a section of the Using TEI chapter, as long as that goes before the Conformance section, then that would seem an appropriate place to discuss these in depth. > 7. I am a bit unclear about the purpose of a "TEI Supported Extension > Schema". Can anyone suggest one? what does "is supported (to some > degree) by the TEI" mean? I.e. TEI with XInclude, TEI with SVG in graphic, etc. Customisations that are not pure TEI which the TEI produces. > 8. The last bullet point in the list at the start of 1.3.3 (requiring > the existence of an ODD to document the schema used by a non conformant > customization) while I agree with it in principle is (a) not a property > of a document (b) somewhat at variance with my point 3 above. This list is meant to be identical as the one at 1.2. > 9. I don't like section 1.7 much: it makes me feel uneasy. We are not in > a position to tell funding bodies what they should or shouldn't think, > and even if we were it shouldn't be a topic for this chapter. We ought > to be clear first about what *we* mean by TEI conformance, and although > I think this discussion is clarifying that quite a lot, we ain't there > yet. Issues of "superior quality" and "greater academic scrutiny" surely > relate to matters which are out of scope here (see for example my point > 1 above) Agreed. But I still feel it is important to stress (to them and others) that Conformance != Quality. > > Let me repeat that I think this draft is definitely going in the right > direction, despite these somewhat picky comments! I think it's really > important to get a good version of this chapter into draft 1.0 so I hope > we can focus on that for a while.. I think all these comments are the kind I was hoping to get. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Mon Apr 2 17:04:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 02 Apr 2007 22:04:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.27962.620536.39642@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> Message-ID: <46116FE1.5010201@computing-services.oxford.ac.uk> Syd Bauman wrote: > If we're going to do this (and I'm still agin it), my instinct is > that webRoma should have a text field for the user to fill in. If you > want to put in a default, why not put in a URI that points to the IP > address of the user? Thus a default value might be something like > > http://128.148.123.321/TEIP5Customization/$ns > > where $ns is the value of the Filename or the Prefix pattern field. That would certainly make namespace pollution much less likely to happen. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:48:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:48:18 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.27962.620536.39642@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> Message-ID: <46117A22.3050701@oucs.ox.ac.uk> Syd Bauman wrote: > If we're going to do this (and I'm still agin it), my instinct is > that webRoma should have a text field for the user to fill in. If you > want to put in a default, why not put in a URI that points to the IP > address of the user? Thus a default value might be something like > > http://128.148.123.321/TEIP5Customization/$ns > > where $ns is the value of the Filename or the Prefix pattern field. > > Gracious. My IP address from home changes every day (assigned by by ISP). More importantly, I need to store it somewhere.... I don't want to overload the meaning of Prefix, as that is used for something else -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 17:49:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 22:49:56 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116F04.8030100@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> Message-ID: <46117A84.8010704@computing-services.oxford.ac.uk> James Cummings wrote: > >> 3. The discussion of a "TEI derived schema" (1.2.2 in the current >> draft) talks about ODD-derived schemas and about exemplars, but does >> not mention the feasibility of constructing a TEI schema by combining >> either DTD fragments or RelaxNG fragments. Are we specifically >> outlawing that approach, or are we just passing over it in silence? I >> don't think either approach will win us any friends. > > I was wondering who would raise that first -- that is before Wendell > sees it -- I was intentionally being hard-line dictatorial and stating > that TEI Conformance requires there to have been an ODD at some point > to generate the schema. I think we should outlaw that approach for TEI > Conformance. I'm happy for people to do it, but think we should have > a No-ODD, No-Conformance, approach. I don't feel that people who will > be doing that will be as concerned about Conformance in any case. OK, well just supposing for the moment that we don't mind upsetting Wendell too much, how do we feel about the current text of MD which I am currently hacking at? I am now thinking that the sensible thing would be to simply axe all the discussion of parameter entities etc. and simply say how to do the job with an ODD. Do we agree? From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:50:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:50:20 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46116CA2.6090004@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <46116B2B.6030609@computing-services.oxford.ac.uk> <46116CA2.6090004@computing-services.oxford.ac.uk> Message-ID: <46117A9C.9030100@oucs.ox.ac.uk> Lou Burnard wrote: > > I can probably be persuaded to like this eventually, but it does > rather raise the spectre of "TEI approved extensions" vs "TEI not > approved extensions". And how on earth can we guarantee that $NAME is > going to be unique? In which case all the arguments about namespace > pollution reappear, though at a higher level. > Not our problem, though. We can't get bogged down in registration of namespaces or resolving conflicts. Whatever scheme we choose, we can't guarentee uniqueness. I am only talking about a _suggestion_ for the namespace, anyone with more than two brains will know to change it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 17:51:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 22:51:30 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117A22.3050701@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> Message-ID: <46117AE2.1060804@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Syd Bauman wrote: >> If we're going to do this (and I'm still agin it), my instinct is >> that webRoma should have a text field for the user to fill in. If you >> want to put in a default, why not put in a URI that points to the IP >> address of the user? Thus a default value might be something like >> >> http://128.148.123.321/TEIP5Customization/$ns >> >> where $ns is the value of the Filename or the Prefix pattern field. >> >> > Gracious. My IP address from home changes every day (assigned by > by ISP). > > More importantly, I need to store it somewhere.... > > I don't want to overload the meaning of Prefix, as that > is used for something else > Then it looks as if you must insist on the poor benighted customizer supplying their own URI for the customization. From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 17:58:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 22:58:21 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117AE2.1060804@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> Message-ID: <46117C7D.9030704@oucs.ox.ac.uk> Lou Burnard wrote: > > Then it looks as if you must insist on the poor benighted customizer > supplying their own URI for the customization. > which may still be the same as the one you choose. I need to see how to do this in Roma, forcing you to fill in a field. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:03:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:03:12 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46117A84.8010704@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> Message-ID: <46117DA0.3070207@oucs.ox.ac.uk> Lou Burnard wrote: > > I am now thinking that the sensible thing would be to simply axe all > the discussion of parameter entities etc. and simply say how to do the > job with an ODD. Do we agree? if we don't document the parameter entities, we might as well stop producing them, no? and we might as well stop distributing the DTD modules? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:08:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:08:03 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46116ADC.2020106@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> Message-ID: <46117EC3.10307@oucs.ox.ac.uk> Lou Burnard wrote: > > 1. The definition of "recommended practice" used to have a third point: > > "all textual features which the guidelines recommend be captured are > in fact encoded. " > which James removed presumably because he could think of no case where > the Guidelines actually makes recommendations about the level of > encoding to be applied (i.e. where it suggests that you really ought > to mark up paragraphs, say, or lines in verse) I confess it all. It was me what removed that sentence. for the reason you suggest. It just begs the question "yeah, so what are they, then?". > > 4. The suggestion that a sourceDesc element is no longer required > seems unwise to me. If a document is "born digital" the fact should > be stated, and the sourceDesc is the place to do it. if a document has no , then its born digital. QED. Its just silly in practice to force me to _say_ so on every document I write, especially since I always leave it blank.... (apropos of which, I can't remember if James avoided this trap? does he say that the mandatory elenents cannot be empty? > > 9. I don't like section 1.7 much: it makes me feel uneasy. We are not > in a position to tell funding bodies what they should or shouldn't > think, and even if we were it shouldn't be a topic for this chapter. > We ought to be clear first about what *we* mean by TEI conformance, > and although I think this discussion is clarifying that quite a lot, > we ain't there yet. Issues of "superior quality" and "greater academic > scrutiny" surely relate to matters which are out of scope here (see > for example my point 1 above) it could be said that this section is a bit patronizing. I didn't mind it when I read it, but if you object, it doesnt damage the chapter to remove it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Mon Apr 2 18:25:10 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 16:25:10 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117AE2.1060804@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> Message-ID: <1175552710.6077.5.camel@localhost> I'm not convinced by the counter arguments to Sebastian's original namespace suggestion. What if instead of ns/ we used user_defined/ or something to indicate that it was not TEI approved? Not knowing the capabilities of Roma's internals, I don't know if this following is possible, but I'd prefer two options: 1) tei.org//user_defined/$name/ 2) $project.$tld/$somethingelse I.e. it seems to me to be useful to supply a default ns for people but also to allow ones that already have something in mind the option of including that. On Mon, 2007-04-02 at 22:51 +0100, Lou Burnard wrote: > Sebastian Rahtz wrote: > > Syd Bauman wrote: > >> If we're going to do this (and I'm still agin it), my instinct is > >> that webRoma should have a text field for the user to fill in. If you > >> want to put in a default, why not put in a URI that points to the IP > >> address of the user? Thus a default value might be something like > >> > >> http://128.148.123.321/TEIP5Customization/$ns > >> > >> where $ns is the value of the Filename or the Prefix pattern field. > >> > >> > > Gracious. My IP address from home changes every day (assigned by > > by ISP). > > > > More importantly, I need to store it somewhere.... > > > > I don't want to overload the meaning of Prefix, as that > > is used for something else > > > > Then it looks as if you must insist on the poor benighted customizer > supplying their own URI for the customization. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:30:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:30:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175552710.6077.5.camel@localhost> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> Message-ID: <461183F0.1070609@oucs.ox.ac.uk> Daniel O'Donnell wrote: > 1) tei.org//user_defined/$name/ > 2) $project.$tld/$somethingelse > not sure what "$tld" is? > I.e. it seems to me to be useful to supply a default ns for people but > also to allow ones that already have something in mind the option of > including that. > it would always be a suggestion, indeed. just a matter of whether a field is filled in with a default or not when you come to "add a new element" page. I would strongly suggest that people use something based on their project URL if they have one. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Mon Apr 2 18:31:06 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 16:31:06 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461183F0.1070609@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> Message-ID: <1175553066.6077.16.camel@localhost> $tld = $tld = .com|.org|.co.uk, etc. On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote: > Daniel O'Donnell wrote: > > 1) tei.org//user_defined/$name/ > > 2) $project.$tld/$somethingelse > > > not sure what "$tld" is? > > I.e. it seems to me to be useful to supply a default ns for people but > > also to allow ones that already have something in mind the option of > > including that. > > > > it would always be a suggestion, indeed. just a matter > of whether a field is filled in with a default or not when you come to > "add a new element" page. > > I would strongly suggest that people use something > based on their project URL if they have one. > -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From lou.burnard at computing-services.oxford.ac.uk Mon Apr 2 18:36:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 02 Apr 2007 23:36:43 +0100 Subject: [tei-council] rules about renaming Message-ID: <4611857B.3060506@computing-services.oxford.ac.uk> If I want to rename a TEI element, I am obviously required not to use as the new name an existing name in the schema. Slightly less obviously, I cannot use as the new name any name from any module I might want to include in some other schema for the same document. I cannot, for example, rename

as if I am already using or plan to use . But what about names which happen to look the same in different languages? For example, suppose the French for "p" were "q"... would the presence of the xml:lang attribute here be enough to make the following valid: q and if not, does this mean that all identifiers share the same name space? I rayther suspect they have to.... From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 2 18:42:52 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 02 Apr 2007 23:42:52 +0100 Subject: [tei-council] rules about renaming In-Reply-To: <4611857B.3060506@computing-services.oxford.ac.uk> References: <4611857B.3060506@computing-services.oxford.ac.uk> Message-ID: <461186EC.5050004@oucs.ox.ac.uk> Lou Burnard wrote: > But what about names which happen to look the same in different > languages? > > For example, suppose the French for "p" were "q"... would the presence > of the xml:lang attribute here be enough to make the following valid: > > > q > > > and if not, does this mean that all identifiers share the same name > space? > the xml:lang makes no difference there, its just documentation. am trying to think what the effect would be. have you tried it? my brain is hurting following through the implications. I suspect that in RELAXNG it might just work, in the sense of getting a valid schema. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Mon Apr 2 19:24:22 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 19:24:22 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46117A22.3050701@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> Message-ID: <17937.37030.473212.244366@emt.wwp.brown.edu> > Gracious. My IP address from home changes every day (assigned by by > ISP). Mine too. What difference does that make? Only reinforces the idea that this is a silly default you might use for quick tests, but not a good idea for you True Customization. > More importantly, I need to store it somewhere.... I don't understand. Don't you need to store it no matter what it is? > I don't want to overload the meaning of Prefix, as that is used for > something else As is the filename. Which may be different than the ident= of . Seems to me to be a good idea to use one of 'em for the default. As you've pointed out, this is only a default, not a suggestion. From conal.tuohy at vuw.ac.nz Mon Apr 2 19:26:48 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 03 Apr 2007 11:26:48 +1200 Subject: [tei-council] rules about renaming In-Reply-To: <4611857B.3060506@computing-services.oxford.ac.uk> References: <4611857B.3060506@computing-services.oxford.ac.uk> Message-ID: <1175556408.3766.104.camel@localhost> On Mon, 2007-04-02 at 23:36 +0100, Lou Burnard wrote: > If I want to rename a TEI element, I am obviously required not to use as > the new name an existing name in the schema. Slightly less obviously, I > cannot use as the new name any name from any module I might want to > include in some other schema for the same document. > > I cannot, for example, rename

as if I am already using or plan > to use . > > But what about names which happen to look the same in different languages? > > For example, suppose the French for "p" were "q"... would the presence > of the xml:lang attribute here be enough to make the following valid: > > > q > > > and if not, does this mean that all identifiers share the same name space? > > I rayther suspect they have to.... I think you're right. In my earlier response to the conformance draft I suggested that the localised TEI schemas should have their own namespace URIs, too, because, as you point out, sharing a common namespace across all natural languages is, on the face of it, running a risk that names will collide. My suggestion to mitigate this risk was that we publish distinct namespace URIs for each language into which the TEI vocabulary is translated, in addition to the existing one for the standard English TEI: http://www.tei-c.org/ns/1.0 I suggest that the namespace URI for every localised version should have the same base URI as above, but also include a fragment identifier to point to part of the page. So, for instance, the hypothetical French TEI, in which means

, might have this namespace URI: http://www.tei-c.org/ns/1.0#fr If we did this we also ought to modify the HTML page at http://www.tei-c.org/ns/1.0 to include an element with an id of "fr", perhaps like so:

This document describes the namespaces of the Text Encoding Initiative (TEI).

The namespace whose URI is "http://www.tei-c.org/P5/" identifies the primary TEI vocabulary described in the TEI Guidelines.

Localised versions

The primary TEI vocabulary is largely based on English, but it has also been localised into other languages. Encoders who are more fluent in one of these languages may wish to use one of these alternative vocabularies.

  • fran?aise
These list items should, where possible, contain pointers to information about the localised versions (e.g. to the relevant guidelines document, ODDs, or whatever was the most appropriate.) Con From daniel.odonnell at uleth.ca Mon Apr 2 19:46:51 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 02 Apr 2007 17:46:51 -0600 Subject: [tei-council] rules about renaming In-Reply-To: <1175556408.3766.104.camel@localhost> References: <4611857B.3060506@computing-services.oxford.ac.uk> <1175556408.3766.104.camel@localhost> Message-ID: <1175557611.9157.0.camel@localhost> Ooh I like this. Fits in with the i18n. On Tue, 2007-04-03 at 11:26 +1200, Conal Tuohy wrote: > On Mon, 2007-04-02 at 23:36 +0100, Lou Burnard wrote: > > If I want to rename a TEI element, I am obviously required not to use as > > the new name an existing name in the schema. Slightly less obviously, I > > cannot use as the new name any name from any module I might want to > > include in some other schema for the same document. > > > > I cannot, for example, rename

as if I am already using or plan > > to use . > > > > But what about names which happen to look the same in different languages? > > > > For example, suppose the French for "p" were "q"... would the presence > > of the xml:lang attribute here be enough to make the following valid: > > > > > > q > > > > > > and if not, does this mean that all identifiers share the same name space? > > > > I rayther suspect they have to.... > > I think you're right. > > In my earlier response to the conformance draft I suggested that the > localised TEI schemas should have their own namespace URIs, too, > because, as you point out, sharing a common namespace across all natural > languages is, on the face of it, running a risk that names will collide. > > My suggestion to mitigate this risk was that we publish distinct > namespace URIs for each language into which the TEI vocabulary is > translated, in addition to the existing one for the standard > English TEI: > > http://www.tei-c.org/ns/1.0 > > I suggest that the namespace URI for every localised version should have > the same base URI as above, but also include a fragment identifier to > point to part of the page. So, for instance, the hypothetical French > TEI, in which means

, might have this namespace URI: > > http://www.tei-c.org/ns/1.0#fr > > If we did this we also ought to modify the HTML page at > http://www.tei-c.org/ns/1.0 to include an element with an id of "fr", > perhaps like so: > > > >

This document describes the namespaces of the Text Encoding > Initiative (TEI).

>

The namespace whose URI is "http://www.tei-c.org/P5/" identifies the > primary TEI vocabulary described in the href="http://www.tei-c.org/release/doc/tei-p5-doc/html/">TEI > Guidelines.

> >

Localised versions

>

The primary TEI vocabulary is largely based on English, but it has > also been localised into other languages. Encoders who are more fluent > in one of these languages may wish to use one of these alternative > vocabularies.

>
    >
  • fran?aise
    • > >
> > > > These list items should, where possible, contain pointers to information > about the localised versions (e.g. to the relevant guidelines document, > ODDs, or whatever was the most appropriate.) > > Con > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From conal.tuohy at vuw.ac.nz Mon Apr 2 19:49:34 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 03 Apr 2007 11:49:34 +1200 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <461183F0.1070609@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> Message-ID: <1175557774.3766.127.camel@localhost> On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote: > I would strongly suggest that people use something > based on their project URL if they have one. I agree. The W3's architecture document "Architecture of the World Wide Web" includes some relevant guidelines, including this one about "namespace documents": http://www.w3.org/TR/webarch/#namespace-document > Good practice: Namespace documents > > The owner of an XML namespace name SHOULD make available material > intended for people to read and material optimized for software agents > in order to meet the needs of those who will use the namespace > vocabulary. Here "an XML namespace name" means the namespace URI itself, and "namespace document" means a document you can retrieve from that URI. The TEI namespace URI, for instance, identifies a document on the TEI website which says that it's the TEI namespace, published by the Council, that there's no plans for it to change, etc, and links to the TEI guidelines themselves. So I think if people are using ODD to make a custom schema in which they add new elements, it is good practice for them to publish information about those changes in a "namespace document". A good way is for their namespace URI to be an http URL pointing to a location where they will publish that information. e.g. If a project were to publish their ODD file on their website, that ODD file could itself be a good namespace document. But I think this W3 guideline implies we should not suggest an http URI which starts with "http://www.tei-c.org/ns/user-defined/" (or similar) because that might imply that we would be maintaining a register of customisations. The namespace URI should clearly belong to the person making the customisation, not to the TEI Consortium. However, if the project doesn't have a website, then it might prove a barrier to provide a "namespace document". During the development phase of a project, it might not be clear what namespace URI would be best, so a temporary URI might be needed. In such cases, rather than use an HTTP URI, they could use some other kind of URI, such as a "tag" URI, e.g. "tag:conal.tuohy at gmail.com,2007:xmlns/my-customisation" The syntax of a tag URI allows for people to mint one based on their own email address, so the barrier to use is low. Tag URI syntax: http://www.taguri.org/07/draft-kindberg-tag-uri-07.html#SYNTAX Cheers Con From Syd_Bauman at Brown.edu Mon Apr 2 23:08:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 2 Apr 2007 23:08:57 -0400 Subject: [tei-council] conformance draft In-Reply-To: <46117DA0.3070207@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> Message-ID: <17937.50505.542961.283268@emt.wwp.brown.edu> Apologies, I'm not entirely up-to-date on this thread, but ... > I was intentionally being hard-line dictatorial and stating that > TEI Conformance requires there to have been an ODD at some point to > generate the schema. I recall that Council expressed a pretty strong opinion on this at the 2005 meeting in Paris, although I don't know if it was an official vote or not. The overwhelming majority thought that ODD should be the only way to go. > I am now thinking that the sensible thing would be to simply axe > all the discussion of parameter entities etc. and simply say how to > do the job with an ODD. Do we agree? I don't think any discussion of parameter entities is warranted. *Maybe* instructions for stitching together a Relax NG schema. Maybe. > if we don't document the parameter entities, we might as well stop > producing them, no? and we might as well stop distributing the DTD > modules? Right. If you wanna use a DTD, the only one you get to use is either a) the one generated from your ODD via roma, or b) one you create from the Relax NG schema you stitched together, if we go that route. Furthermore, if you wanna use a DTD we should make it very clear and abundantly explicit that you are not getting a lot of the validation that you would get if you were using Relax NG. From wittern at kanji.zinbun.kyoto-u.ac.jp Mon Apr 2 21:53:28 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 03 Apr 2007 10:53:28 +0900 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.23322.362024.862804@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> Message-ID: <4611B398.3000107@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: >> Over the last week, Dan, Dot, Arianna, Conal, Sebastian and I have >> all expressed support for James's proposal that (inter alia) >> conformance in a TEI document implies that the TEI namespace >> remains unpolluted by user-defined elements. I would like to register my strong support for the pure namespace in its strict version, with different namespaces for translated vocabularies. > > I had thought that perhaps James (and someone else?) now believed > that namespace-purity be in the realm of the definition of "TEI > Interchange Format", rather than of "TEI Conformance". I certainly > do. To me, this would belong to TEI Conformance, not just interchange, but I am willing to sit on the fence until the interchange is a bit more panned out. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 03:05:25 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Tue, 03 Apr 2007 16:05:25 +0900 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: > Apologies, I'm not entirely up-to-date on this thread, but ... > >> I was intentionally being hard-line dictatorial and stating that >> TEI Conformance requires there to have been an ODD at some point to >> generate the schema. > > I recall that Council expressed a pretty strong opinion on this at > the 2005 meeting in Paris, although I don't know if it was an > official vote or not. The overwhelming majority thought that ODD > should be the only way to go. > At least for conformant documents, that was my impression as well. And I still think this is the way it should be. >> I am now thinking that the sensible thing would be to simply axe >> all the discussion of parameter entities etc. and simply say how to >> do the job with an ODD. Do we agree? > > I don't think any discussion of parameter entities is warranted. > *Maybe* instructions for stitching together a Relax NG schema. Maybe. > We should let go of both, IMHO. P5 is a radical break, part of the 21st century and the future, and DTD are soo 90s. > >> if we don't document the parameter entities, we might as well stop >> producing them, no? and we might as well stop distributing the DTD >> modules? > > Right. If you wanna use a DTD, the only one you get to use is either > a) the one generated from your ODD via roma, or > b) one you create from the Relax NG schema you stitched together, if > we go that route. I don't think (b) needs to be mentioned somewhere. If we do it right, most people (except Wendell) will not feel the need to hack the Schemas. > Furthermore, if you wanna use a DTD we should make it very clear and > abundantly explicit that you are not getting a lot of the validation > that you would get if you were using Relax NG. +1 Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:01:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:01:25 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17937.37030.473212.244366@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <17937.37030.473212.244366@emt.wwp.brown.edu> Message-ID: <461209D5.7010100@oucs.ox.ac.uk> Syd Bauman wrote: >> Gracious. My IP address from home changes every day (assigned by by >> ISP). >> > > Mine too. What difference does that make? Only reinforces the idea > that this is a silly default you might use for quick tests, but not a > good idea for you True Customization. > a default you would never use doesnt seem sensible. I might as well leave blank, and make that an error > >> More importantly, I need to store it somewhere.... >> > > I don't understand. Don't you need to store it no matter what it is? > yes, but i do already store the Name (the @ident of the ) > > >> I don't want to overload the meaning of Prefix, as that is used for >> something else >> > > As is the filename. Which may be different than the ident= of > . Seems to me to be a good idea to use one of 'em for the > default. As you've pointed out, this is only a default, not a > suggestion. > but the prefix is empty by default...... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:20:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:20:58 +0100 Subject: [tei-council] rules about renaming In-Reply-To: <1175556408.3766.104.camel@localhost> References: <4611857B.3060506@computing-services.oxford.ac.uk> <1175556408.3766.104.camel@localhost> Message-ID: <46120E6A.5040106@oucs.ox.ac.uk> I see why a complete Frenchified TEI might have its own namespace. But I would point out that the mechanism used to Frenchify the TEI (ie ) is no different from that used to change

to for readability. By this argument, any use of would mean you should also change the namespace. what if you find most of the TEI OK, but change a few common tags to French names, to help your encoders? I am willing to be convinced, but I don't really see how this would all work in practice. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:27:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:27:39 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175557774.3766.127.camel@localhost> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> Message-ID: <46120FFB.8040909@oucs.ox.ac.uk> I am reluctant to force people to show an email address of any kind, though its a nice idea. I incline to making the box empty by default[1], but compulsory, with some guidelines on good choices. [1] and allowing for a way for them to create elements in the empty namespace... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:32:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:32:43 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <4612112B.1060807@oucs.ox.ac.uk> Syd Bauman wrote: > Right. If you wanna use a DTD, the only one you get to use is either > a) the one generated from your ODD via roma, or > b) one you create from the Relax NG schema you stitched together, if > we go that route. > pretty radical. no DTD modules to be created at all any more? I had the impression on TEI-L that the "DTD bad, schema good" war is not proceeding very well. I'd wager that at least 1/3 of the Council members use DTDs for their day to day work with the TEI.... > Furthermore, if you wanna use a DTD we should make it very clear and > abundantly explicit that you are not getting a lot of the validation > that you would get if you were using Relax NG. > that's a separate matter (though I agree) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 04:32:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 09:32:56 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17937.50505.542961.283268@emt.wwp.brown.edu> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> Message-ID: <46121138.9010801@oucs.ox.ac.uk> Syd Bauman wrote: > Right. If you wanna use a DTD, the only one you get to use is either > a) the one generated from your ODD via roma, or > b) one you create from the Relax NG schema you stitched together, if > we go that route. > pretty radical. no DTD modules to be created at all any more? I had the impression on TEI-L that the "DTD bad, schema good" war is not proceeding very well. I'd wager that at least 1/3 of the Council members use DTDs for their day to day work with the TEI... (including you, Syd?) > Furthermore, if you wanna use a DTD we should make it very clear and > abundantly explicit that you are not getting a lot of the validation > that you would get if you were using Relax NG. > that's a separate matter (though I agree) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:00:14 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:00:14 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121138.9010801@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <46121138.9010801@oucs.ox.ac.uk> Message-ID: <4612179E.50609@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Syd Bauman wrote: >> Right. If you wanna use a DTD, the only one you get to use is either >> a) the one generated from your ODD via roma, or >> b) one you create from the Relax NG schema you stitched together, if >> we go that route. >> > pretty radical. no DTD modules to be created at all any more? > > I had the impression on TEI-L that the "DTD bad, schema good" > war is not proceeding very well. > > I'd wager that at least 1/3 of the Council members > use DTDs for their day to day work with the TEI... > (including you, Syd?) I don't see that this matters? Surely these days those DTDs are generated from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't generated from Roma. Since Syd above in point a) says that DTDs generated from roma are OK, then I don't see this as part of the "DTD bad, Schema good" debate. People are still free to use DTDs, they just have to be generated from Roma. >> Furthermore, if you wanna use a DTD we should make it very clear and >> abundantly explicit that you are not getting a lot of the validation >> that you would get if you were using Relax NG. > that's a separate matter (though I agree) Agreed (though not in Conformance, but Modification section). -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:05:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:05:08 +0100 Subject: [tei-council] conformance draft In-Reply-To: <4612179E.50609@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <46121138.9010801@oucs.ox.ac.uk> <4612179E.50609@computing-services.oxford.ac.uk> Message-ID: <461218C4.5010509@oucs.ox.ac.uk> James Cummings wrote: > I don't see that this matters? Surely these days those DTDs are generated > from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't > generated from Roma. sorry, I mean "old-fashioned DTDs" there. well, turn this around. Someone pose the question on TEI-L "has anyone ever, at all, used the parameterized DTDs of TEI P5? can anyone imagine doing so?", and see if anyone squeaks. I'd post it myself, but am in pre-holiday purdah (off from tomorrow) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:07:48 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:07:48 +0100 Subject: [tei-council] conformance draft In-Reply-To: <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <46121964.5000004@computing-services.oxford.ac.uk> Christian Wittern wrote: > Syd Bauman wrote: >> Apologies, I'm not entirely up-to-date on this thread, but ... >> >>> I was intentionally being hard-line dictatorial and stating that >>> TEI Conformance requires there to have been an ODD at some point to >>> generate the schema. >> I recall that Council expressed a pretty strong opinion on this at >> the 2005 meeting in Paris, although I don't know if it was an >> official vote or not. The overwhelming majority thought that ODD >> should be the only way to go. > At least for conformant documents, that was my impression as well. And I > still think this is the way it should be. Good. Is anyone disagreeing that for Conformance there must have been, at some point, a TEI ODD? (i.e. even if the user is using a tei_lite schema, that was originally an ODD). >>> I am now thinking that the sensible thing would be to simply axe >>> all the discussion of parameter entities etc. and simply say how to >>> do the job with an ODD. Do we agree? >> I don't think any discussion of parameter entities is warranted. >> *Maybe* instructions for stitching together a Relax NG schema. Maybe. > We should let go of both, IMHO. P5 is a radical break, part of the 21st > century and the future, and DTD are soo 90s. I don't think we need instructions for stitching together a Relax NG schema, although there should be discussion of Relax in the Modification section. > I don't think (b) needs to be mentioned somewhere. If we do it right, > most people (except Wendell) will not feel the need to hack the Schemas. Yes, there are some people who will always do such things, but they know enough to recognise that they are 'going off the reservation'. With other guidelines/standards, if you took one part of it and ignored how it was meant to be done and did it an entirely different way, you'd recognise that you might not have support, interoperability, or 'certification' or whatnot. ODD is the way this is meant to be done, so I don't think we should be shy about stating it. >> Furthermore, if you wanna use a DTD we should make it very clear and >> abundantly explicit that you are not getting a lot of the validation >> that you would get if you were using Relax NG. > +1 Me Too -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:11:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:11:35 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121964.5000004@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> Message-ID: <46121A47.2000502@oucs.ox.ac.uk> James Cummings wrote: > Good. Is anyone disagreeing that for Conformance there must have been, at > some point, a TEI ODD? (i.e. even if the user is using a tei_lite schema, > that was originally an ODD). > Well, yes, I am not that happy about it. Just call me Wendell. Seems like painting ourselves into a corner, to throw away the chance of customing it with RELAXNG fragments. > > With other > guidelines/standards, if you took one part of it and ignored how it was > meant to be done and did it an entirely different way, you'd recognise that > you might not have support, interoperability, or 'certification' or > whatnot. note that you don't use the word "conformance" there. I won't go to the stake on this, though. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:16:04 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:16:04 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175557774.3766.127.camel@localhost> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> Message-ID: <46121B54.7030500@computing-services.oxford.ac.uk> Conal Tuohy wrote: > On Mon, 2007-04-02 at 23:30 +0100, Sebastian Rahtz wrote: >> I would strongly suggest that people use something >> based on their project URL if they have one. > I agree. I don't think anyone is disagreeing that this is desirable, if they have a project URL. > But I think this W3 guideline implies we should not suggest an http URI > which starts with "http://www.tei-c.org/ns/user-defined/" (or similar) > because that might imply that we would be maintaining a register of > customisations. The namespace URI should clearly belong to the person > making the customisation, not to the TEI Consortium. I think this is enough to convince me that having user-defined NS at tei-c.org is not a good idea. I think that: 1) the Roma web-form input for the namespace should defaultly be blank (unless the ODD has already got a namespace), 2) that ODD needs somewhere agreed upon to store this namespace, 3) that there should be help text next to the box stating something like: "Required: Add your project namespace here for any new elements you create. We suggest that this is based on the URL for your project. Perhaps something like http://www.ProjectName.org/ns/1.0" > However, if the project doesn't have a website, then it might prove a > barrier to provide a "namespace document". During the development phase > of a project, it might not be clear what namespace URI would be best, so > a temporary URI might be needed. In such cases, rather than use an HTTP > URI, they could use some other kind of URI, such as a "tag" URI, e.g. > > "tag:conal.tuohy at gmail.com,2007:xmlns/my-customisation" I don't like this idea. Even if they don't have a website, they can create a temporary URI, it doesn't even have to point to a real site. (While not best practice, this is within the W3C recommendation I believe?) I feel the tag uri will just confuse them more. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:19:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:19:58 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121B54.7030500@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46121B54.7030500@computing-services.oxford.ac.uk> Message-ID: <46121C3E.7060100@oucs.ox.ac.uk> James Cummings wrote: > > 1) the Roma web-form input for the namespace should defaultly be blank > (unless the ODD has already got a namespace), > agreed > 2) that ODD needs somewhere agreed upon to store this namespace, > no, because you may use several namespaces in one ODD. dont ask me why, but it would not be illegal. I think you're making this over-complicated. Just say "You must supply a namespace for each element you add. Here is a pointer to guidelines on making namespaces. You cannot use the TEI namespace." -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:21:29 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:21:29 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121A47.2000502@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> Message-ID: <46121C99.9050805@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Well, yes, I am not that happy about it. Just call me Wendell. > Seems like painting ourselves into a corner, to throw > away the chance of customing it with RELAXNG fragments. Other than painting ourselves into a corner, can you explain to me why this is such a bad thing? Surely this customising can still be done with RELAXNG inside an ODD? >> With other >> guidelines/standards, if you took one part of it and ignored how it was >> meant to be done and did it an entirely different way, you'd recognise >> that >> you might not have support, interoperability, or 'certification' or >> whatnot. > note that you don't use the word "conformance" there. That's because most of the other standards I've looked at don't have a definition of conformance in the way we do. This is because, I believe, most other standards set out one way, and one way only, for you to do things. The idea of you adding to, expanding, renaming, and otherwise customising the standard are entirely foreign to most of them. TEI's liberality in allowing customisation is simultaneously its greatest strength and greatest barrier to mass-adoption. In most standards there seems to be a one-to-one relationship, "it validates against the schema and you've put the suggested information in the right place, then you are Conformant". i.e. they conflate conformance and validity. > I won't go to the stake on this, though. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:24:08 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:24:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121C3E.7060100@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46121B54.7030500@computing-services.oxford.ac.uk> <46121C3E.7060100@oucs.ox.ac.uk> Message-ID: <46121D38.3000306@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: >> 2) that ODD needs somewhere agreed upon to store this namespace, > no, because you may use several namespaces in one ODD. > dont ask me why, but it would not be illegal. Ok, when I feed my ODD back into Roma, how does it know the namespace(s) of the elements I added last time? > I think you're making this over-complicated. Just > say "You must supply a namespace for each element > you add. Here is a pointer to guidelines on making namespaces. > You cannot use the TEI namespace." I'd have no problem with that. But it would be good if Roma remembered this for the session at least and used as a default the namespace I used for the last 3 elements I added. That would satisfy me. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:30:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:30:39 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121C99.9050805@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> Message-ID: <46121EBF.6090004@oucs.ox.ac.uk> James Cummings wrote: > Other than painting ourselves into a corner, can you explain to me why this > is such a bad thing? Surely this customising can still be done with > RELAXNG inside an ODD? > Yes, but it is a pain. If all you want to do is have a RELAXNG wrapper schema which imports 4 or 5 TEI modules, you are forced to go through a klunky web service, or install amateurish software locally. It makes an unncessary bottleneck. > > TEI's > liberality in allowing customisation is simultaneously its greatest > strength and greatest barrier to mass-adoption. amen, bro... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 05:32:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 10:32:18 +0100 Subject: [tei-council]DTDs (was conformance draft) In-Reply-To: <4612179E.50609@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <46121138.9010801@oucs.ox.ac.uk> <4612179E.50609@computing-services.oxford.ac.uk> Message-ID: <46121F22.9080705@computing-services.oxford.ac.uk> We are not talking about dropping support for DTDs any time soon. We are talking about how much of the inner workings of the TEI DTDs should be exposed in P5. In P3 and preceding, DTD technology was moderately new as far as many of its users were concerned, and so the Guidelines go to great lengths to explain everything about how it works, exactly. There was no pizza chef, let alone Roma, so the only way of customizing the thing was to really grok those parameter entities. We have now introduced ODD which is widely regarded as a great step forward precisely because it conceals that machinery from the user and allows us to specify in the Guidelines how schemas should be constructed without going into details about how they should be instantiated as RelaxNG or DTD or whatever... sort of like we don't talk about the stylesheets needed to format TEI elements. However, I think there is justice in the Mulberry view that says we really ought not to require that everyone use our own ODD engine, and that no-one will ever be able to build another ODD engine if we don't document how such an engine is supposed to work somewhere. Note that I am not saying "we need a user manual for Roma" (we have one more or less); I am saying "we need a specification for how the various bits of ODD are actually used to generate Relaxng and DTD schemas" I am now coming round to the view that this should be a new section of chapter 28. I think the DTD part of it would be fairly easy to compile (l;argely from all the bits I've been hacking out of other parts of that chapter) but I will need help drafting the RelaxNG bits. Something for Sebastian to be thinking about on his boat? Lou James Cummings wrote: > Sebastian Rahtz wrote: > >> Syd Bauman wrote: >> >>> Right. If you wanna use a DTD, the only one you get to use is either >>> a) the one generated from your ODD via roma, or >>> b) one you create from the Relax NG schema you stitched together, if >>> we go that route. >>> >>> >> pretty radical. no DTD modules to be created at all any more? >> >> I had the impression on TEI-L that the "DTD bad, schema good" >> war is not proceeding very well. >> >> I'd wager that at least 1/3 of the Council members >> use DTDs for their day to day work with the TEI... >> (including you, Syd?) >> > > I don't see that this matters? Surely these days those DTDs are generated > from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't > generated from Roma. Since Syd above in point a) says that DTDs generated > from roma are OK, then I don't see this as part of the "DTD bad, Schema > good" debate. People are still free to use DTDs, they just have to be > generated from Roma. > > >>> Furthermore, if you wanna use a DTD we should make it very clear and >>> abundantly explicit that you are not getting a lot of the validation >>> that you would get if you were using Relax NG. >>> >> that's a separate matter (though I agree) >> > > Agreed (though not in Conformance, but Modification section). > > -James > > From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 05:32:28 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 10:32:28 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121D38.3000306@computing-services.oxford.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46121B54.7030500@computing-services.oxford.ac.uk> <46121C3E.7060100@oucs.ox.ac.uk> <46121D38.3000306@computing-services.oxford.ac.uk> Message-ID: <46121F2C.1040009@oucs.ox.ac.uk> James Cummings wrote: > > Ok, when I feed my ODD back into Roma, how does it know the namespace(s) of > the elements I added last time? > the @ns attribute on each , natch. > But it would be good if Roma remembered > this for the session at least and used as a default the namespace I used > for the last 3 elements I added. That would satisfy me. > thats a simple matter of programming, I think. no big problem. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:42:42 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:42:42 +0100 Subject: [tei-council] conformance draft In-Reply-To: <46121EBF.6090004@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> <46121EBF.6090004@oucs.ox.ac.uk> Message-ID: <46122192.2090901@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> Other than painting ourselves into a corner, can you explain to me why >> this >> is such a bad thing? Surely this customising can still be done with >> RELAXNG inside an ODD? >> > Yes, but it is a pain. If all you want to do is have a RELAXNG > wrapper schema which imports 4 or 5 TEI modules, you > are forced to go through a klunky web service, or install > amateurish software locally. It makes an unncessary bottleneck. Ok, but let's remember we're talking about Conformance here... there is no requirement for them to be Conformant, and if all they want to do is have a RELAXNG wrapper schema to do this, perhaps Conformance isn't something they are interested in? >> TEI's >> liberality in allowing customisation is simultaneously its greatest >> strength and greatest barrier to mass-adoption. > amen, bro... And hence why ODD will hopefully be useful in creating focussed micro-formats which will aid this. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Conal.Tuohy at vuw.ac.nz Tue Apr 3 05:43:13 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Tue, 3 Apr 2007 21:43:13 +1200 Subject: [tei-council] Conformance draft: namespace purity References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> Message-ID: yeah I don't think we should force people to use any particular namespace URI. If they want to leave it blank that's OK with me ... though what's the conformance status of a schema that includes names which are not in any namespace? Con -----Original Message----- From: Sebastian Rahtz [mailto:sebastian.rahtz at oucs.ox.ac.uk] Sent: Tue 03/04/07 20:27 To: Conal Tuohy Cc: TEI Council Subject: Re: [tei-council] Conformance draft: namespace purity I am reluctant to force people to show an email address of any kind, though its a nice idea. I incline to making the box empty by default[1], but compulsory, with some guidelines on good choices. [1] and allowing for a way for them to create elements in the empty namespace... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 05:46:08 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 10:46:08 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46121F2C.1040009@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46121B54.7030500@computing-services.oxford.ac.uk> <46121C3E.7060100@oucs.ox.ac.uk> <46121D38.3000306@computing-services.oxford.ac.uk> <46121F2C.1040009@oucs.ox.ac.uk> Message-ID: <46122260.3050302@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> >> Ok, when I feed my ODD back into Roma, how does it know the >> namespace(s) of >> the elements I added last time? >> > the @ns attribute on each , natch. Thus ODD has a place to store the namespace used. That is all I was requiring, and you tell me it can already do it. :-) Ok, on a per element basis could be confusing since if I have multiple namespaces and am adding a new one, Roma has no way to know which one I might want as the default. Wait until I add one then use the last added one I say. >> But it would be good if Roma remembered >> this for the session at least and used as a default the namespace I used >> for the last 3 elements I added. That would satisfy me. >> > thats a simple matter of programming, I think. > no big problem. Good, I'm happy then. -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 06:02:33 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 11:02:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> Message-ID: <46122639.6050601@oucs.ox.ac.uk> Conal Tuohy wrote: > yeah I don't think we should force people to use any particular namespace URI. > > If they want to leave it blank that's OK with me ... though what's the conformance status of a schema that includes names which are not in any namespace? > > Interesting question. Suppose my extension consists of adding some non-namespaced elements which just happen to have the same names as some existing TEI-namespaced elements. A namespace aware processor wont be confused but it sure as hell confuses me. Actually thinking about this further, is there any difference between this case and the case where I do have a namespace for my TEI-homonyms? And, if is not the same as is not the same as

, maybe we can say that by default extensions are not in any namespace? This seems such an obvious escape hatch I must have missed something. From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 06:13:12 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 11:13:12 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> Message-ID: <461228B8.5030503@computing-services.oxford.ac.uk> Conal Tuohy wrote: > If they want to leave it blank that's OK with me ... though what's the > conformance status of a schema that includes names which are not in any > namespace? According to 1.3.2, 'TEI Extension Schema': "All new elements and attributes, which are not renamings of current elements and attributes, must be added in a separate namespace." This implies to me that they should not be in a null namespace. Perhaps this should be stated more explicitly? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Tue Apr 3 08:19:41 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 13:19:41 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46120FFB.8040909@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> Message-ID: <4612465D.5030905@kcl.ac.uk> Sebastian Rahtz wrote: > I am reluctant to force people to show an email address > of any kind, though its a nice idea. > > I incline to making the box empty by default[1], > but compulsory, with some guidelines on good choices. > > [1] and allowing for a way for them to create > elements in the empty namespace... > I think this is the best solution. However, I am not sure whether you would need two fields instead: indeed, how would you retrieve the namespace prefix from the URI? Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Tue Apr 3 08:28:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 13:28:06 +0100 Subject: [tei-council]DTDs (was conformance draft) In-Reply-To: <46121F22.9080705@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <46121138.9010801@oucs.ox.ac.uk> <4612179E.50609@computing-services.oxford.ac.uk> <46121F22.9080705@computing-services.oxford.ac.uk> Message-ID: <46124856.3090002@kcl.ac.uk> Lou Burnard wrote: > Note that I > am not saying "we need a user manual for Roma" (we have one more or > less); I am saying "we need a specification for how the various bits of > ODD are actually used to generate Relaxng and DTD schemas" I agree with this. Arianna > > I am now coming round to the view that this should be a new section of > chapter 28. I think the DTD part of it would be fairly easy to compile > (l;argely from all the bits I've been hacking out of other parts of that > chapter) but I will need help drafting the RelaxNG bits. Something for > Sebastian to be thinking about on his boat? > > Lou > > > James Cummings wrote: >> Sebastian Rahtz wrote: >> >>> Syd Bauman wrote: >>> >>>> Right. If you wanna use a DTD, the only one you get to use is either >>>> a) the one generated from your ODD via roma, or >>>> b) one you create from the Relax NG schema you stitched together, if >>>> we go that route. >>>> >>> pretty radical. no DTD modules to be created at all any more? >>> >>> I had the impression on TEI-L that the "DTD bad, schema good" >>> war is not proceeding very well. >>> >>> I'd wager that at least 1/3 of the Council members >>> use DTDs for their day to day work with the TEI... >>> (including you, Syd?) >>> >> >> I don't see that this matters? Surely these days those DTDs are >> generated >> from ODD via Roma? I haven't used a DTD for absolutely ages which wasn't >> generated from Roma. Since Syd above in point a) says that DTDs >> generated >> from roma are OK, then I don't see this as part of the "DTD bad, Schema >> good" debate. People are still free to use DTDs, they just have to be >> generated from Roma. >> >> >>>> Furthermore, if you wanna use a DTD we should make it very clear and >>>> abundantly explicit that you are not getting a lot of the validation >>>> that you would get if you were using Relax NG. >>>> >>> that's a separate matter (though I agree) >>> >> >> Agreed (though not in Conformance, but Modification section). >> >> -James >> >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 08:31:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 13:31:38 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612465D.5030905@kcl.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> Message-ID: <4612492A.7090004@oucs.ox.ac.uk> Arianna Ciula wrote: > > I think this is the best solution. However, I am not sure whether you > would need two fields instead: indeed, how would you retrieve the > namespace prefix from the URI? namespace prefixes dont come into it. they are an artefact of the XML instance, not the schema -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Apr 3 09:53:06 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 09:53:06 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612492A.7090004@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> Message-ID: <17938.23618.968848.542046@emt.wwp.brown.edu> First, let me reiterate that I think we should permit conformant documents to add elements in the TEI namespace. But given that we are not going to permit that: I think that James' stipulation in the draft that new elements *must* be in a a non-TEI namespace might be a bit overstated -- perhaps we should *permit* null-namespace additions. BUT, it certainly shouldn't be the default. Remember that our target audience includes (lots of) folks who are decidedly not XML experts. Can you imagine the confusion of having to change Blue

My encoded text with the thing I am interested in encoding

into Blue My encoded text with the thing I am interested in encoding Just to add the one element a user needs for some process or other? How annoying. So annoying, BTW, that I think many, if not most, people wouldn't do it even if we did require it. From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 10:01:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 15:01:33 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <46125E3D.1040200@oucs.ox.ac.uk> Syd Bauman wrote: > that I think many, if not > most, people wouldn't do it even if we did require it. > of course, this applies to the whole discussion. people (including funders) may well turn around say "oh well, so we're not conformant. "..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 10:02:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 15:02:06 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <46125E5E.7030800@oucs.ox.ac.uk> PS > I think that James' stipulation in the draft that new elements > *must* be in a a non-TEI namespace might be a bit overstated -- > perhaps we should *permit* null-namespace additions. > I agree .. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Tue Apr 3 10:04:51 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 03 Apr 2007 15:04:51 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines Message-ID: <46125F03.8070702@kcl.ac.uk> I am not sure whom I should address for this: the link from each element description page e.g. http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to the TEI Guidelines (bottom of the page) doesn't seem to work: "No pipeline matched request: release/doc/tei-p5-doc/html/$" Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From James.Cummings at computing-services.oxford.ac.uk Tue Apr 3 10:11:49 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 03 Apr 2007 15:11:49 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E5E.7030800@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E5E.7030800@oucs.ox.ac.uk> Message-ID: <461260A5.8010806@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > PS >> I think that James' stipulation in the draft that new elements >> *must* be in a a non-TEI namespace might be a bit overstated -- >> perhaps we should *permit* null-namespace additions. > I agree .. Discussing this with Lou this afternoon he too seemed to be of the opinion that we should *permit* null-namespace additions as a Conformant TEI Extension schema. I believe the draft he will be working on this weekend will incorporate that. I agree that new elements cannot be in the TEI namespace, but am flexible on whether they need to be in any namespace. Certainly my draft was assuming that they would be, and I think this should be 'Recommended Practice', even if we don't make it a requirement for conformance. This only affects the TEI Extension and similar schemas. For example, a Renaming Customisation is still using the TEI namespace for its TEI-but-renamed elements. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 10:23:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 15:23:54 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] Message-ID: <4612637A.4040501@oucs.ox.ac.uk> Syd sayd: |BUT, it certainly shouldn't be the default. Remember that our target |audience includes (lots of) folks who are decidedly not XML experts. |Can you imagine the confusion of having to change | | | | Blue |

My encoded text with the thing I am | interested in encoding

| | Err, actually I think there is quite a lot less confusion in explaining that they need to turn that into something like this: Blue

My encoded text with the thing I am interested in encoding

 From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 10:25:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 15:25:57 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines In-Reply-To: <46125F03.8070702@kcl.ac.uk> References: <46125F03.8070702@kcl.ac.uk> Message-ID: <461263F5.3000503@oucs.ox.ac.uk> It's a bug in the stylesheets which should be addressed to the TEI's team of professional software developers, only he's going on holiday this afternoon... Arianna Ciula wrote: > I am not sure whom I should address for this: > the link from each element description page e.g. > http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to the > TEI Guidelines (bottom of the page) doesn't seem to work: > "No pipeline matched request: release/doc/tei-p5-doc/html/$" > > Arianna From lou.burnard at computing-services.oxford.ac.uk Tue Apr 3 11:00:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 03 Apr 2007 16:00:37 +0100 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] Message-ID: <46126C15.1080504@oucs.ox.ac.uk> I think this is worthy of note: http://www.w3.org/News/2007#item64 The specification is here: http://www.w3.org/TR/2007/REC-its-20070403/ Why is it worthy of note? well, partly because it's been keeping Sebastian busy for the last 18 months or so, but also because it shows that the TEI ODD language can actually be used to document other non-TEI standards. Congratulations! From daniel.odonnell at uleth.ca Tue Apr 3 11:59:47 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 09:59:47 -0600 Subject: [tei-council] rules about renaming In-Reply-To: <46120E6A.5040106@oucs.ox.ac.uk> References: <4611857B.3060506@computing-services.oxford.ac.uk> <1175556408.3766.104.camel@localhost> <46120E6A.5040106@oucs.ox.ac.uk> Message-ID: <1175615987.3483.11.camel@odonned-eng06> On Tue, 2007-03-04 at 09:20 +0100, Sebastian Rahtz wrote: > I see why a complete Frenchified TEI might have its own namespace. > But I would point out that the mechanism used to Frenchify the TEI > (ie ) is no different from that used to change

to > for readability. By this argument, any use of would mean you > should also change the namespace. > > what if you find most of the TEI OK, but change a few common tags to French > names, to help your encoders? > > I am willing to be convinced, but I don't really see how this would > all work in practice. But what about our hypothetical english

= language x ? If you change the tagnames to accommodate that, you might have something less than a complete internationalisation but something more than an innocuous change. But maybe it is a silly example: since q already exists in the TEI, somebody contemplating a partial change would almost certainly want a longer tagname: maybe or something so as not to conflict with p. I wonder what if we isolated the case of changes that conflict directly with english tei names (or extend an official i18n version) and proposed that in those cases you need a separate namespace to stay conformant. > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Tue Apr 3 12:02:15 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 10:02:15 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E3D.1040200@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E3D.1040200@oucs.ox.ac.uk> Message-ID: <1175616135.3483.13.camel@odonned-eng06> On Tue, 2007-03-04 at 15:01 +0100, Sebastian Rahtz wrote: > Syd Bauman wrote: > > that I think many, if not > > most, people wouldn't do it even if we did require it. > > > of course, this applies to the whole discussion. people > (including funders) may well turn around > say "oh well, so we're not conformant. "..... This is the kind of thing the board should be addressing: it is not a technical issue but a good practice and archiving issue. > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Tue Apr 3 12:53:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 12:53:11 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <46125E3D.1040200@oucs.ox.ac.uk> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E3D.1040200@oucs.ox.ac.uk> Message-ID: <17938.34423.359122.826819@emt.wwp.brown.edu> > of course, this applies to the whole discussion. people (including > funders) may well turn around say "oh well, so we're not > conformant. "..... Yes, they might; and I think it is incumbent upon us to try to make sure that the conformance bar is set low enough that most users *don't*. While I don't think the usefulness of the Guidelines is lost if no one is conformant, certainly the rules for conformance become useless in that case. :-) From Syd_Bauman at Brown.edu Tue Apr 3 13:00:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 13:00:29 -0400 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <4612637A.4040501@oucs.ox.ac.uk> References: <4612637A.4040501@oucs.ox.ac.uk> Message-ID: <17938.34861.379138.981406@emt.wwp.brown.edu> > Err, actually I think there is quite a lot less confusion in > explaining that they need to turn that into something like this: > > xmlns:mine="http://mynamespace.org"> > > > Blue >

My encoded text with the > thing I am > interested in encoding

> > If I understand you correctly, you are absolutely right, and have reiterated the point I was making. If by default Roma gives them a schema for Blue My encoded text with the thing I am interested in encoding (i.e., only new added elements in null namespace) when what they would have really wanted is that which you posted (new added elements in new non-null namespace), they're going to be confused or unhappy (or both). Therefore, I do not think Roma should use the null namespace as a default for newly added elements. From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 13:00:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 18:00:57 +0100 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.34423.359122.826819@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E3D.1040200@oucs.ox.ac.uk> <17938.34423.359122.826819@emt.wwp.brown.edu> Message-ID: <46128849.3070001@oucs.ox.ac.uk> Syd Bauman wrote: > Yes, they might; and I think it is incumbent upon us to try to make > sure that the conformance bar is set low enough that most users > *don't*. > but not so low that baby Maggie can waddle over it. it's hard to tell until we have watched the first 100 competitors try -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 13:04:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 18:04:41 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <17938.34861.379138.981406@emt.wwp.brown.edu> References: <4612637A.4040501@oucs.ox.ac.uk> <17938.34861.379138.981406@emt.wwp.brown.edu> Message-ID: <46128929.6060606@oucs.ox.ac.uk> Syd Bauman wrote: > Therefore, I do not think Roma should use the null > namespace as a default for newly added elements. > I think we all agree on this. I will make the field have a default of "-" (say), and make this illegal. They have to put in some text other than - or something which does not start with "http://www.tei-c.org/", or they can consciously empty it. people who really want to force it to add elemnets in the TEI namespace have to edit the ODD by hand. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Apr 3 13:13:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 13:13:14 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <1175616135.3483.13.camel@odonned-eng06> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E3D.1040200@oucs.ox.ac.uk> <1175616135.3483.13.camel@odonned-eng06> Message-ID: <17938.35626.998383.176354@emt.wwp.brown.edu> > This is the kind of thing the board should be addressing: it is not > a technical issue but a good practice and archiving issue. I'm not sure exactly what you're addressing, Daniel, but I think the issue at hand (how customizations, namespaces, conformance, and interchange format interact) is a technical issue, albeit one with some non-technical ramifications. While the Board may want to review Council's ideas and decisions about these issues and give some high-level guidance in setting the balance point between ease-of-use and best practices (like "it should be easier", or "the definitions should be more specific", or "it would be good if it could handle internationalization more smoothly"), seems to me the details are entirely up to the Council and the editors. That said, if the Board thinks a certain technical path is likely to have a negative impact on the TEI Consortium (which I am quite worried about), they should say so. Since we haven't left ourselves enough time, I don't think, to get a good feeling of how the general TEI community feels about these issues, perhaps getting the Board's thoughts is a good idea. From Syd_Bauman at Brown.edu Tue Apr 3 14:00:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 14:00:21 -0400 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <46128929.6060606@oucs.ox.ac.uk> References: <4612637A.4040501@oucs.ox.ac.uk> <17938.34861.379138.981406@emt.wwp.brown.edu> <46128929.6060606@oucs.ox.ac.uk> Message-ID: <17938.38453.187269.987187@emt.wwp.brown.edu> > I will make the field have a default of "-" (say), and make this > illegal. They have to put in some text other than - or something > which does not start with "http://www.tei-c.org/", or they can > consciously empty it. > > people who really want to force it to add elemnets in the TEI > namespace have to edit the ODD by hand. I think that (given the non-TEI namespace for new element requirement, which I think is a bad idea) this all makes sense, except that I still lean towards making the default be a valid (if useless) namespace URI. Makes it a lot easier to use Roma for quick testing, a use to which webRoma is often put, I think. I agree that a namespace URI in www.tei-c.org, even if it has "user-extension/" carries too much of an implication; I agree that putting an e-mail address inside the URI by default is a bad idea. But note that the "tag" scheme that Conal pointed us to does not require an e-mail address. It only requires a DNSname, and if I read the BNF right, a dotted-quad IP address qualifies as a DNSname. Thus tag:128.148.123.321,2007-04-03:P5customization/$name (where $name is whichever one of prefix, filename, schemaSpec/@ident that Sebastian finds easier to use) seems reasonable to me. From daniel.odonnell at uleth.ca Tue Apr 3 14:16:03 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 03 Apr 2007 12:16:03 -0600 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.35626.998383.176354@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <46125E3D.1040200@oucs.ox.ac.uk> <1175616135.3483.13.camel@odonned-eng06> <17938.35626.998383.176354@emt.wwp.brown.edu> Message-ID: <1175624163.16472.0.camel@odonned-eng06> On Tue, 2007-03-04 at 13:13 -0400, Syd Bauman wrote: > > This is the kind of thing the board should be addressing: it is not > > a technical issue but a good practice and archiving issue. > > I'm not sure exactly what you're addressing, Daniel, but I think the > issue at hand (how customizations, namespaces, conformance, and > interchange format interact) is a technical issue, albeit one with > some non-technical ramifications. While the Board may want to review > Council's ideas and decisions about these issues and give some > high-level guidance in setting the balance point between ease-of-use > and best practices (like "it should be easier", or "the definitions > should be more specific", or "it would be good if it could handle > internationalization more smoothly"), seems to me the details are > entirely up to the Council and the editors. > > That said, if the Board thinks a certain technical path is likely to > have a negative impact on the TEI Consortium (which I am quite > worried about), they should say so. Since we haven't left ourselves > enough time, I don't think, to get a good feeling of how the general > TEI community feels about these issues, perhaps getting the Board's > thoughts is a good idea. No I meant the "shrug" is a board issue: convincing funding agencies that it is nothing to shrug about is not directly technical, provided that the technical is good. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative Director, Digital Medievalist Project Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 14:20:23 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 19:20:23 +0100 Subject: [Fwd: Re: [tei-council] Conformance draft: namespace purity] In-Reply-To: <17938.38453.187269.987187@emt.wwp.brown.edu> References: <4612637A.4040501@oucs.ox.ac.uk> <17938.34861.379138.981406@emt.wwp.brown.edu> <46128929.6060606@oucs.ox.ac.uk> <17938.38453.187269.987187@emt.wwp.brown.edu> Message-ID: <46129AE7.7040008@oucs.ox.ac.uk> Syd Bauman wrote: > I think that (given the non-TEI namespace for new element > requirement, which I think is a bad idea) this all makes sense, > except that I still lean towards making the default be a valid (if > useless) namespace URI. Makes it a lot easier to use Roma for quick > testing, a use to which webRoma is often put, I think. > you may be right. anyway, I'll work on the stuff after Easter so that we can experiment. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Apr 3 15:07:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 15:07:18 -0400 Subject: [tei-council] conformance draft In-Reply-To: <46122192.2090901@computing-services.oxford.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> <46121EBF.6090004@oucs.ox.ac.uk> <46122192.2090901@computing-services.oxford.ac.uk> Message-ID: <17938.42470.585777.717173@emt.wwp.brown.edu> First of all, especially for those of you who were not at the 2004 meeting in Paris, it is mildly amusing to note that once again Sebastian & I have traded places ... in Paris I was the lone voice for permitting users to stitch together a Relax NG schema as they might not have an ODD processor handy. But now, I think James may have convinced me that even if the schema lends itself to such stitching, the definition of Conformance should be through ODD. > >> is such a bad thing? Surely this customising can still be done > >> with RELAXNG inside an ODD? This is not at all clear to me. We haven't developed any rules, guidelines, suggestions, hooks, or any such things for how this would be done, have we? Could someone hack a TEI Relax NG schema so that it made use of Relax NG features that ODD does not support? From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 15:22:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 20:22:04 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17938.42470.585777.717173@emt.wwp.brown.edu> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> <46121EBF.6090004@oucs.ox.ac.uk> <46122192.2090901@computing-services.oxford.ac.uk> <17938.42470.585777.717173@emt.wwp.brown.edu> Message-ID: <4612A95C.5070501@oucs.ox.ac.uk> Syd Bauman wrote: > First of all, especially for those of you who were not at the 2004 > meeting in Paris, it is mildly amusing to note that once again > Sebastian & I have traded places ... in Paris I was the lone voice > for permitting users to stitch together a Relax NG schema as they > might not have an ODD processor handy. do you mean 2005? if so, I was not there. but no matter. > This is not at all clear to me. We haven't developed any rules, > guidelines, suggestions, hooks, or any such things for how this would > be done, have we? Could someone hack a TEI Relax NG schema so that it > made use of Relax NG features that ODD does not support? > > certainly, in a content model, you could make a local element declaration, for instance. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 15:53:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 20:53:58 +0100 Subject: [tei-council] HTML guidelines: link from ref to glines In-Reply-To: <46125F03.8070702@kcl.ac.uk> References: <46125F03.8070702@kcl.ac.uk> Message-ID: <4612B0D6.2000707@oucs.ox.ac.uk> Arianna Ciula wrote: > I am not sure whom I should address for this: > the link from each element description page e.g. > http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-byline.html to > the TEI Guidelines (bottom of the page) doesn't seem to work: > "No pipeline matched request: release/doc/tei-p5-doc/html/$" fixed, updates going onto web site now. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Tue Apr 3 16:18:34 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 16:18:34 -0400 Subject: [tei-council] conformance draft In-Reply-To: <4612A95C.5070501@oucs.ox.ac.uk> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> <46121EBF.6090004@oucs.ox.ac.uk> <46122192.2090901@computing-services.oxford.ac.uk> <17938.42470.585777.717173@emt.wwp.brown.edu> <4612A95C.5070501@oucs.ox.ac.uk> Message-ID: <17938.46746.545430.36475@emt.wwp.brown.edu> > do you mean 2005? if so, I was not there. but no matter. Yes, that was a boo-boo, sorry. 2004 was in Ghent, 2005 in Paris. > > This is not at all clear to me. We haven't developed any rules, > > guidelines, suggestions, hooks, or any such things for how this > > would be done, have we? Could someone hack a TEI Relax NG schema > > so that it made use of Relax NG features that ODD does not > > support? > certainly, in a content model, you could make a local element > declaration, for instance. Hmmm ... you mean in an ODD, or directly? Either way, that gives me the capability to declare the element differently when it is inside a , right? One of Relax NG's greatest powers is co-occurrence constraints. For example, declaring that must have character content or a key= attribute, but not both[1]; or declaring the content of
differently iff the type= is "USA"[2]. I do not think we can do these things via ODD, nor do I have confidence that we can (or even should bother) coming up with a good mechanism for doing so by manipulating the Relax NG schemas somehow. I'm inclined to just say "yup, there are things Relax NG can do that TEI cannot; you can certainly use non-TEI conformant Relax NG schemas in addition to your normal Roma-generated Relax NG schema -- but why not use Schematron embedded in your ODD? Here is a sample of how to do that ...". Notes ----- [1] element name { attribute key { data.key } | xsd:token { pattern = ".+" } } [2] address = addressOther | addressUSA addressUSA = element address { attribute type { xsd:token "USA" }, name, street, city, state, postCode } addressOther = element address { attribute type { xsd:token - "USA" }, addrLine+ } From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 3 16:30:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 03 Apr 2007 21:30:11 +0100 Subject: [tei-council] conformance draft In-Reply-To: <17938.46746.545430.36475@emt.wwp.brown.edu> References: <4603E752.5010806@oucs.ox.ac.uk> <4603ECF7.5060608@computing-services.oxford.ac.uk> <460428B3.6050304@oucs.ox.ac.uk> <46116ADC.2020106@computing-services.oxford.ac.uk> <46116F04.8030100@computing-services.oxford.ac.uk> <46117A84.8010704@computing-services.oxford.ac.uk> <46117DA0.3070207@oucs.ox.ac.uk> <17937.50505.542961.283268@emt.wwp.brown.edu> <4611FCB5.3040007@kanji.zinbun.kyoto-u.ac.jp> <46121964.5000004@computing-services.oxford.ac.uk> <46121A47.2000502@oucs.ox.ac.uk> <46121C99.9050805@computing-services.oxford.ac.uk> <46121EBF.6090004@oucs.ox.ac.uk> <46122192.2090901@computing-services.oxford.ac.uk> <17938.42470.585777.717173@emt.wwp.brown.edu> <4612A95C.5070501@oucs.ox.ac.uk> <17938.46746.545430.36475@emt.wwp.brown.edu> Message-ID: <4612B953.1090607@oucs.ox.ac.uk> Syd Bauman wrote: > Hmmm ... you mean in an ODD, or directly? Either way, that gives me > the capability to declare the element differently when it is > inside a , right? > yes, I think so. I havent tried it yet > ings via ODD, nor do I have confidence that we can (or even should > bother) coming up with a good mechanism for doing so by manipulating > the Relax NG schemas somehow. I'm inclined to just say "yup, there > are things Relax NG can do that TEI cannot; yo and I would say "one of the reasons is that we still want to be able to produce DTDs, so we use a subset of what RELAXNG can offer" -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 21:18:38 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 04 Apr 2007 10:18:38 +0900 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] In-Reply-To: <46126C15.1080504@oucs.ox.ac.uk> References: <46126C15.1080504@oucs.ox.ac.uk> Message-ID: <4612FCEE.5040903@kanji.zinbun.kyoto-u.ac.jp> Lou Burnard wrote: > The specification is here: > http://www.w3.org/TR/2007/REC-its-20070403/ > This is great news indeed. The ODD is even mentioned in the spec with some favourable words. Good PR for TEI-C I'd say. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From wittern at kanji.zinbun.kyoto-u.ac.jp Tue Apr 3 20:58:37 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Wed, 04 Apr 2007 09:58:37 +0900 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <17938.23618.968848.542046@emt.wwp.brown.edu> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> Message-ID: <4612F83D.70209@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: > > I think that James' stipulation in the draft that new elements > *must* be in a a non-TEI namespace might be a bit overstated -- > perhaps we should *permit* null-namespace additions. This seems like splitting hairs, but since the null-namespace is certainly not a TEI namespace, I would think this is licensed by the current draft. > BUT, it certainly shouldn't be the default. Remember that our target > audience includes (lots of) folks who are decidedly not XML experts. > Can you imagine the confusion of having to change > > > > Blue >

My encoded text with the thing I am > interested in encoding

> > > > into > > > > Blue > My encoded text with the thing I am > interested in encoding > > This is not what you will do. You will add a xmlns="http://www.tei-c.org/ns/1.0" to the TEI element above and then get the following: Blue

My encoded text with the thing I am interested in encoding

 This is if we allow a null namespace, which seems reasonable to me, otherwise you will get the thing which seems nice to me as well. The downside of this of course is that it will need to jump some through some hoops in DTD land where you have to emulate namespaces with prefixes and or #FIXED attributes. > > Just to add the one element a user needs for some process or > other? How annoying. So annoying, BTW, that I think many, if not > most, people wouldn't do it even if we did require it. The annoying part starts only if you want to process this, but even there you could argue it is entirely reasonable to have to deal with your own stuff yourself and this namespace business helps you separate your stuff from their stuff. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Tue Apr 3 22:05:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 3 Apr 2007 22:05:41 -0400 Subject: [tei-council] Conformance draft: namespace purity In-Reply-To: <4612F83D.70209@kanji.zinbun.kyoto-u.ac.jp> References: <46114AAE.1030100@computing-services.oxford.ac.uk> <17937.23322.362024.862804@emt.wwp.brown.edu> <46116044.2040709@computing-services.oxford.ac.uk> <46116615.3080101@oucs.ox.ac.uk> <4611681E.3040604@computing-services.oxford.ac.uk> <461169A6.9080707@oucs.ox.ac.uk> <17937.27962.620536.39642@emt.wwp.brown.edu> <46117A22.3050701@oucs.ox.ac.uk> <46117AE2.1060804@computing-services.oxford.ac.uk> <1175552710.6077.5.camel@localhost> <461183F0.1070609@oucs.ox.ac.uk> <1175557774.3766.127.camel@localhost> <46120FFB.8040909@oucs.ox.ac.uk> <4612465D.5030905@kcl.ac.uk> <4612492A.7090004@oucs.ox.ac.uk> <17938.23618.968848.542046@emt.wwp.brown.edu> <4612F83D.70209@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17939.2037.11157.614358@emt.wwp.brown.edu> Good morning, Christian! > > I think that James' stipulation in the draft that new elements > > *must* be in a a non-TEI namespace might be a bit overstated -- > > perhaps we should *permit* null-namespace additions. > > This seems like splitting hairs, but since the null-namespace is > certainly not a TEI namespace, I would think this is licensed by > the current draft. I had thought that an element w/o a namespace declaration in force is not really in a namespace at all, rather than being in the null namespace (which we were using as shorthand notation for this condition). > This is not what you will do. You will add a > xmlns="http://www.tei-c.org/ns/1.0" to the TEI element above and > then get the following: > > > Blue >

My encoded text with the thing I am > interested in encoding

> > I had forgotten about the possibility of xmlns="" -- it is the same as no namespace, right? > The downside of this of course is that it will need to jump some > through some hoops in DTD land where you have to emulate namespaces > with prefixes and or #FIXED attributes. I'm not sure if I want to use that as an argument against requiring added elements be in a different namespace, or against supporting DTDs! :-) > The annoying part starts only if you want to process this, I think it's pretty annoying to edit & proofread, too. > ... but even there you could argue it is entirely reasonable to > have to deal with your own stuff yourself and this namespace > business helps you separate your stuff from their stuff. Absolutely. But my major point is that you are going to have to deal with not only your own stuff, but TEI stuff anyway. It's not like it's really possible to have out-of-the-box TEI software to process your TEI documents. Besides, if such a beast existed, it would likely choke as soon as I use a customization that is not a restriction, but since it isn't a new element, doesn't change the namespace. (E.g., if I were to change a content model to permit an element that isn't available in vanilla.) G'night! From James.Cummings at computing-services.oxford.ac.uk Wed Apr 4 05:27:34 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 04 Apr 2007 10:27:34 +0100 Subject: [tei-council] [Fwd: [oucs-d] W3C ITS Recommendation published, hurrah!] In-Reply-To: <4612FCEE.5040903@kanji.zinbun.kyoto-u.ac.jp> References: <46126C15.1080504@oucs.ox.ac.uk> <4612FCEE.5040903@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <46136F86.1070404@computing-services.oxford.ac.uk> Christian Wittern wrote: > Lou Burnard wrote: >> The specification is here: >> http://www.w3.org/TR/2007/REC-its-20070403/ >> > > This is great news indeed. The ODD is even mentioned in the spec with > some favourable words. Good PR for TEI-C I'd say. Yes, great PR for TEI-C I'd say...so why hasn't someone from the board or directly involved posted it to TEI-L to reassure our community how wonderful we are? Or did they and I miss it? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Wed Apr 4 06:53:58 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 04 Apr 2007 11:53:58 +0100 Subject: [tei-council] Conformance .... the continuing saga Message-ID: <461383C6.6000003@oucs.ox.ac.uk> Sebastian's now gone on holiday, but that hasn't stopped James and me from continuing to argue about conformance! How do other Council Members feel about this? LB >>> You're making the same mistake I was: conflating "support for DTDs" and >>> "support for parameterized DTDs". We certainly have to go on supporting >>> DTDs, but the record isn't clear as to whether we agreed to pull the rug >>> out from under "parameterized DTDs". As in the SG chapter, we have to >>> decide whether to remove that facility or complement it with some >>> discussion of the RelaxNG alternative way. JC >> If Parameterised DTDs are only being used for things which are now >> done in >> ODD, then, cognate with not allowing people to just stitch together >> RelaxNG >> schemas and be conformant, I don't think we necessarily should be >> supporting/mentioning/recommending parameterised DTDs. I'm willing to be >> convinced that we should, but I don't understand the argument for >> continuing in support of them. LB > We need a more open discussion about ways of customizing the TEI. > Parameterised DTD fragments, knitting together RelaxNG fragments, and > using ODD are three varyingly plausible ways of achieving the same goal. > We are near to a consensus on which is regarded as "TEI conformant" (the > last); but we haven't begun the debate as to whether or not we support > the other two as well. Should we actively support non-Conformant methods of doing things, or simply have a short notice that there are other ways to do it with some descriptions? > The simplest argument in favour is > > (a) we are currently generating and distributing them Not a good enough reason to keep doing so > (b) we haven't told anyone we intend to stop doing so Political, but again, P5 is such a big change > (c) people e.g. wendell might want to use them Those who don't care about Conformance? And nothing to stop them using that locally, but producing versions that do the same thing in an ODD. > (d) it's (probably) less work to add some stuff about relaxng than to > completely remove all the stuff about DTDs I can't really judge that. > Maybe we should move this discussion to the council list? Yes, certainly. :-) From Syd_Bauman at Brown.edu Wed Apr 4 08:56:56 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Apr 2007 08:56:56 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <461383C6.6000003@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> Message-ID: <17939.41112.690281.365239@emt.wwp.brown.edu> > Should we actively support non-Conformant methods of doing things, > or simply have a short notice that there are other ways to do it > with some descriptions? I think this is analogous to use of start= of . If you specify , you end up with a schema that will only mark as valid documents that are definitionally non-conformant (because they have no header). The system supports doing so, because it is often a *really* big help when making test files, etc. But it isn't part of a TEI Conformant system. Similarly, you can stitch together a schema from Relax NG fragments when it is more convenient to do so (you're experimenting, you're on an airplane w/o access to Roma, etc.). But the result is non-conformant, and we shouldn't spend a lot of effort (if any) describing how to do this. > > (a) we are currently generating and distributing them > Not a good enough reason to keep doing so Agreed. IMHO distributing parametrized DTD fragments is not only a waste of Sebastian's time (although he points out not much), it is potentially confusing to a DTD user who hasn't read the Guidelines carefully, but remembers extending P4! > > (b) we haven't told anyone we intend to stop doing so > Political, but again, P5 is such a big change No problem. We'll tell 'em now. (Or at release 0.7.) > > (c) people e.g. wendell might want to use them > Those who don't care about Conformance? And nothing to stop them > using that locally, but producing versions that do the same thing > in an ODD. Wendell will want to stitch together Relax NG, sure, but who wants to use parametrized DTDs? Remember, doing so is going to give you all sorts of namespace headaches. > > (d) it's (probably) less work to add some stuff about relaxng than to > > completely remove all the stuff about DTDs > I can't really judge that. Whether we add Relax NG info or not, we should remove stuff about using parametrized DTDs. It's a bad idea. Perhaps a discussion of how to stitch together TEI Relax NG schema fragments should be the subject of a white paper, and not in the Guidelines? From James.Cummings at computing-services.oxford.ac.uk Wed Apr 4 09:07:23 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 04 Apr 2007 14:07:23 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17939.41112.690281.365239@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> Message-ID: <4613A30B.9060607@computing-services.oxford.ac.uk> Syd Bauman wrote: >> Should we actively support non-Conformant methods of doing things, >> or simply have a short notice that there are other ways to do it >> with some descriptions? > > I think this is analogous to use of start= of . If you > specify , you end up with a schema that will > only mark as valid documents that are definitionally non-conformant > (because they have no header). The system supports doing so, because > it is often a *really* big help when making test files, etc. But it > isn't part of a TEI Conformant system. Similarly, you can stitch > together a schema from Relax NG fragments when it is more convenient > to do so (you're experimenting, you're on an airplane w/o access to > Roma, etc.). But the result is non-conformant, and we shouldn't spend > a lot of effort (if any) describing how to do this. Exactly my thinking. We should maybe describe that it can be done and might be useful in those circumstances, but I wouldn't suggest more than that. >>> (a) we are currently generating and distributing them >> Not a good enough reason to keep doing so > > Agreed. IMHO distributing parametrized DTD fragments is not only a > waste of Sebastian's time (although he points out not much), it is > potentially confusing to a DTD user who hasn't read the Guidelines > carefully, but remembers extending P4! Exactly. >>> (b) we haven't told anyone we intend to stop doing so >> Political, but again, P5 is such a big change > No problem. We'll tell 'em now. (Or at release 0.7.) Yup, along with the not-adding-elements to the TEI namespace thing. ;-) >>> (c) people e.g. wendell might want to use them >> Those who don't care about Conformance? And nothing to stop them >> using that locally, but producing versions that do the same thing >> in an ODD. > Wendell will want to stitch together Relax NG, sure, but who wants to > use parametrized DTDs? Remember, doing so is going to give you all > sorts of namespace headaches. I certainly won't -- what are some use cases for doing so assuming one can use ODD to do the same thing? > Whether we add Relax NG info or not, we should remove stuff about > using parametrized DTDs. It's a bad idea. If we aren't supporting it then I say remove it (except maybe a note about the change and how it used to be done). > Perhaps a discussion of how to stitch together TEI Relax NG schema > fragments should be the subject of a white paper, and not in the > Guidelines? Isn't this what the now-conference-like bit of the TEIMM is for? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Wed Apr 4 12:15:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 4 Apr 2007 12:15:18 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613A30B.9060607@computing-services.oxford.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> Message-ID: <17939.53014.822219.184813@emt.wwp.brown.edu> > Yup, along with the not-adding-elements to the TEI namespace thing. > ;-) Which, I am worried, will not go over very well. I could be wrong, but I don't think many TEI users will balk at the idea of not being able to use DTD parametrization for customization, especially once they've been introduced to ODD and realize that they couldn't just port their P4 extensions over easily, anyway. But I worry that a lot of people will be put off by the namespace purity. > I certainly won't -- what are some use cases for doing so assuming > one can use ODD to do the same thing? I haven't come up with one, because you can't just port your P4 customization files, and because you smack into namespace headaches. BTW, I was using Wendell as a generic example of a marvelously maverick Relax NG expert -- I don't pretend to actually know what Wendell will and won't do. > If we aren't supporting it then I say remove it (except maybe a > note about the change and how it used to be done). Maybe. I'm not too fond of "how it used to be done" descriptions, myself. > > Perhaps a discussion of how to stitch together TEI Relax NG > > schema fragments should be the subject of a white paper, and not > > in the Guidelines? > Isn't this what the now-conference-like bit of the TEIMM is for? Hmmm.... while presenting this kind of information at the MM is a good idea, I was thinking of a paper something like a HOWTO but with more discussion of the issues, published by TEI-C, available from the TEI-C website. From lou.burnard at computing-services.oxford.ac.uk Wed Apr 4 13:36:39 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 04 Apr 2007 18:36:39 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17939.53014.822219.184813@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> Message-ID: <4613E227.2090909@oucs.ox.ac.uk> Does no-one else on the Council have a view on this issue? Or is everyone already on holiday? Personally, I am reluctant to remove parametrisable schemas without a bit more consultation. I have no problem with saying that true TEI conformance necessitates production of an ODD. But I still feel we have an obligation to make it feasible for people to customize the system without using tools that only we provide. Which means that we need to continue to provide customizable fragments, and describe how they can be used. We *want* people to use TEI P5 at whatever level they feel comfortable, right? For people still in DTDworld, the old method of stitching together DTD fragments is just fine, and they can go on doing it without having to learn any of this newfangled namespace stuff. People who, by contrast, are hip to the RelaxNG groove will want to know how to plug TEI stuff into their production line without having to completely revise the whole shooting match. So my preferred course of action would be: 1. Revise MD to make explicit that there is more than one way of building a schema from the TEI Guidelines. In fact there are three: (a) write an ODD and process it with a conformant ODD processor (b) write a DTD subset using parameter entities and ting and ting (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib 2. Of these ways, only (a) is guaranteed to result in a schema which can be used to validate TEI conformance for your documents, but the others may be helpful for local use. So we provide suggested ways of doing them, in two distinct subsections of the document. 3. We need, urgently, a definition of what exactly a "conformant ODD processor" is supposed to do. This might include a description of what the current ODD processor does, but that is less important. If, on consultation, it is apparent that no-one cares about (2) above, we can always throw away the lovingly-crafted prose I expect to be generating this weekend, or put it somewhere else... but I think we must have the consultation. From daniel.odonnell at uleth.ca Wed Apr 4 22:36:40 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 04 Apr 2007 20:36:40 -0600 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613E227.2090909@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> Message-ID: <1175740600.5448.4.camel@localhost> I like your proposal and the reasons. On Wed, 2007-04-04 at 18:36 +0100, Lou Burnard wrote: > Does no-one else on the Council have a view on this issue? Or is > everyone already on holiday? > > Personally, I am reluctant to remove parametrisable schemas without a > bit more consultation. I have no problem with saying that true TEI > conformance necessitates production of an ODD. But I still feel we have > an obligation to make it feasible for people to customize the system > without using tools that only we provide. Which means that we need to > continue to provide customizable fragments, and describe how they can be > used. We *want* people to use TEI P5 at whatever level they feel > comfortable, right? For people still in DTDworld, the old method of > stitching together DTD fragments is just fine, and they can go on doing > it without having to learn any of this newfangled namespace stuff. > People who, by contrast, are hip to the RelaxNG groove will want to know > how to plug TEI stuff into their production line without having to > completely revise the whole shooting match. So my preferred course of > action would be: > > 1. Revise MD to make explicit that there is more than one way of > building a schema from the TEI Guidelines. In fact there are three: > (a) write an ODD and process it with a conformant ODD processor > (b) write a DTD subset using parameter entities and ting and ting > (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib > > 2. Of these ways, only (a) is guaranteed to result in a schema which can > be used to validate TEI conformance for your documents, but the others > may be helpful for local use. So we provide suggested ways of doing > them, in two distinct subsections of the document. > > 3. We need, urgently, a definition of what exactly a "conformant ODD > processor" is supposed to do. This might include a description of what > the current ODD processor does, but that is less important. > > If, on consultation, it is apparent that no-one cares about (2) above, > we can always throw away the lovingly-crafted prose I expect to be > generating this weekend, or put it somewhere else... but I think we must > have the consultation. > > > > > > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From arianna.ciula at kcl.ac.uk Thu Apr 5 05:08:22 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 05 Apr 2007 10:08:22 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4613E227.2090909@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> Message-ID: <4614BC86.3000203@kcl.ac.uk> > 1. Revise MD to make explicit that there is more than one way of > building a schema from the TEI Guidelines. In fact there are three: > (a) write an ODD and process it with a conformant ODD processor > (b) write a DTD subset using parameter entities and ting and ting > (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib I support this proposal; it would make clear the evolution from P4 and precedent versions to P5 without simply throwing away the old methods, but giving them a context (even if marginal compared to schemas which can be used to validate TEI conformance --> so I agree with 2 as well). If we will go for it, we need to be sure other chapters (e.g. SG) are consistent with it of course. It would be useful to have 3 (LB:"a description of what the current ODD processor does") somewhere in the guidelines (may be in one of the appendixes?). Arianna Lou Burnard wrote: > Does no-one else on the Council have a view on this issue? Or is > everyone already on holiday? > > Personally, I am reluctant to remove parametrisable schemas without a > bit more consultation. I have no problem with saying that true TEI > conformance necessitates production of an ODD. But I still feel we have > an obligation to make it feasible for people to customize the system > without using tools that only we provide. Which means that we need to > continue to provide customizable fragments, and describe how they can be > used. We *want* people to use TEI P5 at whatever level they feel > comfortable, right? For people still in DTDworld, the old method of > stitching together DTD fragments is just fine, and they can go on doing > it without having to learn any of this newfangled namespace stuff. > People who, by contrast, are hip to the RelaxNG groove will want to know > how to plug TEI stuff into their production line without having to > completely revise the whole shooting match. So my preferred course of > action would be: > > 1. Revise MD to make explicit that there is more than one way of > building a schema from the TEI Guidelines. In fact there are three: > (a) write an ODD and process it with a conformant ODD processor > (b) write a DTD subset using parameter entities and ting and ting > (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib > > 2. Of these ways, only (a) is guaranteed to result in a schema which can > be used to validate TEI conformance for your documents, but the others > may be helpful for local use. So we provide suggested ways of doing > them, in two distinct subsections of the document. > > 3. We need, urgently, a definition of what exactly a "conformant ODD > processor" is supposed to do. This might include a description of what > the current ODD processor does, but that is less important. > > If, on consultation, it is apparent that no-one cares about (2) above, > we can always throw away the lovingly-crafted prose I expect to be > generating this weekend, or put it somewhere else... but I think we must > have the consultation. > > > > > > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Thu Apr 5 09:45:26 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 5 Apr 2007 09:45:26 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4614BC86.3000203@kcl.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> Message-ID: <17940.64886.701634.932767@emt.wwp.brown.edu> While on the face of it Lou's suggestion (mention all 3 methods of generating a complete TEI schema: via ODD, parametrized DTD, or stitching RNG) seems quite reasonable, Arianna's point that we would then need to make sure SG explained both DTDs and RNG enough to do this is a strong argument against, IMHO. SG should not mention details of DTDs at all. (And yes, Lou, stripping 'em out is still on my plate). Nor should the rest of the Guidelines rely on DTD syntax at all. There are lots of non-conformant methods of making a schema that will validate TEI documents that could be conformant.[1] I do not think the Guidelines themselves should discuss any of them. The Guidelines are already daunting enough. Why add large sections of potentially confusing information that will likely be used by an extraordinarily small number of users (perhaps 0), to explain something that isn't even conformant? Again, a separate paper or HOWTO explaining this may be a good idea. BTW, does anyone actually know how to go about stitching together the RNG schema fragments in a manner that permits similar capabilities to using parametrized DTDs? We would have to figure out how to do it (although, because this is not conformant, I daresay we do not have to figure out how to do it optimally), do extensive testing, and write up a serious chunk of prose instructions. Notes ----- [1] E.g. (untested): namespace tei = "http://www.tei-c.org/ns/1.0" attrs = attribute xml:id { xsd:ID } p = element tei:p { text } start = element tei:TEI { attrs, element tei:teiHeader { attrs, element tei:fileDesc { attrs, element tei:titleStmt { attrs, element tei:title { attrs, text } }, element tei:publicationStmt { attrs, p+ }, element tei:sourceDesc { attrs, p+ } } }, element tei:text { attrs, element tei:body { attrs, p+ } } } From arianna.ciula at kcl.ac.uk Thu Apr 5 10:04:41 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 05 Apr 2007 15:04:41 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17940.64886.701634.932767@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> Message-ID: <461501F9.3020200@kcl.ac.uk> Syd Bauman wrote: > While on the face of it Lou's suggestion (mention all 3 methods of > generating a complete TEI schema: via ODD, parametrized DTD, or > stitching RNG) seems quite reasonable, Arianna's point that we would > then need to make sure SG explained both DTDs and RNG enough to do > this is a strong argument against, IMHO. > Probably I didn't explain myself properly. What I meant is that whatever you editors decide to do (e.g. leave or take out the references to the use of parameter entities to stitch DTD fragments in SG), this needs to be consistent with what you say in MD or in your HOWTo do paper. So, for instance, if there are references to the way you can stitch DTD fragments and not references to the way you would do the same with RelaxNG, this needs to be explained rather than left to the reader to figure out that the old DTD method is there because it was once used and supported by TEI. > The Guidelines > are already daunting enough. Why add large sections of potentially > confusing information that will likely be used by an extraordinarily > small number of users (perhaps 0), to explain something that isn't > even conformant? I agree that it may be overwhelming to add all this prose on introductory chapters and, personally, I wouldn't mind if these explanations were confined somewhere else even outside the guidelines if that matters, but I do think they should be accessible and mentioned at least. In any case, I don't want to sound pedantic. At the end of the day, you have to write additional prose, so if adding this information takes time from more urgent stuff, I am totally in favour of postponing work on this. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cc From lou.burnard at computing-services.oxford.ac.uk Thu Apr 5 10:04:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 05 Apr 2007 15:04:52 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17940.64886.701634.932767@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> Message-ID: <46150204.2030103@oucs.ox.ac.uk> Syd Bauman wrote: > While on the face of it Lou's suggestion (mention all 3 methods of > generating a complete TEI schema: via ODD, parametrized DTD, or > stitching RNG) seems quite reasonable, Arianna's point that we would > then need to make sure SG explained both DTDs and RNG enough to do > this is a strong argument against, IMHO. Depends what "it" is. It only has to explain enough for the further explanation in MD to be comprehensible. > > SG should not mention details of DTDs at all. (And yes, Lou, > stripping 'em out is still on my plate). Nor should the rest of the > Guidelines rely on DTD syntax at all. When you get around to reviewing the mail on this list following Arianna's work on that chapter, you may (possibly) notice that this issue has already been raised there. > > There are lots of non-conformant methods of making a schema that will > validate TEI documents that could be conformant.[1] I do not think > the Guidelines themselves should discuss any of them. The Guidelines > are already daunting enough. Why add large sections of potentially > confusing information that will likely be used by an extraordinarily > small number of users (perhaps 0), to explain something that isn't > even conformant? It is your assertion, and your assertion only, that no one will be interested in making a schema capable of validating TEI conformant documents without using ODD. You may be right, you may be wrong. But simply repeating the assertion doesn't make it true. Nor does it address the counter arguments raised in my earlier posting on this topic. > > Again, a separate paper or HOWTO explaining this may be a good idea. > > > BTW, does anyone actually know how to go about stitching together the > RNG schema fragments in a manner that permits similar capabilities to > using parametrized DTDs? Anyone capable of reading the output from Roma maybe? We would have to figure out how to do it > (although, because this is not conformant, I daresay we do not have > to figure out how to do it optimally), do extensive testing, and > write up a serious chunk of prose instructions. Yes, that's what I said earlier. From wittern at kanji.zinbun.kyoto-u.ac.jp Thu Apr 5 21:21:30 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Fri, 06 Apr 2007 10:21:30 +0900 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <46144959.8050803@kanji.zinbun.kyoto-u.ac.jp> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <46144959.8050803@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <4615A09A.7060907@kanji.zinbun.kyoto-u.ac.jp> Sorry, folks -- this seems to have gone only to LB, not the Council list where it was intended to. Christian Christian Wittern wrote: > Lou Burnard wrote: >> Does no-one else on the Council have a view on this issue? Or is >> everyone already on holiday? > > We are a global organization, so you should at least let pass 24 hrs > before any cry of desparation. But I agree that we need more input on > this important matter. > >> >> Personally, I am reluctant to remove parametrisable schemas without a >> bit more consultation. I have no problem with saying that true TEI >> conformance necessitates production of an ODD. But I still feel we >> have an obligation to make it feasible for people to customize the >> system without using tools that only we provide. Which means that we >> need to continue to provide customizable fragments, and describe how >> they can be used. We *want* people to use TEI P5 at whatever level >> they feel comfortable, right? > > Maybe its survey-monkey time again? > I remember us saying that we will continue to maintain P4 for those who > need it for some reason, but will pipe new developments into P5 without > too much consideration for how this will brake peoples *current* > systems. Well, this was some years ago. > > With P5 now so deep into namespaces, data validation etc., we have moved > pretty much away from things possible in DTDs. Because of editing > support, we should continue to offer pre-a-porter DTDs for those who > don't want to dress up, but I do not think we should continue to support > the customization mechanism of P4. If we do not let go of this now, it > will be a big headache down the road, since we stopped ourselve from > removing it later in the P5 product cycle. > >> For people still in DTDworld, the old method of stitching together DTD >> fragments is just fine, and they can go on doing it without having to >> learn any of this newfangled namespace stuff. > > We will do them a mis-service. They will want to grow up and live on > equal footing in XML-Land, so they need to wrap their heads around this > stuff. We should mildly encourage them to do so. > >> People who, by contrast, are hip to the RelaxNG groove will want to >> know how to plug TEI stuff into their production line without having >> to completely revise the whole shooting match. So my preferred course >> of action would be: >> >> 1. Revise MD to make explicit that there is more than one way of >> building a schema from the TEI Guidelines. In fact there are three: >> (a) write an ODD and process it with a conformant ODD processor >> (b) write a DTD subset using parameter entities and ting and ting >> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib > > My course would be: do (a), forget about (b) and either mention (c) in a > footnote or point to some white paper on the TEI website that explains > how to do that, clearly marked as advanced material. > >> 2. Of these ways, only (a) is guaranteed to result in a schema which >> can be used to validate TEI conformance for your documents, but the >> others may be helpful for local use. So we provide suggested ways of >> doing them, in two distinct subsections of the document. > > Hmm. I read the I in TEI as Interchange and think it is not really our > business to think about what people should or should not do in the > privacy of their own hard-drives. > >> >> 3. We need, urgently, a definition of what exactly a "conformant ODD >> processor" is supposed to do. This might include a description of what >> the current ODD processor does, but that is less important. > > Hopefully Sebastian thinks about this while we speak. > >> >> If, on consultation, it is apparent that no-one cares about (2) above, >> we can always throw away the lovingly-crafted prose I expect to be >> generating this weekend, or put it somewhere else... but I think we >> must have the consultation. > > So maybe you could use your time to attend to other pressing matters and > produce the prose once we reached agreement over this? I think that > would be better use of our scarce ressources. > > All the best, "no holidays in sight" Christian > > -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From daniel.odonnell at uleth.ca Fri Apr 6 12:21:58 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 06 Apr 2007 10:21:58 -0600 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4615A09A.7060907@kanji.zinbun.kyoto-u.ac.jp> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <46144959.8050803@kanji.zinbun.kyoto-u.ac.jp> <4615A09A.7060907@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <1175876518.6146.5.camel@localhost> I think also that the issues are getting fine enough that it may be difficult to have a strong opinion: personally I think I am an a and c person in Christian's formulation: ODD as the recommended standard, footnote or whitepaper on RNG, and drop the DTD for P5. I also suspect from conversations I've had that we are likely to see a legacy of P4 projects for quite a while--especially institutional ones--so, I'm happy dropping the dtd business for conformance for P5 anyway. As to ODD processors--I've no informed opinion. On Fri, 2007-04-06 at 10:21 +0900, Christian Wittern wrote: > Sorry, folks -- this seems to have gone only to LB, not the Council list > where it was intended to. > > Christian > > > Christian Wittern wrote: > > Lou Burnard wrote: > >> Does no-one else on the Council have a view on this issue? Or is > >> everyone already on holiday? > > > > We are a global organization, so you should at least let pass 24 hrs > > before any cry of desparation. But I agree that we need more input on > > this important matter. > > > >> > >> Personally, I am reluctant to remove parametrisable schemas without a > >> bit more consultation. I have no problem with saying that true TEI > >> conformance necessitates production of an ODD. But I still feel we > >> have an obligation to make it feasible for people to customize the > >> system without using tools that only we provide. Which means that we > >> need to continue to provide customizable fragments, and describe how > >> they can be used. We *want* people to use TEI P5 at whatever level > >> they feel comfortable, right? > > > > Maybe its survey-monkey time again? > > I remember us saying that we will continue to maintain P4 for those who > > need it for some reason, but will pipe new developments into P5 without > > too much consideration for how this will brake peoples *current* > > systems. Well, this was some years ago. > > > > With P5 now so deep into namespaces, data validation etc., we have moved > > pretty much away from things possible in DTDs. Because of editing > > support, we should continue to offer pre-a-porter DTDs for those who > > don't want to dress up, but I do not think we should continue to support > > the customization mechanism of P4. If we do not let go of this now, it > > will be a big headache down the road, since we stopped ourselve from > > removing it later in the P5 product cycle. > > > >> For people still in DTDworld, the old method of stitching together DTD > >> fragments is just fine, and they can go on doing it without having to > >> learn any of this newfangled namespace stuff. > > > > We will do them a mis-service. They will want to grow up and live on > > equal footing in XML-Land, so they need to wrap their heads around this > > stuff. We should mildly encourage them to do so. > > > >> People who, by contrast, are hip to the RelaxNG groove will want to > >> know how to plug TEI stuff into their production line without having > >> to completely revise the whole shooting match. So my preferred course > >> of action would be: > >> > >> 1. Revise MD to make explicit that there is more than one way of > >> building a schema from the TEI Guidelines. In fact there are three: > >> (a) write an ODD and process it with a conformant ODD processor > >> (b) write a DTD subset using parameter entities and ting and ting > >> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib > > > > My course would be: do (a), forget about (b) and either mention (c) in a > > footnote or point to some white paper on the TEI website that explains > > how to do that, clearly marked as advanced material. > > > >> 2. Of these ways, only (a) is guaranteed to result in a schema which > >> can be used to validate TEI conformance for your documents, but the > >> others may be helpful for local use. So we provide suggested ways of > >> doing them, in two distinct subsections of the document. > > > > Hmm. I read the I in TEI as Interchange and think it is not really our > > business to think about what people should or should not do in the > > privacy of their own hard-drives. > > > >> > >> 3. We need, urgently, a definition of what exactly a "conformant ODD > >> processor" is supposed to do. This might include a description of what > >> the current ODD processor does, but that is less important. > > > > Hopefully Sebastian thinks about this while we speak. > > > >> > >> If, on consultation, it is apparent that no-one cares about (2) above, > >> we can always throw away the lovingly-crafted prose I expect to be > >> generating this weekend, or put it somewhere else... but I think we > >> must have the consultation. > > > > So maybe you could use your time to attend to other pressing matters and > > produce the prose once we reached agreement over this? I think that > > would be better use of our scarce ressources. > > > > All the best, "no holidays in sight" Christian > > > > > > -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From Syd_Bauman at Brown.edu Fri Apr 6 14:02:52 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 6 Apr 2007 14:02:52 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <46150204.2030103@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> Message-ID: <17942.35660.718823.915509@emt.wwp.brown.edu> > Depends what "it" is. It only has to explain enough for the further > explanation in MD to be comprehensible. Absolutely true, but I'm claiming that's too much. > It is your assertion, and your assertion only, that no one will be > interested in making a schema capable of validating TEI conformant > documents without using ODD. You may be right, you may be wrong. Not quite. But I do think few enough people will want to do so strongly enough that putting instructions on doing so in the Guidelines is counter-productive. Discussions of parametrized DTDs will add more confusion to more people than it will help those few who might really want to do this. > > BTW, does anyone actually know how to go about stitching together > > the RNG schema fragments in a manner that permits similar > > capabilities to using parametrized DTDs? > > Anyone capable of reading the output from Roma maybe? Which output from Roma did you have in mind? In any case, I'm guessing you think I mean "stitch together a schema which loads some TEI modules", which I agree, is not particularly difficult. But I had more complex customizations in mind. E.g., things like * load core, tei, header, and textstructure (of course) * also load gaiji & figures * change things 'round so that is only permitted as a child of * move
to model.global * make a required child of
From lou.burnard at computing-services.oxford.ac.uk Fri Apr 6 18:12:14 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 06 Apr 2007 23:12:14 +0100 Subject: [tei-council] floating text launched Message-ID: <4616C5BE.3010803@computing-services.oxford.ac.uk> Following my plea for examples of floating texts earlier this week, I am pleased to report that Julia duly delivered a splendid one, which I have now duly incorporated into the text of DS. At the same time I was doing this, I received notice from Arianna of a whole bunch of other errors in the same chapter, which I was thus able to despatch at the same time. Many thanks to both. The corrected (and expanded) version is now checked into the main branch. As this is new material which all Council members ought to review, I have also put a copy of the revised draft chapter in HTML format on the website at http://www.tei-c.org/Drafts/DS.html Don't expect any of the links in it to work as I haven't put any of the other chapters there! If you just want to cut straight to the chase to find out what on earth a floating text is, go to http://www.tei-c.org/Drafts/DS.html#DSFLT From Syd_Bauman at Brown.edu Fri Apr 6 20:08:21 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 6 Apr 2007 20:08:21 -0400 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> Message-ID: <17942.57589.177531.95758@emt.wwp.brown.edu> LB> 1. Revise MD to make explicit that there is more than one way of LB> building a schema from the TEI Guidelines. In fact there are three: LB> (a) write an ODD and process it with a conformant ODD processor LB> (b) write a DTD subset using parameter entities and ting and ting LB> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib CW> My course would be: do (a), forget about (b) and either mention CW> (c) in a footnote or point to some white paper on the TEI website CW> that explains how to do that, clearly marked as advanced CW> material. So far I agree with you completely, Christian. CW> This is what we invented ODD and Roma for. Whats the point in CW> showing people how to do this on foot? But now you've lost me. Are you thinking that "stitching together" a Relax NG Schema for validating TEI instances should do nothing more than module selection? I (apparently incorrectly) took Lou's "combines TEI RelaxNG modules" to mean the same thing I have been talking about, which includes the usual kinds of customizations users need (without the documentation and perhaps some of the rigor ODD provides, and thus a non-conformant methodology). I think module selection alone would be insufficient. The point of a schema is to provide constraint -- the user has to mold it so that it provides the constraint she wants, else it is not a very useful feature. I think it may be a good idea to discuss/show/demonstrate how to do this because, as has been pointed out * user may not have easy access to roma or webRoma * it's rude to insist people use a system for which the only supplier of software is us In P4 the user didn't need a tool at all. Just a text editor and a copy of the Guidelines would do the trick. (Although I have to admit, a copy of Goldfarb is a good idea, too :-) From wittern at kanji.zinbun.kyoto-u.ac.jp Fri Apr 6 19:27:56 2007 From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern) Date: Sat, 07 Apr 2007 08:27:56 +0900 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17942.35660.718823.915509@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> Message-ID: <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> Syd Bauman wrote: >> Anyone capable of reading the output from Roma maybe? > > Which output from Roma did you have in mind? > > In any case, I'm guessing you think I mean "stitch together a schema > which loads some TEI modules", which I agree, is not particularly > difficult. But I had more complex customizations in mind. E.g., > things like > * load core, tei, header, and textstructure (of course) > * also load gaiji & figures > * change things 'round so that is only permitted as a child of > > * move
to model.global > * make a required child of
This is what we invented ODD and Roma for. Whats the point in showing people how to do this on foot? Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 08:00:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 13:00:23 +0100 Subject: [tei-council] ODD processing and renaming Message-ID: <461787D7.4030500@computing-services.oxford.ac.uk> Given yyy we expect to generate a "foo" declaration for something called yyy However, given yyy zzz we will generate a "foo" declaration for something called zzz iff we are producing a schema in language xx, and one for yyy otherwise. Is overloading xml:lang in this way preferable to having an explicit attribute on the which says "use ME" ? (Note that the current scheme gives us no way of saying "here's another name for this element in some language but don't use it") From Syd_Bauman at Brown.edu Sat Apr 7 09:03:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 09:03:25 -0400 Subject: [tei-council] ODD processing and renaming In-Reply-To: <461787D7.4030500@computing-services.oxford.ac.uk> References: <461787D7.4030500@computing-services.oxford.ac.uk> Message-ID: <17943.38557.51071.828895@emt.wwp.brown.edu> Perhaps because I'm used to the current system, or perhaps because it's still morning here, I don't think I understand what the advantage of a useMe="yes" on would be. Current encoding lets an ODD processor: * use *Spec/@ident, ignoring s * use altIdent[xml:lang="xx"] if present, otherwise altIdent[xml:lang="en"] if present, otherwise *Spec/@ident (what I would call the "expected" behavior, but as I said, perhaps just because that's what I think ours does) * use altIdent[xml:lang="xx"] if present, *Spec/@ident otherwise (ignoring altIdent[xml:lang="en"]) * Arrange possible languages in a desired languages in order (likely to be user-specified, of course. i.e.: use altIdent/[xml:lang="x1"] if present, if not, use altIdent/[xml:lang="x2"] if present, if not, use altIdent/[xml:lang="x3"] if present, if not, use altIdent/[xml:lang="x4"] if present, if not, use altIdent/[xml:lang="en"] if present, if not, use *Spec/@ident. > Is overloading xml:lang in this way preferable to having an > explicit attribute on the which says "use ME" ? (Note > that the current scheme gives us no way of saying "here's another > name for this element in some language but don't use it") I'm having some trouble wrapping my brain around that. Why would we want to put a name for an element/attribute/class/macro in the ODD and then tell the ODD processor not to use it? Maybe what you're objecting to is that there can only be 1 identifier per any given language, except for English, which (because it is the canonical language) has 2 possibilities? On quick thought, this doesn't bother me too much. Nothing stops a user from using RFC 3066 tags in a more fine-grained manner: hypertextDivision hyperDiv ldb Notes ----- * Remember, that these names are not *in* a natural language -- they are arbitrary identifiers chosen to be easy for native speakers of a particular natural language to remember. This, IMHO, is an argument for not using xml:lang=. * IIRC, the only special restriction RFC 3066 places on the second subtag is that it may not be two letters long unless it is a country code from ISO 3166 or whatever. (And in which case it is recommended, but not required, that it be in upper case.) Also 1-letter codes may not be registered with IANA, but I don't think that's an issue here :-) From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 10:01:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 15:01:51 +0100 Subject: [tei-council] Minimal TEI schema Message-ID: <4617A44F.50705@computing-services.oxford.ac.uk> We have abolished the distinction between base and additional tag sets. But we have retained the idea that a conformant document must have a header. This suggests that the minimal combination of modules needed for TEI conformance must include the header. Furthermore, if a conformant document must have a root of TEI or teiCorpus, we must include the textstructure module. Since every element (I think without exception) in those two modules makes use of at least one class defined by the TEI module, you won't get far without that. And it's hard to see how you can get by without at least one element from the Core module, though I am not quite so sure of that as I am of the others. SO, today's question : should we state that a minimal requirement for TEI conformance is that the schema in question uses those four modules (header, textstructure, tei, core)? I don't see that assertion spelled out in the current draft, though there is reference to "the TEI basic four modules" which is presumably the same thing. From Syd_Bauman at Brown.edu Sat Apr 7 10:31:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 10:31:24 -0400 Subject: [tei-council] Minimal TEI schema In-Reply-To: <4617A44F.50705@computing-services.oxford.ac.uk> References: <4617A44F.50705@computing-services.oxford.ac.uk> Message-ID: <17943.43836.477780.598730@emt.wwp.brown.edu> > And it's hard to see how you can get by without at least one > element from the Core module, though I am not quite so sure of that > as I am of the others. By default if you load only tei, header, and textstructure (but not core) you get an invalid schema. You could, of course, delete the elements that are referenced but not declared. You would get a valid schema, but it wouldn't have the element, and <sourceDesc> would have to contain a <recordingStmt> with any number of nested empty <recording> and <broadcast> elements. > SO, today's question : should we state that a minimal requirement > for TEI conformance is that the schema in question uses those four > modules (header, textstructure, tei, core)? I don't see that > assertion spelled out in the current draft, though there is > reference to "the TEI basic four modules" which is presumably the > same thing. While it isn't strictly necessary (I think I can come up with an ODD that would not use core, but otherwise would make sense to call conformant), I think it would be much easier on everyone involved (users, editors, council members) to just say core is required. After all, the schema generated from an ODD that does not use core cannot be used to encode anything, it's just an oddity :-) Only those of us who are interested in writing papers about literate schema-building and the interaction between prose and formal rules are going to care. From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 12:40:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 17:40:35 +0100 Subject: [tei-council] namespaces and modifications Message-ID: <4617C983.4040502@computing-services.oxford.ac.uk> The consensus seems to be that if I add a completely new element, it makes sense to define it as belonging to a new namespace. Presumably the same also applies if I define a new attribute for an existing element, so I could get by with just putting the new attribute in a non-TEI namespace. But hold on, what if I get the new attribute by adding the element to an existing attribute class which it wasn't in before? Now I have to distinguish the @type I get from att.typed in a kosher manner from the exact same attribute which I got by modification! It seems to me that the only sane thing to do is to say that my newly modified element is in a new namespace, and leave it at that. So if there is a TEI:foo, and a my:foo, and even the bits of my:foo which are unchanged from the TEI scheme are still in a different namespace as soon as I tweak any part of it. From daniel.odonnell at uleth.ca Sat Apr 7 13:18:41 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 07 Apr 2007 11:18:41 -0600 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617C983.4040502@computing-services.oxford.ac.uk> References: <4617C983.4040502@computing-services.oxford.ac.uk> Message-ID: <1175966322.6824.2.camel@localhost> As somebody has done both of these things, I can say that this sounds reasonable--in fact is probably helpful as it reminds one constantly of the modifications. When I did some of these kind of modifications in P3 SGML (I messed around with w and added a couple of other things) it was an issue to remember what had changed and how. I think this is a useful conformance approach. -dan On Sat, 2007-04-07 at 17:40 +0100, Lou Burnard wrote: > The consensus seems to be that if I add a completely new element, it > makes sense to define it as belonging to a new namespace. Presumably the > same also applies if I define a new attribute for an existing element, > so I could get by with just putting the new attribute in a non-TEI > namespace. But hold on, what if I get the new attribute by adding the > element to an existing attribute class which it wasn't in before? Now I > have to distinguish the @type I get from att.typed in a kosher manner > from the exact same attribute which I got by modification! > > It seems to me that the only sane thing to do is to say that my newly > modified element is in a new namespace, and leave it at that. So if > there is a TEI:foo, and a my:foo, and even the bits of my:foo which are > unchanged from the TEI scheme are still in a different namespace as soon > as I tweak any part of it. > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 13:31:33 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 18:31:33 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617C983.4040502@computing-services.oxford.ac.uk> References: <4617C983.4040502@computing-services.oxford.ac.uk> Message-ID: <4617D575.7090503@computing-services.oxford.ac.uk> Lou Burnard wrote: > The consensus seems to be that if I add a completely new element, it > makes sense to define it as belonging to a new namespace. Presumably the > same also applies if I define a new attribute for an existing element, > so I could get by with just putting the new attribute in a non-TEI > namespace. But hold on, what if I get the new attribute by adding the > element to an existing attribute class which it wasn't in before? Now I > have to distinguish the @type I get from att.typed in a kosher manner > from the exact same attribute which I got by modification! > > It seems to me that the only sane thing to do is to say that my newly > modified element is in a new namespace, and leave it at that. So if > there is a TEI:foo, and a my:foo, and even the bits of my:foo which are > unchanged from the TEI scheme are still in a different namespace as soon > as I tweak any part of it. Hrmmm. If I've added a brand new element, my:foo, I've done so in my own namespace, of course. But if I add it to class att.typed, it joins that club and gets the TEI element tei:typed, right? So, playing devil's advocate, why should that attribute be in any other namespace than the TEI? As long as it is still a TEI attribute, it should be in the TEI namespace, right? Just like we use xml:id and xml:lang. <tei:div xmlns:tei="http://www.tei-c.org/ns/1.0" my:newAtt="blort"> <my:foo xmlns:my="http://my-new-namespace.info/" tei:type="wibble"/> </tei:div> I'm happy to be argued down about this, I just want to make sure we are clear on the reasons why. So explain it to me again like I'm even more ignorant than I am.... -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 13:46:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 18:46:52 +0100 Subject: [tei-council] Minimal TEI schema In-Reply-To: <17943.43836.477780.598730@emt.wwp.brown.edu> References: <4617A44F.50705@computing-services.oxford.ac.uk> <17943.43836.477780.598730@emt.wwp.brown.edu> Message-ID: <4617D90C.2090508@computing-services.oxford.ac.uk> Syd Bauman wrote: >> SO, today's question : should we state that a minimal requirement >> for TEI conformance is that the schema in question uses those four >> modules (header, textstructure, tei, core)? I don't see that >> assertion spelled out in the current draft, though there is >> reference to "the TEI basic four modules" which is presumably the >> same thing. > > While it isn't strictly necessary (I think I can come up with an ODD > that would not use core, but otherwise would make sense to call > conformant), I think it would be much easier on everyone involved > (users, editors, council members) to just say core is required. After > all, the schema generated from an ODD that does not use core cannot > be used to encode anything, it's just an oddity :-) Only those of us > who are interested in writing papers about literate schema-building > and the interaction between prose and formal rules are going to care. Do we need our definition of Conformance to necessarily reference what modules you must use? While I can't picture anything other than 99.9% TEI Conformant documents using Core, I'm not as sure that we need to specify that XYZ modules must be included in the ODD for your document (that validates against the schema generated from that ODD) to be Conformant. While almost everyone is going to do this anyway, does it benefit us to make it a requirement? To be honest, I'm ambivalent, but wondered why this should be a requirement. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Sat Apr 7 14:06:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 07 Apr 2007 19:06:54 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617D575.7090503@computing-services.oxford.ac.uk> References: <4617C983.4040502@computing-services.oxford.ac.uk> <4617D575.7090503@computing-services.oxford.ac.uk> Message-ID: <4617DDBE.9070506@computing-services.oxford.ac.uk> James Cummings wrote: > Lou Burnard wrote: >> The consensus seems to be that if I add a completely new element, it >> makes sense to define it as belonging to a new namespace. Presumably >> the same also applies if I define a new attribute for an existing >> element, so I could get by with just putting the new attribute in a >> non-TEI namespace. But hold on, what if I get the new attribute by >> adding the element to an existing attribute class which it wasn't in >> before? Now I have to distinguish the @type I get from att.typed in a >> kosher manner from the exact same attribute which I got by modification! >> >> It seems to me that the only sane thing to do is to say that my newly >> modified element is in a new namespace, and leave it at that. So if >> there is a TEI:foo, and a my:foo, and even the bits of my:foo which >> are unchanged from the TEI scheme are still in a different namespace >> as soon as I tweak any part of it. > > Hrmmm. If I've added a brand new element, my:foo, I've done so in my > own namespace, of course. But if I add it to class att.typed, it > joins that club and gets the TEI element tei:typed, right? So, > playing devil's advocate, why should that eh? do you mean it gets the TEI attribute tei:type? > attribute be in any other namespace than the TEI? As long as it is > still a TEI attribute, it should be in the TEI namespace, right? Just > like we use xml:id and xml:lang. > well, yes that was the point of my query. It's just that my head started to hurt when I started thinking about how to document the rules here. > <tei:div xmlns:tei="http://www.tei-c.org/ns/1.0" my:newAtt="blort"> > > <my:foo xmlns:my="http://my-new-namespace.info/" tei:type="wibble"/> > > </tei:div> > > > I'm happy to be argued down about this, I just want to make sure we > are clear on the reasons why. So explain it to me again like I'm even > more ignorant than I am.... just about to check in a revised version of MD which maybe will help... > > -James > From James.Cummings at computing-services.oxford.ac.uk Sat Apr 7 14:35:41 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 07 Apr 2007 19:35:41 +0100 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617DDBE.9070506@computing-services.oxford.ac.uk> References: <4617C983.4040502@computing-services.oxford.ac.uk> <4617D575.7090503@computing-services.oxford.ac.uk> <4617DDBE.9070506@computing-services.oxford.ac.uk> Message-ID: <4617E47D.8080408@computing-services.oxford.ac.uk> Lou Burnard wrote: >> Hrmmm. If I've added a brand new element, my:foo, I've done so in my >> own namespace, of course. But if I add it to class att.typed, it >> joins that club and gets the TEI element tei:typed, right? So, >> playing devil's advocate, why should that > eh? do you mean it gets the TEI attribute tei:type? erm yes, exactly. Sorry, typo. > well, yes that was the point of my query. It's just that my head started > to hurt when I started thinking about how to document the rules here. Yes, I can understand that. All existing TEI elements and attributes are in the TEI namespace, even if used on new elements in a different namespace? > just about to check in a revised version of MD which maybe will help... I look forward to it. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Sat Apr 7 18:18:18 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 7 Apr 2007 18:18:18 -0400 Subject: [tei-council] namespaces and modifications In-Reply-To: <4617D575.7090503@computing-services.oxford.ac.uk> References: <4617C983.4040502@computing-services.oxford.ac.uk> <4617D575.7090503@computing-services.oxford.ac.uk> Message-ID: <17944.6314.687475.774701@emt.wwp.brown.edu> > Hrmmm. If I've added a brand new element, my:foo, I've done so in > my own namespace, of course. But if I add it to class att.typed, it > joins that club and gets the TEI element tei:typed, right? This turns out not to be the case. Being added to class att.typed gets you the TEI attribute type=, *not* the attribute tei:type=. Attributes, unless explicitly qualified, are in no namespace. "The namespace name for an unprefixed attribute name always has no value." -- http://www.w3.org/TR/REC-xml-names/#defaulting But Lou has pointed out some of the major headaches I was referring to when this came up. Things like the following. * What if user adds new attribute to existing TEI element? Does she have to put it in her namespace, or can it be in no namespace like the other attributes? * What if a user deletes attributes from a standard TEI element -- does that element now have to get moved from the TEI namespace to her namespace? Especially if it was a required attribute, normal TEI software may not be able to process that element anymore. * If she deletes an attribute from an attribute class, do all members of that class now have to change namespace? * What if a user adds an existing TEI element to an existing TEI attribute class, such that it now has attributes it doesn't have in vanilla? * What about the reverse: she removes an element from an existing attribute class? And we haven't even started to think about changing model classes and content models yet! Issues like this are why I think this general idea that putting new elements in a different namespace will help in processing TEI documents is tenuous at best. From daniel.odonnell at uleth.ca Sun Apr 8 00:16:06 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sat, 07 Apr 2007 22:16:06 -0600 Subject: [tei-council] namespaces and modifications In-Reply-To: <17944.6314.687475.774701@emt.wwp.brown.edu> References: <4617C983.4040502@computing-services.oxford.ac.uk> <4617D575.7090503@computing-services.oxford.ac.uk> <17944.6314.687475.774701@emt.wwp.brown.edu> Message-ID: <1176005766.6261.6.camel@localhost> On Sat, 2007-04-07 at 18:18 -0400, Syd Bauman wrote: > > Hrmmm. If I've added a brand new element, my:foo, I've done so in > > my own namespace, of course. But if I add it to class att.typed, it > > joins that club and gets the TEI element tei:typed, right? > > This turns out not to be the case. Being added to class att.typed > gets you the TEI attribute type=, *not* the attribute tei:type=. > Attributes, unless explicitly qualified, are in no namespace. > > "The namespace name for an unprefixed attribute name always has no > value." -- http://www.w3.org/TR/REC-xml-names/#defaulting > > > But Lou has pointed out some of the major headaches I was referring > to when this came up. Things like the following. > > * What if user adds new attribute to existing TEI element? Does she > have to put it in her namespace, Yes. > or can it be in no namespace like > the other attributes? > > * What if a user deletes attributes from a standard TEI element -- > does that element now have to get moved from the TEI namespace to > her namespace? Yes. > Especially if it was a required attribute, normal > TEI software may not be able to process that element anymore. > > * If she deletes an attribute from an attribute class, do all members > of that class now have to change namespace? > > * What if a user adds an existing TEI element to an existing TEI > attribute class, such that it now has attributes it doesn't have in > vanilla? I think yes--own namespace > > * What about the reverse: she removes an element from an existing > attribute class? I think yes, --own namespace > > And we haven't even started to think about changing model classes and > content models yet! > > Issues like this are why I think this general idea that putting new > elements in a different namespace will help in processing TEI > documents is tenuous at best. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From Syd_Bauman at Brown.edu Mon Apr 9 15:50:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 9 Apr 2007 15:50:23 -0400 Subject: [tei-council] ISO 8601 ambiguity Message-ID: <17946.39167.37543.189412@emt.wwp.brown.edu> This is mostly aimed at James, who I think has an interest in this stuff, but others may be interested as well. I've been reading ISO 8601:2004 lately, and it seems to me there is a glaring ambiguity. <date value="1948"> <!-- calendar year basic format, reduced accuracy; see 4.1.2.3(b); represents the year Mahatma Gandhi was assassinated --> <time value="1948"> <!-- local time basic format, reduced accuracy; see 4.2.2.3(a); represents a good time to clear the dinner table and get ready for bed: 19.8 hours into the day --> (Of course, if you were to use the extended format for the time, i.e. "19:48", no ambiguity exists.) I have *never* liked the basic formats, and the current draft of the Guidelines says <p>For all representations for which ISO 8601 describes both a <soCalled>basic</soCalled> and an <soCalled>extended</soCalled> format, these Guidelines recommend use of the extended format.</p> I'm wondering if this shouldn't be worded more strongly. (And those <soCalled>s should probably be <term>s or <name>s.) I note that the Wikipedia says "The extended formats are preferred over basic formats because some basic formats are ambiguous." From lou.burnard at computing-services.oxford.ac.uk Mon Apr 9 16:20:30 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Apr 2007 21:20:30 +0100 Subject: [tei-council] MD chapter revised: namespace rules Message-ID: <461AA00E.50405@computing-services.oxford.ac.uk> I have now checked in a completely rewritten version of chapter MD. Its content (I now realize) overlaps somewhat with the ODD Customization Manual that Sebastian wrote many moons ago, which foolishly I did not think of using as source material, until too late; instead I tried to stick to the original goal of describing just as much as is necessary to motivate the following discussion of what conformance means. Inter alia, and as a straw man, I'd like to propose for discussion the following draconian rules about the use of namespaces in modification: 1. New elements may not be placed in the TEI namespace 2. If new attributes are added to a TEI element, the resulting element must be moved out of the TEI namespace. 3. Only modified elements which have undergone a clean modification [1] may remain in the TEI namespace. 4. If a TEI element is renamed, it may not remain in the TEI namespace, except that TEI namespaces are defined for systematic renaming of TEI elements into different languages. [1]A "clean" modification is defined in chapter MD as one which results in a schema that matches a proper subset of the documents matched by an unmodified schema. Comments? Alternative proposals? From lou.burnard at computing-services.oxford.ac.uk Mon Apr 9 18:16:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 09 Apr 2007 23:16:28 +0100 Subject: [tei-council] Conformance draft checked in Message-ID: <461ABB3C.2090308@computing-services.oxford.ac.uk> Working through James's draft definition of conformance, I've made the following substantive changes (plus a bunch of minor stylistic changes) 1. I've added the requirement that a tei conformant document must respect the semantics embodied in the Guidelines to the discussion of the TEI abstract model and moved that up the list of conformance pre-requisites a bit. 2. I've reinstated the requirement for a sourceDesc. Even James says that this is "recommended practice" for documents born digital, and since conformance is a prerequisite for "recommended practice".... 3. I've combined the three varieties of nonconformance into one section, and turned around the comment about the use of TEI namespace in such documents (James had it expressed as a pious hope, and I have made it an opportunity not to be missed) I got tired at the point that James started talking about namespaces (section CFNS to be exact) and haven't revised that or following subsections. I'm minded to delete the last section (on funding bodies) completely, as aforesaid. And I am sorry, but I haven't reviewed all the comments made so far to make sure I've addressed them all. I am handing the draft over to James to do that! I have also removed completely what used to be chapter IN. It's possible that we might need to add a new section following CF, which says (a) Use Unicode and use <g> if unicode doesnt do it for you (b) Use XML but that shouldn't amount to more than a paragraph or two. I am still not sure what (if anything) should replace the current chapter DT. And, John, where are we with the updates for the current section SH? Anyway, a new HTML version of all this stuff is now available for your reading pleasure at http://www.tei-c.org/Drafts/USE.html Please read through this as soon as possible and comment here. We need to get our story on this sorted out before Berlin, in my opinion. From James.Cummings at oucs.ox.ac.uk Tue Apr 10 08:13:19 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 10 Apr 2007 13:13:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461AA00E.50405@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> Message-ID: <461B7F5F.1000502@oucs.ox.ac.uk> Lou Burnard wrote: > Inter alia, and as a straw man, I'd like to propose for discussion the > following draconian rules about the use of namespaces in modification: > > 1. New elements may not be placed in the TEI namespace I can agree with that, though we may disagree on what is a 'new' element. > 2. If new attributes are added to a TEI element, the resulting element > must be moved out of the TEI namespace. I'm not convinced by that. If I add a new attribute to a TEI element, the TEI element is still a TEI element. It just has a new attribute and that attribute is signalled as not being part of the TEI by itself being in a different namespace. my:newAtt="foo". I don't see that the element is now so changed that it is no longer the TEI element. > 3. Only modified elements which have undergone a clean modification [1] > may remain in the TEI namespace. Agreed, but I think adding an attribute which is in a different namespace is a clean modification. You are right that changed content models, etc. are dirty changes. However, if the change is to remove an element from some classes, or limit an open attribute value list, or anything similar which constrains it, then that is a clean modification because the TEI content still validates against tei_all. > 4. If a TEI element is renamed, it may not remain in the TEI namespace, > except that TEI namespaces are defined for systematic renaming of TEI > elements into different languages. I'm still not convinced that TEI translations need separate namespaces. They should be conformant according to the Renaming Subset schema. If something is simply a renamed element/attribute and it otherwise is identical to the TEI original (and documented with ODD/equiv) then I do not feel it needs to be in a different namespace. It is, for all intents and purposes, the TEI element. If I have <div type="chapter"> and instead rename this <chapter> keeping everything else the same, does this really need a new namespace? The original view of the Renaming Subset was that it didn't. > [1]A "clean" modification is defined in chapter MD as one which results > in a schema that matches a proper subset of the documents matched by an > unmodified schema. I think clean should include reversal of renamings, and that translations are just a specialised form of renamings. > Comments? Alternative proposals? Alternative proposal: 1. Entirely new elements should be in a new namespace 2. Renamed elements, properly documented should remain in TEI namespace 3. Translations are just a form of renaming. 4. Adding new (namespaced) attributes to a TEI element, does not stop that TEI element being TEI. 5. Our definition of 'clean' modification should include renamings. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Tue Apr 10 08:38:35 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Apr 2007 13:38:35 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B7F5F.1000502@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> Message-ID: <461B854B.60704@oucs.ox.ac.uk> James Cummings wrote: > Lou Burnard wrote: >> Inter alia, and as a straw man, I'd like to propose for discussion the >> following draconian rules about the use of namespaces in modification: >> >> 1. New elements may not be placed in the TEI namespace > > I can agree with that, though we may disagree on what is a 'new' element. By "new" I mean an element not already defined by the Guidelines. What fiendishly cunning other case do you have in mind Dr Cummings? > >> 2. If new attributes are added to a TEI element, the resulting element >> must be moved out of the TEI namespace. > > I'm not convinced by that. If I add a new attribute to a TEI element, the > TEI element is still a TEI element. It just has a new attribute and that > attribute is signalled as not being part of the TEI by itself being in a > different namespace. my:newAtt="foo". I don't see that the element is now > so changed that it is no longer the TEI element. OK, this is a plausible argument and I am disposed to agree with you. > >> 3. Only modified elements which have undergone a clean modification [1] >> may remain in the TEI namespace. > > Agreed, but I think adding an attribute which is in a different namespace > is a clean modification. Yes, though only if I agree with you on (2) above. You are right that changed content models, etc. > are dirty changes. However, if the change is to remove an element from > some classes, or limit an open attribute value list, or anything similar > which constrains it, then that is a clean modification because the TEI > content still validates against tei_all. > Yes. The draft does try to make this distinction clear. >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, >> except that TEI namespaces are defined for systematic renaming of TEI >> elements into different languages. > > I'm still not convinced that TEI translations need separate namespaces. Well, let us wait for reactions from others, because I currently still think that separate namespaces for separate translations makes a whole lot of sense, organizationally, politically, and technically. If we dont do that, then every new translation has to watch out for name collision with every other language now and in the future! I am less sure about individual renamings, but still feel that basically if you don't use the names we have chosen for our elements, whether or not you make explicit the relationship between your name and ours, you are polluting the TEI namespace. And you have all the headaches about name collision. And my dimwitted TEI application has to go and read the ODD every time it processes a document to know what to do with your renaming. > They should be conformant according to the Renaming Subset schema. If > something is simply a renamed element/attribute and it otherwise is > identical to the TEI original (and documented with ODD/equiv) then I do not > feel it needs to be in a different namespace. It is, for all intents and > purposes, the TEI element. If I have <div type="chapter"> and instead > rename this <chapter> keeping everything else the same, does this really > need a new namespace? The original view of the Renaming Subset was that it > didn't. I'm happy with the concept of a renaming subset schema. I just think it ought to use a different namespace for the renamed elements. > >> [1]A "clean" modification is defined in chapter MD as one which results >> in a schema that matches a proper subset of the documents matched by an >> unmodified schema. > > I think clean should include reversal of renamings, and that translations > are just a specialised form of renamings. > I think adding this level of complexity may be just a level too far for many simple-minded processors. But, as I said, let's wait to see what others think. >> Comments? Alternative proposals? > > Alternative proposal: > 1. Entirely new elements should be in a new namespace yes > 2. Renamed elements, properly documented should remain in TEI namespace no > 3. Translations are just a form of renaming. yes, except that they are systematic > 4. Adding new (namespaced) attributes to a TEI element, does not stop that > TEI element being TEI. yes > 5. Our definition of 'clean' modification should include renamings. > no! From laurent.romary at loria.fr Tue Apr 10 08:48:18 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Apr 2007 14:48:18 +0200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B7F5F.1000502@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> Message-ID: <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> Hi all, I have kept track of the discussion fo a while and could not see how to enter it... now I have it. I am completely in line with James on his arguments related to points 2 and 3. The requirements that adding an attribute too an element (especially an existing TEI attribute by the way) should force the element to change namespace is slightly too strong. I am thinking of people who may want to add a simple type attribute to an element and would not want to bother about namespaces though. Laurent Le 10 avr. 07 ? 14:13, James Cummings a ?crit : > Lou Burnard wrote: >> 2. If new attributes are added to a TEI element, the resulting >> element >> must be moved out of the TEI namespace. > > I'm not convinced by that. If I add a new attribute to a TEI > element, the > TEI element is still a TEI element. It just has a new attribute > and that > attribute is signalled as not being part of the TEI by itself being > in a > different namespace. my:newAtt="foo". I don't see that the > element is now > so changed that it is no longer the TEI element. > >> 3. Only modified elements which have undergone a clean >> modification [1] >> may remain in the TEI namespace. > > Agreed, but I think adding an attribute which is in a different > namespace > is a clean modification. You are right that changed content > models, etc. > are dirty changes. However, if the change is to remove an element > from > some classes, or limit an open attribute value list, or anything > similar > which constrains it, then that is a clean modification because the TEI > content still validates against tei_all. From James.Cummings at computing-services.oxford.ac.uk Tue Apr 10 08:55:43 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 10 Apr 2007 13:55:43 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B854B.60704@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> Message-ID: <461B894F.7080000@computing-services.oxford.ac.uk> Lou Burnard wrote: > James Cummings wrote: >> Lou Burnard wrote: >>> Inter alia, and as a straw man, I'd like to propose for discussion the >>> following draconian rules about the use of namespaces in modification: >>> >>> 1. New elements may not be placed in the TEI namespace >> >> I can agree with that, though we may disagree on what is a 'new' element. > > By "new" I mean an element not already defined by the Guidelines. What > fiendishly cunning other case do you have in mind Dr Cummings? A properly documented renaming, of course, whether by means of translation or otherwise. >>> 2. If new attributes are added to a TEI element, the resulting element >>> must be moved out of the TEI namespace. >> >> I'm not convinced by that. If I add a new attribute to a TEI element, >> the >> TEI element is still a TEI element. It just has a new attribute and that >> attribute is signalled as not being part of the TEI by itself being in a >> different namespace. my:newAtt="foo". I don't see that the element >> is now >> so changed that it is no longer the TEI element. > OK, this is a plausible argument and I am disposed to agree with you. Oh good, that was easy. >>> 3. Only modified elements which have undergone a clean modification [1] >>> may remain in the TEI namespace. >> >> Agreed, but I think adding an attribute which is in a different namespace >> is a clean modification. > > Yes, though only if I agree with you on (2) above. Didn't you just agree to that above? > Yes. The draft does try to make this distinction clear. Indeed it does. >>> 4. If a TEI element is renamed, it may not remain in the TEI namespace, >>> except that TEI namespaces are defined for systematic renaming of TEI >>> elements into different languages. >> >> I'm still not convinced that TEI translations need separate namespaces. > > Well, let us wait for reactions from others, because I currently still > think that separate namespaces for separate translations makes a whole > lot of sense, organizationally, politically, and technically. If we dont > do that, then every new translation has to watch out for name collision > with every other language now and in the future! Well, I'd argue that it should only worry about it for the set of guidelines from which it derives (and that version number should be stored). The guidelines for renaming should state that you can't rename something to an existing name in another module (or translation?) I suppose translation namespaces would solve this problem. :-( > I am less sure about > individual renamings, but still feel that basically if you don't use the > names we have chosen for our elements, whether or not you make explicit > the relationship between your name and ours, you are polluting the TEI > namespace. And you have all the headaches about name collision. And my > dimwitted TEI application has to go and read the ODD every time it > processes a document to know what to do with your renaming. Or you need to interchange your documents in TEI Interchange Format where these renamings should have been un-done? > I'm happy with the concept of a renaming subset schema. I just think it > ought to use a different namespace for the renamed elements. I suppose I could be convinced of this, but it certainly wasn't the way I had envisioned it. >> I think clean should include reversal of renamings, and that translations >> are just a specialised form of renamings. > I think adding this level of complexity may be just a level too far for > many simple-minded processors. But, as I said, let's wait to see what > others think. I'll be interested to hear what other council members think as well. -James >>> Comments? Alternative proposals? >> >> Alternative proposal: >> 1. Entirely new elements should be in a new namespace > yes > >> 2. Renamed elements, properly documented should remain in TEI namespace > no > >> 3. Translations are just a form of renaming. > yes, except that they are systematic > >> 4. Adding new (namespaced) attributes to a TEI element, does not stop >> that >> TEI element being TEI. > yes > >> 5. Our definition of 'clean' modification should include renamings. >> > > no! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From dporter at uky.edu Tue Apr 10 08:57:24 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 10 Apr 2007 08:57:24 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B854B.60704@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> Message-ID: <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> I also agree with James on points 1, 2, and 3. I'm on the fence on point 4 - whether renamed elements should be in a different namespace - but I think Lou makes a very good point about name collision which has me leaning towards renaming = different namespace. It's a little more work up front, perhaps, but would save a lot of headache in the long run. Dot On 4/10/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> wrote: > James Cummings wrote: > > Lou Burnard wrote: > >> Inter alia, and as a straw man, I'd like to propose for discussion the > >> following draconian rules about the use of namespaces in modification: > >> > >> 1. New elements may not be placed in the TEI namespace > > > > I can agree with that, though we may disagree on what is a 'new' element. > > By "new" I mean an element not already defined by the Guidelines. What > fiendishly cunning other case do you have in mind Dr Cummings? > > > > >> 2. If new attributes are added to a TEI element, the resulting element > >> must be moved out of the TEI namespace. > > > > I'm not convinced by that. If I add a new attribute to a TEI element, the > > TEI element is still a TEI element. It just has a new attribute and that > > attribute is signalled as not being part of the TEI by itself being in a > > different namespace. my:newAtt="foo". I don't see that the element is now > > so changed that it is no longer the TEI element. > > > OK, this is a plausible argument and I am disposed to agree with you. > > > > >> 3. Only modified elements which have undergone a clean modification [1] > >> may remain in the TEI namespace. > > > > Agreed, but I think adding an attribute which is in a different namespace > > is a clean modification. > > Yes, though only if I agree with you on (2) above. > > You are right that changed content models, etc. > > are dirty changes. However, if the change is to remove an element from > > some classes, or limit an open attribute value list, or anything similar > > which constrains it, then that is a clean modification because the TEI > > content still validates against tei_all. > > > > Yes. The draft does try to make this distinction clear. > > > >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, > >> except that TEI namespaces are defined for systematic renaming of TEI > >> elements into different languages. > > > > I'm still not convinced that TEI translations need separate namespaces. > > Well, let us wait for reactions from others, because I currently still > think that separate namespaces for separate translations makes a whole > lot of sense, organizationally, politically, and technically. If we dont > do that, then every new translation has to watch out for name collision > with every other language now and in the future! I am less sure about > individual renamings, but still feel that basically if you don't use the > names we have chosen for our elements, whether or not you make explicit > the relationship between your name and ours, you are polluting the TEI > namespace. And you have all the headaches about name collision. And my > dimwitted TEI application has to go and read the ODD every time it > processes a document to know what to do with your renaming. > > > > > They should be conformant according to the Renaming Subset schema. If > > something is simply a renamed element/attribute and it otherwise is > > identical to the TEI original (and documented with ODD/equiv) then I do not > > feel it needs to be in a different namespace. It is, for all intents and > > purposes, the TEI element. If I have <div type="chapter"> and instead > > rename this <chapter> keeping everything else the same, does this really > > need a new namespace? The original view of the Renaming Subset was that it > > didn't. > > > I'm happy with the concept of a renaming subset schema. I just think it > ought to use a different namespace for the renamed elements. > > > > >> [1]A "clean" modification is defined in chapter MD as one which results > >> in a schema that matches a proper subset of the documents matched by an > >> unmodified schema. > > > > I think clean should include reversal of renamings, and that translations > > are just a specialised form of renamings. > > > > I think adding this level of complexity may be just a level too far for > many simple-minded processors. But, as I said, let's wait to see what > others think. > > > >> Comments? Alternative proposals? > > > > Alternative proposal: > > 1. Entirely new elements should be in a new namespace > yes > > > 2. Renamed elements, properly documented should remain in TEI namespace > no > > > 3. Translations are just a form of renaming. > yes, except that they are systematic > > > 4. Adding new (namespaced) attributes to a TEI element, does not stop that > > TEI element being TEI. > yes > > > 5. Our definition of 'clean' modification should include renamings. > > > > no! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From arianna.ciula at kcl.ac.uk Tue Apr 10 10:09:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 10 Apr 2007 15:09:43 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> Message-ID: <461B9AA7.5040107@kcl.ac.uk> Laurent Romary wrote: > I am completely in line with James on his arguments related to points 2 > and 3. The requirements that adding an attribute too an element > (especially an existing TEI attribute by the way) should force the > element to change namespace is slightly too strong. I agree with these points as well (2 and 3). I am not sure what to say about the translated element names though. It probably makes sense to have other TEI namespaces for those for pragmatical reasons as Lou suggested, even if, conceptually, I still think they are a sort of a priori approved renaming and therefore shouldn't be perceived as different from what is in the TEI namespace. Arianna > I am thinking of people who may want to add a simple type attribute to > an element and would not want to bother about namespaces though. > Laurent > > Le 10 avr. 07 ? 14:13, James Cummings a ?crit : > >> Lou Burnard wrote: >>> 2. If new attributes are added to a TEI element, the resulting element >>> must be moved out of the TEI namespace. >> >> I'm not convinced by that. If I add a new attribute to a TEI element, >> the >> TEI element is still a TEI element. It just has a new attribute and that >> attribute is signalled as not being part of the TEI by itself being in a >> different namespace. my:newAtt="foo". I don't see that the element >> is now >> so changed that it is no longer the TEI element. >> >>> 3. Only modified elements which have undergone a clean modification [1] >>> may remain in the TEI namespace. >> >> Agreed, but I think adding an attribute which is in a different namespace >> is a clean modification. You are right that changed content models, etc. >> are dirty changes. However, if the change is to remove an element from >> some classes, or limit an open attribute value list, or anything similar >> which constrains it, then that is a clean modification because the TEI >> content still validates against tei_all. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From laurent.romary at loria.fr Tue Apr 10 10:26:16 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 10 Apr 2007 16:26:16 +0200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461B9AA7.5040107@kcl.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <29D84E84-F900-4778-82AB-110B51C168BE@loria.fr> <461B9AA7.5040107@kcl.ac.uk> Message-ID: <42B07763-0BED-424E-8979-6073E2BB8421@loria.fr> I would support the idea to have translated elements in another namespace: they really represent a different "vocabulary" and as such should not interfere with the reference TEI one. Laurent Le 10 avr. 07 ? 16:09, Arianna Ciula a ?crit : > > > Laurent Romary wrote: >> I am completely in line with James on his arguments related to >> points 2 and 3. The requirements that adding an attribute too an >> element (especially an existing TEI attribute by the way) should >> force the element to change namespace is slightly too strong. > > I agree with these points as well (2 and 3). > I am not sure what to say about the translated element names > though. It probably makes sense to have other TEI namespaces for > those for pragmatical reasons as Lou suggested, even if, > conceptually, I still think they are a sort of a priori approved > renaming and therefore shouldn't be perceived as different from > what is in the TEI namespace. > > Arianna > >> I am thinking of people who may want to add a simple type >> attribute to an element and would not want to bother about >> namespaces though. >> Laurent >> Le 10 avr. 07 ? 14:13, James Cummings a ?crit : >>> Lou Burnard wrote: >>>> 2. If new attributes are added to a TEI element, the resulting >>>> element >>>> must be moved out of the TEI namespace. >>> >>> I'm not convinced by that. If I add a new attribute to a TEI >>> element, the >>> TEI element is still a TEI element. It just has a new attribute >>> and that >>> attribute is signalled as not being part of the TEI by itself >>> being in a >>> different namespace. my:newAtt="foo". I don't see that the >>> element is now >>> so changed that it is no longer the TEI element. >>> >>>> 3. Only modified elements which have undergone a clean >>>> modification [1] >>>> may remain in the TEI namespace. >>> >>> Agreed, but I think adding an attribute which is in a different >>> namespace >>> is a clean modification. You are right that changed content >>> models, etc. >>> are dirty changes. However, if the change is to remove an >>> element from >>> some classes, or limit an open attribute value list, or anything >>> similar >>> which constrains it, then that is a clean modification because >>> the TEI >>> content still validates against tei_all. >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Arianna Ciula > Research Associate > Centre for Computing in the Humanities > King's College London > Strand > London WC2R 2LS (UK) > Tel: +44 (0)20 78481945 > http://www.kcl.ac.uk/cch > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From djbpitt+tei at pitt.edu Tue Apr 10 10:44:38 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Tue, 10 Apr 2007 10:44:38 -0400 Subject: [tei-council] renaming and namespaces Message-ID: <461BA2D6.6070501@pitt.edu> Dear TEI Council, I'm also with Lou on the question of renaming. Since namespaces are intended to avoid collision and renaming can create collision, it would seem wisest not to put renamed elements in the tei namespace. Best, David Dot Porter wrote: > I also agree with James on points 1, 2, and 3. I'm on the fence on > point 4 - whether renamed elements should be in a different namespace > - but I think Lou makes a very good point about name collision which > has me leaning towards renaming = different namespace. It's a little > more work up front, perhaps, but would save a lot of headache in the > long run. > > Dot > > On 4/10/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> > wrote: >> James Cummings wrote: >> > Lou Burnard wrote: >> >> Inter alia, and as a straw man, I'd like to propose for discussion >> the >> >> following draconian rules about the use of namespaces in >> modification: >> >> >> >> 1. New elements may not be placed in the TEI namespace >> > >> > I can agree with that, though we may disagree on what is a 'new' >> element. >> >> By "new" I mean an element not already defined by the Guidelines. What >> fiendishly cunning other case do you have in mind Dr Cummings? >> >> > >> >> 2. If new attributes are added to a TEI element, the resulting >> element >> >> must be moved out of the TEI namespace. >> > >> > I'm not convinced by that. If I add a new attribute to a TEI >> element, the >> > TEI element is still a TEI element. It just has a new attribute >> and that >> > attribute is signalled as not being part of the TEI by itself being >> in a >> > different namespace. my:newAtt="foo". I don't see that the >> element is now >> > so changed that it is no longer the TEI element. >> >> >> OK, this is a plausible argument and I am disposed to agree with you. >> >> > >> >> 3. Only modified elements which have undergone a clean >> modification [1] >> >> may remain in the TEI namespace. >> > >> > Agreed, but I think adding an attribute which is in a different >> namespace >> > is a clean modification. >> >> Yes, though only if I agree with you on (2) above. >> >> You are right that changed content models, etc. >> > are dirty changes. However, if the change is to remove an element >> from >> > some classes, or limit an open attribute value list, or anything >> similar >> > which constrains it, then that is a clean modification because the TEI >> > content still validates against tei_all. >> > >> >> Yes. The draft does try to make this distinction clear. >> >> >> >> 4. If a TEI element is renamed, it may not remain in the TEI >> namespace, >> >> except that TEI namespaces are defined for systematic renaming of TEI >> >> elements into different languages. >> > >> > I'm still not convinced that TEI translations need separate >> namespaces. >> >> Well, let us wait for reactions from others, because I currently still >> think that separate namespaces for separate translations makes a whole >> lot of sense, organizationally, politically, and technically. If we dont >> do that, then every new translation has to watch out for name collision >> with every other language now and in the future! I am less sure about >> individual renamings, but still feel that basically if you don't use the >> names we have chosen for our elements, whether or not you make explicit >> the relationship between your name and ours, you are polluting the TEI >> namespace. And you have all the headaches about name collision. And my >> dimwitted TEI application has to go and read the ODD every time it >> processes a document to know what to do with your renaming. >> >> >> >> > They should be conformant according to the Renaming Subset schema. If >> > something is simply a renamed element/attribute and it otherwise is >> > identical to the TEI original (and documented with ODD/equiv) then >> I do not >> > feel it needs to be in a different namespace. It is, for all >> intents and >> > purposes, the TEI element. If I have <div type="chapter"> and instead >> > rename this <chapter> keeping everything else the same, does this >> really >> > need a new namespace? The original view of the Renaming Subset was >> that it >> > didn't. >> >> >> I'm happy with the concept of a renaming subset schema. I just think it >> ought to use a different namespace for the renamed elements. >> >> > >> >> [1]A "clean" modification is defined in chapter MD as one which >> results >> >> in a schema that matches a proper subset of the documents matched >> by an >> >> unmodified schema. >> > >> > I think clean should include reversal of renamings, and that >> translations >> > are just a specialised form of renamings. >> > >> >> I think adding this level of complexity may be just a level too far for >> many simple-minded processors. But, as I said, let's wait to see what >> others think. >> >> >> >> Comments? Alternative proposals? >> > >> > Alternative proposal: >> > 1. Entirely new elements should be in a new namespace >> yes >> >> > 2. Renamed elements, properly documented should remain in TEI >> namespace >> no >> >> > 3. Translations are just a form of renaming. >> yes, except that they are systematic >> >> > 4. Adding new (namespaced) attributes to a TEI element, does not >> stop that >> > TEI element being TEI. >> yes >> >> > 5. Our definition of 'clean' modification should include renamings. >> > >> >> no! >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > From daniel.odonnell at uleth.ca Tue Apr 10 11:02:10 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 10 Apr 2007 09:02:10 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> Message-ID: <1176217330.21190.40.camel@odonned-eng06> It seems to me that we can refine the set of principles: 1. New elements may not be placed in the TEI namespace. 3. Only modified elements which have undergone a clean modification may remain in the TEI namespace. The addition of attributes to a TEI element is clean as long as the new attribute itself is identified as coming from a different namespace. 4. Official translations have their own TEI namespace as long as they represent a 1:1 translation of the entire standard and remain up-to-date. Like everybody else, I'm having trouble with simple project-based renamings, since they can remain in the TEI namespace under principle 3. The same is also true of translations if you see them as being in essence renamings (about which more below), since they should also be clean--though I can see the practical and political argument in favour of using distinct (sub) namespaces for official translations as long as they reflect a complete, up-to-date, and 1:1 translation of the standard. I think my own leaning is that the clean modification principle 3 is key. The use of the TEI namespace says: "I am identical to or have been cleanly modified from the TEI standard; you can process me with the assurance that you understand what I am"--i.e. the question of whether something stays in the namespace is not only a negative decision identifying elements that have diverged from the standard, but a positive one identifying elements that have not. So under this, cleanly renamed elements would remain in the namespace, even if that adds a processing cost in figuring out what they are an alias of. Of course the addition of a processing cost is an argument against renaming elements for interchange that projects might want to pay attention to. Avoiding conflicts is the responsibility of the renamer, and a conflicting name is not a clean modification IMO (except for translations of the entire standard, see below). If we take the view that the TEI namespace is a positive assertion, then translations are a bit of an issue: presumably they are by definition clean modifications (except that unlike modifications of individual elements, there is always the possibility that individual translated elements might conflict with English language ones), in which case they should under principle 3 be in the TEI namespace. We don't want translations by implication or practice to be or be seen as substantively different from the standard in anyway. Perhaps the way to see this is that "renaming" and "translation" are not exactly the same thing: a "renaming" may involve less than all the element names and may occur with other extensions and additions; a "translation" involves the entire standard and may not involve other additions and extensions. Renamed elements remain in the TEI space from which they have been renamed; translations are given a (sub) TEI namespace of their own to indicate that they are 1:1 but may have name conflicts with the standard names. Individuals and projects can rename, extend, or otherwise modify translations, subject to the same rules about names spaces that apply to modifications of the standard as long as we replace "tei namespace" with the name of the specific translation. Finally a question: what happens if I extend a tei attribute to a new element (or make it global). In this case it seems to me that the "extended" attributes have to go in a different namespace; but I'm not sure about the "original" tei:namespaced attributes: presumably I'm extending the element because I want additional elements to share the attribute with original tei elements. I'm leaning towards saying that the "original" tei attribute has also changed in this case. Or in other words: if I make @type global, I am actually removing tei:type from the elements on which it is found and replacing it with mynamespace:type throughout the whole tei. -dan On Tue, 2007-10-04 at 08:57 -0400, Dot Porter wrote: > I also agree with James on points 1, 2, and 3. I'm on the fence on > point 4 - whether renamed elements should be in a different namespace > - but I think Lou makes a very good point about name collision which > has me leaning towards renaming = different namespace. It's a little > more work up front, perhaps, but would save a lot of headache in the > long run. > > Dot > > On 4/10/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> wrote: > > James Cummings wrote: > > > Lou Burnard wrote: > > >> Inter alia, and as a straw man, I'd like to propose for discussion the > > >> following draconian rules about the use of namespaces in modification: > > >> > > >> 1. New elements may not be placed in the TEI namespace > > > > > > I can agree with that, though we may disagree on what is a 'new' element. > > > > By "new" I mean an element not already defined by the Guidelines. What > > fiendishly cunning other case do you have in mind Dr Cummings? > > > > > > > >> 2. If new attributes are added to a TEI element, the resulting element > > >> must be moved out of the TEI namespace. > > > > > > I'm not convinced by that. If I add a new attribute to a TEI element, the > > > TEI element is still a TEI element. It just has a new attribute and that > > > attribute is signalled as not being part of the TEI by itself being in a > > > different namespace. my:newAtt="foo". I don't see that the element is now > > > so changed that it is no longer the TEI element. > > > > > > OK, this is a plausible argument and I am disposed to agree with you. > > > > > > > >> 3. Only modified elements which have undergone a clean modification [1] > > >> may remain in the TEI namespace. > > > > > > Agreed, but I think adding an attribute which is in a different namespace > > > is a clean modification. > > > > Yes, though only if I agree with you on (2) above. > > > > You are right that changed content models, etc. > > > are dirty changes. However, if the change is to remove an element from > > > some classes, or limit an open attribute value list, or anything similar > > > which constrains it, then that is a clean modification because the TEI > > > content still validates against tei_all. > > > > > > > Yes. The draft does try to make this distinction clear. > > > > > > >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, > > >> except that TEI namespaces are defined for systematic renaming of TEI > > >> elements into different languages. > > > > > > I'm still not convinced that TEI translations need separate namespaces. > > > > Well, let us wait for reactions from others, because I currently still > > think that separate namespaces for separate translations makes a whole > > lot of sense, organizationally, politically, and technically. If we dont > > do that, then every new translation has to watch out for name collision > > with every other language now and in the future! I am less sure about > > individual renamings, but still feel that basically if you don't use the > > names we have chosen for our elements, whether or not you make explicit > > the relationship between your name and ours, you are polluting the TEI > > namespace. And you have all the headaches about name collision. And my > > dimwitted TEI application has to go and read the ODD every time it > > processes a document to know what to do with your renaming. > > > > > > > > > They should be conformant according to the Renaming Subset schema. If > > > something is simply a renamed element/attribute and it otherwise is > > > identical to the TEI original (and documented with ODD/equiv) then I do not > > > feel it needs to be in a different namespace. It is, for all intents and > > > purposes, the TEI element. If I have <div type="chapter"> and instead > > > rename this <chapter> keeping everything else the same, does this really > > > need a new namespace? The original view of the Renaming Subset was that it > > > didn't. > > > > > > I'm happy with the concept of a renaming subset schema. I just think it > > ought to use a different namespace for the renamed elements. > > > > > > > >> [1]A "clean" modification is defined in chapter MD as one which results > > >> in a schema that matches a proper subset of the documents matched by an > > >> unmodified schema. > > > > > > I think clean should include reversal of renamings, and that translations > > > are just a specialised form of renamings. > > > > > > > I think adding this level of complexity may be just a level too far for > > many simple-minded processors. But, as I said, let's wait to see what > > others think. > > > > > > >> Comments? Alternative proposals? > > > > > > Alternative proposal: > > > 1. Entirely new elements should be in a new namespace > > yes > > > > > 2. Renamed elements, properly documented should remain in TEI namespace > > no > > > > > 3. Translations are just a form of renaming. > > yes, except that they are systematic > > > > > 4. Adding new (namespaced) attributes to a TEI element, does not stop that > > > TEI element being TEI. > > yes > > > > > 5. Our definition of 'clean' modification should include renamings. > > > > > > > no! > > > > > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Tue Apr 10 11:12:19 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 10 Apr 2007 16:12:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> Message-ID: <461BA953.5070003@oucs.ox.ac.uk> Dan O'Donnell wrote: > Finally a question: what happens if I extend a tei attribute to a new > element (or make it global). > That's an unclean modification -- the set of documents matched by the extended schema is not a pure subset of the set of documents matched by the unextended one -- ergo you must put a namespace on something, presumably the attribute you've now defined as global. From daniel.odonnell at uleth.ca Tue Apr 10 11:26:33 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Tue, 10 Apr 2007 09:26:33 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461BA953.5070003@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461BA953.5070003@oucs.ox.ac.uk> Message-ID: <1176218793.24696.10.camel@odonned-eng06> On Tue, 2007-10-04 at 16:12 +0100, Lou Burnard wrote: > Dan O'Donnell wrote: > > > Finally a question: what happens if I extend a tei attribute to a new > > element (or make it global). > > > > That's an unclean modification -- the set of documents matched by the > extended schema is not a pure subset of the set of documents matched by > the unextended one -- ergo you must put a namespace on something, > presumably the attribute you've now defined as global. Thanks. That's the solution I slouched towards myself. > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From Conal.Tuohy at vuw.ac.nz Tue Apr 10 16:43:33 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 11 Apr 2007 08:43:33 +1200 Subject: [tei-council] MD chapter revised: namespace rules References: <461AA00E.50405@computing-services.oxford.ac.uk><461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D7C@STAWINCOMAILCL1.staff.vuw.ac.nz> For the record I am with Lou 100%. I think TEI-processing software can safely ignore attributes which it does not understand. Regarding translation and renaming in general, it's clear to me that a new namespace must be used whenever a name is changed, for whatever reason. Otherwise I will change <text> to <chapter> and you will change <div> to <chapter>, and we will have the potential for confusion. Or 2 languages will have the same word meaning 2 different things, and again we have a confusion. On a positive note, distinct XML namespaces should actually help to clarify the distinction between the distinct vocabularies, and allow for simple transformation mechanisms (for canonicalisation into TEI interchange form). Con -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Dot Porter Sent: Wed 11/04/07 0:57 To: Lou Burnard Cc: TEI Council; James.Cummings at oucs.ox.ac.uk Subject: Re: [tei-council] MD chapter revised: namespace rules I also agree with James on points 1, 2, and 3. I'm on the fence on point 4 - whether renamed elements should be in a different namespace - but I think Lou makes a very good point about name collision which has me leaning towards renaming = different namespace. It's a little more work up front, perhaps, but would save a lot of headache in the long run. Dot On 4/10/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> wrote: > James Cummings wrote: > > Lou Burnard wrote: > >> Inter alia, and as a straw man, I'd like to propose for discussion the > >> following draconian rules about the use of namespaces in modification: > >> > >> 1. New elements may not be placed in the TEI namespace > > > > I can agree with that, though we may disagree on what is a 'new' element. > > By "new" I mean an element not already defined by the Guidelines. What > fiendishly cunning other case do you have in mind Dr Cummings? > > > > >> 2. If new attributes are added to a TEI element, the resulting element > >> must be moved out of the TEI namespace. > > > > I'm not convinced by that. If I add a new attribute to a TEI element, the > > TEI element is still a TEI element. It just has a new attribute and that > > attribute is signalled as not being part of the TEI by itself being in a > > different namespace. my:newAtt="foo". I don't see that the element is now > > so changed that it is no longer the TEI element. > > > OK, this is a plausible argument and I am disposed to agree with you. > > > > >> 3. Only modified elements which have undergone a clean modification [1] > >> may remain in the TEI namespace. > > > > Agreed, but I think adding an attribute which is in a different namespace > > is a clean modification. > > Yes, though only if I agree with you on (2) above. > > You are right that changed content models, etc. > > are dirty changes. However, if the change is to remove an element from > > some classes, or limit an open attribute value list, or anything similar > > which constrains it, then that is a clean modification because the TEI > > content still validates against tei_all. > > > > Yes. The draft does try to make this distinction clear. > > > >> 4. If a TEI element is renamed, it may not remain in the TEI namespace, > >> except that TEI namespaces are defined for systematic renaming of TEI > >> elements into different languages. > > > > I'm still not convinced that TEI translations need separate namespaces. > > Well, let us wait for reactions from others, because I currently still > think that separate namespaces for separate translations makes a whole > lot of sense, organizationally, politically, and technically. If we dont > do that, then every new translation has to watch out for name collision > with every other language now and in the future! I am less sure about > individual renamings, but still feel that basically if you don't use the > names we have chosen for our elements, whether or not you make explicit > the relationship between your name and ours, you are polluting the TEI > namespace. And you have all the headaches about name collision. And my > dimwitted TEI application has to go and read the ODD every time it > processes a document to know what to do with your renaming. > > > > > They should be conformant according to the Renaming Subset schema. If > > something is simply a renamed element/attribute and it otherwise is > > identical to the TEI original (and documented with ODD/equiv) then I do not > > feel it needs to be in a different namespace. It is, for all intents and > > purposes, the TEI element. If I have <div type="chapter"> and instead > > rename this <chapter> keeping everything else the same, does this really > > need a new namespace? The original view of the Renaming Subset was that it > > didn't. > > > I'm happy with the concept of a renaming subset schema. I just think it > ought to use a different namespace for the renamed elements. > > > > >> [1]A "clean" modification is defined in chapter MD as one which results > >> in a schema that matches a proper subset of the documents matched by an > >> unmodified schema. > > > > I think clean should include reversal of renamings, and that translations > > are just a specialised form of renamings. > > > > I think adding this level of complexity may be just a level too far for > many simple-minded processors. But, as I said, let's wait to see what > others think. > > > >> Comments? Alternative proposals? > > > > Alternative proposal: > > 1. Entirely new elements should be in a new namespace > yes > > > 2. Renamed elements, properly documented should remain in TEI namespace > no > > > 3. Translations are just a form of renaming. > yes, except that they are systematic > > > 4. Adding new (namespaced) attributes to a TEI element, does not stop that > > TEI element being TEI. > yes > > > 5. Our definition of 'clean' modification should include renamings. > > > > no! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From cwittern at gmail.com Tue Apr 10 21:13:18 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 11 Apr 2007 10:13:18 +0900 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> Message-ID: <461C362E.2010704@gmail.com> Dan O'Donnell wrote: > It seems to me that we can refine the set of principles: > > 1. New elements may not be placed in the TEI namespace. > 3. Only modified elements which have undergone a clean modification may > remain in the TEI namespace. The addition of attributes to a TEI element > is clean as long as the new attribute itself is identified as coming > from a different namespace. > 4. Official translations have their own TEI namespace as long as they > represent a 1:1 translation of the entire standard and remain > up-to-date. > > This is what I would agree to as well. > Like everybody else, I'm having trouble with simple project-based > renamings, since they can remain in the TEI namespace under principle 3. > I do not have a problem here. For interchange, it would be a matter of courtesy to restore the original TEI form. > The same is also true of translations if you see them as being in > essence renamings (about which more below), since they should also be > clean--though I can see the practical and political argument in favour > of using distinct (sub) namespaces for official translations as long as > they reflect a complete, up-to-date, and 1:1 translation of the > standard. > It might be better just to indicate the "valid as of" date. > I think my own leaning is that the clean modification principle 3 is > key. The use of the TEI namespace says: "I am identical to or have been > cleanly modified from the TEI standard; you can process me with the > assurance that you understand what I am"--i.e. the question of whether > something stays in the namespace is not only a negative decision > identifying elements that have diverged from the standard, but a > positive one identifying elements that have not. So under this, cleanly > renamed elements would remain in the namespace, even if that adds a > processing cost in figuring out what they are an alias of. Of course the > addition of a processing cost is an argument against renaming elements > for interchange that projects might want to pay attention to. Avoiding > conflicts is the responsibility of the renamer, and a conflicting name > is not a clean modification IMO (except for translations of the entire > standard, see below). > > If we take the view that the TEI namespace is a positive assertion, then > translations are a bit of an issue: presumably they are by definition > clean modifications (except that unlike modifications of individual > elements, there is always the possibility that individual translated > elements might conflict with English language ones), in which case they > should under principle 3 be in the TEI namespace. Translations *are* in a TEI namespace, just a different one from the canonical TEI. All the best, Christian From conal.tuohy at vuw.ac.nz Tue Apr 10 21:39:28 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 11 Apr 2007 13:39:28 +1200 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176217330.21190.40.camel@odonned-eng06> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> Message-ID: <1176255568.3766.333.camel@localhost> On Tue, 2007-04-10 at 09:02 -0600, Dan O'Donnell wrote: > The use of the TEI namespace says: "I am identical to or have been > cleanly modified from the TEI standard; you can process me with the > assurance that you understand what I am"--i.e. the question of whether > something stays in the namespace is not only a negative decision > identifying elements that have diverged from the standard, but a > positive one identifying elements that have not. So under this, cleanly > renamed elements would remain in the namespace, even if that adds a > processing cost in figuring out what they are an alias of. I don't think this can work, really. IMHO if an element is renamed, it MUST go into a different namespace. Remember, the namespace URI is an identifier for a vocabulary. If you rename a TEI element, e.g. renaming <div> to <chapter>, then you are using a different vocabulary from the TEI standard, and you should use a different namespace URI. Otherwise, if I rename <text> to <chapter>, how can we tell whether your <chapter> and my <chapter> elements are the same? > If we take the view that the TEI namespace is a positive assertion, then > translations are a bit of an issue: presumably they are by definition > clean modifications (except that unlike modifications of individual > elements, there is always the possibility that individual translated > elements might conflict with English language ones) Indeed there would be that possibility, because the English-based TEI vocabulary and the other non-English TEI translations are by definition different vocabularies. But we simply must not allow this possibility - we mustn't define a namespace in which names are ambiguous. Hence we must have distinct namespaces for the localised TEI tagsets. > , in which case they > should under principle 3 be in the TEI namespace. We don't want > translations by implication or practice to be or be seen as > substantively different from the standard in anyway. I suggest that we need to "bite the bullet" and define official TEI namespaces for all the translated versions. Con From daniel.odonnell at uleth.ca Tue Apr 10 22:54:38 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 10 Apr 2007 20:54:38 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176255568.3766.333.camel@localhost> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <1176255568.3766.333.camel@localhost> Message-ID: <1176260078.6262.3.camel@localhost> Good enough. I don't feel it strongly and the renamed elements are the only ones that I thought might be in the same space. But then we need to redefine the principle. It is not "clean" but not change for element names that we allow in the same namespace then? On Wed, 2007-04-11 at 13:39 +1200, Conal Tuohy wrote: > On Tue, 2007-04-10 at 09:02 -0600, Dan O'Donnell wrote: > > > The use of the TEI namespace says: "I am identical to or have been > > cleanly modified from the TEI standard; you can process me with the > > assurance that you understand what I am"--i.e. the question of whether > > something stays in the namespace is not only a negative decision > > identifying elements that have diverged from the standard, but a > > positive one identifying elements that have not. So under this, cleanly > > renamed elements would remain in the namespace, even if that adds a > > processing cost in figuring out what they are an alias of. > > I don't think this can work, really. IMHO if an element is renamed, it > MUST go into a different namespace. Remember, the namespace URI is an > identifier for a vocabulary. If you rename a TEI element, e.g. renaming > <div> to <chapter>, then you are using a different vocabulary from the > TEI standard, and you should use a different namespace URI. Otherwise, > if I rename <text> to <chapter>, how can we tell whether your <chapter> > and my <chapter> elements are the same? > > > If we take the view that the TEI namespace is a positive assertion, then > > translations are a bit of an issue: presumably they are by definition > > clean modifications (except that unlike modifications of individual > > elements, there is always the possibility that individual translated > > elements might conflict with English language ones) > > Indeed there would be that possibility, because the English-based TEI > vocabulary and the other non-English TEI translations are by definition > different vocabularies. But we simply must not allow this possibility - > we mustn't define a namespace in which names are ambiguous. Hence we > must have distinct namespaces for the localised TEI tagsets. > > > , in which case they > > should under principle 3 be in the TEI namespace. We don't want > > translations by implication or practice to be or be seen as > > substantively different from the standard in anyway. > > I suggest that we need to "bite the bullet" and define official TEI > namespaces for all the translated versions. > > Con -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 05:00:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 10:00:10 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461C362E.2010704@gmail.com> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> Message-ID: <461CA39A.806@oucs.ox.ac.uk> Wittern Christian wrote: > Dan O'Donnell wrote: >> It seems to me that we can refine the set of principles: >> >> 1. New elements may not be placed in the TEI namespace. >> 3. Only modified elements which have undergone a clean modification may >> remain in the TEI namespace. The addition of attributes to a TEI element >> is clean as long as the new attribute itself is identified as coming >> from a different namespace. >> 4. Official translations have their own TEI namespace as long as they >> represent a 1:1 translation of the entire standard and remain >> up-to-date. >> >> > This is what I would agree to as well. > >> Like everybody else, I'm having trouble with simple project-based >> renamings, since they can remain in the TEI namespace under principle 3. >> > I think there's a misunderstanding here. Renaming an element is *not* a clean modification, since the set of documents now regarded as valid is not a pure subset of the documents regarded as valid before the modification. From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 05:05:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 10:05:57 +0100 Subject: [tei-council] TRAC system down Message-ID: <461CA4F5.8020602@oucs.ox.ac.uk> Apologies for the inconvenience, but the machine tei.oucs.ox.ac.uk is currently feeling a bit peaky. This means that Roma, Trac, and TEI-at-Oxford are all inaccessible until I find out what's wrong. From James.Cummings at computing-services.oxford.ac.uk Wed Apr 11 06:37:27 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 11 Apr 2007 11:37:27 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CA39A.806@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> Message-ID: <461CBA67.6050105@computing-services.oxford.ac.uk> Lou Burnard wrote: > Wittern Christian wrote: >>> Like everybody else, I'm having trouble with simple project-based >>> renamings, since they can remain in the TEI namespace under principle 3. > I think there's a misunderstanding here. Renaming an element is *not* a > clean modification, since the set of documents now regarded as valid is > not a pure subset of the documents regarded as valid before the > modification. I think this misunderstanding arises from my proposal... I was suggesting that TEI Conformant documents could have renamings in the TEI namespace, as long as they could be reverted according to the information in the referenced ODD. And then TEI Interchange Format would insist that any such renamings be reverted before interchange. However, it seems like a majority of people now do not see renamings as a clean modification, so renamings must then appear in a new namespace. So: 1) Any new element must be in user-defined namespace (UDN) 2) Any new attribute must be in UDN 3) If you make a dirty (i.e. non-subsetting) change to an element it must move to a UDN (and possibly be renamed) 4) If you make a dirty change to an attribute it must move to a UDN (and possibly be renamed) 5) The only changes to elements or attributes which do not result in them being moved to a UDN are subsetting changes. That is, changes with further restrict content models, attribute value lists, or datatypes, in such a manner that a document which validates against this schema also continues to validate against tei_all. Is that a fair summary? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 07:19:07 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 12:19:07 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CBA67.6050105@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> Message-ID: <461CC42B.8050200@oucs.ox.ac.uk> James Cummings wrote: > Lou Burnard wrote: >> Wittern Christian wrote: >>>> Like everybody else, I'm having trouble with simple project-based >>>> renamings, since they can remain in the TEI namespace under principle 3. >> I think there's a misunderstanding here. Renaming an element is *not* a >> clean modification, since the set of documents now regarded as valid is >> not a pure subset of the documents regarded as valid before the >> modification. > > > I think this misunderstanding arises from my proposal... > > I was suggesting that TEI Conformant documents could have renamings in the > TEI namespace, as long as they could be reverted according to the > information in the referenced ODD. And then TEI Interchange Format would > insist that any such renamings be reverted before interchange. > > However, it seems like a majority of people now do not see renamings as a > clean modification, so renamings must then appear in a new namespace. > > So: > 1) Any new element must be in user-defined namespace (UDN) > 2) Any new attribute must be in UDN > 3) If you make a dirty (i.e. non-subsetting) change to an element it must > move to a UDN (and possibly be renamed) > 4) If you make a dirty change to an attribute it must move to a UDN (and > possibly be renamed) > 5) The only changes to elements or attributes which do not result in them > being moved to a UDN are subsetting changes. That is, changes with further > restrict content models, attribute value lists, or datatypes, in such a > manner that a document which validates against this schema also continues > to validate against tei_all. > > Is that a fair summary? > > -James > tick. vg. From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 07:20:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 12:20:41 +0100 Subject: [tei-council] TRAC system down In-Reply-To: <461CA4F5.8020602@oucs.ox.ac.uk> References: <461CA4F5.8020602@oucs.ox.ac.uk> Message-ID: <461CC489.1080501@oucs.ox.ac.uk> All systems are back now. Apologies for the interruption to service. L Lou Burnard wrote: > Apologies for the inconvenience, but the machine tei.oucs.ox.ac.uk is > currently feeling a bit peaky. This means that Roma, Trac, and > TEI-at-Oxford are all inaccessible until I find out what's wrong. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From daniel.odonnell at uleth.ca Wed Apr 11 10:54:09 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 08:54:09 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461CBA67.6050105@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> Message-ID: <1176303249.4952.3.camel@caedmon> On Wed, 2007-04-11 at 11:37 +0100, James Cummings wrote: > Lou Burnard wrote: > > Wittern Christian wrote: > >>> Like everybody else, I'm having trouble with simple project-based > >>> renamings, since they can remain in the TEI namespace under principle 3. > > I think there's a misunderstanding here. Renaming an element is *not* a > > clean modification, since the set of documents now regarded as valid is > > not a pure subset of the documents regarded as valid before the > > modification. > > > I think this misunderstanding arises from my proposal... Oh good--it's not just me. > > I was suggesting that TEI Conformant documents could have renamings in the > TEI namespace, as long as they could be reverted according to the > information in the referenced ODD. And then TEI Interchange Format would > insist that any such renamings be reverted before interchange. This is what I understood as well. > > However, it seems like a majority of people now do not see renamings as a > clean modification, so renamings must then appear in a new namespace. The only issue I have with that is that it seems to vitiate any reason for following canonical methods of altering or renaming elements. It seems to me that your original explanation in the paragraph above represents a case where people are working "within" the TEI. If the ODD references the changes and they are reverted before interchange, then it seems to me that non-conflicting renamings are suitable for remaining in the namespace of the version or translation to which they belong. -dan > > So: > 1) Any new element must be in user-defined namespace (UDN) > 2) Any new attribute must be in UDN > 3) If you make a dirty (i.e. non-subsetting) change to an element it must > move to a UDN (and possibly be renamed) > 4) If you make a dirty change to an attribute it must move to a UDN (and > possibly be renamed) > 5) The only changes to elements or attributes which do not result in them > being moved to a UDN are subsetting changes. That is, changes with further > restrict content models, attribute value lists, or datatypes, in such a > manner that a document which validates against this schema also continues > to validate against tei_all. > > Is that a fair summary? > > -James > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 11:46:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 16:46:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176303249.4952.3.camel@caedmon> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> Message-ID: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20070411/8591b685/attachment.ksh From James.Cummings at oucs.ox.ac.uk Wed Apr 11 12:30:19 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Apr 2007 17:30:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> Message-ID: <461D0D1B.8000204@oucs.ox.ac.uk> Lou Burnard wrote: > In message <1176303249.4952.3.camel at caedmon> daniel.odonnell at uleth.ca writes: >>> I was suggesting that TEI Conformant documents could have renamings in the >>> TEI namespace, as long as they could be reverted according to the >>> information in the referenced ODD. And then TEI Interchange Format would >>> insist that any such renamings be reverted before interchange. >> This is what I understood as well. > OK, it's time to get radical. What do we need "TEI Interchange format" for? Why > do we need to define it at all? > > TEI-conformant documents must be valid XML and must have an ODD. Why do we need > to go beyond that? > > So far after much scratching of heads, I don't think I have come up with any > need for the concept beyond the possibility of non-TEI names cluttering up the > namespace (which I also think we have now agreed to get rid of). In my mind it was solely there to insist on TEI Pure Subset versions of documents for interchange. I.e. to revert all renamings etc. I suppose that idea still *could* have some small merit, in that if I have renamed tei:div[@type='chapter'] to my:chapter then in a TEI Interchange Format it would, one assume be renamed back. This is why I never viewed renaming changes as being as dirty as content model changes...there was always a possibility of them being switched back. Once you change the content model you can't really do that in most cases. Does that mean those documents should never be interchanged? No, of course not. Thus, TEI Interchange Format really becomes meaningless, just another way to say TEI Pure Subset. > The keen eyed readers amongst you will have noticed that chapter IN has now > disappeared from P5. I see no need to bring it back, since it is of purely > antiquarian interest. > > So, TEI Conformant documents are ipso facto in the interchange format. End of > story. We don't need to worry about non TEI conformant (but interchangeable) XML > documents. I think I can agree with that now. -James From laurent.romary at loria.fr Wed Apr 11 14:35:04 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 11 Apr 2007 20:35:04 +0200 Subject: [tei-council] DTD or schema Message-ID: <C2D97EDD-7E28-4737-AAEC-27CE21FB37D3@loria.fr> Hi all (editors?), A small and quick question: in the PD chapter I find the expression "in the following DTD fragment", which actually refers to a RelaxNG fragment. What wording should we use in the guidelines: - in the following schema fragment - in the following RelaxNG schema fragment - ... Laurent From laurent.romary at loria.fr Wed Apr 11 14:35:24 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 11 Apr 2007 20:35:24 +0200 Subject: [tei-council] DTD or schema Message-ID: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> Hi all (editors?), A small and quick question: in the PD chapter I find the expression "in the following DTD fragment", which actually refers to a RelaxNG fragment. What wording should we use in the guidelines: - in the following schema fragment - in the following RelaxNG schema fragment - ... Laurent From daniel.odonnell at uleth.ca Wed Apr 11 14:50:37 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 12:50:37 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461D0D1B.8000204@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <461D0D1B.8000204@oucs.ox.ac.uk> Message-ID: <1176317437.4952.18.camel@caedmon> On Wed, 2007-04-11 at 17:30 +0100, James Cummings wrote: > Lou Burnard wrote: > > In message <1176303249.4952.3.camel at caedmon> daniel.odonnell at uleth.ca writes: > >>> I was suggesting that TEI Conformant documents could have renamings in the > >>> TEI namespace, as long as they could be reverted according to the > >>> information in the referenced ODD. And then TEI Interchange Format would > >>> insist that any such renamings be reverted before interchange. > >> This is what I understood as well. > > OK, it's time to get radical. What do we need "TEI Interchange format" for? Why > > do we need to define it at all? > > > > TEI-conformant documents must be valid XML and must have an ODD. Why do we need > > to go beyond that? > > > > So far after much scratching of heads, I don't think I have come up with any > > need for the concept beyond the possibility of non-TEI names cluttering up the > > namespace (which I also think we have now agreed to get rid of). > > In my mind it was solely there to insist on TEI Pure Subset versions of > documents for interchange. I.e. to revert all renamings etc. > > I suppose that idea still *could* have some small merit, in that if I > have renamed tei:div[@type='chapter'] to my:chapter then in a TEI > Interchange Format it would, one assume be renamed back. This is why I > never viewed renaming changes as being as dirty as content model > changes...there was always a possibility of them being switched back. > Once you change the content model you can't really do that in most > cases. Does that mean those documents should never be interchanged? > No, of course not. Thus, TEI Interchange Format really becomes > meaningless, just another way to say TEI Pure Subset. > > > The keen eyed readers amongst you will have noticed that chapter IN has now > > disappeared from P5. I see no need to bring it back, since it is of purely > > antiquarian interest. > > > > So, TEI Conformant documents are ipso facto in the interchange format. End of > > story. We don't need to worry about non TEI conformant (but interchangeable) XML > > documents. > > I think I can agree with that now.\ My only question is why to we discuss renaming elements as distinct from just creating new ones at all then? I.e. why raise the possibility at all? It sounds like we now have the following principles: 1) Only official TEI subsets and translations or clean subsets thereof may use the official TEI namespaces 2) All new or renamed elements, attributes, or non-clean modifications of elements or attributes, must be in a user defined namespace. > > -James > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Wed Apr 11 15:04:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Apr 2007 15:04:09 -0400 Subject: [tei-council] DTD or schema In-Reply-To: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> References: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> Message-ID: <17949.12585.803142.804630@emt.wwp.brown.edu> > A small and quick question: in the PD chapter I find the expression > "in the following DTD fragment", which actually refers to a RelaxNG > fragment. What wording should we use in the guidelines: > - in the following schema fragment > - in the following RelaxNG schema fragment The latter is what we've been using. But in truth, at some point we need to go through and fix all the references to that schema language to "RELAX NG"[1]. Note ---- [1] I am pretty sure the correct name is "RELAX NG", even though quite a few people, including Eric van der Vlist and I, call it "Relax NG". But the authors of the language pretty consistently call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and ISO/IEC (it is becoming an international standard). From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:13:25 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:13:25 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <C2D97EDD-7E28-4737-AAEC-27CE21FB37D3@loria.fr> References: <C2D97EDD-7E28-4737-AAEC-27CE21FB37D3@loria.fr> Message-ID: <461D4165.6080804@computing-services.oxford.ac.uk> Laurent Romary wrote: > Hi all (editors?), > A small and quick question: in the PD chapter I find the expression > "in the following DTD fragment", which actually refers to a RelaxNG > fragment. What wording should we use in the guidelines: > - in the following schema fragment My preference would be for this. > - in the following RelaxNG schema fragment The trouble is that it is actually a Relax NG schema fragment in compact syntax notation, which is a bit of a mouthful. > - ... > Laurent > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:19:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:19:49 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <17949.12585.803142.804630@emt.wwp.brown.edu> References: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> <17949.12585.803142.804630@emt.wwp.brown.edu> Message-ID: <461D42E5.5030009@computing-services.oxford.ac.uk> Syd Bauman wrote: > > ---- > [1] I am pretty sure the correct name is "RELAX NG", even though > quite a few people, including Eric van der Vlist and I, call it > "Relax NG". But the authors of the language pretty consistently > call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and > ISO/IEC (it is becoming an international standard). > > At http://www.relaxng.org/ it is "pretty consistently" called "RELAX NG". Also throughout the text of Eric van Vlist's book. So that's definitely what it should be, even though the lower casing does look sort of cute. And, btw, fwiw, it *is* an ISO standard isn't it (or at least a DIS)? 19757-2 From lou.burnard at computing-services.oxford.ac.uk Wed Apr 11 16:26:22 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 11 Apr 2007 21:26:22 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176317437.4952.18.camel@caedmon> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <461D0D1B.8000204@oucs.ox.ac.uk> <1176317437.4952.18.camel@caedmon> Message-ID: <461D446E.8060800@computing-services.oxford.ac.uk> Daniel O'Donnell wrote: > > My only question is why to we discuss renaming elements as distinct from > just creating new ones at all then? I.e. why raise the possibility at > all? Renaming, like translation, is a specific kind of user mod which may greatly improve usability for some applications. In TEI-Tite, for example, they have introduced lots of renaming mods of the kind <xx> which are defined as renamings for <hi rend="xx">. It seems helpful to identify this as a possibility which is not quite the same as *inventing* a tag <xx>, even though in conformance terms they are much of a muchness -- if only because, as James points out, it's a Simple Matter Of Programming to canonicalise the renaming. > 1) Only official TEI subsets and translations or clean subsets thereof > may use the official TEI namespaces > what exactly is an "official" TEI subset? I think you mean "only schemas derived from the TEI modules either without modification or using only "clean" modification" > 2) All new or renamed elements, attributes, or non-clean modifications > of elements or attributes, must be in a user defined namespace. > > that's about the size of it. From Syd_Bauman at Brown.edu Wed Apr 11 16:45:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 11 Apr 2007 16:45:04 -0400 Subject: [tei-council] DTD or schema In-Reply-To: <461D42E5.5030009@computing-services.oxford.ac.uk> References: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> <17949.12585.803142.804630@emt.wwp.brown.edu> <461D42E5.5030009@computing-services.oxford.ac.uk> Message-ID: <17949.18640.40107.20630@emt.wwp.brown.edu> > > - in the following schema fragment > My preference would be for this. And then we'd use the same phrase if it were a Schematron fragment? Sounds OK to me, actually, as the two don't look in the least alike. (And, as long as prefixes are used, wouldn't look alike even if we used the XML syntax.) > And, btw, fwiw, it *is* an ISO standard isn't it (or at least a > DIS)? 19757-2 Last I knew it was a DIS, but ... whadayaknow, I just checked, and yes, it is indeed now a full-fledged ISO standard (stage "60.60", aka "International Standard published"). And it has been so since early 2004 or so, which shows you how well I was paying attention! So if you want to spend just over USD 100, you can get your very own copy. From daniel.odonnell at uleth.ca Wed Apr 11 17:43:03 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 11 Apr 2007 15:43:03 -0600 Subject: [tei-council] 2007 Members Meeting Message-ID: <1176327783.5222.33.camel@caedmon> Hi all, The Members Meeting Committee met today and it looks like we are going to have a very interesting programme--in addition to plenary speakers and poster sessions as in past years, we also have what is shaping up to be a very full series of conference-style sessions on various TEI and other markup issues. We also can accept up to 25 posters. Currently we have about proposals for about half that number. Given the amount of work currently been done by members of the council as we push towards finishing P5, however, we thought members of the council may also have interesting ideas that they would like to share in the poster session. As council members are currently preparing for our Berlin meeting, let this be an initial invitation. While we expect to close the poster session at some point, we can consider proposals for the next month or so. -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 11 19:53:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 00:53:18 +0100 Subject: [tei-council] DTD or schema In-Reply-To: <17949.12585.803142.804630@emt.wwp.brown.edu> References: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> <17949.12585.803142.804630@emt.wwp.brown.edu> Message-ID: <461D74EE.1000102@oucs.ox.ac.uk> Syd Bauman wrote: > > call it RELAX NG, as do OASIS (remember, it is an OASIS spec) and > ISO/IEC (it is becoming an international standard). > > it has been an ISO standard since 1st December 2003 :-} and I agree, "RELAX NG" is the moniker. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From laurent.romary at loria.fr Thu Apr 12 04:52:53 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 12 Apr 2007 10:52:53 +0200 Subject: [tei-council] DTD or schema In-Reply-To: <17949.18640.40107.20630@emt.wwp.brown.edu> References: <AC532E95-D1B1-43DD-8E2D-87F363B16A5A@loria.fr> <17949.12585.803142.804630@emt.wwp.brown.edu> <461D42E5.5030009@computing-services.oxford.ac.uk> <17949.18640.40107.20630@emt.wwp.brown.edu> Message-ID: <2D7C3512-3C5E-4790-8BFD-7A30AF1EE96C@loria.fr> Le 11 avr. 07 ? 22:45, Syd Bauman a ?crit : >>> - in the following schema fragment >> My preference would be for this. > > And then we'd use the same phrase if it were a Schematron fragment? > Sounds OK to me, actually, as the two don't look in the least alike. > (And, as long as prefixes are used, wouldn't look alike even if we > used the XML syntax.) > OK. I stick to this. Laurent From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:23:07 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:23:07 +0100 Subject: [tei-council] "TEI Interchange" chapter Message-ID: <461DFA7B.1090002@oucs.ox.ac.uk> This was one of the chapters I found inside my chocolate egg last Sunday. Interesting as it is for connoisseurs of technology archaeology, I can find more or less nothing in it worth saving for P5. My recommendation is that we simply drop it. Could I hear opinions to the contrary? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 05:25:03 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 10:25:03 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFA7B.1090002@oucs.ox.ac.uk> References: <461DFA7B.1090002@oucs.ox.ac.uk> Message-ID: <461DFAEF.3060008@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > This was one of the chapters I found inside my chocolate egg last Sunday. > > Interesting as it is for connoisseurs of technology archaeology, > I can find more or less nothing in it worth saving for P5. > > My recommendation is that we simply drop it. Hasn't Lou already done this? See his message from 2007-04-11T16:46 > Could I hear opinions to the contrary? Not from me. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 05:31:10 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 10:31:10 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFA7B.1090002@oucs.ox.ac.uk> References: <461DFA7B.1090002@oucs.ox.ac.uk> Message-ID: <461DFC5E.3040703@oucs.ox.ac.uk> Sebastian Rahtz wrote: > This was one of the chapters I found inside my chocolate egg last Sunday. > > Interesting as it is for connoisseurs of technology archaeology, > I can find more or less nothing in it worth saving for P5. > > My recommendation is that we simply drop it. > > Could I hear opinions to the contrary? > When you get a bit further on in your email backlog, you'll see that this has already been done. From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:37:12 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:37:12 +0100 Subject: [tei-council] "TEI Interchange" chapter In-Reply-To: <461DFAEF.3060008@computing-services.oxford.ac.uk> References: <461DFA7B.1090002@oucs.ox.ac.uk> <461DFAEF.3060008@computing-services.oxford.ac.uk> Message-ID: <461DFDC8.1030606@oucs.ox.ac.uk> James Cummings wrote: > > Hasn't Lou already done this? See his message from 2007-04-11T16:46 > Why, so he has. By commenting it out, sigh, rather than removing it.... when will people start to trust version control... grumble.... So I have to read that backlog of email, eh. Drat. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 05:49:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 10:49:19 +0100 Subject: [tei-council] formatting of guidelines - schema fragments Message-ID: <461E009F.5040007@oucs.ox.ac.uk> I know we have a work task on this, but that may not address a fundamental issue I have. When reading one of my allocated chapters, I was struck by the inclusion of schema fragments in the section with the formal definition of elements. What is the point of them, I wondered? The technical details are available in the alphabetical list of elements etc (the "second volume", if you like), for those who can read this stuff, so why repeat it here? More importantly, the code shown is simply one interpretation of the ODD (ie it divides each element into two patterns, foo.content and foo.attributes), which is not normative. Has this bothered anyone else? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 06:19:39 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 11:19:39 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E009F.5040007@oucs.ox.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> Message-ID: <461E07BB.7060804@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > I know we have a work task on this, but that > may not address a fundamental issue I have. Probably not, so we'd appreciate hearing of any other issues you have. > When reading one of my allocated chapters, > I was struck by the inclusion of schema fragments > in the section with the formal definition > of elements. What is the point of them, I wondered? > The technical details are available in the > alphabetical list of elements etc (the "second > volume", if you like), for those who can read > this stuff, so why repeat it here? I assume so that readers don't have to go elsewhere to find out the nitty-gritty of the elements they have been reading about. Might it be better to move these all to the end of the chapter? i.e. each chapter has section at the end for all the formal declarations? > More importantly, > the code shown is simply one interpretation > of the ODD (ie it divides each element into > two patterns, foo.content and foo.attributes), > which is not normative. > > Has this bothered anyone else? No, I hadn't even considered it. (tbh) However, I do see that it is a bit strange that we are saying ODD is the way and then showing one particular interpretation of that ODD as Relax NG Compact Syntax throughout the guidelines. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Thu Apr 12 07:00:31 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 12 Apr 2007 12:00:31 +0100 Subject: [tei-council] Report on Vilnius meeting In-Reply-To: <45FD6538.1060002@computing-services.oxford.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0EF47148@humxsrv1.hum.ku.dk> <45FD2EA2.60207@kanji.zinbun.kyoto-u.ac.jp> <45FD6538.1060002@computing-services.oxford.ac.uk> Message-ID: <461E114F.8060600@kcl.ac.uk> Hi, my third Easter egg is the proofreading of ND. I wander now, should I just read/edit the xml on sourceforge at P5-Council\Source\Guidelines\en\ND-NamesDates.xml or should I also look at the proposed additions after Vilnius somewhere within P5-Council\Test? If the latter, could I please have the reference to the exact most up to date file? Thank-you, Arianna Lou Burnard wrote: > Christian Wittern wrote: >> Matthew James Driscoll wrote: >>> >>> <listNym> >> >> does that mean you also proposa a <gi>listNym</gi> for TEI? >> >> > > Yes. Matthew's report doesn't mention that there is a draft ODD, > probably because I have not yet got round to putting it anywhere where > Council members can see it easily. But if you look in the P5/Test > directory on sourceforge, you will see a file called testndextra.odd, > which contains the current state of the draft. > > I've just put a copy of the HTML generated from this by Roma on the > website at http://www.tei-c.org/Drafts/ndextra.html -- will try to keep > this up to date as the draft progresses > > >>> Our principal task at this meeting was to develop mechanisms for >>> encoding >>> place-names, analogous to those which were developed for personal >>> names at >>> the meeting in Oxford last year, which would allow for the recording of >>> abstracted information about a place, such as map coordinate, GIS >>> information etc., as well as variant forms of the name, in different >>> languages (e.g. Praha, Prague, Praga) and/or different forms over >>> time (e.g. >>> Lundunum, London). On the analogy with <person>, we propose a <place> >>> element, which will usually contain at least one, and possibly several, >>> <placeName> elements, followed by one or more <location> elements to >>> provide >>> geographical and/or geo-political information about the location of the >>> place. >> >> Why would you need more than one <location>? I had the impression >> that the place is what stays constant? Is it because it also stands in >> for the geopolitical information? > > Because a place might be located in more than one way (e.g. by its > geopolitical status, or by its co-ordinates), and may also move its > location over time. >> However, if we talk about administrative geography here, you will also >> have to account for changes in the size and super/sub components of a >> place and a way to link this to coordinates defining the polygon. >> Would the tagset be up to this task? > > probably... because we embed GML! > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Thu Apr 12 10:36:40 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 08:36:40 -0600 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E07BB.7060804@computing-services.oxford.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> Message-ID: <1176388600.25445.2.camel@odonned-eng06> On Thu, 2007-12-04 at 11:19 +0100, James Cummings wrote: > Sebastian Rahtz wrote: > > I know we have a work task on this, but that > > may not address a fundamental issue I have. > > Probably not, so we'd appreciate hearing of any other issues you have. > > > When reading one of my allocated chapters, > > I was struck by the inclusion of schema fragments > > in the section with the formal definition > > of elements. What is the point of them, I wondered? > > The technical details are available in the > > alphabetical list of elements etc (the "second > > volume", if you like), for those who can read > > this stuff, so why repeat it here? > > I assume so that readers don't have to go elsewhere to find out the > nitty-gritty of the elements they have been reading about. Might it be > better to move these all to the end of the chapter? i.e. each chapter has > section at the end for all the formal declarations? > > > More importantly, > > the code shown is simply one interpretation > > of the ODD (ie it divides each element into > > two patterns, foo.content and foo.attributes), > > which is not normative. > > > > Has this bothered anyone else? > > No, I hadn't even considered it. (tbh) However, I do see that it is a bit > strange that we are saying ODD is the way and then showing one particular > interpretation of that ODD as Relax NG Compact Syntax throughout the > guidelines. I agree. Good catch, Sebastian--although you don't seem to do any other kind! > > -James > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 10:37:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 15:37:42 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <1176388600.25445.2.camel@odonned-eng06> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> Message-ID: <461E4436.8040001@oucs.ox.ac.uk> Dan O'Donnell wrote: I do see that it is a bit >> strange that we are saying ODD is the way and then showing one particular >> interpretation of that ODD as Relax NG Compact Syntax throughout the >> guidelines. > > I agree. Good catch, Sebastian--although you don't seem to do any other > kind! > Coincidentamentally, only yesterday I was asked by the person currently rewriting the FSD spec for ISO why we used this funny syntax (he meant RelaxNC) to express constraints on the element structures. I told him that we had to use some formal language or other, and that the compact syntax was felt to be simpler to take in than the comparatively verbose relaxng syntax used in the ODDs. While I take the point, I don't see any sensible alternative. BNF anyone? From laurent.romary at loria.fr Thu Apr 12 10:47:21 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 12 Apr 2007 16:47:21 +0200 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E4436.8040001@oucs.ox.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> Message-ID: <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> BNF: Yearrrk. I must admit I do read RelaxNG fragment to check the content models and their presence inliine within chapters is quite a nice feature for me. I have more problems with the fact that for each class description, we get the various variants of linearisation (ordered, unordered, optional, etc.). Could we get rid of that? Laurent Le 12 avr. 07 ? 16:37, Lou Burnard a ?crit : > Dan O'Donnell wrote: > I do see that it is a bit >>> strange that we are saying ODD is the way and then showing one >>> particular >>> interpretation of that ODD as Relax NG Compact Syntax throughout the >>> guidelines. >> I agree. Good catch, Sebastian--although you don't seem to do any >> other >> kind! > > Coincidentamentally, only yesterday I was asked by the person > currently rewriting the FSD spec for ISO why we used this funny > syntax (he meant RelaxNC) to express constraints on the element > structures. I told him that we had to use some formal language or > other, and that the compact syntax was felt to be simpler to take > in than the comparatively verbose relaxng syntax used in the ODDs. > > While I take the point, I don't see any sensible alternative. BNF > anyone? > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 11:02:16 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 16:02:16 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> Message-ID: <461E49F8.60001@computing-services.oxford.ac.uk> Laurent Romary wrote: > BNF: Yearrrk. > > I must admit I do read RelaxNG fragment to check the content models and > their presence inliine within chapters is quite a nice feature for me. I > have more problems with the fact that for each class description, we get > the various variants of linearisation (ordered, unordered, optional, > etc.). Could we get rid of that? > Since we're in the process of re-examining how the guidelines should be displayed, there is of course another possibility. That is, this information could be hidden from view until some expansion text is click by the user. (c.f. recent TEI-L discussion on inline display of marginal annotations) This would allow the majority of users just to ignore their existence, and the interested few to expand the CSS-hidden specifications when they desire. How much are we wedded to the notion of avoiding use of javascript and similar? Although I was going to wait until after Dot and I had our brainstorming meeting, if anyone has any other suggestions for how the display of the guidelines can be improved do let us know (preferably on-list to encourage debate). -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 11:10:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 16:10:41 +0100 Subject: [tei-council] class struggle continues Message-ID: <461E4BF1.4040909@oucs.ox.ac.uk> I've just fallen over what looks to be a mistake in the way a couple of classes are defined. The two are: att.personal "common attributes for those elements which form part of a personal name" which gives you @type @full and @sort att.naming "provides attributes common to elements which refer to named persons, places, organizations etc." which just gives you @key (and will also shortly give you @nymKey) Members of att.personal: addName forename genName nameLink roleName surname Members of att.naming: affiliation birth bloc collection country death district education geog geogName institution name nationality occupation persEvent persName persState persTrait placeName pubPlace region relation repository residence rs settlement socecStatus Seems to me that * persName ought to be a member of att.personal (definitely) * @full and @sort ought to be separated from @type (maybe) * att.naming is a silly name if all it does is give you @key, especially as some of its members are not by any stretch of the imagination names at all * att.personal ought to be a member of att.naming (definitely) I propose to make the changes marked "(definitely)" above since without them I won't be able to validate the new version of ND I have promised Arianna for tomorrow... From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 11:37:33 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 16:37:33 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E4436.8040001@oucs.ox.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> Message-ID: <461E523D.8090701@oucs.ox.ac.uk> Lou Burnard wrote: > > While I take the point, I don't see any sensible alternative. BNF anyone? look at http://www.w3.org/TR/its/#translatability-markup and you'll see that generating a sort of BNF from ODD is not that hard. I did a variant stylesheet for W3C purposes. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Thu Apr 12 11:37:49 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 11:37:49 -0400 Subject: [tei-council] class struggle continues In-Reply-To: <461E4BF1.4040909@oucs.ox.ac.uk> References: <461E4BF1.4040909@oucs.ox.ac.uk> Message-ID: <17950.21069.979640.94940@emt.wwp.brown.edu> > * persName ought to be a member of att.personal (definitely) I agree, definitely. > * @full and @sort ought to be separated from @type (maybe) My instinct (w/o actually looking at 'em) is that either type= should be dropped from att.personal (and members of it likely should be members of att.typed, too), or att.personal should itself be a member of att.typed. > * att.naming is a silly name if all it does is give you @key, > especially as some of its members are not by any stretch of the > imagination names at all Agreed. IIRC it is a legacy name. > * att.personal ought to be a member of att.naming (definitely) I'm less convinced. You don't think it is useful to have an element that has key= but not full= & sort=? I'm not sure, to be honest. From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 11:39:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 16:39:46 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <461E52C2.9020003@oucs.ox.ac.uk> James Cummings wrote: > > Since we're in the process of re-examining how the guidelines should be > displayed, there is of course another possibility. That is, this > information could be hidden from view until some expansion text is click by > the user. I came at this while reading paper on holiday; maybe the PDF should diverge more radically from the HTML > How much are we wedded to the notion of avoiding use of javascript and similar? > not at all in this case; ie if they disable JS, they see everything, which is a good fallback. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Thu Apr 12 11:48:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 11:48:04 -0400 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <17950.21684.810181.28894@emt.wwp.brown.edu> Without paying strict attention to the thread so far * The current formatting in the HTML is of almost no use to most users. * This is not a technical issue which needs to be dealt with before Berlin, and so I don't think we should spend time & effort on it now. From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 12:01:18 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 17:01:18 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E4BF1.4040909@oucs.ox.ac.uk> References: <461E4BF1.4040909@oucs.ox.ac.uk> Message-ID: <461E57CE.4050508@computing-services.oxford.ac.uk> Lou Burnard wrote: > I've just fallen over what looks to be a mistake in the way a couple of > classes are defined. The two are: > > att.personal "common attributes for those elements which form part of a > personal name" which gives you @type @full and @sort > > att.naming "provides attributes common to elements which refer to > named persons, places, organizations etc." which just gives you @key > (and will also shortly give you @nymKey) > > Members of att.personal: addName forename genName nameLink roleName > surname > > Members of att.naming: affiliation birth bloc collection country > death district education geog geogName institution name > nationality occupation persEvent persName persState persTrait > placeName pubPlace region relation repository residence rs > settlement socecStatus > > Seems to me that > * persName ought to be a member of att.personal (definitely) agreed > * @full and @sort ought to be separated from @type (maybe) Is there anything special about @type here compared to that provided by att.typed? Or maybe I should be asking, what is the difference? > * att.naming is a silly name if all it does is give you @key, especially > as some of its members are not by any stretch of the imagination names > at all If we rename it, is it really the right place for @nymKey? I have no suggestions for better names, but agree that one isn't really right. > * att.personal ought to be a member of att.naming (definitely) agreed. -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Thu Apr 12 12:07:24 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 12 Apr 2007 17:07:24 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E49F8.60001@computing-services.oxford.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> Message-ID: <461E593C.30601@kcl.ac.uk> James Cummings wrote: > Laurent Romary wrote: >> BNF: Yearrrk. >> >> I must admit I do read RelaxNG fragment to check the content models and >> their presence inliine within chapters is quite a nice feature for me. I >> have more problems with the fact that for each class description, we get >> the various variants of linearisation (ordered, unordered, optional, >> etc.). Could we get rid of that? >> > > Since we're in the process of re-examining how the guidelines should be > displayed, there is of course another possibility. That is, this > information could be hidden from view until some expansion text is click by > the user. (c.f. recent TEI-L discussion on inline display of marginal > annotations) This would allow the majority of users just to ignore their > existence, and the interested few to expand the CSS-hidden specifications > when they desire. This is exactly what I was going to suggest. Indeed, as Laurent, I find these formal descriptions useful myself. If people perceive this as too obtrusive we could have an expandable section, whatever the preferred format of the formal description is going to be. > > How much are we wedded to the notion of avoiding use of javascript and similar? > > Although I was going to wait until after Dot and I had our brainstorming > meeting, if anyone has any other suggestions for how the display of the > guidelines can be improved do let us know (preferably on-list to encourage > debate). I have addedd some chapter-specific suggestions in Trac under my tickets with the title "Output issues". > > -James > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Thu Apr 12 12:26:36 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 10:26:36 -0600 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E52C2.9020003@oucs.ox.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> <461E52C2.9020003@oucs.ox.ac.uk> Message-ID: <1176395196.25445.23.camel@odonned-eng06> I'm pretty sure you can handle that with pure CSS as well, btw. Don't know how myself, but I could swear I read that somewhere. On Thu, 2007-12-04 at 16:39 +0100, Sebastian Rahtz wrote: > James Cummings wrote: > > > > Since we're in the process of re-examining how the guidelines should be > > displayed, there is of course another possibility. That is, this > > information could be hidden from view until some expansion text is click by > > the user. > I came at this while reading paper on holiday; > maybe the PDF should diverge more radically > from the HTML > > How much are we wedded to the notion of avoiding use of javascript and similar? > > > not at all in this case; ie if they disable JS, they see everything, > which is a good fallback. > -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 12:26:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 17:26:01 +0100 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <17950.21684.810181.28894@emt.wwp.brown.edu> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> <17950.21684.810181.28894@emt.wwp.brown.edu> Message-ID: <461E5D99.5000105@oucs.ox.ac.uk> Syd Bauman wrote: > * The current formatting in the HTML is of almost no use to most > users. > I hope you mean just the schema frags... > * This is not a technical issue which needs to be dealt with before > Berlin, and so I don't think we should spend time & effort on it > now. > I don't disagree. its light relief for anyone who has finished their chapters :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 12:42:09 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 17:42:09 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E57CE.4050508@computing-services.oxford.ac.uk> References: <461E4BF1.4040909@oucs.ox.ac.uk> <461E57CE.4050508@computing-services.oxford.ac.uk> Message-ID: <461E6161.5060001@oucs.ox.ac.uk> James Cummings wrote: > >> Seems to me that >> * persName ought to be a member of att.personal (definitely) > agreed Unfortunately, this causes everything to break, since persName explicitly defines its own @type >> * @full and @sort ought to be separated from @type (maybe) > Is there anything special about @type here compared to that provided by > att.typed? Or maybe I should be asking, what is the difference? > Sometimes (about 40%) when an element has a @type, it has inherited it from att.typed. Other times it defines it for itself. Usually this is because the locally-defined variant has a helpful valList associated with it. We looked at this problem, gingerly, at the class meeting in Oxford and then ran away from it. att.typed also gives you @subtype which you may not want, but that seems to be less of an issue to me. >> * att.naming is a silly name if all it does is give you @key, especially >> as some of its members are not by any stretch of the imagination names >> at all > > If we rename it, is it really the right place for @nymKey? I have no > suggestions for better names, but agree that one isn't really right. > I think it definitely is the right place for @nymKey. One gives you a pointer to the thing being named, the other gives you a pointer to the canonical name used for the naming. >> * att.personal ought to be a member of att.naming (definitely) > > agreed. > but vide supra... From Syd_Bauman at Brown.edu Thu Apr 12 12:59:00 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 12:59:00 -0400 Subject: [tei-council] formatting of guidelines - schema fragments In-Reply-To: <461E5D99.5000105@oucs.ox.ac.uk> References: <461E009F.5040007@oucs.ox.ac.uk> <461E07BB.7060804@computing-services.oxford.ac.uk> <1176388600.25445.2.camel@odonned-eng06> <461E4436.8040001@oucs.ox.ac.uk> <837A872B-4210-40DB-9809-9B261BCC906A@loria.fr> <461E49F8.60001@computing-services.oxford.ac.uk> <17950.21684.810181.28894@emt.wwp.brown.edu> <461E5D99.5000105@oucs.ox.ac.uk> Message-ID: <17950.25940.251219.26596@emt.wwp.brown.edu> > > * The current formatting in the HTML is of almost no use to most > > users. > I hope you mean just the schema frags... Yes, that is what I meant. From James.Cummings at computing-services.oxford.ac.uk Thu Apr 12 13:00:10 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 12 Apr 2007 18:00:10 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E6161.5060001@oucs.ox.ac.uk> References: <461E4BF1.4040909@oucs.ox.ac.uk> <461E57CE.4050508@computing-services.oxford.ac.uk> <461E6161.5060001@oucs.ox.ac.uk> Message-ID: <461E659A.3020604@computing-services.oxford.ac.uk> Lou Burnard wrote: > James Cummings wrote: >> >>> Seems to me that >>> * persName ought to be a member of att.personal (definitely) >> agreed > > Unfortunately, this causes everything to break, since persName > explicitly defines its own @type And I assume, as below, that is because it has a useful valList? Oh wait, when I look it up it allows anything that is data.enumerated. Maybe this should change? So I guess the problem is also partly that you want to have descriptive prose that is different for this @type compared to the one that is in att.typed? >>> * @full and @sort ought to be separated from @type (maybe) > Sometimes (about 40%) when an element has a @type, it has inherited it > from att.typed. Other times it defines it for itself. Usually this is > because the locally-defined variant has a helpful valList associated > with it. We looked at this problem, gingerly, at the class meeting in > Oxford and then ran away from it. att.typed also gives you @subtype > which you may not want, but that seems to be less of an issue to me. Yes, I remember that. I have little problem with subtype being there whenever type is, even if minorly inappropriate in some instances. > I think it definitely is the right place for @nymKey. One gives you a > pointer to the thing being named, the other gives you a pointer to the > canonical name used for the naming. Fair enough, thanks for the explanation, then I say rename it... but to what? >>> * att.personal ought to be a member of att.naming (definitely) >> agreed. > but vide supra... What is best to do about that? These darn type attributes. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 13:07:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 18:07:56 +0100 Subject: [tei-council] class struggle continues In-Reply-To: <461E659A.3020604@computing-services.oxford.ac.uk> References: <461E4BF1.4040909@oucs.ox.ac.uk> <461E57CE.4050508@computing-services.oxford.ac.uk> <461E6161.5060001@oucs.ox.ac.uk> <461E659A.3020604@computing-services.oxford.ac.uk> Message-ID: <461E676C.3050609@oucs.ox.ac.uk> James Cummings wrote: ? > >>>> * att.personal ought to be a member of att.naming (definitely) >>> agreed. >> but vide supra... > > What is best to do about that? These darn type attributes. > (a) removed @type from att.personal (b) make all current members of att.personal also members of att.typed That's what I've done, anyway. From Syd_Bauman at Brown.edu Thu Apr 12 13:17:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 13:17:46 -0400 Subject: [tei-council] development version of Guidelines In-Reply-To: <4616C5BE.3010803@computing-services.oxford.ac.uk> References: <4616C5BE.3010803@computing-services.oxford.ac.uk> Message-ID: <17950.27066.429563.334026@emt.wwp.brown.edu> LB> Don't expect any of the links in it to work as I haven't put any LB> of the other chapters there! I don't know, but if I had to hazard a guess, I'd bet Lou didn't put the other chapters, etc., there because doing so with Perforce would be a pain. (Probably not all that bad, but once you've used Subversion ... :-) I often like to have a current version of the development version of the Guidelines available in HTML. Usually it's sitting on my local hard drive, but on occasion it's useful to have on the web. As we run up to Berlin I'm betting some Council members would find this helpful, too. Current version (as of this morning, my time) is at http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html Note that what makes this easy for me also makes it comparatively unreliable: that server is in my basement, and will blink out if the power goes out at my house (several times a year), my cable company suffers a snag (several times a year), or my son decides to see what that glowing button on the front does (hasn't since he was 4, but who knows.) From Syd_Bauman at Brown.edu Thu Apr 12 14:22:08 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 14:22:08 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> Message-ID: <17950.30928.5625.745800@emt.wwp.brown.edu> > OK, it's time to get radical. What do we need "TEI Interchange > format" for? Why do we need to define it at all? So that we can move all these draconian restrictions out of the definition of "conformance", but still put them somewhere useful. Remember that this marvelous capability to differentiate those XML structures that come from the TEI namespace from those that do not is only helpful if you both have software that can process the generic TEI structures and find it useful. That is, a lot of TEI users will have to go through a lot of hoops to generate documents that fit the current namespace-concerned definition of conformance, with no benefit to themselves at all. On the other hand, when they want to exchange that document with someone else (say, an archive), following the more draconian rules is likely to be quite helpful. Some further thoughts. If we insist that TEI conformant documents follow draconian namespace rules, there are some pretty predictable potentially problematic probable consequences: * Most projects will not use TEI for document capture -- dealing with those namespaces will just be too annoying. E.g., imagine the project that expected to capture TEI P5 texts using a customization that replaced <choice> with the old Janus attributes (because they know they are dealing with only 1 language and have no characters out of Unicode), and want to change xml:id= to id= and target= to an IDREF attribute for capture so that their XML editor will do the right thing. * Many projects will not even bother to store their texts locally in TEI, and will either abandon TEI conformance completely, or only trot out the namesaced-conformant version for funding agencies and blind interchange. * We will never have a conformant <soCalled>TEI Tite</soCalled> for vendor use. I don't see this as a major problem, personally, as the goal has always been to use Tite as a capture format, and transform into more canonical TEI later. I really think that this is an issue about which users should be canvassed before we commit to constraining conformance, as opposed to interchange format. BTW, if we are going to go this route of force-feeding namespaces which impart no direct benefit on users, we had better make it as easy as possible. That is, roma and webRoma should do the right thing w/o significant extra work. This may not be easy. For example, roma will need to know that changing an attribute from data.numeric to data.count is a clean change, but from data.name to data.word is not. (There are things we may not be able to expect roma to do, of course, like read users' regular expressions and figure out if it represents a clean subset of a datatype or not.) I just asked a colleague what he thought of all this. He suggested a different likely pattern of behavior for users. He suggested that many users would tolerate the namespace business, but would not make the effort to, or not be able to, figure out which customizations are clean subsets and which are not, and thus would stick all customizations into their own namespace. He left me with a very insightful parting thought: "Boy, I hope the Council doesn't make TEI into W3C Schema". P.S. As it applies to interchange format, as opposed to conformance, I think I agree with the direction this thread is headed, including that translated or renamed elements should be in another namespace. From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 14:48:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 19:48:56 +0100 Subject: [tei-council] New version of ND checked in Message-ID: <461E7F18.8030502@computing-services.oxford.ac.uk> There having been no comment on the nym proposals since I announced them here over a month ago, I have now integrated them into a new version of chapter ND. I took the opportunity also of correcting a few anomalies in the class system, as discussed on this list earlier today. I haven't, however, done anything yet with the proposed changes to introduce <place> and <listPlace>. I think this needs more discussion. The new version and associated changes are, as ever, checked into the trunk of the svn repository, rather than the council branch. If no one is currently working on files in the latter, maybe someone ought to bring it up to date with the trunk, since there have been quite a few minor and not so minor tweaks since it was forked. I will put an updated HTML version of the new chapter into the Drafts web page later this evening. Dinner first. From Syd_Bauman at Brown.edu Thu Apr 12 15:49:37 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 15:49:37 -0400 Subject: [tei-council] New version of ND checked in In-Reply-To: <461E7F18.8030502@computing-services.oxford.ac.uk> References: <461E7F18.8030502@computing-services.oxford.ac.uk> Message-ID: <17950.36177.285828.727857@emt.wwp.brown.edu> > I will put an updated HTML version of the new chapter into the > Drafts web page later this evening. Dinner first. http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html updated completely. (I never update this site file-by-file, I just plop a newly generated complete copy in there, so to read Lou's latest and greatest, you can go to http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html.) From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 16:24:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 21:24:41 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.30928.5625.745800@emt.wwp.brown.edu> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> Message-ID: <461E9589.3080100@oucs.ox.ac.uk> I think this is a matter of roses smelling as sweet by any other name. If all the draconian prose moves to "interchange", fine; but in that case, just quietly lose the "conformance" chapter entirely. Let's not have *two* distinct barriers, or one so low ("if you want to be TEI conformant, BE GOOD") that it doesn't merit more than a paragraph of text. As far as I am concerned, you can either be inspired by the TEI, or conform to the TEI. Call that "interchangeable with the TEI" if preferred. > Some further thoughts. If we insist that TEI conformant documents > follow draconian namespace rules, there are some pretty predictable > potentially problematic probable consequences > your nightmare scenarios are possible, I agree, but not inevitable. Let's stop trying to second guess what people will say, but publish a conformance draft quickly and let them comment. > * Most projects will not use TEI for document capture -- dealing with > those namespaces will just be too annoying. E.g., imagine the > project that expected to capture TEI P5 texts using a customization > that replaced <choice> with the old Janus attributes (because they > know they are dealing with only 1 language and have no characters > out of Unicode), and want to change xml:id= to id= and target= to > an IDREF attribute for capture so that their XML editor will do the > right thing. > sounds like they won't be conformant, poor people. > * Many projects will not even bother to store their texts locally in > TEI, and will either abandon TEI conformance completely, or only > trot out the namesaced-conformant version for funding agencies and > blind interchange > if they have a route to get conformant texts for when it comes out of their vaults, sounds great. just what the doctor ordered > * We will never have a conformant <soCalled>TEI Tite</soCalled> for > vendor use. why not? > > I really think that this is an issue about which users should be > canvassed before we commit to constraining conformance, as opposed to > interchange format. > agreed. if we can get the users to speak, rather have just expose ourselves to another public shouting match between Wendell and me.... > This may not be easy. For example, roma > will need to know that changing an attribute from data.numeric to > data.count is a clean change, but from data.name to data.word is not. > (There are things we may not be able to expect roma to do, of course, > like read users' regular expressions and figure out if it represents > a clean subset of a datatype or not.) > you could implement some of this with a free-standing TEI conformance checked for an ODD? > > I just asked a colleague what he thought of all this. He suggested a > different likely pattern of behavior for users. He suggested that > many users would tolerate the namespace business, but would not make > the effort to, or not be able to, figure out which customizations are > clean subsets and which are not, and thus would stick all > customizations into their own namespace. you'll have to expand that for me. can you give an example of what you think he meant? > He left me with a very > insightful parting thought: "Boy, I hope the Council doesn't make TEI > into W3C Schema". > you'll have to gloss that a little further, too. did he mean "make the TEI as Byzantine as Schema", or "make the TEI use Schema"? if the former, its far too late, it already is :-} > > P.S. As it applies to interchange format, as opposed to conformance, > I think I agree with the direction this thread is headed, > including that translated or renamed elements should be in > another namespace. > I thought the opposite was agreed? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 16:38:25 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 12 Apr 2007 21:38:25 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E9589.3080100@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> Message-ID: <461E98C1.7020809@computing-services.oxford.ac.uk> >> >> P.S. As it applies to interchange format, as opposed to conformance, >> I think I agree with the direction this thread is headed, >> including that translated or renamed elements should be in >> another namespace. >> > I thought the opposite was agreed? > Just for the avoidance of doubt, my belief is that we agreed that - the TEI systematic translations should be in a different TEI namespace - user-defined renaming should be in a user-defined namespace From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 16:48:07 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 21:48:07 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E98C1.7020809@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <461E98C1.7020809@computing-services.oxford.ac.uk> Message-ID: <461E9B07.8090208@oucs.ox.ac.uk> Lou Burnard wrote: >> > Just for the avoidance of doubt, my belief is that we agreed that > - the TEI systematic translations should be in a different TEI namespace > - user-defined renaming should be in a user-defined namespace > oh, I haven't paid attention, then. You want syntactic sugar renaming in a new namespace? Yikes. I don't know how on earth I am going to program that in Roma-land. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Thu Apr 12 18:28:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 18:28:10 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461E9589.3080100@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> Message-ID: <17950.45690.802744.758277@emt.wwp.brown.edu> > I think this is a matter of roses smelling as sweet by any other > name. If all the draconian prose moves to "interchange", fine; but > in that case, just quietly lose the "conformance" chapter entirely. > > Let's not have *two* distinct barriers, or one so low ("if you want > to be TEI conformant, BE GOOD") that it doesn't merit more than a > paragraph of text. > > As far as I am concerned, you can either be inspired by the TEI, or > conform to the TEI. Call that "interchangeable with the TEI" if > preferred. Your logic completely escapes me. What's wrong with two different barriers? After all, we are talking about two completely different use cases. The first, well thought out, documented, and dealt with by the creators of P3, is the barrier for document creation, processing, and to a lesser extent, interchange. This is the barrier called "conformance", which I would like to see set reasonably low. The other is the barrier for interoperability, a goal that has never really been discussed in previous versions of the Guidelines, and which requires a much higher barrier. Remember that with P3/P4 we set the barrier to conformant customization too high, and the result was that most projects used TEI Lite, and many hacked it directly. (Mind you, I'm not saying we made a mistake in doing so -- given the technology of the day I'm not sure there was much other choice.) The barrier to proper customization of P5, although a *lot* better than with P4 (thanks in large part to you, Sebastian), is still pretty high. > > E.g., imagine the project that expected to capture TEI P5 texts > > using a customization that replaced <choice> with the old Janus > > attributes (because they know they are dealing with only 1 > > language and have no characters out of Unicode), and want to > > change xml:id= to id= and target= to an IDREF attribute for > > capture so that their XML editor will do the right thing. > sounds like they won't be conformant, poor people. That's my point. This is the very kind of customization we have been telling people they could do, or might even be available directly from the TEI as an example ODD or some such, all along. People liked the idea. > if they have a route to get conformant texts for when it comes out > of their vaults, sounds great. just what the doctor ordered I disagree. I think there are advantages both for the TEI and for users to using the Guidelines for text encoding, not just for interchange with the hope of interoperability. For starters, such projects will have both less incentive to be TEI-C members, and less ammunition when they talk to their deans about becoming TEI-C members. ("OK, so you transform it to TEI to put it in an archive, so what? You transform it into HTML for web delivery, do you want us to become W3C members, too?") > > * We will never have a conformant <soCalled>TEI Tite</soCalled> for > > vendor use. > why not? The point of much of the syntactic sugar renaming in Tite is to reduce keystrokes. Requiring even a 1-character namespace prefix would negate any advantages. > > This may not be easy. For example, roma will need to know that > > changing an attribute from data.numeric to data.count is a clean > > change, but from data.name to data.word is not. (There are things > > we may not be able to expect roma to do, of course, like read > > users' regular expressions and figure out if it represents a > > clean subset of a datatype or not.) > > > you could implement some of this with a free-standing > TEI conformance checked for an ODD? Well, yes, but my point was a) it should be integrated into roma / webRoma; b) it isn't easy. > you'll have to expand that for me. can you give an example of what > you think he meant? Sure. The Imaginary Project creates a schema with half a dozen changes vs. vanilla TEI. Rather than expend the effort to figure out which things affected by the changes should be in tei: namespace and which should be in ip: namespace, they will just put every element and attribute affected by the change into the ip: namespace. > > He left me with a very insightful parting thought: "Boy, I hope > > the Council doesn't make TEI into W3C Schema". > > > you'll have to gloss that a little further, too. did he mean > "make the TEI as Byzantine as Schema", or "make the TEI > use Schema"? if the former, its far too late, it already is :-} He meant the former, and he obviously does not think it is far too late. Nor do I, for that matter. I doubt you really do, either, Sebastian, as you understand TEI, but IIRC still have trouble wrapping your mind around W3C Schema (although you certainly do better than I with it :-) From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 18:45:48 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Apr 2007 23:45:48 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.45690.802744.758277@emt.wwp.brown.edu> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> Message-ID: <461EB69C.8050106@oucs.ox.ac.uk> Syd Bauman wrote: > After all, we are talking about two completely different > use cases. The first, well thought out, documented, and dealt with by > the creators of P3, is the barrier for document creation, processing, > and to a lesser extent, interchange. This is the barrier called > "conformance", which I would like to see set reasonably low. we do have that fundamental difference in our views :-} > > > Remember that with P3/P4 we set the barrier to conformant > customization too high, and the result was that most projects used > TEI Lite, and many hacked it directly. > that was a technology barrier, not a policy one, I suspect > > I disagree. I think there are advantages both for the TEI and for > users to using the Guidelines for text encoding, not just for > interchange with the hope of interoperability. For starters, such > projects will have both less incentive to be TEI-C members, and less > ammunition when they talk to their deans about becoming TEI-C members. > ("OK, so you transform it to TEI to put it in an archive, so what? > You transform it into HTML for web delivery, do you want us to become > W3C members, too?") > if they're interested in the TEI, they'll join, even though they abuse it in their dark inner sanctums. > The point of much of the syntactic sugar renaming in Tite is to > reduce keystrokes. Requiring even a 1-character namespace prefix > would negate any advantages. > yes, I had not grasped that these syntactic sugars would be in a different namespace until a few hours ago. I agree, I personally think that's simply unworkable. > > Sure. The Imaginary Project creates a schema with half a dozen > changes vs. vanilla TEI. Rather than expend the effort to figure out > which things affected by the changes should be in tei: namespace and > which should be in ip: namespace, they will just put every element > and attribute affected by the change into the ip: namespace. > I think I get you. You mean that when they constrain the @type on <div>, they'll put <div> in the ip: space, because they think they have to? yes, that would be absurd. > > He meant the former, and he obviously does not think it is far too > late. Nor do I, for that matter. I doubt you really do, either, > Sebastian, as you understand TEI, but IIRC still have trouble > wrapping your mind around W3C Schema (although you certainly do > better than I with it :-) > after a few hours studying an XSD recently, I think I finally realized how the demented brains of the designers were working. I still don't fully understand the ODD processing model, and I am the one who has to document it :-{ anyway, forget this side meander. The issue is whether conformance and interchange are the same thing or not. I conflate them, you clearly separate them. we definitely agree that whatever happens, this is a case where the user community needs a thorough consultation. And the good news is that this does not stop us doing other work in the meanwhile - the definition of conformance can be revisited again and again (god help us) over the next 3 or 4 months if it really has to, I think. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:20:37 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:20:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.45690.802744.758277@emt.wwp.brown.edu> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> Message-ID: <461EBEC5.6050106@computing-services.oxford.ac.uk> Syd Bauman wrote: > > Your logic completely escapes me. What's wrong with two different > barriers? After all, we are talking about two completely different > use cases. The first, well thought out, documented, and dealt with by > the creators of P3, is the barrier for document creation, processing, > and to a lesser extent, interchange. This is the barrier called > "conformance", which I would like to see set reasonably low. The > other is the barrier for interoperability, a goal that has never > really been discussed in previous versions of the Guidelines, and > which requires a much higher barrier. > Where on earth did you get the idea that P3 doesn't talk about "interoperability"? There's a whole chapter on it! The point though is that everything in it is redundant in the world of XML. I also think that you're unlikely to persuade anyone to agree with you until you come up with some definition of what *you* think TEI-conformance means. > > Remember that with P3/P4 we set the barrier to conformant > customization too high, and the result was that most projects used > TEI Lite, and many hacked it directly. What barrier did we set? you just said there was nothing about conformance in P3, and now you're saying that we made it too difficult? make your mind up! > I disagree. I think there are advantages both for the TEI and for > users to using the Guidelines for text encoding, not just for > interchange with the hope of interoperability. For starters, such > projects will have both less incentive to be TEI-C members, and less > ammunition when they talk to their deans about becoming TEI-C members. > ("OK, so you transform it to TEI to put it in an archive, so what? > You transform it into HTML for web delivery, do you want us to become > W3C members, too?") > > Yes, I agree that being TEI conformant for purposes other than interchange is a desirable goal. But designing an encoding scheme that fits every possible project's needs is a quixotic goal we never set ourselves. So there has to be room for compromise -- which is why we distinguish conformance/interoperable format from local practice. > >>> * We will never have a conformant <soCalled>TEI Tite</soCalled> for >>> vendor use. >>> >> why not? >> > > The point of much of the syntactic sugar renaming in Tite is to > reduce keystrokes. Requiring even a 1-character namespace prefix > would negate any advantages. > > > I don't get this. If you want 1 character tag names, don't use the TEI. Write your own schema, define a mapping between it and the TEI. You have attained conformance without confusing the TEI namespace. Next. > > > Sure. The Imaginary Project creates a schema with half a dozen > changes vs. vanilla TEI. Rather than expend the effort to figure out > which things affected by the changes should be in tei: namespace and > which should be in ip: namespace, they will just put every element > and attribute affected by the change into the ip: namespace. > > > There's no telling what foolishness some people will get up to. But I repeat -- what's your alternative proposal? If we are going to use namespaces at all, we must use them properly. No-one has yet proposed reversing the decision to define a TEI namespace. A namespace is, by definition, fixed, isn't it? >>> He left me with a very insightful parting thought: "Boy, I hop e >>> the Council doesn't make TEI into W3C Schema". >>> >>> >> you'll have to gloss that a little further, too. did he mean >> "make the TEI as Byzantine as Schema", or "make the TEI >> use Schema"? if the former, its far too late, it already is :-} >> > > He meant the former, and he obviously does not think it is far too > late. Nor do I, for that matter. I doubt you really do, either, > Sebastian, as you understand TEI, but IIRC still have trouble > wrapping your mind around W3C Schema (although you certainly do > better than I with it :-) > I don't see any sense in which we are making the TEI byzantine. We are making it a lot clearer what we mean and what the boundaries are. From daniel.odonnell at uleth.ca Thu Apr 12 19:34:34 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Thu, 12 Apr 2007 17:34:34 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <1176420874.23247.2.camel@odonned-eng06> On Thu, 2007-12-04 at 23:45 +0100, Sebastian Rahtz wrote: > yes, I had not grasped that these syntactic sugars > would be in a different namespace until a few hours ago. > I agree, I personally think that's simply unworkable. This I agree with as well. Sugar is a way of simplifying things. I'm still in favour of "TEI namespace if your renaming doesn't conflict and can be undone cleanly" > > > > Sure. The Imaginary Project creates a schema with half a dozen > > changes vs. vanilla TEI. Rather than expend the effort to figure out > > which things affected by the changes should be in tei: namespace and > > which should be in ip: namespace, they will just put every element > > and attribute affected by the change into the ip: namespace. > > > I think I get you. You mean that when they constrain > the @type on <div>, they'll put <div> in the ip: space, > because they think they have to? yes, that would be > absurd. > > > > He meant the former, and he obviously does not think it is far too > > late. Nor do I, for that matter. I doubt you really do, either, > > Sebastian, as you understand TEI, but IIRC still have trouble > > wrapping your mind around W3C Schema (although you certainly do > > better than I with it :-) > > > > after a few hours studying an XSD recently, I think > I finally realized how the demented brains > of the designers were working. I still don't > fully understand the ODD processing model, > and I am the one who has to document it :-{ > > anyway, forget this side meander. The issue is > whether conformance and interchange > are the same thing or not. I conflate them, > you clearly separate them. But do you Sebastian? If you think Sugar is not a namespace issue, surely you think it needs to be undoable for interchange? -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:32:26 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:32:26 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <461EC18A.6060105@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > >> The point of much of the syntactic sugar renaming in Tite is to >> reduce keystrokes. Requiring even a 1-character namespace prefix >> would negate any advantages. >> > yes, I had not grasped that these syntactic sugars > would be in a different namespace until a few hours ago. > I agree, I personally think that's simply unworkable. I don't see any alternative. If you decide to rename <div type="chapter"> as <chapter> and James decides to rename <div type="section"> as <chapter> how will I tell them apart? Am I really going to go to the trouble of canonicalizing every document I receive (using tools I haven't got, and reference to the ODD you probably forgot to send me)?. Surely it's less work for me to deal with different namespaces, which my current toolkit *has* to be able to deal with anyway? Maybe the way to approach this is, as for different languages, for the TEI to define yet another namespace for sugarred variants? From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 19:35:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 00:35:19 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EBEC5.6050106@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EBEC5.6050106@computing-services.oxford.ac.uk> Message-ID: <461EC237.7020407@oucs.ox.ac.uk> Lou Burnard wrote: > I don't get this. If you want 1 character tag names, don't use the > TEI. Write your own schema, define a mapping between it and the TEI. > You have attained conformance without confusing the TEI namespace. Next. I think you're maybe misunderstanding Syd here. Tite proposes (eg) <sup> as syntactic sugar for <hi rend="sup">. I think you are saying that <sup> will have to be either <sup xmlns="......"> or <x:sup>, where "x" is defined up front. Given the usage of <sup>, you _will_ end up doing one or other on every occasion, at a minimum extra cost of 4 characters per use (start and end tag). Given that the aim is to save money, it does seem undesirable. Me, I think that if <sup> has an <equiv> doing the mapping, it can stay in the TEI namespace, but I still haven't read the discussion of you lot over Easter. As Syd says, no sane Tite user would pay for <x:sup> over <sup>, so Tite won't conform; unlike Lite, which _will_ be OK. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 19:40:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 00:40:50 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC18A.6060105@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <461EC18A.6060105@computing-services.oxford.ac.uk> Message-ID: <461EC382.4040607@oucs.ox.ac.uk> Lou Burnard wrote: > I don't see any alternative. If you decide to rename <div > type="chapter"> as <chapter> and James decides to rename <div > type="section"> as <chapter> how will I tell them apart? God gave you <equiv> for this purpose > Am I really going to go to the trouble of canonicalizing every > document I receive (using tools I haven't got, and reference to the > ODD you probably forgot to send me)? no ODD, no conformance. the tool you want, I wrote for my TEI MM 2005 talk. > Surely it's less work for me to deal with different namespaces, which > my current toolkit *has* to be able to deal with anyway? for you, maybe, but what about me? > > Maybe the way to approach this is, as for different languages, for the > TEI to define yet another namespace for sugarred variants? > that doesn't really help, asI haven't bought the "different namespace for language translations" thing yet either. I have a horrible feeling I am coming to the idea that "interchange format" means "expanding the <equiv> information". I had better go to bed before I end up agreeing to anything else. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu Apr 12 19:46:53 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 00:46:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC237.7020407@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EBEC5.6050106@computing-services.oxford.ac.uk> <461EC237.7020407@oucs.ox.ac.uk> Message-ID: <461EC4ED.9070606@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > > Tite proposes (eg) <sup> as syntactic sugar for <hi rend="sup">. > I think you are saying that <sup> will have to be either <sup > xmlns="......"> > or <x:sup>, where "x" is defined up front. Given the usage of <sup>, > you _will_ end up doing one or other on every occasion, at a minimum > extra cost of 4 characters per use (start and end tag). That is correct. > Given that > the aim is to save money, it does seem undesirable. The aim of the TEI is not to make the smallest possible tagset. If you want small tags and few keystrokes, you can't be TEI conformant. It doesn't mean you can't have a jolly good schema, nor indeed one that can't be automatically made TEI conformant. (James proposed a special name for such a beast, which I've now forgotten). Have you *read* the draft yet? > > Me, I think that if <sup> has an <equiv> doing the mapping, > it can stay in the TEI namespace, but I still haven't read the discussion > of you lot over Easter. > But that mapping isn't accessible to anyone's normal document processing tools is it? We don't have TEIFORM anymore. Of course if you can whip out of the bag some foolproof way of implementing something equivalent using standard XML processing tools, I'll stop complaining... > As Syd says, no sane Tite user would pay for <x:sup> over <sup>, > so Tite won't conform; unlike Lite, which _will_ be OK. > If the primary objective of Tite (or any schema) is to save keystrokes, then TEI conformance/interoperability is going to be a secondary objective for it. (I Dont see what Lite has to do with the price of fish) From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 20:10:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 01:10:26 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC4ED.9070606@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EBEC5.6050106@computing-services.oxford.ac.uk> <461EC237.7020407@oucs.ox.ac.uk> <461EC4ED.9070606@computing-services.oxford.ac.uk> Message-ID: <461ECA72.5010202@oucs.ox.ac.uk> Lou Burnard wrote: > But that mapping isn't accessible to anyone's normal document > processing tools is it? We don't have TEIFORM anymore. Of course if > you can whip out of the bag some foolproof way of implementing > something equivalent using standard XML processing tools, I'll stop > complaining... well, as I say, I did demonstrate this in Sofia! > >> As Syd says, no sane Tite user would pay for <x:sup> over <sup>, >> so Tite won't conform; unlike Lite, which _will_ be OK. >> > If the primary objective of Tite (or any schema) is to save > keystrokes, then TEI conformance/interoperability is going to be a > secondary objective for it. hmm, better explain that to Big John U. He thinks Tite will be the TEI's next big thing. And here we are saying it won't even be TEI conformant.... > (I Dont see what Lite has to do with the price of fish) > you vaguely wondered if Tite could replace Lite. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 12 20:12:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 01:12:15 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <1176420874.23247.2.camel@odonned-eng06> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> Message-ID: <461ECADF.4090508@oucs.ox.ac.uk> Dan O'Donnell wrote: > But do you Sebastian? If you think Sugar is not a namespace issue, > surely you think it needs to be undoable for interchange? > I *still* haven't gone to bed, and I admit that I am backing myself slowly into an interchange corner..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From cwittern at gmail.com Thu Apr 12 21:14:27 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 13 Apr 2007 10:14:27 +0900 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <17950.30928.5625.745800@emt.wwp.brown.edu> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> Message-ID: <461ED973.1090009@gmail.com> Syd Bauman wrote: >> OK, it's time to get radical. What do we need "TEI Interchange >> format" for? Why do we need to define it at all? >> > > Some further thoughts. If we insist that TEI conformant documents > follow draconian namespace rules, there are some pretty predictable > potentially problematic probable consequences: > [...] Syd, what you are saying here reminds me of the kind of statements I heard from die-hard SGML users when they first heard about XML and its "draconian" error-checking rules. My prediction is quite contrary to yours: I think we will *finally* see some kind of TEI Software that is worth being called so, since an implementer now has a way to know what to deal with. -- Well, the bets are open. Lets look at the results in three years time. Christian From Syd_Bauman at Brown.edu Thu Apr 12 21:35:19 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 12 Apr 2007 21:35:19 -0400 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EB69C.8050106@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> Message-ID: <17950.56919.510899.582380@emt.wwp.brown.edu> > And the good news is that this does not stop us doing other work in > the meanwhile - the definition of conformance can be revisited > again and again (god help us) over the next 3 or 4 months if it > really has to, I think. Oh! I had thought conformance was one of those things that could not be changed after Berlin. Good. While I obviously have some work cut out for me responding to this evening's posts on this thread, I am going to deliberately defer until after Berlin, and get back to work on those phrase-level classes. G'night. From arianna.ciula at kcl.ac.uk Fri Apr 13 05:11:37 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 10:11:37 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461E7F18.8030502@computing-services.oxford.ac.uk> References: <461E7F18.8030502@computing-services.oxford.ac.uk> Message-ID: <461F4949.5090405@kcl.ac.uk> Lou Burnard wrote: > > I will put an updated HTML version of the new chapter into the Drafts > web page later this evening. Dinner first. I assume I can update the trunk and get going with it now then. Arianna > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 05:45:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 10:45:05 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461ECADF.4090508@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> Message-ID: <461F5121.9040905@oucs.ox.ac.uk> Sebastian Rahtz wrote: > Dan O'Donnell wrote: >> But do you Sebastian? If you think Sugar is not a namespace issue, >> surely you think it needs to be undoable for interchange? >> > I *still* haven't gone to bed, and I admit that > I am backing myself slowly into an interchange corner..... > > I, on the other hand, did go to bed at a sensible time, and thus have had the opportunity to sleep on it. Let me try to reformulate the issues here: 1. "Conformance" means, fundamentally, conformance to the TEI abstract model. The markup scheme defined by or applied in a TEI conformant document marks up abstract concepts which are also present in the TEI abstract model, and with the same meaning. 2. The particular part of the TEI abstract model which a set of document uses can be expressed in three ways, only two of which can be automatically checked: a) the application of the elements is something that a human reader recognizes as plausible i.e. the thing tagged <l> does actually contain a line of verse b) particular things are called by particular names i.e. the thing containing a line of verse is called <l> (in the TEI namespace) and not <line>. Namespaces are a useful way of asserting whether the "l" here is the TEI "<l>" or some other one. c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but not vice versa. Validating this is what schemas are for. 3. Modification/customization/personalization is something we do in order to generate and document a schema, so it is about both (a) and (c). A modification which replaces the <desc> of <l> to say that it is for typographic lines is an unclean one, as is one which modifies its content model to permit <div>s within it -- in the same way and for the same reasons. Only "clean"[1] modifications are conformant (this doesnt mean that unclean modifications are evil, just that they are different. Most improvements to the TEI scheme start off life as unclean modifications.) 4. We are disagreeing about whether or not a modification which is a simple renaming is unclean, i.e. about whether 2(b) is somehow different from the other kinds of conformance constraint. I can identify the following reasons for this disagreement: i/ We are so used to seeing different names for the same thing that it just doesn't seem important to insist on using a specific name, or to insist that names declare their namespace. (cf the pain of going from case-insensitive to case-sensitive identifiers which some of us old'uns are still suffering from). ii/ We think many people will find namespace technology a step too far and that this fear will lead them (or us) into all manner of folly iii/ We know how to easily convert document instances which use renaming into ones which don't (whereas conversion of other kinds of uncleanly modified documents is in general problematic or impossible) iiii/ We (or me at least) are not quite sure how to support extra namespaces for renaming modifications with the current tool kit v/ Namespaces are just not the same kind of constraint as schemas -- in particular they are open-ended: any element can assert that it belongs to a given namespace and the assertion cannot be validated Of these I think all but iii are fairly weak. If we take iii seriously though, maybe what it shows is that we do need an extra concept. We have previously spoken about "conformance" and "interchange format" and havered somewhat about the distinction between the two. Maybe what we need instead is a concept of "canonical representation". How about this as a compromise: A conformant TEI document can take either of two forms * local form -- in which ODD-documented renamings are permitted to join the TEI namespace * canonical form -- in which ODD-documented renamings must either be converted to their equivalent TEI form, or must be assigned to some other namespace Probably enough to be going on with, but I would appreciate some indication of where in this diatribe you stopped saying "yeah yeah we know that" L [1] "clean" as defined in the current draft for MD From arianna.ciula at kcl.ac.uk Fri Apr 13 06:11:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 11:11:15 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17950.36177.285828.727857@emt.wwp.brown.edu> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> Message-ID: <461F5743.9000302@kcl.ac.uk> Syd Bauman wrote: >> I will put an updated HTML version of the new chapter into the >> Drafts web page later this evening. Dinner first. > > http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html > updated completely. (I never update this site file-by-file, I just > plop a newly generated complete copy in there, so to read Lou's > latest and greatest, you can go to > http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html.) mh...before continuing proofreading, I have a doubt here. In Lou's latest XML (downloaded from the trunk) I can see: <specList><specDesc key="att.naming" atts="key nimKey"/></specList> However, on Syd's server (at http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html) I only see: att.naming provides attributes common to elements which refer to named persons, places, organizations etc. key provides a means of locating a full definition for the entity being named such as a database record key or a URI. i.e. nimKey is not there. Why is that? Are the two files real mirrors? Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Fri Apr 13 07:21:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 07:21:10 -0400 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F5743.9000302@kcl.ac.uk> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> <461F5743.9000302@kcl.ac.uk> Message-ID: <17951.26534.891669.875211@emt.wwp.brown.edu> > mh...before continuing proofreading, I have a doubt here. In Lou's > latest XML (downloaded from the trunk) I can see: > <specList><specDesc key="att.naming" atts="key nimKey"/></specList> > > However, on Syd's server (at > http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ND.html) I only > see: > > att.naming provides attributes common to elements which refer to named > persons, places, organizations etc. > key provides a means of locating a full definition for the entity being > named such as a database record key or a URI. > > i.e. nimKey is not there. > > Why is that? Are the two files real mirrors? I think because of a mis-match in spelling. The <specDesc> in ND-namesdates.xml is asking for information about the attribute nimKey=. The <classSpec> in att.naming.xml defines the nymKey= attribute. From arianna.ciula at kcl.ac.uk Fri Apr 13 07:31:03 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 12:31:03 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17951.26534.891669.875211@emt.wwp.brown.edu> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> <461F5743.9000302@kcl.ac.uk> <17951.26534.891669.875211@emt.wwp.brown.edu> Message-ID: <461F69F7.1030908@kcl.ac.uk> Syd Bauman wrote: > I think because of a mis-match in spelling. The <specDesc> in > ND-namesdates.xml is asking for information about the attribute > nimKey=. The <classSpec> in att.naming.xml defines the nymKey= > attribute. ops...you are right, thanks. Will change the XML then. Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 07:40:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 12:40:18 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <17951.26534.891669.875211@emt.wwp.brown.edu> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> <461F5743.9000302@kcl.ac.uk> <17951.26534.891669.875211@emt.wwp.brown.edu> Message-ID: <461F6C22.7070708@oucs.ox.ac.uk> Syd Bauman wrote: >> >> >> i.e. nimKey is not there. >> >> Why is that? Are the two files real mirrors? > > I think because of a mis-match in spelling. The <specDesc> in > ND-namesdates.xml is asking for information about the attribute > nimKey=. The <classSpec> in att.naming.xml defines the nymKey= > attribute. > > Not quite. The problem is that the HTML on Syd's site was generated from an older version of the XML source in which the nimKey attribute is erroneously referred to as "nimkey". This error has been corrected in the XML source in SVN, but Syd hasn't yet regenerated his HTML to reflect the correction. From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 07:45:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 12:45:08 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F6C22.7070708@oucs.ox.ac.uk> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> <461F5743.9000302@kcl.ac.uk> <17951.26534.891669.875211@emt.wwp.brown.edu> <461F6C22.7070708@oucs.ox.ac.uk> Message-ID: <461F6D44.9060300@oucs.ox.ac.uk> Lou Burnard wrote: > > Not quite. The problem is that the HTML on Syd's site was generated from > an older version of the XML source in which the nimKey attribute is > erroneously referred to as "nimkey". This error has been corrected in > the XML source in SVN, but Syd hasn't yet regenerated his HTML to > reflect the correction. > > Ooops. No, I am wrong. Spellyng never was my strong poynt. From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 07:50:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 12:50:31 +0100 Subject: [tei-council] New version of ND checked in In-Reply-To: <461F6D44.9060300@oucs.ox.ac.uk> References: <461E7F18.8030502@computing-services.oxford.ac.uk> <17950.36177.285828.727857@emt.wwp.brown.edu> <461F5743.9000302@kcl.ac.uk> <17951.26534.891669.875211@emt.wwp.brown.edu> <461F6C22.7070708@oucs.ox.ac.uk> <461F6D44.9060300@oucs.ox.ac.uk> Message-ID: <461F6E87.8050001@oucs.ox.ac.uk> it can't be beyond the wit of man to generate the HTML dynamically on a web server. its silly to have to depend on Syd's basement server when we pay good money for managed ones..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Fri Apr 13 08:32:19 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 08:32:19 -0400 Subject: [tei-council] dating attrs Message-ID: <17951.30803.46014.797703@emt.wwp.brown.edu> BTW, the development version of the Guidelines (the one which is in https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5/Source/ and available as HTML at http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html) also has all the new dating attributes in it. Since we all voted on it, I don't think there is much controversial there, except as listed below. On the other hand, paying close attention for class errors, typos, etc., would be helpful. Possible Issues -------- ------ * Rather than create a new module for ISO dating attributes, I stuck 'em directly into the namesdates module. * We never decided on the names of the ISO attributes. I called them value-iso= dur-iso= notBefore-iso= etc. My thinking (what little there was) was that it would be nice if these attributes sorted near their "simple" W3C counterparts. * We should perhaps discuss how strong the warnings against using "24:00" and basic formats (i.e., no colons or hyphens in some cases) should be. Currently the remarks say <p>For all representations for which ISO 8601 describes both a <term>basic</term> and an <term>extended</term> format, these Guidelines recommend use of the extended format.</p> <p>While ISO 8601 permits the use of both <code>00:00</code> and <code>24:00</code> to represent midnight, these Guidelines strongly recommend against the use of <code>24:00</code>. <!-- As there are only 24 hours in a day, numbered "00" through "23", use of "24:00" implies a 25th hour, and some software may be confused. Note that when there is a leap second, it should be indicated with 23:59:60. --></p> From lou.burnard at computing-services.oxford.ac.uk Fri Apr 13 08:42:13 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 13 Apr 2007 13:42:13 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> References: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <461F7AA5.70505@oucs.ox.ac.uk> Syd Bauman wrote: > Since we all voted on > it, I don't think there is much controversial there, except as listed > below. On the other hand, paying close attention for class errors, > typos, etc., would be helpful. > The summary of outstanding issues here is useful but I must admit that I for one have long since forgotten the rationale for making these changes, and there doesn't seem to be any prose added to the Guidelines to explain them Could you perhaps remind us why we needed to make this change and how exactly it is meant to be used? > > * Rather than create a new module for ISO dating attributes, I stuck > 'em directly into the namesdates module. I don't think see them there, unless I'm missing something. There's a specList which mentions the attributes' names, but no text discussing them, and the actual classSpec is in ST, where it probably belongs. However, since I've now handed the ND chapter over to Arianna for review, I expect she will comment on this too. > > * We never decided on the names of the ISO attributes. I called them > value-iso= > dur-iso= > notBefore-iso= > etc. My thinking (what little there was) was that it would be nice > sounds plausible to me if these attributes sorted near their "simple" W3C counterparts. > > * We should perhaps discuss how strong the warnings against using > "24:00" and basic formats (i.e., no colons or hyphens in some > cases) should be. Currently the remarks say > > <p>For all representations for which ISO 8601 describes both a > <term>basic</term> and an <term>extended</term> format, these > Guidelines recommend use of the extended format.</p> > <p>While ISO 8601 permits the use of both <code>00:00</code> and > <code>24:00</code> to represent midnight, these Guidelines > strongly recommend against the use of <code>24:00</code>. I think "recommend" is enough: it's not so big a deal surely? The notion of "recommended practice" is something we explicitly talk about in the context of conformance, so having a quick checklist of occasions, like this, where we *do* make a recommendation would be very useful. From arianna.ciula at kcl.ac.uk Fri Apr 13 08:50:23 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 13:50:23 +0100 Subject: [tei-council] dating attrs In-Reply-To: <461F7AA5.70505@oucs.ox.ac.uk> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F7AA5.70505@oucs.ox.ac.uk> Message-ID: <461F7C8F.7050502@kcl.ac.uk> Lou Burnard wrote: > Syd Bauman wrote: >> Since we all voted on >> it, I don't think there is much controversial there, except as listed >> below. On the other hand, paying close attention for class errors, >> typos, etc., would be helpful. >> > > The summary of outstanding issues here is useful but I must admit that I > for one have long since forgotten the rationale for making these > changes, and there doesn't seem to be any prose added to the Guidelines > to explain them > > Could you perhaps remind us why we needed to make this change and how > exactly it is meant to be used? > >> >> * Rather than create a new module for ISO dating attributes, I stuck >> 'em directly into the namesdates module. > > I don't think see them there, unless I'm missing something. There's a > specList which mentions the attributes' names, but no text discussing > them, and the actual classSpec is in ST, where it probably belongs. I can seem them in ND as <specList> <specDesc key="data.temporal.iso"/> <specDesc key="data.duration.iso"/></specList> > > However, since I've now handed the ND chapter over to Arianna for > review, I expect she will comment on this too. Will make comments once I'll get there if will be able to. > >> >> * We never decided on the names of the ISO attributes. I called them >> value-iso= >> dur-iso= >> notBefore-iso= >> etc. My thinking (what little there was) was that it would be nice >> > > sounds plausible to me > > if these attributes sorted near their "simple" W3C counterparts. >> >> * We should perhaps discuss how strong the warnings against using >> "24:00" and basic formats (i.e., no colons or hyphens in some >> cases) should be. Currently the remarks say >> >> <p>For all representations for which ISO 8601 describes both a >> <term>basic</term> and an <term>extended</term> format, these >> Guidelines recommend use of the extended format.</p> >> <p>While ISO 8601 permits the use of both <code>00:00</code> and >> <code>24:00</code> to represent midnight, these Guidelines >> strongly recommend against the use of <code>24:00</code>. > > > I think "recommend" is enough: it's not so big a deal surely? > > The notion of "recommended practice" is something we explicitly talk > about in the context of conformance, so having a quick checklist of > occasions, like this, where we *do* make a recommendation would be very > useful. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 08:58:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 13:58:58 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <461F7E92.8080201@oucs.ox.ac.uk> I think I am reaching a little closer to understanding; and I think I am now happy that anything which makes a document unclean must not be in the TEI namespace. * The case where a customization adds an entirely new element, and how to deal with the namespace there, seems clear. * The language translations seem clear too. * The case where I rename "div1" to "section" is less clear, because the document can go four ways: a) distributed in pure TEI form, back to <div1>, via a canonicalizer b) foreign namespace form, to <myspace:section> c) non-conformant, with <section> in TEI namespace d) put entire document in foreign namespace (syntactic sugar similarly, assuming we understand <equiv>) The detailed ramifications and recommendations are what concern me, because the person currently doing this will naturally say "OK, so what is the Right Thing for me to do now". Can someone tell me the story of what how the div1/section thing will pan out in real-life workflow? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Fri Apr 13 09:49:37 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 14:49:37 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <461F8A71.6090904@oucs.ox.ac.uk> Lou Burnard wrote: > 1. "Conformance" means, fundamentally, conformance to the TEI abstract > model. The markup scheme defined by or applied in a TEI conformant > document marks up abstract concepts which are also present in the TEI > abstract model, and with the same meaning. > > 2. The particular part of the TEI abstract model which a set of document > uses can be expressed in three ways, only two of which can be > automatically checked: > > a) the application of the elements is something that a human reader > recognizes as plausible i.e. the thing tagged <l> does actually contain > a line of verse > > b) particular things are called by particular names i.e. the thing > containing a line of verse is called <l> (in the TEI namespace) and not > <line>. Namespaces are a useful way of asserting whether the "l" here > is the TEI "<l>" or some other one. > > c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but > not vice versa. Validating this is what schemas are for. > > 3. Modification/customization/personalization is something we do in > order to generate and document a schema, so it is about both (a) and > (c). A modification which replaces the <desc> of <l> to say that it is > for typographic lines is an unclean one, as is one which modifies its > content model to permit <div>s within it -- in the same way and for > the same reasons. Only "clean"[1] modifications are conformant (this > doesnt mean that unclean modifications are evil, just that they are > different. Most improvements to the TEI scheme start off life as unclean > modifications.) All of this seems reasonable to me so far. And I agree that we should highlight that non-conformance is not evil, and is where useful development takes place. > 4. We are disagreeing about whether or not a modification which is a > simple renaming is unclean, i.e. about whether 2(b) is somehow different > from the other kinds of conformance constraint. I can identify the > following reasons for this disagreement: ... iii/ We know how to easily > convert document instances which use renaming into ones which don't > (whereas conversion of other kinds of uncleanly modified documents is in > general problematic or impossible) ... Of these I think all but iii are > fairly weak. If we take iii seriously though, maybe what it shows is > that we do need an extra concept. We have previously spoken about > "conformance" and "interchange format" and havered somewhat about the > distinction between the two. Maybe what we need instead is a concept of > "canonical representation". Ok, I'm not sure that I follow the logic here. Yes, we know how to easily convert document instances which use syntactic sugar renaming into ones which don't. I don't see that it necessarily follows that the necessary solution to this is two types of Conformance. I think in the rigid use of namespaces that Conal argues for, that even these renamings should be in a separate namespace. Otherwise the TEI namespace is polluted. If there is local vs canonical versions, > How about this as a compromise: A conformant TEI document can take > either of two forms * local form -- in which ODD-documented renamings > are permitted to join the TEI namespace * canonical form -- in which > ODD-documented renamings must either be converted to their equivalent > TEI form, or must be assigned to some other namespace While it was part of my original draft that because we know how to undo renamings, that these be allowed to pollute the TEI namespace, I'm still not convinced by these two types of conformance. I want to know that when a document is conformant it is one type of thing, not two possible types of things. That is, I think the canonical form is Conformant, and the local form is not. All of the arguments you posted as to why the local form should be acceptable are reasonable, but as I understand it that we know how to easily convert back renamings isn't a good reason to step down from the Namespace Moral High Ground. If the local form uses a user-defined namespace for all these modifications, than it suddenly becomes conformant. I understand 'clean' modifications to be those which constrain the TEI further so that a resulting document instance would still validate against tei_all. Renamings, by definition, don't do this. Unless, yes, we pass them through some sort of canonicalising processing step. But because they are able to be put through this processing doesn't make them any more TEI elements than ones I've added by hand. There are other unclean modifications I can make, say expressing my date attributes values in a form of "07/04/13", which we can all agree are unclean. I can write an xslt stylesheet (if I've been consistent) which changes these into 2007-04-13, but that doesn't mean my document deserves some special status as Conformant, even if I've documented my change in an ODD. Or does it? While I agree that syntactic sugar renamings are a specialised case of this, I'm not convinced they are truly a different thing. But maybe I'm not fully understanding what your definition of 'clean' is. The MD draft says: > Each schema resulting from a modified combination of TEI modules will > define a different set of documents. The set of documents valid > according to the unmodified schema may be properly contained in the set > of documents considered to be valid according to the modified schema, or > vice versa. Modifications that have either of these two results are > called clean modifications. Alternatively, the set of documents > considered valid by the original schema might overlap the set of > documents considered valid by the modified schema with neither being > properly contained in the other. Modifications that have this result are > called unclean modifications. Clear as mud. If I'm understanding it right, this means documents that validate against tei_all must also validate against the modified schema, or the documents that validate against the modified schema, must also validate against tei_all. Or am I misunderstanding? (In either case, more explanation of these two concepts would be useful to readers.) I don't see that renamings fit into that definition of clean, and I don't want to introduce and extra step (canonicalisation) that users need to go through. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 10:19:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 15:19:21 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F7E92.8080201@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> Message-ID: <461F9169.5040401@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > * The case where I rename "div1" to "section" > is less clear, because the document can go four ways: > > a) distributed in pure TEI form, back to <div1>, via a canonicalizer > b) foreign namespace form, to <myspace:section> > c) non-conformant, with <section> in TEI namespace > d) put entire document in foreign namespace > > (syntactic sugar similarly, assuming we understand <equiv>) It is c) that I think I disagree with Lou about. I am convinced now that if you rename tei:div1 to tei:section you are now non-conformant because you provide an element in the TEI namespace that the TEI has not defined. Namespaces say 'we are part of this' and if the TEI buys the concept of namespaces I think it needs to also accept that then only it can define TEI elements. (i.e. all the rest are in another namespace or not 'official' (i.e. non-conformant).) > The detailed ramifications and recommendations are what > concern me, because the person currently doing this > will naturally say "OK, so what is the Right Thing > for me to do now". Yes, I agree that these concern me as well, and that more time than we think is going to have to be spent on making the default process as clear and painless for users. > Can someone tell me the story of what how > the div1/section thing will pan out in real-life > workflow? Here is how I'd want it to work: Johannes Projektmann after reading a lot about the TEI, comes to webRoma and wants to rename div1 to section. This is the only change he wants to make. Johannes fills in the form and Roma puts this 'section' element in a new namespace which he has an option of customising. He saves his ODD file so he can come back and customise it later, and generates a Relax NG XML schema which is able to validate his documents (including the my:section elements and the tei elements they contain). Because his documents validate against schemas that Roma produces from this ODD, they are Conformant, and he doesn't have to worry about doing anything to his document instances to make them so. (Other, perhaps, of making the ODD available.) Later, after much more experience, he decides he really needs a 'thingy' element, for something the TEI doesn't really know about. So he feeds his ODD back in, and adds a new element, optionally placing it in the same namespace as his earlier change. The my:thingy element has a complex content model that includes references to TEI classes and pointers to outside schemas like SVG. He saves his ODD, and regenerates his schemas and they produce a Relax NG schema which validates his documents including his my:thingy elements and their funny contents which are part TEI and part SVG. His documents are still Conformant (though perhaps a different 'variety' of conformance). If Johannes needs to run something else to make his documents fully conformant, then he won't bother doing so. But if it "just works", then he'll happily be conformant. I recognise I'm side stepping some of the issues there. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 10:21:58 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 15:21:58 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F8A71.6090904@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F8A71.6090904@oucs.ox.ac.uk> Message-ID: <461F9206.1080204@computing-services.oxford.ac.uk> James Cummings wrote: > solution to this is two types of Conformance. I think in the rigid use of > namespaces that Conal argues for, that even these renamings should be in a > separate namespace. Otherwise the TEI namespace is polluted. If there is > local vs canonical versions, (I seemed to have stopped in mid thought there, I probably meant to continue something like:) "... then the namespace is still polluted. (Which I think it shouldn't be on grounds of principle, rather than on anticipation of actual collision, etc.)" -james -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:07:25 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:07:25 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F9169.5040401@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> Message-ID: <461F9CAD.6040106@oucs.ox.ac.uk> James Cummings wrote: > > I recognise I'm side stepping some of the issues there. > When you contact Johannes and say "can you send me your document for my corpus", what does he do? I am rapidly coming to the conclusion that Roma should seriously downplay the use of <altIdent>, and use it mainly for the full-scale language translations, where the whole doc changes namespace. Using <altIdent> to rename div1 to section, and then forcing JP to use <my:section> seems unfriendly and unhelpful. If he really wants to use alternate notation for the TEI abstract model, better if he switches namespace for the whole document. I shudder to think about the work needed on Roma to support the last 2 weeks discussion properly. I am now assuming that, inter alia, Roma should support a "canonical mode", in which <altIdent> and <equiv> follow a different route, in which the schema created is canonical, but as a side effect an ad hoc canonicaliser is created for you, to apply to documents which are valid against a non-canonical schema. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:11:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:11:08 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> References: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <461F9D8C.90604@oucs.ox.ac.uk> I am a little bothered by the variation in names of *Spec. It seems to me that "att.dateTime.iso" does not follow TEI naming practice? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Fri Apr 13 11:19:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 11:19:58 -0400 Subject: [tei-council] dating attrs In-Reply-To: <461F9D8C.90604@oucs.ox.ac.uk> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F9D8C.90604@oucs.ox.ac.uk> Message-ID: <17951.40862.894630.161583@emt.wwp.brown.edu> > I am a little bothered by the variation in names of *Spec. It seems > to me that "att.dateTime.iso" does not follow TEI naming practice? What would you suggest? From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 11:29:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 16:29:10 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.40862.894630.161583@emt.wwp.brown.edu> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F9D8C.90604@oucs.ox.ac.uk> <17951.40862.894630.161583@emt.wwp.brown.edu> Message-ID: <461FA1C6.1020106@oucs.ox.ac.uk> Syd Bauman wrote: >> I am a little bothered by the variation in names of *Spec. It seems >> to me that "att.dateTime.iso" does not follow TEI naming practice? >> > > What would you suggest? > att.isoDateTime, unfortunately -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Fri Apr 13 11:40:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 13 Apr 2007 11:40:45 -0400 Subject: [tei-council] dating attrs In-Reply-To: <461FA1C6.1020106@oucs.ox.ac.uk> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F9D8C.90604@oucs.ox.ac.uk> <17951.40862.894630.161583@emt.wwp.brown.edu> <461FA1C6.1020106@oucs.ox.ac.uk> Message-ID: <17951.42109.547286.804926@emt.wwp.brown.edu> > att.isoDateTime, unfortunately If it's so unfortunate, perhaps the practice should change (in this case, to more closely resemble the naming practices of model classes). I thought you were going to complain that "dateTime" is not adjectival. From daniel.odonnell at uleth.ca Fri Apr 13 11:44:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 09:44:07 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F5121.9040905@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> Message-ID: <1176479048.6268.21.camel@caedmon> On Fri, 2007-04-13 at 10:45 +0100, Lou Burnard wrote: > Let me try to reformulate the issues here: > > 1. "Conformance" means, fundamentally, conformance to the TEI abstract > model. The markup scheme defined by or applied in a TEI conformant > document marks up abstract concepts which are also present in the TEI > abstract model, and with the same meaning. This is a definition of identity, not conformance, IMO. For me conformance means the same as what I've always understood "clean" to mean: not necessarily identity, but any changes that have been made a) can be undone using canonical tools that must be provided with the document (i.e. <equiv> and the like and ODDs) b) are made using provided mechanisms for making such changes. a) is fundamental; b) is slightly less so since the end of SGML days. > > 2. The particular part of the TEI abstract model which a set of document > uses can be expressed in three ways, only two of which can be > automatically checked: > > a) the application of the elements is something that a human reader > recognizes as plausible i.e. the thing tagged <l> does actually contain > a line of verse > > b) particular things are called by particular names i.e. the thing > containing a line of verse is called <l> (in the TEI namespace) and not > <line>. Namespaces are a useful way of asserting whether the "l" here > is the TEI "<l>" or some other one. > > c) TEI syntactic rules are respected e.g. <l>s appear inside <div>s but > not vice versa. Validating this is what schemas are for. Or you could have renamed <l> <line> and i) properly documented this with <equiv> (a local renaming) and/or ii) built it into an ODD (as in Tite, as proposed in this discussion) or iii) changed it back before shipping it to somebody else (interchange). All three of these methods are essentially methods of achieving your states b) and/or c) and are open to automatic checking. I hasten to note moreover, that I am saying these should be allowed ONLY on the condition that they can be reversed on a 1:1 basis and reversed using supplied information. I.e. if you don't use equiv, introduce a conflict to the existing TEI namespace you are using, and/or don't supply the ODD, the document is not conformant. > > 3. Modification/customization/personalization is something we do in > order to generate and document a schema, so it is about both (a) and > (c). A modification which replaces the <desc> of <l> to say that it is > for typographic lines is an unclean one, as is one which modifies its > content model to permit <div>s within it -- in the same way and for > the same reasons. Only "clean"[1] modifications are conformant (this > doesnt mean that unclean modifications are evil, just that they are > different. Most improvements to the TEI scheme start off life as unclean > modifications.) > > 4. We are disagreeing about whether or not a modification which is a > simple renaming is unclean, i.e. about whether 2(b) is somehow different > from the other kinds of conformance constraint. I can identify the > following reasons for this disagreement: > > i/ We are so used to seeing different names for the same thing that it > just doesn't seem important to insist on using a specific name, or to > insist that names declare their namespace. (cf the pain of going from > case-insensitive to case-sensitive identifiers which some of us old'uns > are still suffering from). Not a great reason, but not a bad one either for projects that have invested immense amount of time in legacy training and/or data. And not by any means a fatal error--it allows more things to be acceptable P5 without polluting the namespace because it is automatically undoable if the document is conformant in the way I've described it. > > ii/ We think many people will find namespace technology a step too far > and that this fear will lead them (or us) into all manner of folly Not a good reason in my view. I agree with whoever it was who pointed to the parallel with SGMLers attitude towards the question of throwing errors in XML. > > iii/ We know how to easily convert document instances which use renaming > into ones which don't (whereas conversion of other kinds of uncleanly > modified documents is in general problematic or impossible) This is THE crucial distinction in my view. I still thing "conformant documents are identical to canonical TEI or cleanly and recoverably modified from it" is the principle we should have. > > iiii/ We (or me at least) are not quite sure how to support extra > namespaces for renaming modifications with the current tool kit Not such a good reason in my view. > > v/ Namespaces are just not the same kind of constraint as schemas -- in > particular they are open-ended: any element can assert that it belongs > to a given namespace and the assertion cannot be validated Not really an issue. > > > Of these I think all but iii are fairly weak. If we take iii seriously > though, maybe what it shows is that we do need an extra concept. We have > previously spoken about "conformance" and "interchange format" and > havered somewhat about the distinction between the two. Maybe what we > need instead is a concept of "canonical representation". > > How about this as a compromise: > > A conformant TEI document can take either of two forms > > * local form -- in which ODD-documented renamings are permitted to join > the TEI namespace > * canonical form -- in which ODD-documented renamings must either be > converted to their equivalent TEI form, or must be assigned to some > other namespace Basically this looks like "conformant" (in my non-"identical" sense above) and "identical" (in your "conformant" sense, above). I think "local" is a misnomer, however, since that implies that it is for local use only, whereas your tagging it as "conformant" and the provisos you add make it clear that it is useful for interchange. If you revise the definition of local to "in which ODD-documented renamings THAT DO NOT CONFLICT WITH CANONICAL FORMS" to you definition of local (capitals = <hi> not <shout>), then you have a form that can be pretty freely circulated as long as the ODD is included--which given the big deal we are making of it, seems not unreasonable. As I read this, what is striking to me that the difference between what you call "local" (if you edit it as I suggest) and "canonical" forms really involves where the processing is done: on my computer or on yours. This suggests to me they may be from an XML point of more much of a more-or-less-ness. > > Probably enough to be going on with, but I would appreciate some > indication of where in this diatribe you stopped saying "yeah yeah we > know that" Hopefully the annotations will help ;) > > > L > > > [1] "clean" as defined in the current draft for MD > > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at computing-services.oxford.ac.uk Fri Apr 13 11:49:53 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 13 Apr 2007 16:49:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461F9CAD.6040106@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> Message-ID: <461FA6A1.7000308@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> >> I recognise I'm side stepping some of the issues there. >> > When you contact Johannes and say "can you send me your > document for my corpus", what does he do? He says "My document is freely available at the following URI: http://www.projektmann.de/meinDokument.xml It's teiHeader includes a pointer to the licence it is released under, and also a pointer to the ODD, just where the Guidelines say I should include such things." > I am rapidly coming to the conclusion that Roma > should seriously downplay the use of <altIdent>, > and use it mainly for the full-scale language > translations, where the whole doc changes > namespace. Using <altIdent> to rename > div1 to section, and then forcing JP to > use <my:section> seems unfriendly and > unhelpful. If he really wants to use alternate > notation for the TEI abstract model, better if > he switches namespace for the whole document. So you are suggesting that if I want to rename 'div1' to 'section' then the entire document is no longer TEI, doesn't use TEI elements and so shouldn't be in the TEI namespace??! That seems much more extreme than anything we've been suggesting, doesn't it? > I shudder to think about the work needed on > Roma to support the last 2 weeks discussion > properly. Yes, that is my worry as well. > I am now assuming that, inter alia, > Roma should support a "canonical mode", in which > <altIdent> and <equiv> follow a different > route, in which the schema created is canonical, > but as a side effect an ad hoc canonicaliser > is created for you, to apply to documents > which are valid against a non-canonical > schema. I'm not sure I buy this two types of conformant documents, a local non-namespaced one and a canonical one. While command-line Roma maybe should have this distinction, I'm convinced that we should strive to have webRoma only produce ODDs (to generate schemas) to validate Conformant documents. -james -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From daniel.odonnell at uleth.ca Fri Apr 13 11:57:44 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 09:57:44 -0600 Subject: [tei-council] dating attrs In-Reply-To: <17951.42109.547286.804926@emt.wwp.brown.edu> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F9D8C.90604@oucs.ox.ac.uk> <17951.40862.894630.161583@emt.wwp.brown.edu> <461FA1C6.1020106@oucs.ox.ac.uk> <17951.42109.547286.804926@emt.wwp.brown.edu> Message-ID: <1176479864.6268.32.camel@caedmon> On Fri, 2007-04-13 at 11:40 -0400, Syd Bauman wrote: > > att.isoDateTime, unfortunately > > If it's so unfortunate, perhaps the practice should change (in this > case, to more closely resemble the naming practices of model > classes). > > I thought you were going to complain that "dateTime" is not > adjectival. Since dating has come up, I'd like to ask a question that seems to have got lost in our placename discussion: should we not have an @at attribute as well as @from, @to, @notbefore and @notafter? Fort Whoop Up near Lethbridge was founded not before 1869 (they were rumrunners, so they didn't make an official announcement) and it washed away in the flood of the Old Man river of 1915, though I don't know the date, so notBefore="1869"/to="1915" are acceptable values. Opening cermonies, however, happen at specific times and do not represent a range. The North West Mounted Police arrived at Fort Whoop Up on, let's say, November 11, 1874. If my placeEvent is that they arrived (as opposed to that they arrived and stayed for a while), @from is not really an appropriate attribute. Likewise with incorporations. The birth element has @date for birth dates for exactly this reason. Since people are not the only things that have exactlyAt events in their lives, I wonder if we shouldn't have this as a generalisable attribute. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Fri Apr 13 12:22:11 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 13 Apr 2007 10:22:11 -0600 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461EC237.7020407@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EBEC5.6050106@computing-services.oxford.ac.uk> <461EC237.7020407@oucs.ox.ac.uk> Message-ID: <1176481331.6268.49.camel@caedmon> On Fri, 2007-04-13 at 00:35 +0100, Sebastian Rahtz wrote: > Lou Burnard wrote: > > I don't get this. If you want 1 character tag names, don't use the > > TEI. Write your own schema, define a mapping between it and the TEI. > > You have attained conformance without confusing the TEI namespace. Next. > > > As Syd says, no sane Tite user would pay for <x:sup> over <sup>, > so Tite won't conform; unlike Lite, which _will_ be OK. Also, this is running against what I've always seen as the customisation principle of the TEI: we provide a standard and methods of customising that standard to your specific needs. ROMA provide you with custom ODDs that fit your precise encoding situation and keep you conformant, renaming provides a mechanism for meeting your keyboarding and/or training needs while remaining conformant. While I am not at all against being quite strict about minimum requirements, I think we don't need to go out of our way to ban behaviour that can be easily reconciled with the canonical standard. -dan > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From arianna.ciula at kcl.ac.uk Fri Apr 13 12:52:53 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 13 Apr 2007 17:52:53 +0100 Subject: [tei-council] dating attrs In-Reply-To: <1176479864.6268.32.camel@caedmon> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <461F9D8C.90604@oucs.ox.ac.uk> <17951.40862.894630.161583@emt.wwp.brown.edu> <461FA1C6.1020106@oucs.ox.ac.uk> <17951.42109.547286.804926@emt.wwp.brown.edu> <1176479864.6268.32.camel@caedmon> Message-ID: <461FB565.40905@kcl.ac.uk> Daniel O'Donnell wrote: > On Fri, 2007-04-13 at 11:40 -0400, Syd Bauman wrote: >>> att.isoDateTime, unfortunately >> If it's so unfortunate, perhaps the practice should change (in this >> case, to more closely resemble the naming practices of model >> classes). >> >> I thought you were going to complain that "dateTime" is not >> adjectival. > > Since dating has come up, I'd like to ask a question that seems to have > got lost in our placename discussion: should we not have an @at > attribute as well as @from, @to, @notbefore and @notafter? Before creating yet another attribute for specifying dates, I would see whether some or all the elements related to place names (and person names as well?) could be members of the new class att.dateTime. Or am I not understanding where we are going at all? Arianna > > Fort Whoop Up near Lethbridge was founded not before 1869 (they were > rumrunners, so they didn't make an official announcement) and it washed > away in the flood of the Old Man river of 1915, though I don't know the > date, so notBefore="1869"/to="1915" are acceptable values. > > Opening cermonies, however, happen at specific times and do not > represent a range. The North West Mounted Police arrived at Fort Whoop > Up on, let's say, November 11, 1874. If my placeEvent is that they > arrived (as opposed to that they arrived and stayed for a while), @from > is not really an appropriate attribute. Likewise with incorporations. > > The birth element has @date for birth dates for exactly this reason. > Since people are not the only things that have exactlyAt events in their > lives, I wonder if we shouldn't have this as a generalisable attribute. > > >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 13 16:39:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Apr 2007 21:39:47 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <17942.57589.177531.95758@emt.wwp.brown.edu> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> Message-ID: <461FEA93.5020604@oucs.ox.ac.uk> apropos of a thread I saw somewhere, the cognoscenti will remember that I gave a talk at XML Europe in 2004 demonstrating how to merge TEI and Docbook, using pure RELAX NG fragments stuff like this: include "Schema/figures.rnc" { datatype.Formula = mathml.math formula.attributes = attribute id { datatype.ID }?, attribute notation { formulaNotations }?, attribute type { text }? } (not up to date, obviously). Just in case anyone doubted that customizing the TEI in pure RELAX NG is relatively easy, and has been done. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sat Apr 14 03:49:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 08:49:51 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <461FEA93.5020604@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> Message-ID: <4620879F.1020907@oucs.ox.ac.uk> Sebastian Rahtz wrote: > apropos of a thread I saw somewhere, the cognoscenti will > remember that I gave a talk at XML Europe in 2004 demonstrating > how to merge TEI and Docbook, using pure RELAX NG fragments > > stuff like this: > > include "Schema/figures.rnc" { > datatype.Formula = mathml.math > formula.attributes = > attribute id { datatype.ID }?, > attribute notation { formulaNotations }?, > attribute type { text }? > } > > (not up to date, obviously). > > Just in case anyone doubted that customizing the TEI > in pure RELAX NG is relatively easy, and has been done. I never doubt that this was possible or something that some people would do. Because your subject line relates this to conformance, I'm assuming that your implication is that we should reconsider the requirement of ODD for conformance? Does the fact that this is fairly easy, and has been done previously, affect the council's decision that an ODD is required for conformance? -James From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 06:40:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 11:40:39 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620879F.1020907@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> Message-ID: <4620AFA7.605@oucs.ox.ac.uk> James Cummings wrote: > Because your subject line relates this to conformance, I'm assuming > that your implication is that we should reconsider the requirement of > ODD for conformance? Does the fact that this is fairly easy, and has > been done previously, affect the council's decision that an ODD is > required for conformance? not really. I am generally happy with TEI Conformance being a serious target, including ODD (though see below). I do want to remember the debate, though, about what we should deliver. It seriously affects the description of what an ODD processor should do if I say that it must generate a parameterized schema with clearly defined entry points. Can the user guarentee that for every "model.foo" she reads about in the guidelines there is a corresponding RELAX NG pattern "model.foo" in a RELAXNG schema published by the TEI? there is no apriori reason why R_ODD (ie the XSL stylesheets which are beyond Roma, and are our defacto definition of what an ODD processor should do) _should_ preserve those names, you understand, or even preserve the knowledge of classes in the schemas it generates. In the flurry of emails over Easter which I finally read (don't you guys have holidays?), I see a pretty clear consensus that conformance and ODD are closely linked, and that modification via DTD or RELAX NG fragments is simply not on. I am not sure I see a clear conclusion as to whether we continue to generate the DTD and RELAX NG modules for those who don't give a dang about conformance. Can I introduce you to someone? This person (let's call him Wohann :-}) shuns ODD entirely, and maintains his customization by writing a wrapper RELAX NG schema which does just what he wants, pulling in bits of TEI RELAX NG schemas. It is readable, documented, efficient and expressive. He uses extra features of RELAX NG or other ISO DSDL standards to manage his documents to a high standard. He is, you may say, non-conformant. He cannot show his "workings" in the approved form, and gets an F. HOWEVER, when you get Wohann's document, it validates fine against tei_all. If he could be bothered, he could write an ODD equivalent of his hand-crafted schema, and the document would validate against that too. The document validates against _many_ schemas, and breaks no TEI semantic or syntactic rules. It adds no new elements or does any renaming, or breaks any models. So two questions: a) Can Wohann put the "TEI Conformant" badge on his web site, by the fiction that his ODD is the implicit tei_all? Even though he and all his workers use the evil little hand-crafted schema, and the document contains a PI linking to that? b) do we encourage/support/allow Wohann's working method by generating the schemas for him? Or I am just going the mulberry bush again? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 07:00:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 12:00:16 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <461FA6A1.7000308@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> Message-ID: <4620B440.604@oucs.ox.ac.uk> James Cummings wrote: > > So you are suggesting that if I want to rename 'div1' to 'section' then the > entire document is no longer TEI, doesn't use TEI elements and so shouldn't > be in the TEI namespace??! That seems much more extreme than anything > we've been suggesting, doesn't it? > no, I am saying that Johann might prefer to see it this way, to avoid the chop and change of namespaces every other line. His choice. > > While command-line Roma maybe > should have this distinction, I'm convinced that we should strive to have > webRoma only produce ODDs (to generate schemas) to validate Conformant > documents. > yes, whichever way you do it, conformant documents are involved. the distinction is between conformant and interchangeable, ie where the <altIdent>s have been reversed. all conformant documents have the potential to be canonical as well, after a transformation. So how about Roma shows you a new paradigm? Instead of "renaming div1 to section", it only lets you add a new element called "section"; however, when you create it, you have the short-form option of saying "I want it to be a *move* of div1, but I want to change the name, the description and the examples". So you get the "edit element" screen, but with no chance to change classes or content model; you are *forced* to use a new namespace. This removes the possibility in webRoma (command line Roma is just an ODD processor, so not relevant) of doing simple renames. Internally, we manage the "move of div1to section" as a change of div1 and an <altIdent>. I am groping here towards a work plan for rewriting Roma. If we can make the use of <altIdent> much harder, that strange case which bothers us arises less often; either way, a new namespace for a moved or new element is mandatory; and the algorithm for that is that we start off forcing you to think one up, and thereafter propose the same as you said last time. Whether newly added attributes are forced to a namespace, as opposed to the default null one, is tricky. I am personally inclined to think that this is <soCalled>political correctness gone mad</soCalled>. I still believe that we have an option in Roma (maybe just on the desktop version for advanced use) which ignores the <altIdent>s and generates a script to reverse them and <equiv>s you have stuck in, probably by hand, in documents. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sat Apr 14 07:56:05 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 12:56:05 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620AFA7.605@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> <4620AFA7.605@oucs.ox.ac.uk> Message-ID: <4620C155.1080907@oucs.ox.ac.uk> Sebastian Rahtz wrote: > on. I am not sure I see a clear conclusion as to whether we continue to > generate > the DTD and RELAX NG modules for those who don't give a dang about > conformance. I feel this is optional but nice -- does it take much effort to produce them? Yes they can be used as you describe below, but I don't think that is reason to no produce them if this is done automatically. > Can I introduce you to someone? This person (let's call him Wohann :-}) > shuns ODD entirely, and maintains his customization by writing > a wrapper RELAX NG schema which does just what he wants, pulling > in bits of TEI RELAX NG schemas. It is readable, > documented, efficient and expressive. He uses extra features of RELAX NG > or other ISO DSDL standards to manage his documents to a high standard. > He is, you may say, non-conformant. He cannot show his "workings" > in the approved form, and gets an F. Students are customers these days and thus rarely receive Fs. He would be given some credit for his obvious understanding of the system. I'd give him a C- or a D. :-) > HOWEVER, when you get Wohann's document, > it validates fine against tei_all. If he could be bothered, he could write > an ODD equivalent of his hand-crafted schema, and the document would > validate against that too. The document validates against _many_ schemas, > and breaks no TEI semantic or syntactic rules. It adds no new elements > or does any renaming, or breaks any models. Sounds like the document is conformant, even if his schema is not a conformantly created one. > So two questions: > > a) Can Wohann put the "TEI Conformant" badge on his web site, by the > fiction > that his ODD is the implicit tei_all? Even though he and all his workers > use the evil little hand-crafted schema, and the document contains a PI > linking to that? Yes. Wohann's documents are conformant with reference to the tei_all ODD and schemas. This situation is also true of all TEI Pure Subset Schemas... they do not *need* to provide their ODD because they can claim they are using tei_all (or another existing subset like tei_lite if it contains the entirety of their subset). They are encouraged to provide their ODD as documentation and use ODD to customise the TEI to constrain it to their purposes. But this is like taking your non-namespaced non-conformant documents and then adding in the namespace -- Conformance has nothing to say on how your documents got to the state they are in, simply whether they are conformant at the point or not. > b) do we encourage/support/allow Wohann's working method by generating > the schemas for him? I'm ambivalent about that. If it is a pain to do, then let's not, knowing Wohann's skills I'm sure he could do this himself, if it isn't a pain to do this, then I don't see that doing so really affects the conformance message. There are always other non-conformant ways to do things which may end up in giving you Conformant documents. > Or I am just going the mulberry bush again? Always useful to check for needed pruning. -James From James.Cummings at oucs.ox.ac.uk Sat Apr 14 08:07:00 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 13:07:00 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620B440.604@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> Message-ID: <4620C3E4.2070206@oucs.ox.ac.uk> Sebastian Rahtz wrote: > no, I am saying that Johann might prefer to see it this > way, to avoid the chop and change of namespaces > every other line. His choice. Oh that's fine then. So he produces a non-conformant document which he can then transform back at some stage should he desire. > yes, whichever way you do it, conformant documents > are involved. the distinction is between conformant > and interchangeable, ie where the <altIdent>s have > been reversed. Yes, I see what you mean. > all conformant documents have > the potential to be canonical as well, after a transformation. If canonical only means that renamings are reversed, then this is true. But remember there will still be all those extensions in the user-defined namespace(s) which can't be transformed back (reliably) to PureTEI (tm). > So how about Roma shows you a new paradigm? > Instead of "renaming div1 to section", it > only lets you add a new element called "section"; > however, when you create it, you have the short-form > option of saying "I want it to be a *move* of div1, > but I want to change the name, > the description and the examples". So you get > the "edit element" screen, but with no chance > to change classes or content model; you are > *forced* to use a new namespace. This seems reasonable to me. Would I also have a short-form of saying I want my element not to be a *move* but a *copy*? I.e. given me the same content model/class affiliations as element X? > This removes the possibility in webRoma (command > line Roma is just an ODD processor, so not > relevant) of doing simple renames. Internally, > we manage the "move of div1to section" as > a change of div1 and an <altIdent>. Seems reasonable. > I am groping here towards a work plan > for rewriting Roma. Yes, I recognise that, and think there will be a lot more work here than perhaps originally conceived. > If we can make the use > of <altIdent> much harder, that strange > case which bothers us arises less often; either > way, a new namespace for a moved or new > element is mandatory; and the algorithm for that > is that we start off forcing you to think one up, > and thereafter propose the same as you said > last time. Sounds good to me, I'm sure Johannes would be happy with that, don't know about Wohann though, but he's doing his own thing. > Whether newly added attributes are forced to a > namespace, as opposed to the default null one, > is tricky. I am personally inclined to think > that this is <soCalled>political > correctness gone mad</soCalled>. Current consensus seems to be that they should so they don't collide with existing elements, etc. > I still believe that we have an option in Roma > (maybe just on the desktop version for advanced > use) which ignores the <altIdent>s > and generates a script to reverse them and > <equiv>s you have stuck in, probably by hand, > in documents. That would be nice. (But 'nice' taking less priority than other Roma development I think.) -James From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 08:33:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 13:33:32 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620C155.1080907@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> <4620AFA7.605@oucs.ox.ac.uk> <4620C155.1080907@oucs.ox.ac.uk> Message-ID: <4620CA1C.4080502@oucs.ox.ac.uk> James Cummings wrote: > > I feel this is optional but nice -- does it take much effort to > produce them? Yes they can be used as you describe below, but I don't > think that is reason to no produce them if this is done automatically. The modules were, until recently, what we regarded as the primary output of the Guidelines. The "compiled schema" came later. So, yes, the work is all done. > > I'm ambivalent about that. If it is a pain to do, then let's not, > knowing Wohann's skills I'm sure he could do this himself, when someone writes the first non-Consortium ODD processor, oh frabjous day. So my critical question is whether the form of the generated schema and DTD fragments is normative or merely indicative. Can I break the format at P5.1? In case anyone is wondering, it really is not that obvious what to model in the RELAX NG schemas. CUrrently I say foo = foo.content, foo.attributes because that lets you say foo.attributes = empty but I could equally say foo = foo.content, attribute bar ( text) and miss out the intermediate stage. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 08:39:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 13:39:53 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620C3E4.2070206@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> Message-ID: <4620CB99.7090207@oucs.ox.ac.uk> James Cummings wrote: > > This seems reasonable to me. Would I also have a short-form of saying > I want my element not to be a *move* but a *copy*? I.e. given me the > same content model/class affiliations as element X? I'd regard it as a luxury, but not that hard to do, I suppose. > >> I am groping here towards a work plan >> for rewriting Roma. > > Yes, I recognise that, and think there will be a lot more work here > than perhaps originally conceived. too right. its going to be a major pain. > >> Whether newly added attributes are forced to a >> namespace, as opposed to the default null one, >> is tricky. I am personally inclined to think >> that this is <soCalled>political >> correctness gone mad</soCalled>. > > Current consensus seems to be that they should so they don't collide > with existing elements, etc. how can attributes collide with elements? it seems to me that in XML world attributes are regarded differently, for instance in not being followed by default in XSLT. So I'd regard it as plausible to leave them alone, and let all attributes (including TEI ones) wallow in the default null mudpool -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sat Apr 14 08:57:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 13:57:51 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620CA1C.4080502@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> <4620AFA7.605@oucs.ox.ac.uk> <4620C155.1080907@oucs.ox.ac.uk> <4620CA1C.4080502@oucs.ox.ac.uk> Message-ID: <4620CFCF.5030207@oucs.ox.ac.uk> Sebastian Rahtz wrote: > when someone writes the first non-Consortium ODD processor, > oh frabjous day. I'm not holding my breath. > So my critical question is whether the form of the > generated schema and DTD fragments is normative > or merely indicative. Can I break the format > at P5.1? I think you can, they are an output and just as we are changing the organisation of the guidelines (which will change again if we add a chapter in P5.1) then other outputs can change. We're committed to avoiding breaking backwards compatibility in the recommendations the guidelines provide (etc.), but if the form of the generated schemas change from one version to the next, I think only Wohann would complain. > In case anyone is wondering, it really is not that obvious > what to model in the RELAX NG schemas. CUrrently > I say > foo = foo.content, foo.attributes > > because that lets you say > > foo.attributes = empty Which seems like a good thing to me. > but I could equally say > > foo = foo.content, attribute bar ( text) > > and miss out the intermediate stage. But loses you the indirection and just doesn't seem to be a good thing. Does not creating this intermediate stage save lots of work? What is gained by it? -James From James.Cummings at oucs.ox.ac.uk Sat Apr 14 09:03:42 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 14:03:42 +0100 Subject: [tei-council] MD chapter revised: namespace rules In-Reply-To: <4620CB99.7090207@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> Message-ID: <4620D12E.8060309@oucs.ox.ac.uk> Sebastian Rahtz wrote: > I'd regard it as a luxury, but not that hard to do, I suppose. True, further down the list than the other nice things. > too right. its going to be a major pain. Yup. >> Current consensus seems to be that they should so they don't collide >> with existing elements, etc. > how can attributes collide with elements? erm, typo, I meant attributes. I.e. we don't want someone creating a new attribute 'where' if possible because the TEI already defines one (on <move>), and we want to avoid confusion if possible. Obviously @where added to tei:div and @where on tei:move are different, but since this is an addition of something new to the TEI, it shouldn't be in the the TEI namespace so should be @mynew:where. > it seems to me that in XML world attributes are regarded differently, > for instance in not being followed by default in XSLT. So > I'd regard it as plausible to leave them alone, and let all > attributes (including TEI ones) wallow in the default null mudpool I think I need to look into that more before I can comment with any assurance. -James From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 09:09:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 14:09:01 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620CFCF.5030207@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> <4620AFA7.605@oucs.ox.ac.uk> <4620C155.1080907@oucs.ox.ac.uk> <4620CA1C.4080502@oucs.ox.ac.uk> <4620CFCF.5030207@oucs.ox.ac.uk> Message-ID: <4620D26D.7050706@oucs.ox.ac.uk> James Cummings wrote: > >> but I could equally say >> >> foo = foo.content, attribute bar ( text) >> >> and miss out the intermediate stage. > > But loses you the indirection and just doesn't seem to be a good > thing. Does not creating this intermediate stage save lots of work? > What is gained by it? neither gain nor loss. I just have to decide when I meet an attList whether I - make a new object with the attributes and then reference it - put the attributes right here Is this my decision as an ODD programmer, or will the Guidelines tell me what to do? James, if I install Debian on my slug, will it attempt to repartition/reformat my disk? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Sat Apr 14 11:47:44 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 14 Apr 2007 16:47:44 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620D12E.8060309@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461B7F5F.1000502@oucs.ox.ac.uk> <461B854B.60704@oucs.ox.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> Message-ID: <4620F7A0.4040906@computing-services.oxford.ac.uk> James Cummings wrote: > > erm, typo, I meant attributes. I.e. we don't want someone creating a > new attribute 'where' if possible because the TEI already defines one > (on <move>), and we want to avoid confusion if possible. Obviously > @where added to tei:div and @where on tei:move are different, but > since this is an addition of something new to the TEI, it shouldn't be > in the the TEI namespace so should be @mynew:where. Just to be pernickety for a moment (moi!): attribute names on different elements in the same namespace don't have to be distinct per XML. The @where on tei:foo and the @where on tei:bar can have completely different semantics and datatypes. TEI *recommended practice* however is that they ought to be the same. And if you put @myspace:where on tei:foo it *has* to be the same thing as say a @myspace:where on tei:bar, because there's no way of saying otherwise. From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 11:53:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 16:53:36 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F7A0.4040906@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> Message-ID: <4620F900.8060005@oucs.ox.ac.uk> Lou's Laptop wrote: > Just to be pernickety for a moment (moi!): attribute names on > different elements in the same namespace don't have to be distinct per > XML. The @where on tei:foo and the @where on tei:bar can have > completely different semantics and datatypes. TEI *recommended > practice* however is that they ought to be the same. yet we don't stick to this in our own Guidelines, as I just found to my cost (check out uses of eg @value). > And if you put @myspace:where on tei:foo it *has* to be the same > thing as say a @myspace:where on tei:bar, because there's no way of > saying otherwise. I lost the will to live during this sentence. can you say it more slowly? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Sat Apr 14 12:48:54 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 14 Apr 2007 17:48:54 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F900.8060005@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <4620F900.8060005@oucs.ox.ac.uk> Message-ID: <462105F6.6070707@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Lou's Laptop wrote: >> Just to be pernickety for a moment (moi!): attribute names on >> different elements in the same namespace don't have to be distinct >> per XML. The @where on tei:foo and the @where on tei:bar can have >> completely different semantics and datatypes. TEI *recommended >> practice* however is that they ought to be the same. > yet we don't stick to this in our own Guidelines, as I just found to > my cost > (check out uses of eg @value). Such cases should be hunted down and extirpated with extreme prejeducie then! > >> And if you put @myspace:where on tei:foo it *has* to be the same >> thing as say a @myspace:where on tei:bar, because there's no way of >> saying otherwise. > I lost the will to live during this sentence. can you say it more slowly? > > > the way tony puts it is that all explicitly namespaced attributes are global because you cannot necessarily tell what elements they are defined for. From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 12:55:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 17:55:10 +0100 Subject: [tei-council] incompatible datatypes for same-named attributes Message-ID: <4621076E.1090407@oucs.ox.ac.uk> There are 32 occasions in the TEI where two attributes of the same name have different datatypes (leaving aside semantics). I know we went all over these some time back and decided some variations were inevitable, but some are, I suspect, oversights which we could now correct. There are two types of situation: a) Surely @type should consistently enumerated or word? (though the effect is the same, in practice) b) something niche like @cRef must surely mean the same in all 4 places? simply an error on ptr and ref. similarly, @resp is such a characeristic TEI attribute, it must surely behave consistently? Is this an important matter? It seems so to me. Shall I add a specific ticket to trac and assign to (Syd?)? BTW, Syd, note the remaining "targets". is that deliberate, or a smidgeon of unfinished business? active: data.pointer: relation active: data.enumerated: interaction cRef: data.pointer: gloss cRef: data.pointer: term cRef: data.word: ptr cRef: data.word: ref degree: data.probability: certainty degree: data.count: node degree: data.certainty: purpose extent: data.word: gap extent: data.enumerated: orth extent: data.enumerated: pron extent: data.word: damage extent: data.word: space form: data.enumerated: objectDesc from: data.temporal.w3c: att.datable.w3c from: data.word: locus from: data.pointer: span from: data.pointer: app from: data.pointer: arc ident: data.language: language ident: data.name: att.identified level: data.numeric: sense level: data.code: langKnown ink: data.enumerated: hand ink: data.enumerated: handShift name: data.namespace: namespace name: data.name: equiv name: data.name: f name: data.word: vLabel name: data.enumerated: relation name: data.name: fDecl name: data.word: attRef new: data.enumerated: shift new: data.code: handShift notation: data.enumerated: pron notation: data.code: formula ord: data.enumerated: tree ord: data.truthValue: root ord: data.truthValue: iNode passive: data.pointer: relation passive: data.enumerated: interaction perf: data.pointer: move perf: data.enumerated: tech reg: data.code: country reg: data.code: nationality resp: data.pointer: att.editLike resp: data.pointer: att.interpLike resp: data.pointer: note resp: data.pointer: respons resp: data.code: hand resp: data.code: handShift resp: data.pointer: space resp: data.pointer: att.textCritical resp: data.pointer: witDetail role: data.enumerated: att.tableDecoration role: data.enumerated: editor role: data.word: person role: data.code: personGrp scheme: data.pointer: keywords scheme: data.pointer: classCode scheme: data.pointer: catRef scheme: data.enumerated: locus scheme: data.pointer: occupation scheme: data.pointer: socecStatus scheme: data.enumerated: att scheme: data.enumerated: gi scheme: data.enumerated: tag scribe: data.name: handNote scribe: data.code: hand script: data.code: writing script: data.name: handNote size: data.word: personGrp size: data.count: graph source: data.pointer: normalization source: data.word: supplied start: data.pointer: att.timed start: data.name: schemaSpec target: data.pointer: catRef target: data.pointer: gloss target: data.pointer: term target: data.pointer: ptr target: data.pointer: ref target: data.pointer: note target: data.pointer: att.ptrLike.form target: data.pointer: certainty target: data.pointer: respons target: data.pointer: witDetail target: data.pointer: specGrpRef targets: data.pointer: locus targets: data.pointer: link targets: data.pointer: join targets: data.pointer: alt to: data.temporal.w3c: att.datable.w3c to: data.word: locus to: data.pointer: span to: data.pointer: app to: data.pointer: arc type: data.enumerated: att.authorialIntervention type: data.enumerated: att.divLike type: data.enumerated: att.interpLike type: data.enumerated: att.segLike type: data.word: att.typed type: data.enumerated: teiHeader type: data.enumerated: idno type: data.enumerated: fsdDecl type: data.enumerated: metDecl type: data.enumerated: distinct type: data.enumerated: q type: data.enumerated: name type: data.enumerated: rs type: data.enumerated: num type: data.enumerated: measure type: data.enumerated: abbr type: data.enumerated: list type: data.enumerated: head type: data.enumerated: note type: data.enumerated: divGen type: data.enumerated: title type: data.enumerated: biblScope type: data.enumerated: stage type: data.enumerated: titlePage type: data.enumerated: titlePart type: data.enumerated: move type: data.enumerated: sound type: data.enumerated: writing type: data.enumerated: att.entryLike type: data.enumerated: form type: data.enumerated: orth type: data.enumerated: gram type: data.enumerated: iType type: data.word: colloc type: data.enumerated: usg type: data.word: lbl type: data.enumerated: xr type: data.word: re type: data.enumerated: oRef type: data.enumerated: oVar type: data.enumerated: dimensions type: data.word: att.pointing type: data.enumerated: fs type: data.name: restore type: data.enumerated: damage type: data.enumerated: fw type: data.enumerated: att.textCritical type: data.enumerated: app type: data.word: witDetail type: data.enumerated: persName type: data.enumerated: geogName type: data.enumerated: orgName type: data.enumerated: orgTitle type: data.enumerated: orgType type: data.enumerated: orgDivn type: data.enumerated: relation type: data.enumerated: graph type: data.enumerated: node type: data.enumerated: forest type: data.enumerated: forestGrp type: data.enumerated: derivation type: data.enumerated: domain type: data.enumerated: preparedness type: data.enumerated: purpose type: data.enumerated: fsDecl value: data.temporal.w3c: att.dateTime.w3c value: data.word: metSym value: data.numeric: num value: data.temporal.w3c: docDate value: data.truthValue: binary value: data.word: symbol value: data.numeric: numeric value: data.count: age value: data.sex: sex value: data.pointer: node value: data.pointer: root value: data.pointer: iNode value: data.pointer: leaf value: data.pointer: eTree value: data.pointer: triangle value: data.pointer: eLeaf version: data.word: att.translatable version: data.numeric: unicodeName wit: data.pointer: att.rdgPart wit: data.pointer: att.textCritical wit: data.code: witDetail -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 13:01:08 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 18:01:08 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <462105F6.6070707@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <4620F900.8060005@oucs.ox.ac.uk> <462105F6.6070707@computing-services.oxford.ac.uk> Message-ID: <462108D4.6000406@oucs.ox.ac.uk> Lou's Laptop wrote: > > Such cases should be hunted down and extirpated with extreme > prejeducie then! I bet you are sorry you said that after you read my later mail showing how many there are... never mind, you don't want to watch Dr Who anyway. > the way tony puts it is that all explicitly namespaced attributes are > global because you cannot necessarily tell what elements they are > defined for. is that the same Tony who lied about the war? this is lie too. An attribute is defined in the context of an element, or a group of elements. Whether the attribute is in a namespace is irrelevant. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Sat Apr 14 13:07:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 14 Apr 2007 13:07:35 -0400 Subject: [tei-council] incompatible datatypes for same-named attributes In-Reply-To: <4621076E.1090407@oucs.ox.ac.uk> References: <4621076E.1090407@oucs.ox.ac.uk> Message-ID: <17953.2647.641184.464887@emt.wwp.brown.edu> > a) Surely @type should consistently enumerated or word? (though the > effect is the same, in practice) Yes, type= should always be data.enumerated. > b) something niche like @cRef must surely mean the same in all 4 > places? simply an error Yes, I think so, but would have to check > Is this an important matter? It seems so to me. Shall I add a > specific ticket to trac and assign to (Syd?)? Yes, it is important, but since it's error-checking and not new stuff, it should be deferred until after Berlin. > BTW, Syd, note the remaining "targets". is that deliberate, or a > smidgeon of unfinished business? Completely deliberate, and importantly so. (A targets= attribute requires 2 or more pointers as its value.) In great haste ... From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 13:12:50 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 18:12:50 +0100 Subject: [tei-council] incompatible datatypes for same-named attributes In-Reply-To: <17953.2647.641184.464887@emt.wwp.brown.edu> References: <4621076E.1090407@oucs.ox.ac.uk> <17953.2647.641184.464887@emt.wwp.brown.edu> Message-ID: <46210B92.4020508@oucs.ox.ac.uk> Syd Bauman wrote: > >> BTW, Syd, note the remaining "targets". is that deliberate, or a >> smidgeon of unfinished business? >> > > Completely deliberate, and importantly so. (A targets= attribute > requires 2 or more pointers as its value.) > isnt that catered for with our new list and its minOccurs/maxOccurs? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sat Apr 14 17:20:52 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 22:20:52 +0100 Subject: [tei-council] Conformance .... the continuing saga In-Reply-To: <4620D26D.7050706@oucs.ox.ac.uk> References: <461383C6.6000003@oucs.ox.ac.uk> <17939.41112.690281.365239@emt.wwp.brown.edu> <4613A30B.9060607@computing-services.oxford.ac.uk> <17939.53014.822219.184813@emt.wwp.brown.edu> <4613E227.2090909@oucs.ox.ac.uk> <4614BC86.3000203@kcl.ac.uk> <17940.64886.701634.932767@emt.wwp.brown.edu> <46150204.2030103@oucs.ox.ac.uk> <17942.35660.718823.915509@emt.wwp.brown.edu> <4616D77C.6000500@kanji.zinbun.kyoto-u.ac.jp> <17942.57589.177531.95758@emt.wwp.brown.edu> <461FEA93.5020604@oucs.ox.ac.uk> <4620879F.1020907@oucs.ox.ac.uk> <4620AFA7.605@oucs.ox.ac.uk> <4620C155.1080907@oucs.ox.ac.uk> <4620CA1C.4080502@oucs.ox.ac.uk> <4620CFCF.5030207@oucs.ox.ac.uk> <4620D26D.7050706@oucs.ox.ac.uk> Message-ID: <462145B4.1000203@oucs.ox.ac.uk> Sebastian Rahtz wrote: > neither gain nor loss. I just have to decide when I meet an attList whether > I > > - make a new object with the attributes and then reference it > - put the attributes right here > > Is this my decision as an ODD programmer, or will the Guidelines > tell me what to do? I think that is an implementation thing, and thus up to you. > James, if I install Debian on my slug, will it attempt to > repartition/reformat my disk? I attached two 500GB drives to mine (one on a usb hub). Format and/or partition the drives as you might desire on a different machine first. (Otherwise it might hang being out of memory.) Obviously it will need somewhere to install root, but during the install you can simple choose to use the existing partitions rather than reformat them. (i.e. manually partitioning, not guided.) (Apologies to the rest of council who won't understand this...google for "NSLU2 Debian" if you are interested.) -James From James.Cummings at oucs.ox.ac.uk Sat Apr 14 17:23:34 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2007 22:23:34 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4620F7A0.4040906@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <96f3df640704100557g78b63f53p7e2ad9ce6d3884fd@mail.gmail.com> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> Message-ID: <46214656.7040802@oucs.ox.ac.uk> Lou's Laptop wrote: > James Cummings wrote: >> >> erm, typo, I meant attributes. I.e. we don't want someone creating a >> new attribute 'where' if possible because the TEI already defines one >> (on <move>), and we want to avoid confusion if possible. Obviously >> @where added to tei:div and @where on tei:move are different, but >> since this is an addition of something new to the TEI, it shouldn't be >> in the the TEI namespace so should be @mynew:where. > Just to be pernickety for a moment (moi!): attribute names on different > elements in the same namespace don't have to be distinct per XML. The > @where on tei:foo and the @where on tei:bar can have completely > different semantics and datatypes. TEI *recommended practice* however > is that they ought to be the same. And if you put @myspace:where on > tei:foo it *has* to be the same thing as say a @myspace:where on > tei:bar, because there's no way of saying otherwise. Yup, I understand and agree with all of that. So by suggesting that people use namespaces for their new attributes we encourage the good practice that TEI already follows of not having @myspace:where mean something on one element and @myspace:where mean something else on another element. -James From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 17:32:11 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2007 22:32:11 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46214656.7040802@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> Message-ID: <4621485B.6020809@oucs.ox.ac.uk> James Cummings wrote: > > Yup, I understand and agree with all of that. So by suggesting that > people use namespaces for their new attributes we encourage the good > practice that TEI already follows of not having @myspace:where mean > something on one element and @myspace:where mean something else on > another element. what if add the TEI-consonant @type to an element which doesnt have it already? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sun Apr 15 05:32:13 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 15 Apr 2007 10:32:13 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4621485B.6020809@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> Message-ID: <4621F11D.9080703@oucs.ox.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> >> Yup, I understand and agree with all of that. So by suggesting that >> people use namespaces for their new attributes we encourage the good >> practice that TEI already follows of not having @myspace:where mean >> something on one element and @myspace:where mean something else on >> another element. > what if add the TEI-consonant @type to an element which doesnt have it > already? I believe consensus was that this was an 'unclean' change, and thus element and attribute are put in a user-defined namespace. -James From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 16:00:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 21:00:59 +0100 Subject: [tei-council] question about <char> Message-ID: <4622847B.8020204@computing-services.oxford.ac.uk> The description of the <char> element includes the following example: <char xml:id="circledU4EBA"> <charName>CIRCLED IDEOGRAPH 4EBA</charName> <charProp> <unicodeName>character-decomposition-mapping</unicodeName> <value>circle</value> </charProp> <charProp> <localName>daikanwa</localName> <value>36</value>is a standard mapping why is it using a <g> element? What's wrong with just using </charProp> <mapping type="standard"> <g ref="#U4EBA">?</g> </mapping> </char> I am puzzled by the <g> within the <mapping>. If this is a standard mapping why is it using a <g> element? What's wrong with just using the character, or an NCR like this? <mapping type="standard"> 人 </mapping> From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 16:34:08 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 21:34:08 +0100 Subject: [tei-council] @scheme datatype Message-ID: <46228C40.70408@computing-services.oxford.ac.uk> The scheme attribute is variously used with more or less the same semantics to give a short name for some external classification scheme, values from which are being deployed in a TEI document It has the datatype data.pointer on <keywords>, <classCode>, <catRef>, <occupation> and <socecStatus>, and the datatype data.enumerated on <locus>, <att>, <gi>,<tag> This inconsistency seems undesirable. Changing them all to data.pointer means that they can provide URLs for the schemes concerned which seems more useful than encouraging people to go on using arbitrary opaque codes like "LCSH" (for which now read http://classificationweb.net). Dissenters please speak up! From lou.burnard at computing-services.oxford.ac.uk Sun Apr 15 17:01:15 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2007 22:01:15 +0100 Subject: [tei-council] @source again Message-ID: <4622929B.30301@computing-services.oxford.ac.uk> The source attribute on <att>, <gi>, and <tag> seems to me ripe for the chop. It duplicates a function better performed by namespaces (as the descriptive prose in the relevant tagdocs already points out)... I think it has survived so long solely for reasons of historical sentiment. Unless anyone objects therefore, I propose to remove it. You have 48 hours to object, starting now! From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 17:10:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 15 Apr 2007 22:10:03 +0100 Subject: [tei-council] @source again In-Reply-To: <4622929B.30301@computing-services.oxford.ac.uk> References: <4622929B.30301@computing-services.oxford.ac.uk> Message-ID: <462294AB.9090105@oucs.ox.ac.uk> Lou Burnard wrote: > The source attribute on <att>, <gi>, and <tag> seems to me ripe for > the chop. It duplicates a function better performed by namespaces (as > the descriptive prose in the relevant tagdocs already points out)... I > think it has survived so long solely for reasons of historical sentiment. > > Unless anyone objects therefore, I propose to remove it. You have 48 > hours to object, starting now! I assume you mean @scheme. what if I want to say <gi scheme="unknown">? <gi scheme="TEI"> (any TEI)? I don't care much, but schema and namespace are not _quite_ the same. I can't imagine many tears if you drop it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 17:16:13 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 15 Apr 2007 22:16:13 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <46228C40.70408@computing-services.oxford.ac.uk> References: <46228C40.70408@computing-services.oxford.ac.uk> Message-ID: <4622961D.4030704@oucs.ox.ac.uk> what would @schema on <locus> point to? I see we have no example of its use :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Sun Apr 15 17:29:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 17:29:23 -0400 Subject: [tei-council] @scheme datatype In-Reply-To: <46228C40.70408@computing-services.oxford.ac.uk> References: <46228C40.70408@computing-services.oxford.ac.uk> Message-ID: <17954.39219.955701.862122@emt.wwp.brown.edu> If it's going to be a URL on <att>, <gi>, and <tag>, shouldn't it be the namespace of the tagset being used? And if so, shouldn't it be namespace= or ns= isnstead of scheme=? From Syd_Bauman at Brown.edu Sun Apr 15 18:44:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 18:44:20 -0400 Subject: [tei-council] quotation marks, quotes, etc. Message-ID: <17954.43716.870610.6618@emt.wwp.brown.edu> I'd like to address Trac ticket #304. Passages offset by quotation marks in the source may be encoded as a specific type of feature, e.g. mentioned not used (<mentioned>), authorial distancing (<soCalled>), quotation (<quote>), speech or thought (<q>); or may be encoded as "taken from elsewhere, details unknown or unsaid" (<q>). The problem here is that <q> is overloaded, serving two purposes. Need to develop a proposal to leave <q> as a generic (perhaps even more generic?) element, and introduce a new element for the "speech or thought" function. I think the way forward here is pretty clear, and Lou & I agree to the basic game-plan sketched out above. But there are still a couple of potentially controversial issues. So here is a slightly more detailed proposal, followed by questions. * Retain <quote> as it is: passage attributed to some agency external to the text, i.e. a quotation from a written source. Remains a member of model.quoteLike, also a member of new model.quoted. * New element <quo> for direct speech or thought. (I.e., not a quotation of a written source, not authorial distancing, not an example in a dictionary entry.) A member of new model.quoted. * Change semantics of <q> to be a bit more broad, basically covering anything that was indicated in the source with quotation marks, but about which the encoder does not wish to say more. Essentially syntactic sugar for <hi rend="quotation marks">. A member of model.hiLike. * <cit> remains as is, becomes a member of new model.quoted This system has the advantage of a clean break between quoting of passages external to the text and direct speech or thought of, e.g., a character. But it also permits <q> to be used quite loosely, which is good, because it reflects what lots of projects already do. That is, - quotation could be encoded with <quote> or <q> - that which a character speaks could be encoded with <quo> or <q> - authorial distance could be encoded with <soCalled> or <q> - words mentioned not used could be encoded with <mentioned> or <q> - dictionary examples could be encoded with <quote> or <q> (what if they are contrived?) - a filename that appeared in quotes could be encoded as <name> or <q> - a filepath that appeared in quotes could be encoded as <ident> or <q> - a newly introduced term could be encoded as <term> or <q> You can well imagine projects that encode all this stuff with <q> on the first pass (because it is easier and thus less expensive), and then on a second pass convert to more nuanced encoding for those aspects they care about, and not others. Questions: * Does anyone strongly object to the basic idea? * Is the name <quo> OK? (If not, please provide a suggested alternative :-) * Have I got the model divisions correct? From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 19:01:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 00:01:30 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17954.43716.870610.6618@emt.wwp.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> Message-ID: <4622AECA.40505@oucs.ox.ac.uk> While I confess that I don't feel very opinionated on this, I kind of like the idea of <q> being a lowest common denominator, with more specialist elements for serious encoding. I don't much like <quo>. Its neither a word not a decent abbreviation in English, but has a meaning in Latin, which seems unwise. <speech> and <spoken> are available but not perfect. <quotedSpeech>? I think that airing this on TEI-L next week, if people agree, would be no bad thing. sebastian From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 19:02:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 00:02:36 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17954.43716.870610.6618@emt.wwp.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> Message-ID: <4622AF0C.8050001@oucs.ox.ac.uk> oh, and <qs>, as an abbreviation for quoted speech -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Sun Apr 15 21:01:40 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 15 Apr 2007 21:01:40 -0400 (EDT) Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <4622AF0C.8050001@oucs.ox.ac.uk> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> Message-ID: <200704160101.l3G11eiw026283@perseus.services.brown.edu> > I don't much like <quo>. Its neither a word not a decent > abbreviation in English, but has a meaning in Latin, which seems > unwise. Oh, good point about the Latin. According to one dictionary "quo" is an archaic version of "quoth" (somewhat archaic itself), as in "Quoth the the raven, 'Nevermore'". But I'm pretty sure that doesn't trump the disadvantage of the Latin. > <speech> and <spoken> are available but not perfect. > <quotedSpeech>? oh, and <qs>, as an abbreviation for quoted speech I don't wonder if <qs> looks to much like <ps>, which element I hope to add next week. Probably not a good argument against. How about - <sot>: speech or thought - <qst>: quoted speech or thought - <said>: said > I think that airing this on TEI-L next week, if people agree, would > be no bad thing. I agree. From cwittern at gmail.com Sun Apr 15 21:52:12 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 16 Apr 2007 10:52:12 +0900 Subject: [tei-council] question about <char> In-Reply-To: <4622847B.8020204@computing-services.oxford.ac.uk> References: <4622847B.8020204@computing-services.oxford.ac.uk> Message-ID: <4622D6CC.6040400@gmail.com> Lou Burnard wrote: > The description of the <char> element includes the following example: > > > <char xml:id="circledU4EBA"> > <charName>CIRCLED IDEOGRAPH 4EBA</charName> > <charProp> > <unicodeName>character-decomposition-mapping</unicodeName> > <value>circle</value> > </charProp> > <charProp> > <localName>daikanwa</localName> > <value>36</value>is a standard mapping why is it using a <g> element? > What's wrong with just using > </charProp> > <mapping type="standard"> > <g ref="#U4EBA">?</g> > </mapping> > </char> > > I am puzzled by the <g> within the <mapping>. If this is a standard > mapping why is it using a <g> element? What's wrong with just using > the character, or an NCR like this? > > <mapping type="standard"> > 人 > </mapping> > You are right, it is not necessary. If I remember correctly, this was put in to show to human readers both the character and the codepoint. If you find it confusing, your suggestion for replacement seems acceptable to me on this dark and rainy Monday morning. Christian From daniel.odonnell at uleth.ca Sun Apr 15 23:12:11 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 21:12:11 -0600 Subject: [tei-council] question about <char> In-Reply-To: <4622D6CC.6040400@gmail.com> References: <4622847B.8020204@computing-services.oxford.ac.uk> <4622D6CC.6040400@gmail.com> Message-ID: <1176693131.7781.12.camel@localhost> Not being part of the earlier discussions, the main reason I can see for the g are 1) To provide a mechanism for describing non-unicode characters 2) To keep the content model of mapping the same whether the character is unicode or not. Looking up mapping and g, and see the definition of mapping supports my hypothesis here, but the nomenclature and definition of g does not: In mapping: > The <g> elements contained by this element can point to either another > <char> or <glyph>element or contain a character that is intended to be > the target of this mapping. In g: > (character or glyph) represents a non-standard character or glyph. ... > The name g is short for gaiji, which is the Japanese term for a > non-standardized character or glyph.[1] Personally, I really like consistent content models for structures independent of specifics of the content--so I prefer requiring g for both standard and non-standard characters. But the name of g is misleading then in this case. Have we other places where you use cdata if the content is one thing and a structural element is the content is structurally the same thing but non-standard or the like? [1] I notice that others use gaiji in a slightly different sense as "supplemental" or "any glyph that's valid in your written language but is not in the font you are using" (both Adobe: http://www.adobe.com/products/indesign/sing_gaiji.html). "Any computer system can only provide a limited, finite set of characters. Additional characters are handled as 'gaiji'" (http://www.chibs.edu.tw/~chris/papers/ie/xml-gaiji/foil02.html). "A character not included in a standard set of characters" (Wiktionary). In these cases it is less of a stretch to use <g> for Unicode characters that need mapping: presumably you only map the ones that are relatively unusual and are not likely to be in a users usual character set or font. My preference is to leave it in and maybe amend the definition of g/gaiji. -dan On Mon, 2007-04-16 at 10:52 +0900, Wittern Christian wrote: > Lou Burnard wrote: > > The description of the <char> element includes the following example: > > > > > > <char xml:id="circledU4EBA"> > > <charName>CIRCLED IDEOGRAPH 4EBA</charName> > > <charProp> > > <unicodeName>character-decomposition-mapping</unicodeName> > > <value>circle</value> > > </charProp> > > <charProp> > > <localName>daikanwa</localName> > > <value>36</value>is a standard mapping why is it using a <g> element? > > What's wrong with just using > > </charProp> > > <mapping type="standard"> > > <g ref="#U4EBA">?</g> > > </mapping> > > </char> > > > > I am puzzled by the <g> within the <mapping>. If this is a standard > > mapping why is it using a <g> element? What's wrong with just using > > the character, or an NCR like this? > > > > <mapping type="standard"> > > 人 > > </mapping> > > > You are right, it is not necessary. If I remember correctly, this was > put in to show to human readers both the character and the codepoint. > If you find it confusing, your suggestion for replacement seems > acceptable to me on this dark and rainy Monday morning. > > Christian > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From daniel.odonnell at uleth.ca Sun Apr 15 23:29:36 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 21:29:36 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704160101.l3G11eiw026283@perseus.services.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> Message-ID: <1176694176.7781.30.camel@localhost> On Sun, 2007-04-15 at 21:01 -0400, Syd Bauman wrote: > > I don't much like <quo>. Its neither a word not a decent > > abbreviation in English, but has a meaning in Latin, which seems > > unwise. > > Oh, good point about the Latin. According to one dictionary "quo" is > an archaic version of "quoth" (somewhat archaic itself), as in "Quoth > the the raven, 'Nevermore'". But I'm pretty sure that doesn't trump > the disadvantage of the Latin. > > > > <speech> and <spoken> are available but not perfect. > > <quotedSpeech>? oh, and <qs>, as an abbreviation for quoted speech > > I don't wonder if <qs> looks to much like <ps>, which element I hope > to add next week. Probably not a good argument against. > > How about > - <sot>: speech or thought > - <qst>: quoted speech or thought > - <said>: said Are these not all syntactic sugar for q at type? I am not at all keen on introducing more elements here, since the two we have are historically a place where people have a mess of a time. I agree with Sebastian that I like the idea of q as the default element. I'm less keen on trying to distinguish the others, partially because it is not a structural distinction people make in actually non-marked up running text--unlike, arguably q vs. socalled which is sometimes indicated by double or single quotations, though it is a bad habit, I'm told. I can see people having an immense amount of difficulty with this: is this a "speech or a thought" but not "quoted speech or thought" and not "said"? Do I need to tag every indirect quotation? ad infin. Another argument against it is the very nomenclature difficulty we are having: q/quote/qst and with a little extension, said, are all arguably short forms of the same word: quote/quotation. People who really need this level of granularity can surely use @type or some form of seg? If it turns out that there is a real need for this, treating q as the base element will allow us to introduce more later. But I think this may be a solution looking for a problem. If we do ask tei-l next week, I'd like to ask first whether we need more than q and optionally quote. My next preference would be for q-quote-said, and finally something like q-quote-said-iquote (for indirect quote). -dan > > > > I think that airing this on TEI-L next week, if people agree, would > > be no bad thing. > > I agree. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From daniel.odonnell at uleth.ca Mon Apr 16 00:22:12 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 15 Apr 2007 22:22:12 -0600 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4621F11D.9080703@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <1176217330.21190.40.camel@odonned-eng06> <461C362E.2010704@gmail.com> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> Message-ID: <1176697332.7781.73.camel@localhost> On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: > Sebastian Rahtz wrote: > > James Cummings wrote: > >> > >> Yup, I understand and agree with all of that. So by suggesting that > >> people use namespaces for their new attributes we encourage the good > >> practice that TEI already follows of not having @myspace:where mean > >> something on one element and @myspace:where mean something else on > >> another element. > > what if add the TEI-consonant @type to an element which doesnt have it > > already? > > I believe consensus was that this was an 'unclean' change, and thus > element and attribute are put in a user-defined namespace. Indeed it was the consensus. And indeed if you added it to new elements because you wanted to have a global type element, we seemed to think that all types were my:type. -dan > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From cwittern at gmail.com Mon Apr 16 00:38:05 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 16 Apr 2007 13:38:05 +0900 Subject: [tei-council] question about <char> In-Reply-To: <1176693131.7781.12.camel@localhost> References: <4622847B.8020204@computing-services.oxford.ac.uk> <4622D6CC.6040400@gmail.com> <1176693131.7781.12.camel@localhost> Message-ID: <4622FDAD.10708@gmail.com> Daniel O'Donnell wrote: > Not being part of the earlier discussions, the main reason I can see for > the g are > > 1) To provide a mechanism for describing non-unicode characters > 2) To keep the content model of mapping the same whether the character > is unicode or not. > I had the impression, Lou's question was not about changing the content model, but rather specifically about the example we provide. > Looking up mapping and g, and see the definition of mapping supports my > hypothesis here, but the nomenclature and definition of g does not: > > In mapping: > > >> The <g> elements contained by this element can point to either another >> <char> or <glyph>element or contain a character that is intended to be >> the target of this mapping. >> The "pointing" to <char> and <glyph> is done via a <g> element. What this comes down to is that the content is either a character used directly, or a <g> element, which represents a otherwise not representable character. Mapping as such is used only within the structure of a <char> or <glyph> element to point to a related version of a character (for example from a lower case to a upper case version). > > In g: > > >> (character or glyph) represents a non-standard character or glyph. >> > ... > >> The name g is short for gaiji, which is the Japanese term for a >> non-standardized character or glyph.[1] >> The formulation is not ideal. I now prefer to merge this with the one from Wikipedia: "The name g is short for gaiji, which is the Japanese term for a character not included in a standard set of characters" > Personally, I really like consistent content models for structures > independent of specifics of the content--so I prefer requiring g for > both standard and non-standard characters. But the name of g is > misleading then in this case. Have we other places where you use cdata > if the content is one thing and a structural element is the content is > structurally the same thing but non-standard or the like? > The <g> is special here in that it uses markup to represent a character. In that sense, it is not comparable to other situations, I think. Christian From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 16 03:57:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 08:57:16 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704160101.l3G11eiw026283@perseus.services.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> Message-ID: <46232C5C.2090307@oucs.ox.ac.uk> I like <said>. But if others feel that <q tyype="said"> will do, no tears here (having a dry day) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Mon Apr 16 05:46:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 10:46:15 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <4622961D.4030704@oucs.ox.ac.uk> References: <46228C40.70408@computing-services.oxford.ac.uk> <4622961D.4030704@oucs.ox.ac.uk> Message-ID: <462345E7.5070108@kcl.ac.uk> Sebastian Rahtz wrote: > what would @schema on <locus> point to? > > I see we have no example of its use :-} > mh...I don't agree with this. I can see lots of potential uses of @scheme for <gi>locus</gi> as it is defined in the guidelines: "identifies the foliation scheme in terms of which the location is being specified.". Indeed, as I am sure other people who have worked with manuscripts can confirm, the same codex, for instance, can include several systems of foliation/pagination added over the years and centuries, following different readings, different arrangements of the folios, different conventions, different interventions on the book itself. To encode these parallelisms or conflicts between folio numbers can be useful to study the tradition/reading of the text as well as to render various outputs of the same source. If you think another existing element can do the trick fine, but otherwise I would keep @scheme. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Mon Apr 16 06:12:55 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 11:12:55 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <462345E7.5070108@kcl.ac.uk> References: <46228C40.70408@computing-services.oxford.ac.uk> <4622961D.4030704@oucs.ox.ac.uk> <462345E7.5070108@kcl.ac.uk> Message-ID: <46234C27.4010407@kcl.ac.uk> Arianna Ciula wrote: > > > Sebastian Rahtz wrote: >> what would @schema on <locus> point to? I forgot to say it would point to the foliation scheme as defined in the <foliation> element. >> >> I see we have no example of its use :-} >> > mh...I don't agree with this. I can see lots of potential uses of > @scheme for <gi>locus</gi> as it is defined in the guidelines: > "identifies the foliation scheme in terms of which the location is being > specified.". > > Indeed, as I am sure other people who have worked with manuscripts can > confirm, the same codex, for instance, can include several systems of > foliation/pagination added over the years and centuries, following > different readings, different arrangements of the folios, different > conventions, different interventions on the book itself. To encode these > parallelisms or conflicts between folio numbers can be useful to study > the tradition/reading of the text as well as to render various outputs > of the same source. > > If you think another existing element can do the trick fine, but > otherwise I would keep @scheme. > > Arianna > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Mon Apr 16 06:25:19 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 11:25:19 +0100 Subject: [tei-council] dating attrs In-Reply-To: <17951.30803.46014.797703@emt.wwp.brown.edu> References: <17951.30803.46014.797703@emt.wwp.brown.edu> Message-ID: <46234F0F.1000104@kcl.ac.uk> Syd Bauman wrote: > BTW, the development version of the Guidelines (the one which is in > https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5/Source/ and > available as HTML at > http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/index.html) This must be down for some reasons today. Lou, could you please point me to the html draft of ND or could you make one please? I can't find it within the Draft folder. May be it's easy to produce one with the xsl on sourceforge, but don't want to risk to use the wrong stylesheet etc. Arianna > also has all the new dating attributes in it. Since we all voted on > it, I don't think there is much controversial there, except as listed > below. On the other hand, paying close attention for class errors, > typos, etc., would be helpful. > > Possible Issues > -------- ------ > > * Rather than create a new module for ISO dating attributes, I stuck > 'em directly into the namesdates module. > > * We never decided on the names of the ISO attributes. I called them > value-iso= > dur-iso= > notBefore-iso= > etc. My thinking (what little there was) was that it would be nice > if these attributes sorted near their "simple" W3C counterparts. > > * We should perhaps discuss how strong the warnings against using > "24:00" and basic formats (i.e., no colons or hyphens in some > cases) should be. Currently the remarks say > > <p>For all representations for which ISO 8601 describes both a > <term>basic</term> and an <term>extended</term> format, these > Guidelines recommend use of the extended format.</p> > <p>While ISO 8601 permits the use of both <code>00:00</code> and > <code>24:00</code> to represent midnight, these Guidelines > strongly recommend against the use of <code>24:00</code>. <!-- As > there are only 24 hours in a day, numbered "00" through "23", use > of "24:00" implies a 25th hour, and some software may be confused. > Note that when there is a leap second, it should be indicated > with 23:59:60. --></p> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 16 07:32:39 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 16 Apr 2007 12:32:39 +0100 Subject: [tei-council] @scheme datatype In-Reply-To: <462345E7.5070108@kcl.ac.uk> References: <46228C40.70408@computing-services.oxford.ac.uk> <4622961D.4030704@oucs.ox.ac.uk> <462345E7.5070108@kcl.ac.uk> Message-ID: <46235ED7.3040502@oucs.ox.ac.uk> Arianna Ciula wrote: > >> what would @schema on <locus> point to? >> >> I see we have no example of its use :-} >> > mh...I don't agree with this. I can see lots of potential uses of > @scheme for <gi>locus</gi> as it is defined in the guidelines: > "identifies the foliation scheme in terms of which the location is > being specified.". > sorry, misunderstanding. I just meant that the Guidelines have no example of <locus scheme=; Lou has now added one -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Mon Apr 16 09:52:58 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 09:52:58 -0400 Subject: [tei-council] question about <char> In-Reply-To: <4622D6CC.6040400@gmail.com> References: <4622847B.8020204@computing-services.oxford.ac.uk> <4622D6CC.6040400@gmail.com> Message-ID: <17955.32698.492563.153935@emt.wwp.brown.edu> > ... on this dark and rainy Monday morning. We are having a dark and rainy morning here, too ... in fact, we've been hit by a N'oreaster, and have been without power at my home for at least 5 hours now. This means 2 things: * I am quite behind in Council mail, etc. * The copy of the Guidelines I had on my server will probably not be available until circa 18:00 UTC. If folks want, I'll try to put a new copy up at another site in a few mins ... From Syd_Bauman at Brown.edu Mon Apr 16 10:18:32 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 10:18:32 -0400 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <1176694176.7781.30.camel@localhost> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> <1176694176.7781.30.camel@localhost> Message-ID: <17955.34232.705683.173662@emt.wwp.brown.edu> > Are these not all syntactic sugar for q at type? I am not at all keen > on introducing more elements here, since the two we have are > historically a place where people have a mess of a time. I'm not sure which 'all' you are asking about, but the answer, I think, is yes, to some extent they are syntactic sugar for <q> with type=. But that doesn't change the need for a new element, which is very strong. The problem is that the Guidelines up to now have used <q> for more than one thing. But on further reading your reply, I think I may not have made myself clear. The following > > How about > > - <sot>: speech or thought > > - <qst>: quoted speech or thought > > - <said>: said was not meant as a recommendation for 3 new elements, but rather as 3 possible names for the 1 new element we need to add. The thought occured to me to use <said> with an aloud= attribute that would be data.xTruthValue. Thus you might see He was trying to butter her up in earnest now. She showed him a picture of her dog. <said>What a cutie! I bet he's smart, too.</said>, he said, as he thought <said aloud="false">gak, what an ugly dog</said> to himself. > If we do ask tei-l next week, I'd like to ask first whether we need > more than q and optionally quote. I think it's pretty important that we make this distinction. I have received quite a few complaints about the "<q> as speech or thought" vs "<q> as written quotation, speech, thought, or example" problem. While there are many (perhaps most) who don't care, there are a quite a few projects for which the difference between quotations of written passages external to the text and a character's spoken words in running prose are really quite important. I think the proposed solution brings the folks who don't care at all and use <q> for everything into the fold, while giving those for whom the nuances are important a mechanism for clean distinction. From Syd_Bauman at Brown.edu Mon Apr 16 10:20:20 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 16 Apr 2007 10:20:20 -0400 Subject: [tei-council] dating attrs In-Reply-To: <46234F0F.1000104@kcl.ac.uk> References: <17951.30803.46014.797703@emt.wwp.brown.edu> <46234F0F.1000104@kcl.ac.uk> Message-ID: <17955.34340.44374.42774@emt.wwp.brown.edu> > This must be down for some reasons today. Lou, could you please > point me to the html draft of ND or could you make one please? I'll take this as a "yes" :-) http://dev.stg.brown.edu/staff/Syd_Bauman/temp/Guidelines-web/en/html/ND.html From arianna.ciula at kcl.ac.uk Mon Apr 16 10:21:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 16 Apr 2007 15:21:06 +0100 Subject: [tei-council] question about <char> In-Reply-To: <17955.32698.492563.153935@emt.wwp.brown.edu> References: <4622847B.8020204@computing-services.oxford.ac.uk> <4622D6CC.6040400@gmail.com> <17955.32698.492563.153935@emt.wwp.brown.edu> Message-ID: <46238652.7010402@kcl.ac.uk> Syd Bauman wrote: > * The copy of the Guidelines I had on my server will probably not be > available until circa 18:00 UTC. If folks want, I'll try to put a > new copy up at another site in a few mins ... sorry to hear about the disruption Syd. It would be good for me if you can pout another copy somewhere, unless there are other solutions for me to have an HTML view of that third Easter egg. Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Mon Apr 16 11:02:18 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 16 Apr 2007 16:02:18 +0100 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <17955.34232.705683.173662@emt.wwp.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> <1176694176.7781.30.camel@localhost> <17955.34232.705683.173662@emt.wwp.brown.edu> Message-ID: <46238FFA.7030900@oucs.ox.ac.uk> Sorry, but I really do not agree with Syd on this issue, though I am pleased that he thinks I do! As I understand it, the proposal is to invent a new element, presumably to join the already over-burdened Core module, for the purpose of marking up representations of speech (but not thought) which are considered (by someone) to be "part of the text", and not quoted from somewhere else. It's less clear whether or not such representations are necessarily typographically distinct in the original but that seems to be relevant. I don't doubt that for some people and some applications these distinctions are important, and may even be useful, but I do doubt very much whether Mr or Ms TEI-average-user will want to make them. In the decade or more that people have been happily using <q> to mark "representation of speech or thought", I am not aware of anyone having the kind of major problem we are being told now exists. "representation of speech or thought" is an inherently vague concept (after all, that's what *all* text is!) It's true that some feel we can distinguish "rep of speech or thought" which is "internal" to a work from ditto when presented as external, but that's why we have both <q> and <quote>; I am happy with the idea of promoting <quote> as the tag to use if you want to make explicit that something is regarded as external, though I don't believe it to be strictly necessary. If you want to distinguish more finely within either of these elements, the attributes are there: in particular, @type is there precisely to indicate whether the material is "spoken" "thought" or "written", and speech can be further subdivided according to @direct. So the best interpretation I can put on this proposal is that it is arguing for a new bit of syntactic sugar. Less charitably, and to quote our esteemeed Board chair, this looks like "a solution looking for a problem". Hmm, should that have been a <q> or a <quote>? does what someone says in an email count as <q> or <said> or what? aaargh! Furthermore, I really don't think this is the most important issue for us to be consulting with Mr and Mrs TEI Average User about right now. They will say <said>not said but sad</said>... Lou Syd Bauman wrote: >> Are these not all syntactic sugar for q at type? I am not at all keen >> on introducing more elements here, since the two we have are >> historically a place where people have a mess of a time. > > I'm not sure which 'all' you are asking about, but the answer, I > think, is yes, to some extent they are syntactic sugar for <q> with > type=. But that doesn't change the need for a new element, which is > very strong. The problem is that the Guidelines up to now have used > <q> for more than one thing. > > But on further reading your reply, I think I may not have made myself > clear. The following >>> How about >>> - <sot>: speech or thought >>> - <qst>: quoted speech or thought >>> - <said>: said > was not meant as a recommendation for 3 new elements, but rather as 3 > possible names for the 1 new element we need to add. > > The thought occured to me to use <said> with an aloud= attribute that > would be data.xTruthValue. > > Thus you might see > He was trying to butter her up in earnest now. She showed > him a picture of her dog. <said>What a cutie! I bet he's smart, > too.</said>, he said, as he thought <said aloud="false">gak, what > an ugly dog</said> to himself. > > >> If we do ask tei-l next week, I'd like to ask first whether we need >> more than q and optionally quote. > > I think it's pretty important that we make this distinction. I have > received quite a few complaints about the "<q> as speech or thought" > vs "<q> as written quotation, speech, thought, or example" problem. > While there are many (perhaps most) who don't care, there are a quite > a few projects for which the difference between quotations of written > passages external to the text and a character's spoken words in > running prose are really quite important. > > I think the proposed solution brings the folks who don't care at all > and use <q> for everything into the fold, while giving those for whom > the nuances are important a mechanism for clean distinction. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From cwittern at gmail.com Mon Apr 16 20:54:43 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 17 Apr 2007 09:54:43 +0900 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <1176697332.7781.73.camel@localhost> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461CA39A.806@oucs.ox.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> Message-ID: <46241AD3.9070000@gmail.com> Daniel O'Donnell wrote: > On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: > >> Sebastian Rahtz wrote: >> >>> James Cummings wrote: >>> >>>> Yup, I understand and agree with all of that. So by suggesting that >>>> people use namespaces for their new attributes we encourage the good >>>> practice that TEI already follows of not having @myspace:where mean >>>> something on one element and @myspace:where mean something else on >>>> another element. >>>> >>> what if add the TEI-consonant @type to an element which doesnt have it >>> already? >>> >> I believe consensus was that this was an 'unclean' change, and thus >> element and attribute are put in a user-defined namespace. >> > > Indeed it was the consensus. And indeed if you added it to new elements > because you wanted to have a global type element, we seemed to think > that all types were my:type. > > Well, things are moving so fast it becomes difficult to keep track. Say I want to add @type to p. Does this mean my tei:p has to be changed to my:p? This seems quite drastic to me. It would be sufficient in my book simply to say @my:type and leave p as tei:p. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From daniel.odonnell at uleth.ca Tue Apr 17 00:23:28 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Mon, 16 Apr 2007 22:23:28 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <46238FFA.7030900@oucs.ox.ac.uk> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> <1176694176.7781.30.camel@localhost> <17955.34232.705683.173662@emt.wwp.brown.edu> <46238FFA.7030900@oucs.ox.ac.uk> Message-ID: <1176783808.7115.18.camel@localhost> While I may have been more pithy than politic, I certainly didn't mean to be uncharitable about the issue. I can certainly see how people might want to mark these distinctions. But I think the lack of traditional non-structural punctuation for this distinction is crucial. The distinctions are far finer than most of us *can* regularly make, let alone want to, and I agree with Lou here that type covers a lot of ground for more specialist uses. I'm still not convinced that q and quote are actually necessary, let alone said. I like said as an element name, but am not sure about its use being that necessary. -dan On Mon, 2007-04-16 at 16:02 +0100, Lou Burnard wrote: > Sorry, but I really do not agree with Syd on this issue, though I am > pleased that he thinks I do! > > As I understand it, the proposal is to invent a new element, presumably > to join the already over-burdened Core module, for the purpose of > marking up representations of speech (but not thought) which are > considered (by someone) to be "part of the text", and not quoted from > somewhere else. It's less clear whether or not such representations are > necessarily typographically distinct in the original but that seems to > be relevant. > > I don't doubt that for some people and some applications these > distinctions are important, and may even be useful, but I do doubt very > much whether Mr or Ms TEI-average-user will want to make them. In the > decade or more that people have been happily using <q> to mark > "representation of speech or thought", I am not aware of anyone having > the kind of major problem we are being told now exists. "representation > of speech or thought" is an inherently vague concept (after all, that's > what *all* text is!) It's true that some feel we can distinguish "rep > of speech or thought" which is "internal" to a work from ditto when > presented as external, but that's why we have both <q> and <quote>; I > am happy with the idea of promoting <quote> as the tag to use if you > want to make explicit that something is regarded as external, though I > don't believe it to be strictly necessary. > > If you want to distinguish more finely within either of these elements, > the attributes are there: in particular, @type is there precisely to > indicate whether the material is "spoken" "thought" or "written", and > speech can be further subdivided according to @direct. > > So the best interpretation I can put on this proposal is that it is > arguing for a new bit of syntactic sugar. Less charitably, and to quote > our esteemeed Board chair, this looks like "a solution looking for a > problem". Hmm, should that have been a <q> or a <quote>? does what > someone says in an email count as <q> or <said> or what? aaargh! > > Furthermore, I really don't think this is the most important issue for > us to be consulting with Mr and Mrs TEI Average User about right now. > They will say <said>not said but sad</said>... > > > Lou > > > Syd Bauman wrote: > >> Are these not all syntactic sugar for q at type? I am not at all keen > >> on introducing more elements here, since the two we have are > >> historically a place where people have a mess of a time. > > > > I'm not sure which 'all' you are asking about, but the answer, I > > think, is yes, to some extent they are syntactic sugar for <q> with > > type=. But that doesn't change the need for a new element, which is > > very strong. The problem is that the Guidelines up to now have used > > <q> for more than one thing. > > > > But on further reading your reply, I think I may not have made myself > > clear. The following > >>> How about > >>> - <sot>: speech or thought > >>> - <qst>: quoted speech or thought > >>> - <said>: said > > was not meant as a recommendation for 3 new elements, but rather as 3 > > possible names for the 1 new element we need to add. > > > > The thought occured to me to use <said> with an aloud= attribute that > > would be data.xTruthValue. > > > > Thus you might see > > He was trying to butter her up in earnest now. She showed > > him a picture of her dog. <said>What a cutie! I bet he's smart, > > too.</said>, he said, as he thought <said aloud="false">gak, what > > an ugly dog</said> to himself. > > > > > >> If we do ask tei-l next week, I'd like to ask first whether we need > >> more than q and optionally quote. > > > > I think it's pretty important that we make this distinction. I have > > received quite a few complaints about the "<q> as speech or thought" > > vs "<q> as written quotation, speech, thought, or example" problem. > > While there are many (perhaps most) who don't care, there are a quite > > a few projects for which the difference between quotations of written > > passages external to the text and a character's spoken words in > > running prose are really quite important. > > > > I think the proposed solution brings the folks who don't care at all > > and use <q> for everything into the fold, while giving those for whom > > the nuances are important a mechanism for clean distinction. > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From lou.burnard at computing-services.oxford.ac.uk Tue Apr 17 04:30:12 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 17 Apr 2007 09:30:12 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46241AD3.9070000@gmail.com> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461CBA67.6050105@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> Message-ID: <46248594.1000408@computing-services.oxford.ac.uk> Wittern Christian wrote: > Daniel O'Donnell wrote: >> On Sun, 2007-04-15 at 10:32 +0100, James Cummings wrote: >> >>> Sebastian Rahtz wrote: >>> >>>> James Cummings wrote: >>>> >>>>> Yup, I understand and agree with all of that. So by suggesting >>>>> that people use namespaces for their new attributes we encourage >>>>> the good practice that TEI already follows of not having >>>>> @myspace:where mean something on one element and @myspace:where >>>>> mean something else on another element. >>>>> >>>> what if add the TEI-consonant @type to an element which doesnt have >>>> it already? >>>> >>> I believe consensus was that this was an 'unclean' change, and thus >>> element and attribute are put in a user-defined namespace. >>> >> >> Indeed it was the consensus. And indeed if you added it to new elements >> because you wanted to have a global type element, we seemed to think >> that all types were my:type. >> >> > Well, things are moving so fast it becomes difficult to keep track. > Say I want to add @type to p. Does this mean my tei:p has to be > changed to my:p? This seems quite drastic to me. It would be > sufficient in my book simply to say @my:type and leave p as tei:p. > > Christian > > Well, as regards namespace, the options seems to be: 1. The line of least resistance: say that your schema is not in any namespace (by saying ns="" on your <schemaSpec>) 2. The odour of sanctity: say that the attribute is new (by saying ns="http://myspace.com" on the <attDef> in the <elementSpec> in your <schemaSpec>) 3. Political correctness gone mad: say that the element is new (by saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) Of these three, I believe (but I'm not sure) that (2) and (3) are both what we are currently calling "conformant", but obvious (2) makes more sense. We don't have a name for (1) yet. From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 04:45:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 09:45:55 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46248594.1000408@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <1176303249.4952.3.camel@caedmon> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> <46248594.1000408@computing-services.oxford.ac.uk> Message-ID: <46248943.2010500@oucs.ox.ac.uk> Lou Burnard wrote: > Well, as regards namespace, the options seems to be: > > 1. The line of least resistance: say that your schema is not in any > namespace (by saying ns="" on your <schemaSpec>) > 2. The odour of sanctity: say that the attribute is new (by saying > ns="http://myspace.com" on the <attDef> in the <elementSpec> in your > <schemaSpec>) > 3. Political correctness gone mad: say that the element is new (by > saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) and leave the attribute in the empty namespace in that case > > Of these three, I believe (but I'm not sure) that (2) and (3) are both > what we are currently calling "conformant", but obvious (2) makes more > sense. I agree. And note that the most interchangeable format is (2). > > We don't have a name for (1) yet. "Overlap". The schema Christian makes for (1) overlaps the TEI mostly. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 17 09:26:52 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 17 Apr 2007 14:26:52 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <46248943.2010500@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <20070411154637.79588EB04B@webmail221.herald.ox.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> <46248594.1000408@computing-services.oxford.ac.uk> <46248943.2010500@oucs.ox.ac.uk> Message-ID: <4624CB1C.90105@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Lou Burnard wrote: >> Well, as regards namespace, the options seems to be: >> >> 1. The line of least resistance: say that your schema is not in any >> namespace (by saying ns="" on your <schemaSpec>) >> 2. The odour of sanctity: say that the attribute is new (by saying >> ns="http://myspace.com" on the <attDef> in the <elementSpec> in your >> <schemaSpec>) >> 3. Political correctness gone mad: say that the element is new (by >> saying ns="http://myspace.com" on the <elementSpec> in your <schemaSpec>) > and leave the attribute in the empty namespace in that case >> >> Of these three, I believe (but I'm not sure) that (2) and (3) are both >> what we are currently calling "conformant", but obvious (2) makes more >> sense. > I agree. And note that the most interchangeable format is (2). I agree, if Christian adds @type to tei:p, then it is tei:p/@my:type... only the attribute is in a different namespace, not the element. If he changes the content model of tei:p in any way which is not a pure subset, then it would become my:p. >> We don't have a name for (1) yet. > "Overlap". The schema Christian makes for (1) overlaps the TEI mostly. I believe on the little chart you produced recently (for an in-house discussion) of different aspects of Conformance, this might be 'Extended TEI'. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 09:36:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 14:36:46 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CB1C.90105@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <17950.30928.5625.745800@emt.wwp.brown.edu> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> <46248594.1000408@computing-services.oxford.ac.uk> <46248943.2010500@oucs.ox.ac.uk> <4624CB1C.90105@computing-services.oxford.ac.uk> Message-ID: <4624CD6E.8040702@oucs.ox.ac.uk> James Cummings wrote: > I believe on the little chart you produced recently (for an in-house > discussion) of different aspects of Conformance, this might be 'Extended TEI'. > Yes, it is a sibling to Tite. I'll let Lou share the gory details of the classification system which arose from our discussion here. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Tue Apr 17 09:38:45 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Tue, 17 Apr 2007 14:38:45 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CD6E.8040702@oucs.ox.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <461E9589.3080100@oucs.ox.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> <46248594.1000408@computing-services.oxford.ac.uk> <46248943.2010500@oucs.ox.ac.uk> <4624CB1C.90105@computing-services.oxford.ac.uk> <4624CD6E.8040702@oucs.ox.ac.uk> Message-ID: <4624CDE5.5060409@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> I believe on the little chart you produced recently (for an in-house >> discussion) of different aspects of Conformance, this might be >> 'Extended TEI'. >> > Yes, it is a sibling to Tite. > > I'll let Lou share the gory details of the classification > system which arose from our discussion here. > Be aware that the printout you gave me has an error .. (in the heading of the last column, you've called it 'TEI conformant', when t'ain't since t'ain't no ODD.) -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 09:47:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 14:47:18 +0100 Subject: [tei-council] attribute names (was MD chapter revised: namespace rules) In-Reply-To: <4624CDE5.5060409@computing-services.oxford.ac.uk> References: <461AA00E.50405@computing-services.oxford.ac.uk> <17950.45690.802744.758277@emt.wwp.brown.edu> <461EB69C.8050106@oucs.ox.ac.uk> <1176420874.23247.2.camel@odonned-eng06> <461ECADF.4090508@oucs.ox.ac.uk> <461F5121.9040905@oucs.ox.ac.uk> <461F7E92.8080201@oucs.ox.ac.uk> <461F9169.5040401@computing-services.oxford.ac.uk> <461F9CAD.6040106@oucs.ox.ac.uk> <461FA6A1.7000308@computing-services.oxford.ac.uk> <4620B440.604@oucs.ox.ac.uk> <4620C3E4.2070206@oucs.ox.ac.uk> <4620CB99.7090207@oucs.ox.ac.uk> <4620D12E.8060309@oucs.ox.ac.uk> <4620F7A0.4040906@computing-services.oxford.ac.uk> <46214656.7040802@oucs.ox.ac.uk> <4621485B.6020809@oucs.ox.ac.uk> <4621F11D.9080703@oucs.ox.ac.uk> <1176697332.7781.73.camel@localhost> <46241AD3.9070000@gmail.com> <46248594.1000408@computing-services.oxford.ac.uk> <46248943.2010500@oucs.ox.ac.uk> <4624CB1C.90105@computing-services.oxford.ac.uk> <4624CD6E.8040702@oucs.ox.ac.uk> <4624CDE5.5060409@computing-services.oxford.ac.uk> Message-ID: <4624CFE6.4040802@oucs.ox.ac.uk> James Cummings wrote: > Be aware that the printout you gave me has an error .. (in the heading of > the last column, you've called it 'TEI conformant', when t'ain't since > t'ain't no ODD.) > This is a document which was born without benefit of clergy, ie validated by its author against a hand-constructed schema. HOWEVER, since the document has no DOCTYPE or schema PI, we can't hold its bastardy against it, so we make it a ward of court and say that its ODD is teiall. Unless we mandate a link to an ODD, using a notation we don't have, we can never claim conformant documents must have an ODD. A TEI Conformant System has an ODD, as part of it, yes. You may say that the unnamed document's ODD being teiall is a legal fiction, but that may be true of any document. If I show you a XML doc, and an ODD, and claim the two relate, you're just taking my word for it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From laurent.romary at loria.fr Tue Apr 17 12:41:16 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 17 Apr 2007 18:41:16 +0200 Subject: [tei-council] TEI Week in Berlin Message-ID: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Dear all, Here's some update information about the TEI related events in Berlin next week. You will see below the outline of 3 events (you're not involved in the first one, but it's just to keep you informed), and I would like to ask at this stage for some volunteer to chair and ask as commentators for the workshop some of you have agreed to participate to (see program). Viele Gr??e, Laurent Summary of the TEI week in Berlin: ?eSciDoc-Textgrid TEI expert workshop? [you are not concerned by this - it's a joint tutorial between the two projects date: 24.04.07 place: Tagungsst?tte Harnack-Haus Ihnestra?e 16-20 14195 Berlin http://www.harnackhaus-berlin.mpg.de timeframe: 13-17:30h ?Putting the TEI to the test? [see program below - I need two volunteers per session: one to chair and one to comment on the fly after the talks] date: 25.04.07 place: Tagungsst?tte Harnack-Haus Ihnestra?e 16-20 14195 Berlin http://www.harnackhaus-berlin.mpg.de timeframe: 10:30 - 17:20h "TEI Council Meeting" [well you know about it, don't you?] date: 26.04.-27.04.07 place: Berlin-Brandenburgische Akademie der Wissenschaften Jaegerstr. 22/23 10117 Berlin timeframe: 9-18h ---------------------------------------------------- Program TEI workshop Putting the TEI to the test, 25.04.07 10:30 ? 11:00 Introductory Talk 10:30 ? 10:45 Christian Wittern: P5: current state and prospects 10:45 ? 11:00 Lou Burnard: P5: technical overview -------- 11:00 ? 13:10 1. Session: Text-based projects Chair: N.N. 11:00 ? 11:15 Fotis Jannidis: Searching TEI texts in TextGrid using basic encodings 11:15 ? 11:30 Torsten Scha?an: Aspects of the integration of TEI in the workflows of the Wolfenbuettel digital library (WDB) 11:30 ? 12:00 joint discussion 12:00 ? 12:15 Christian Mahnke: Fulltext processing at the GDZ 12:15 ? 12:25 Bernhard Assmann: The application of TEI in the digitalization project of the work of Frederick the Great (status report, presentation in German) 12:25 ? 12:35 Thomas Burch: The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus (status report) 12:35 ? 13:10 joint discussion ----------- 13:10 - 14:00 lunch break --------- 14:00 ? 15:00 2. Session: Charter Chair: N.N. 14:00 ? 14:30 Georg Vogeler: How to standardize XML-encoding of medieval and early modern charters and instruments 14:30 ? 15:00 discussion -------- 15:00 ? 16:00 3. Session: Dictionaries Chair: N.N. 15:00 ? 15:15 Alexander Geyken: Representation of the German ?Woerterbuch der Gegenwartssprache? in TEI: encoding strategies and limitations 15:15 ? 15:30 Werner Wegstein: The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses 15:30 ? 16:00 joint discussion --------- 16:00 ? 16:20 coffee break ------- 16:20 ? 17:20 4. Session: Linguistic Annotations Chair: N.N. 16:20 ? 16:35 Susanne Alt: TEI encoding of parallel texts: issues and proposals 16:35 ? 16:50 Andreas Witt: The Role of TEI-Annotations for the Sustainable Representation of Linguistic Resources 16:50 ? 17:20 joint discussion -------- 17:20 end of workshop From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 17 16:49:37 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 17 Apr 2007 21:49:37 +0100 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> References: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <462532E1.2080304@oucs.ox.ac.uk> I am happy to chair session 1 if you like sebastian From Syd_Bauman at Brown.edu Tue Apr 17 21:24:25 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 17 Apr 2007 21:24:25 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> References: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <17957.29513.557381.774077@emt.wwp.brown.edu> I am of course happy to assist you in any way I can; either chairing or commenting on any session would be fine. From jawalsh at indiana.edu Tue Apr 17 22:10:35 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Tue, 17 Apr 2007 22:10:35 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> References: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <8D4537AF-D998-4FA6-BFF8-90F6184DB6CC@indiana.edu> Laurent, Feel free to plug me in as a chair or commentator for any session where you need people. John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> On Apr 17, 2007, at 12:41 PM, Laurent Romary wrote: > Dear all, > Here's some update information about the TEI related events in > Berlin next week. You will see below the outline of 3 events > (you're not involved in the first one, but it's just to keep you > informed), and I would like to ask at this stage for some volunteer > to chair and ask as commentators for the workshop some of you have > agreed to participate to (see program). > Viele Gr??e, > Laurent > > Summary of the TEI week in Berlin: > > ?eSciDoc-Textgrid TEI expert workshop? [you are not concerned by > this - it's a joint tutorial between the two projects > date: 24.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 13-17:30h > > ?Putting the TEI to the test? [see program below - I need two > volunteers per session: one to chair and one to comment on the fly > after the talks] > date: 25.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 10:30 - 17:20h > > "TEI Council Meeting" [well you know about it, don't you?] > date: 26.04.-27.04.07 > place: > Berlin-Brandenburgische Akademie der Wissenschaften > Jaegerstr. 22/23 > 10117 Berlin > timeframe: 9-18h > > ---------------------------------------------------- > Program TEI workshop Putting the TEI to the test, 25.04.07 > > 10:30 ? 11:00 > Introductory Talk > 10:30 ? 10:45 Christian Wittern: > P5: current state and prospects > > 10:45 ? 11:00 Lou Burnard: > P5: technical overview > -------- > 11:00 ? 13:10 > 1. Session: Text-based projects > Chair: N.N. > > 11:00 ? 11:15 Fotis Jannidis: > Searching TEI texts in TextGrid using basic encodings > > 11:15 ? 11:30 Torsten Scha?an: > Aspects of the integration of TEI in the workflows of the > Wolfenbuettel digital library (WDB) > > 11:30 ? 12:00 > joint discussion > > 12:00 ? 12:15 Christian Mahnke: > Fulltext processing at the GDZ > > 12:15 ? 12:25 Bernhard Assmann: > The application of TEI in the digitalization project of the work of > Frederick the Great > (status report, presentation in German) > > 12:25 ? 12:35 Thomas Burch: > The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus > (status report) > > 12:35 ? 13:10 > joint discussion > ----------- > 13:10 - 14:00 > lunch break > --------- > 14:00 ? 15:00 > 2. Session: Charter > Chair: N.N. > > 14:00 ? 14:30 Georg Vogeler: > How to standardize XML-encoding of medieval and early modern > charters and > instruments > > 14:30 ? 15:00 > discussion > -------- > 15:00 ? 16:00 > 3. Session: Dictionaries > Chair: N.N. > > 15:00 ? 15:15 Alexander Geyken: > Representation of the German ?Woerterbuch der Gegenwartssprache? in > TEI: > encoding strategies and limitations > > 15:15 ? 15:30 Werner Wegstein: > The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses > > 15:30 ? 16:00 > joint discussion > --------- > 16:00 ? 16:20 > coffee break > ------- > 16:20 ? 17:20 > 4. Session: Linguistic Annotations > Chair: N.N. > > 16:20 ? 16:35 Susanne Alt: > TEI encoding of parallel texts: issues and proposals > > 16:35 ? 16:50 Andreas Witt: > The Role of TEI-Annotations for the Sustainable Representation of > Linguistic > Resources > > 16:50 ? 17:20 > joint discussion > -------- > 17:20 > end of workshop > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From cwittern at gmail.com Tue Apr 17 22:55:33 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 18 Apr 2007 11:55:33 +0900 Subject: [tei-council] New elements in TEI Tite Message-ID: <462588A5.80307@gmail.com> Dear Council members, Users from the library community have submitted work done under the title "TEI Tite" to the TEI Board and Council. While I have hold off the announcement here to see what the Board thinks, it now seems to be justified to ask the Council's opinion on some specific items. The whole submission is available at http://artsci.wustl.edu/~ptrolard/tite.tgz. Within this archive, there is a document p5/teitite.odd, which is a P5 customization that defines a schema that is intended for the use of keyboarding companies, most likely with subsequent conversion to proper TEI. (More about the background of this is in preface/tei/preface-tei.pdf and preface/tei/preface-dlf.pdf, but I do not waste our time by requesting you to read it). Most of the modifications in Tite are deletions or syntactical sugar, but there are two elements newly defined. It seems worthwhile to ask the question, whether these should have a place in P5 as well. The two elements are defined as follows: <elementSpec ident="cols" mode="add"> <desc>(columns) with the "n" attribute (denoting new number of columns) is used to mark where a document changes columnar layout.</desc> <classes> <memberOf key="model.milestoneLike"/> </classes> <content> <rng:empty/> </content> <attList> <attDef ident="ed" mode="add"> <desc>indicates the edition or version in which the change in columnar layout is located at this point</desc> <datatype> <rng:ref name="data.code"/> </datatype> <!--<default value=""/> <valList type="open"/>--> </attDef> </attList> </elementSpec> <elementSpec ident="ornament" mode="add"> <desc>for capturing typographical feature: printer's ornament, horizontal line, strings of asterisks or periods, etc, indicating an informal division that does not call for a new <div> element. If a horizontal rule or printer's ornament, use appropriate "type" attribute and leave the element empty; if the ornament can be represented with characters, set "type" value to "characters" and include these in the element.</desc> <classes> <!-- ornament appears where figure can appear --> <memberOf key="model.inter"/> <memberOf key="model.titlepagePart"/> <memberOf key="model.common"/> <memberOf key="att.typed"/> </classes> <content> <rng:text/> </content> </elementSpec> -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From cwittern at gmail.com Tue Apr 17 22:58:29 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 18 Apr 2007 11:58:29 +0900 Subject: [tei-council] Draft Agenda for Berlin meeting Message-ID: <46258955.4010705@gmail.com> Dear Council members, I am circulating the draft agenda. Please read through and report as indicated. If there are additional items that need to be added or other oversights, please say so. Christian DRAFT Agenda for the TEI Council meeting in Berlin, April 26 to 27 Expected to participate: Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern PART I 1) Adotion of Agenda 2) Minutes, work items, progress since last meeting: http://www.tei-c.org.uk/Council/tcm29.xml?style=printable Please look at the action items and report progress here before the meeting! 3) Reports on Chapter reviews Council members are expected to report on the outcome of the chapter review they have undertaken in the last weeks. It would be helpful, if you could provide a short summary of your findings, including the outstanding issues that have to be adressed. We will collect these issues during this phase and resolve them later. 4) Conformance Draft (JC) 5) Formatting of Guidelines (JC & DP) PART II 6) Resolution of outstanding issues: - proposal to add a metadata element to record application information (SR) - nyms (LB) - proposal for places & placenames (MD) - fascsimile markup (TC) - elements suggested for TEI Tite - ... (more to come? please remind me of other issues) 7) Adoption of Resolutions -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 03:59:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 08:59:34 +0100 Subject: [tei-council] New elements in TEI Tite In-Reply-To: <462588A5.80307@gmail.com> References: <462588A5.80307@gmail.com> Message-ID: <4625CFE6.20008@oucs.ox.ac.uk> I have made this ticket 321 in trac, to provide a context for resolution > -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Wed Apr 18 05:44:24 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 18 Apr 2007 05:44:24 -0400 (EDT) Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <46238FFA.7030900@oucs.ox.ac.uk> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> <1176694176.7781.30.camel@localhost> <17955.34232.705683.173662@emt.wwp.brown.edu> <46238FFA.7030900@oucs.ox.ac.uk> Message-ID: <200704180944.l3I9iOBX009476@draco.services.brown.edu> In the following, I'm going to use "said" as the name of the proposed element for direct speech or thought only. The name is not carved in stone, but I think Sebastian, Dan, Julia and I all like it better than anything else that has been suggested. > I really do not agree with Syd on this issue > As I understand it, ... I'm curious then, Lou, whether you've changed your mind or it's just that I did such a bad job explaining the proposal, you didn't recognize it as the one to which we had already agreed! No matter, really, but I suspect I must have done a very poor job of explaining it, for your recap does not match the proposal well at all. Let me try again. There were actually 2 proposals rolled up in my previous e-mail, so I will separate them explicitly here. In all cases here typographic distinction is no more important for these elements than it is for <soCalled> et al. That is, it is not relevant in the abstract, although it is important to some encoders & projects. --- 1 --- Lou: this first proposal is exactly what we spoke at length about on the phone ~3 weeks ago. You were behind this proposal as long as we leave <q> as the general-purpose element. <said> is for direct speech (or its discursive equivalents: e.g. reported thought or speech, dialog, etc.), whether real or contrived, typically as part of the current text, although I suppose one could imagine otherwise. Most common usage is likely to be a character's spoken words in a novel or a person's spoken words reported in a non-fiction article. In English prose it will very often be associated with phrases like "he said", or "she asked". <said> would not be a viable child of <cit>. <quote> is for material that is quoted from sources outside the text, whether correctly or not, whether real or contrived, whether originally spoken or written. Most common usage is likely to be quoting passages from other documents. May be used in a dictionary for real or contrived examples of usage. <quote> would continue to be a viable child of <cit>. <q> is for passages quoted from elsewhere; in narrative, either direct or indirect speech or something being quoted from outside the text; in dictionaries, real or contrived examples of usage. <q> would continue to be a viable child of <cit>, for those who don't use the more specific <quote>. That is, <q> remains exactly as it was in P4; <quote> remains as it was in P4; <said> takes the role of only the "direct speech or thought" subset of what <q> handles. There are of course cases where people speak quotations or quotations include direct speech, in which case <quote> can go in <said> or vice-versa. Some people assert that they can't see the distinction between <quote> and the proposed <said>, and I'm sorry to say I simply can't understand this point of view. While there must be some difficult edge cases, as a general rule I do not think it is difficult to tell these two phenomena apart at all. I just picked up a mid-20th century science fiction novel and flipped through the pages. I had no trouble at all differentiating (the vast majority were <said>). I read an article in the NY Times over the weekend -- again, no trouble at all differentiating. I just asked Julia, and she said that in the creation of the entire WWP corpus so far there has never been a case where an encoder (most of whom are undergraduates) has had any difficulty making the distinction. There are 17,104 occurrences of <q> or <quote> start-tags in the distributed WWP corpus[2]. She said "it's harder to tell what is and isn't a <list> than it is to [differentiate between <said> and <quote>]". There is one definite hole in this proposal: as it is worded, the encoding of indirect speech (e.g. the bit about grapes in "He said that he doesn't like grapes") is forced into <q>. The only two reasonable solutions I see are: A. add indirect speech to semantics of <said> B. remove indirect speech from semantics of <q> Personally, I really don't care. I have never seen anyone encode indirect speech ever, but that doesn't mean there aren't cases out there. Here is a passage from an article about an anti-war protest that was held in Boston while we were in Sofia at the 2005 MM. <p>One demonstrator carried a sign that read, <quote>Bush Wants Your Children For Cannon Fodder,</quote> and another ...</p> <p>[Cindy Sheehan] mentioned a woman who had once e-mailed her after she cursed the Bush administration.</p> <p><said>She said, <said>Cindy, don't you want to use a little nicer language, because you know there might be people sitting on the fence that you offend,</said></said> Sheehan told the crowd. <said>And do you know what I said? I said, <said>Damn it, why is anybody on that fence still?</said></said> <p><said>A lot of people will come up to me and say, <said>My country right or wrong,</said></said> Sheehan added later. <said>And you know what I say? When my country is wrong, it is so wrong, and it is mandatory for us to stop it, to stop the killing, to stop the people in power.</said> -- http://www.commondreams.org/headlines05/1030-05.htm I will also note that off the top of my head I can't really see why an example of usage in a dictionary would be <q> instead of <quote>. Laurent? --- 2 --- The second proposal is essentially an offshoot or amplification of the first. It stems from my observation that there are people out there who not only don't want to differentiate between <said> and <quote>, but who don't want to make the distinctions between <soCalled>, <mentioned>, <term>, etc., either. In many cases these encoders don't use any element (they just transcribe the quotation marks), but IIRC at least one library project used <q> for all of them. This second proposal leaves <said> and <quote> as they were in the first proposal, but expands the catchment of <q> to include all of these often- enclosed-in-quotation-marks sorts of phrase level phenomena: <q> id for any of a number of features when differentiating among them is not desired, e.g. because it is economically not feasible or simply not of interest for the current purpose. Items that may be encoded this way include - representation of speech or thought - quotation - technical terms and glosses - passages mentioned, not used - authorial distance and perhaps even - from a foreign language - linguistically distinct - emphasized - any other use of quotation marks in the source Notes ----- [1] "Outside the text" here does not necessarily mean "not a descendant of my ancestor <text> element", but rather something quite a bit less precise, more along the lines of "not from 'round here". I.e., something in chapter 1 may be a <quote> even if the thing being quoted is a passage from chapter 3 of the same document. This, of course, blurs the line a bit, and may be worth consideration. [2] I did not say "elements" because many of these <q> and <quote> elements may be partial elements which, via next= and prev=, are only part of a complete aggregate element. From cwittern at gmail.com Wed Apr 18 07:26:35 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 18 Apr 2007 20:26:35 +0900 Subject: [tei-council] Draft Agenda for Berlin meeting In-Reply-To: <CD07E394-DA40-4FB2-8CEA-99CD3C2A80F0@aksis.uib.no> References: <46258955.4010705@gmail.com> <CD07E394-DA40-4FB2-8CEA-99CD3C2A80F0@aksis.uib.no> Message-ID: <5268d87d0704180426x7f1db189q6a0e08deb97136df@mail.gmail.com> On 18/04/07, Tone Merete Bruvik <tone.bruvik at aksis.uib.no> wrote: > > Hello Christian, > > Did you have in mind that we should do the reporting on "3) Reports on > Chapter reviews" before the meeting to the Council list or at the meeting, > or both? > Both :-) Thanks for the first part. All the best, Christian > To summaries that I have done: > > My chapters are "Ch. 1: Languages and Character Sets" and the last part of > ch. 24: "Using The TEI", that is "Multiple Hierarchies". I have done this by > adding comments to the trac system, as suggested in Lou's email "What to do > with an easter egg" as method "(b) add a comment to the TRAC ticket for > this chapter in this task, leaving the ticket open for someone else to > complete the required action". See the trac system for details. -- Christian Wittern, Kyoto From Syd_Bauman at Brown.edu Wed Apr 18 07:44:09 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 18 Apr 2007 07:44:09 -0400 Subject: [tei-council] Trac err, anyone? Message-ID: <17958.1161.251387.587569@emt.wwp.brown.edu> Is anyone else getting "Oops... Trac detected an internal error:" followed by a Python traceback from http://tei.oucs.ox.ac.uk/trac/TEIP5 or http://tei.oucs.ox.ac.uk/trac/TEIP5/login? From arianna.ciula at kcl.ac.uk Wed Apr 18 07:49:10 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 18 Apr 2007 12:49:10 +0100 Subject: [tei-council] Draft Agenda for Berlin meeting In-Reply-To: <5268d87d0704180426x7f1db189q6a0e08deb97136df@mail.gmail.com> References: <46258955.4010705@gmail.com> <CD07E394-DA40-4FB2-8CEA-99CD3C2A80F0@aksis.uib.no> <5268d87d0704180426x7f1db189q6a0e08deb97136df@mail.gmail.com> Message-ID: <462605B6.6020203@kcl.ac.uk> Hi, you will find the comments on the chapters I was supposed to proofread in the tickets assigned to me in Trac. I am sorry these comments are very fragmentary, but I can make a brief summary for Berlin. I have sent only to Lou some additional comments about the extension proposed for places for ND with the suggestion to ask feedback from the council after he had a look through it. I believe work has started already on all these chapters, in part based on some of my comments, so it may be not that useful to report on my proofreading, but rather on the work that has been done by the editors on them. Arianna Christian Wittern wrote: > On 18/04/07, Tone Merete Bruvik <tone.bruvik at aksis.uib.no> wrote: >> >> Hello Christian, >> >> Did you have in mind that we should do the reporting on "3) Reports on >> Chapter reviews" before the meeting to the Council list or at the >> meeting, >> or both? >> > Both :-) > > Thanks for the first part. > > All the best, > > Christian > > >> To summaries that I have done: >> >> My chapters are "Ch. 1: Languages and Character Sets" and the last >> part of >> ch. 24: "Using The TEI", that is "Multiple Hierarchies". I have done >> this by >> adding comments to the trac system, as suggested in Lou's email "What >> to do >> with an easter egg" as method "(b) add a comment to the TRAC ticket for >> this chapter in this task, leaving the ticket open for someone else to >> complete the required action". See the trac system for details. > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 09:04:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 14:04:21 +0100 Subject: [tei-council] Trac err, anyone? In-Reply-To: <17958.1161.251387.587569@emt.wwp.brown.edu> References: <17958.1161.251387.587569@emt.wwp.brown.edu> Message-ID: <46261755.8000104@oucs.ox.ac.uk> Syd Bauman wrote: > Is anyone else getting "Oops... Trac detected an internal error:" > followed by a Python traceback from > http://tei.oucs.ox.ac.uk/trac/TEIP5 or > http://tei.oucs.ox.ac.uk/trac/TEIP5/login? > > sory about that, restored service now. it happens because we run kernel 2.6.15, and our SAN triggers a bug which existed from 2.6.13 to 2.6.15. Sigh. You did want to know, right? Am considering a dist-upgrade. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 12:01:06 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 17:01:06 +0100 Subject: [tei-council] trac Message-ID: <462640C2.2060202@oucs.ox.ac.uk> sorry, this is off briefly after an upgrade. back very soon -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 12:48:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2007 17:48:14 +0100 Subject: [tei-council] trac Message-ID: <46264BCE.8050105@oucs.ox.ac.uk> back now. hopefully the OS upgrade we just did will stop the problem which caused Roma and trac to fall over twice this month. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Wed Apr 18 14:04:00 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 18 Apr 2007 12:04:00 -0600 Subject: [tei-council] quotation marks, quotes, etc. In-Reply-To: <200704180944.l3I9iOBX009476@draco.services.brown.edu> References: <17954.43716.870610.6618@emt.wwp.brown.edu> <4622AF0C.8050001@oucs.ox.ac.uk> <200704160101.l3G11eiw026283@perseus.services.brown.edu> <1176694176.7781.30.camel@localhost> <17955.34232.705683.173662@emt.wwp.brown.edu> <46238FFA.7030900@oucs.ox.ac.uk> <200704180944.l3I9iOBX009476@draco.services.brown.edu> Message-ID: <1176919440.12509.14.camel@odonned-eng06> I understand the point of this much more clearly now and see that it is not necessarily creating artificial or uncommon distinctions. For reasons that have never been clear to me (which may be where the problem lies) q:quote is one of the distinctions I always need to look up, and I can see me having to do the same with q:quote:said. But I think that's me rather than the element. So basically the idea is: a) if you don't care about distinguishing anything that might appear in quotations, or can't decide use q b) If you do care, use quote for things that are documentable in principle--i.e. quotations of speech or text or whatever from somewhere else. c) If you are reporting what was said, written, or thought spontaneously, use said. <p>President Bush read <quote>underestimate</quote> from the teleprompter, but said <said>misunderestimate</said>. He got the next bit right, though, when he said <said>us</us> which agreed exactly with the teleprompter's <quote>us</quote>.</p> <p>When I said <quote>The insurgency's in its last throes</quote>, I didn't say how long they'd last.</p> I think that it is useful to keep open the possibility of marking indirect speech, though of course that could be done using <seg>, since I can think off the top of my head, as I was saying to Syd, of a research project that could usefully mark direct and indirect speech for analysis. -dan On Wed, 2007-18-04 at 05:44 -0400, Syd Bauman wrote: > In the following, I'm going to use "said" as the name of the proposed > element for direct speech or thought only. The name is not carved in > stone, but I think Sebastian, Dan, Julia and I all like it better > than anything else that has been suggested. > > > > I really do not agree with Syd on this issue > > As I understand it, ... > > I'm curious then, Lou, whether you've changed your mind or it's just > that I did such a bad job explaining the proposal, you didn't > recognize it as the one to which we had already agreed! No matter, > really, but I suspect I must have done a very poor job of explaining > it, for your recap does not match the proposal well at all. Let me try > again. > > > There were actually 2 proposals rolled up in my previous e-mail, so I > will separate them explicitly here. > > In all cases here typographic distinction is no more important for > these elements than it is for <soCalled> et al. That is, it is not > relevant in the abstract, although it is important to some encoders & > projects. > > > --- 1 --- > Lou: this first proposal is exactly what we spoke at length about on > the phone ~3 weeks ago. You were behind this proposal as long as we > leave <q> as the general-purpose element. > > <said> is for direct speech (or its discursive equivalents: e.g. > reported thought or speech, dialog, etc.), whether real or > contrived, typically as part of the current text, although I > suppose one could imagine otherwise. Most common usage is > likely to be a character's spoken words in a novel or a > person's spoken words reported in a non-fiction article. In > English prose it will very often be associated with phrases > like "he said", or "she asked". <said> would not be a viable > child of <cit>. > > <quote> is for material that is quoted from sources outside the text, > whether correctly or not, whether real or contrived, whether > originally spoken or written. Most common usage is likely to > be quoting passages from other documents. May be used in a > dictionary for real or contrived examples of usage. <quote> > would continue to be a viable child of <cit>. > > <q> is for passages quoted from elsewhere; in narrative, either > direct or indirect speech or something being quoted from outside > the text; in dictionaries, real or contrived examples of usage. > <q> would continue to be a viable child of <cit>, for those who > don't use the more specific <quote>. > > That is, <q> remains exactly as it was in P4; <quote> remains as it > was in P4; <said> takes the role of only the "direct speech or thought" > subset of what <q> handles. > > There are of course cases where people speak quotations or quotations > include direct speech, in which case <quote> can go in <said> or > vice-versa. > > Some people assert that they can't see the distinction between <quote> > and the proposed <said>, and I'm sorry to say I simply can't > understand this point of view. While there must be some difficult edge > cases, as a general rule I do not think it is difficult to tell these > two phenomena apart at all. I just picked up a mid-20th century > science fiction novel and flipped through the pages. I had no trouble > at all differentiating (the vast majority were <said>). I read an > article in the NY Times over the weekend -- again, no trouble at all > differentiating. I just asked Julia, and she said that in the creation > of the entire WWP corpus so far there has never been a case where an > encoder (most of whom are undergraduates) has had any difficulty making > the distinction. There are 17,104 occurrences of <q> or <quote> > start-tags in the distributed WWP corpus[2]. She said "it's harder to > tell what is and isn't a <list> than it is to [differentiate between > <said> and <quote>]". > > There is one definite hole in this proposal: as it is worded, the > encoding of indirect speech (e.g. the bit about grapes in "He said > that he doesn't like grapes") is forced into <q>. The only two > reasonable solutions I see are: > A. add indirect speech to semantics of <said> > B. remove indirect speech from semantics of <q> > Personally, I really don't care. I have never seen anyone encode > indirect speech ever, but that doesn't mean there aren't cases out > there. > > Here is a passage from an article about an anti-war protest that was > held in Boston while we were in Sofia at the 2005 MM. > > <p>One demonstrator carried a sign that read, <quote>Bush Wants > Your Children For Cannon Fodder,</quote> and another ...</p> > <p>[Cindy Sheehan] mentioned a woman who had once e-mailed her > after she cursed the Bush administration.</p> > <p><said>She said, <said>Cindy, don't you want to use a little > nicer language, because you know there might be people sitting on > the fence that you offend,</said></said> Sheehan told the crowd. > <said>And do you know what I said? I said, <said>Damn it, why is > anybody on that fence still?</said></said> > <p><said>A lot of people will come up to me and say, <said>My > country right or wrong,</said></said> Sheehan added later. > <said>And you know what I say? When my country is wrong, it is so > wrong, and it is mandatory for us to stop it, to stop the killing, > to stop the people in power.</said> > -- http://www.commondreams.org/headlines05/1030-05.htm > > I will also note that off the top of my head I can't really see why an > example of usage in a dictionary would be <q> instead of <quote>. > Laurent? > > > --- 2 --- > The second proposal is essentially an offshoot or amplification of the > first. It stems from my observation that there are people out there > who not only don't want to differentiate between <said> and <quote>, > but who don't want to make the distinctions between <soCalled>, > <mentioned>, <term>, etc., either. In many cases these encoders don't > use any element (they just transcribe the quotation marks), but IIRC > at least one library project used <q> for all of them. This second > proposal leaves <said> and <quote> as they were in the first proposal, > but expands the catchment of <q> to include all of these often- > enclosed-in-quotation-marks sorts of phrase level phenomena: > > <q> id for any of a number of features when differentiating among > them is not desired, e.g. because it is economically not feasible > or simply not of interest for the current purpose. Items that may > be encoded this way include > - representation of speech or thought > - quotation > - technical terms and glosses > - passages mentioned, not used > - authorial distance > and perhaps even > - from a foreign language > - linguistically distinct > - emphasized > - any other use of quotation marks in the source > > > Notes > ----- > [1] "Outside the text" here does not necessarily mean "not a > descendant of my ancestor <text> element", but rather something > quite a bit less precise, more along the lines of "not from 'round > here". I.e., something in chapter 1 may be a <quote> even if the > thing being quoted is a passage from chapter 3 of the same > document. This, of course, blurs the line a bit, and may be worth > consideration. > [2] I did not say "elements" because many of these <q> and <quote> > elements may be partial elements which, via next= and prev=, are > only part of a complete aggregate element. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Thu Apr 19 10:09:57 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 10:09:57 -0400 Subject: [tei-council] proposed re-org of div wrapping Message-ID: <17959.30773.719929.754597@emt.wwp.brown.edu> First, has anyone looked at or tested this limited phrase stuff yet? Second, in order to fix the content of <div> and permit an element for postscripts (which I propose to call <ps>), I am planning to re-organize the div wrapper classes. --------- current arrangement --------- model.divWrapper = argument byline dateline docAuthor docDate epigraph head opener salute model.divWrapper.bottom = closer signed trailer model.divWrapper is in the content model of lots of things, typically both at the top & bottom. model.divWrapper is in the content model of almost all the same things (but not <divGen> nor <castList>), but only at the bottom. --------- proposed arrangement --------- model.divTop = head opener salute epigraph model.divBottom = closed signed trailer ps model.divWrapper = argument byline dateline docAuthor docDate In general, model.divWrapper & model.divTop will be used near the tops of things; and correspondingly, model.divWrapper and model.divBottom would be used near the bottom. --------- This becomes a bit of a problem for <divGen>, which I just realized is permitted to have content. (It is required to be empty in P3 & P4, and was in P5 until we changed how the <index> element worked in summer 2005. I'm at a bit of a loss at the moment -- can someone explain to me why we did this? Why would <divGen> need content?) Please speak up if you have any thoughts about this. From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 19 10:16:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 19 Apr 2007 15:16:03 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <462779A3.3040105@oucs.ox.ac.uk> Can you summarize how <div> is broken at present? it had some major surgery not too long ago already. I am wondering what problem your proposal is solving. Sleeping dogs and all that. Limited phrase - no. I was vaguely trusting the test suite. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 10:30:29 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 19 Apr 2007 15:30:29 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <46277D05.8090604@oucs.ox.ac.uk> Syd Bauman wrote: > First, has anyone looked at or tested this limited phrase stuff yet? I'm still hoping for a report on what exactly you've done, but if you want it tested, the quickest method would be to hack together a quick test file in the tests directory, no? > > Second, in order to fix the content of <div> and permit an element > for postscripts (which I propose to call <ps>), I am planning to > re-organize the div wrapper classes. Eh? Hang on! where did this postscript element come from? is there a sffr or trac item about it? why do you think the content model of div is broken? > > --------- current arrangement --------- > > model.divWrapper = argument byline dateline docAuthor docDate > epigraph head opener salute > > model.divWrapper.bottom = closer signed trailer > > > model.divWrapper is in the content model of lots of things, typically > both at the top & bottom. > > model.divWrapper is in the content model of almost all the same ^.bottom, I presume > things (but not <divGen> nor <castList>), but only at the bottom. > > > --------- proposed arrangement --------- > > model.divTop = head opener salute epigraph > model.divBottom = closed signed trailer ps > model.divWrapper = argument byline dateline docAuthor docDate > this is not far from what we used to have, before (in Oxford) we decided to make divWrapper.bottom a subclass of divWrapper, and make divWrapper a combination of the old divTop and divBottom Why are you revisiting this issue? > In general, model.divWrapper & model.divTop will be used near the > tops of things; and correspondingly, model.divWrapper and > model.divBottom would be used near the bottom. > > --------- > > This becomes a bit of a problem for <divGen>, which I just realized > is permitted to have content. (It is required to be empty in P3 & P4, > and was in P5 until we changed how the <index> element worked in > summer 2005. I'm at a bit of a loss at the moment -- can someone > explain to me why we did this? Why would <divGen> need content?) > divGen is supposed to behave just like a div, except that its content can be generated. If it's a div it has to be able to have divWrapper elements inside it. It's a convenience for the encoder if the divWrapper elements can be explicitly attached to the divGen rather than generated along with the content. I don't think it's anything to do with <index> particularly. > > Please speak up if you have any thoughts about this. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From arianna.ciula at kcl.ac.uk Thu Apr 19 11:00:24 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 19 Apr 2007 16:00:24 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.30773.719929.754597@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> Message-ID: <46278408.9060401@kcl.ac.uk> Syd Bauman wrote: > model.divWrapper is in the content model of almost all the same > things (but not <divGen> nor <castList>), but only at the bottom. I think you mean model.divWrapper.bottom here. Arianna > > > --------- proposed arrangement --------- > > model.divTop = head opener salute epigraph > model.divBottom = closed signed trailer ps > model.divWrapper = argument byline dateline docAuthor docDate > > In general, model.divWrapper & model.divTop will be used near the > tops of things; and correspondingly, model.divWrapper and > model.divBottom would be used near the bottom. > > --------- > > This becomes a bit of a problem for <divGen>, which I just realized > is permitted to have content. (It is required to be empty in P3 & P4, > and was in P5 until we changed how the <index> element worked in > summer 2005. I'm at a bit of a loss at the moment -- can someone > explain to me why we did this? Why would <divGen> need content?) > > > Please speak up if you have any thoughts about this. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Thu Apr 19 11:27:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 11:27:38 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <462779A3.3040105@oucs.ox.ac.uk> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <462779A3.3040105@oucs.ox.ac.uk> Message-ID: <17959.35434.210454.689469@emt.wwp.brown.edu> > Can you summarize how <div> is broken at present? The main issue is that <head> & <opener> are premitted near the end of a division. > Limited phrase - no. I was vaguely trusting the test suite. I haven't looked to see if any of the test suite stresses this yet, although some of it probably does. The fact that nothing new seems to break in there is good sign, and I hope to check that there are a few tests in there or explicitly add them soon, but nonetheless I'd like someone to say "I tried it against my P5 docs, and ..." From Syd_Bauman at Brown.edu Thu Apr 19 15:09:23 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 15:09:23 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46277D05.8090604@oucs.ox.ac.uk> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> Message-ID: <17959.48739.941886.134351@emt.wwp.brown.edu> > Eh? Hang on! where did this postscript element come from? is there > a sffr or trac item about it? IIRC, you were the one who said that while we can publish P5 1.0 without a letters & memos module, not having a method for encoding postscripts would be an embarrassment. > why do you think the content model of div is broken? Because <head> and <opener> are allowed at the bottom where they shouldn't be. > > model.divTop = head opener salute epigraph > > model.divBottom = closed signed trailer ps > > model.divWrapper = argument byline dateline docAuthor docDate > > this is not far from what we used to have, before (in Oxford) we > decided to make divWrapper.bottom a subclass of divWrapper, and > make divWrapper a combination of the old divTop and divBottom > Why are you revisiting this issue? You are correct, it is quite similar. I'm revisiting it because as implemented bottom-in-Wrapper turns out not to work.[1] I wonder if it wouldn't be better to use different names, though. model.div.start, model.div.end? BTW, the proposal I sketched out was to keep the three models separate, but it might be cleaner to have only 2 classes that get referenced from content models. I.e., instead of what I sketched out, have model.divTop = model.divWrapper head opener salute epigraph model.divBottom = model.divWrapper closed signed trailer ps model.divWrapper = argument byline dateline docAuthor docDate So rather than having thinks like ( model.divTop | model.divWrapper )* in content models, you'd have only model.divTop* Since I can't see any reason to want to refer to the top-only things by themselves from within content, this may make more sense. > divGen is supposed to behave just like a div, except that its > content can be generated. If it's a div it has to be able to have > divWrapper elements inside it. It's a convenience for the encoder > if the divWrapper elements can be explicitly attached to the divGen > rather than generated along with the content. I don't think it's > anything to do with <index> particularly. Hmmm ... I suppose I can see how it might be more convenient to have some of the stuff surrounding the generated content in the source XML. <divGen type="stats"> <head>Statistics</head> </divGen> Although it's a little harder to see the case for <argument>, <epigraph>, or <salute>, let's presume there is a case. But if so, why not <closed>, <signed>, or <trailer>? [Lots of train-of-thought that is unnecessary but some may find mildly interesting moved from here to appendix.] What is the difference, in P4, between <div> and <divGen>? Simple: the former is *required* to have content, the latter is *required* to be empty. (Oh, yeah, and they have different names :-) In the current instantiation of P5, though, <div> is not required to have content and <divGen> is permitted to have some (but not all). Why not just ditch <divGen> entirely, and advise people to use <div type="generatedIndex"/> or whatever? Or perhaps we can add <div> to att.typed (taking type= out of att.divLike), so that there's a subtype=: <div type="generated" subtype="index"/> The semantics of the suggested value "generated" could be applied to other elements as well. <ab> jumps to mind, but I chuckle when I think what it means to see <lg type="generated" subtype="sonnet"> :-) (I guess I could quite easily be convinced that type= is not the right attribute here, but that there should be generated= of data.truthValue.) Note ---- [1] The system we currently have doesn't match what we decided in Oxford, I don't think; but it's not completely clear to me, and not important at this point. Appendix -------- There might well be other content that I'd prefer not to bother auto-generating, too. E.g. <divGen type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> </divGen> But if we allow either the above *or* having both div-top-stuff and then div-bottom-stuff, we need some mechanism for saying "put the generated content here". E.g. <divGen type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> <put-it-here/> <p>Any discrepancies in the table above ...</p> </divGen> or <divGen type="FuncInd"> <head>index of functions</head> <put-it-here/> <trailer>only functions written in ...</trailer> </divGen> If we're going to have some mechanism for "put the generated content here", why not call it <divGen>? E.g.: <div type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> <divGen type="genStats"/> <p>Any discrepancies in the table above ...</p> </div> or <div type="functionIndex"> <head>index of functions</head> <divGen type="funcs"/> <trailer>only functions written in ...</trailer> </divGen> The answer is, of course, because the statics example above is neither valid nor in harmony with the semantics of divisions. So perhaps there should be an <abGen>? From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 17:49:38 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 19 Apr 2007 22:49:38 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.48739.941886.134351@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> Message-ID: <4627E3F2.3010307@computing-services.oxford.ac.uk> Syd Bauman wrote: >> Eh? Hang on! where did this postscript element come from? is there >> a sffr or trac item about it? >> > > IIRC, you were the one who said that while we can publish P5 1.0 > without a letters & memos module, not having a method for encoding > postscripts would be an embarrassment. > Did I really. But that doesn't actually answer my question, does it? > > >> why do you think the content model of div is broken? >> > > Because <head> and <opener> are allowed at the bottom where they > shouldn't be. > > It depends what you mean by "bottom". If you have a div that has only a head in it, that's OK in my book, even tho the head is at the bottom. I assume that what you're objecting to is <div><p/><head/></div> which i agree looks decidedly broken. If you have a proposed revision of the divWrapper bit of the class system which provides a solution to this then so much the better: let's see it properly worked out and tested. > >>> model.divTop = head opener salute epigraph >>> model.divBottom = closed signed trailer ps >>> model.divWrapper = argument byline dateline docAuthor docDate >>> >> this is not far from what we used to have, before (in Oxford) we >> decided to make divWrapper.bottom a subclass of divWrapper, and >> make divWrapper a combination of the old divTop and divBottom >> Why are you revisiting this issue? >> > > You are correct, it is quite similar. I'm revisiting it because as > implemented bottom-in-Wrapper turns out not to work.[1] I wonder if > it wouldn't be better to use different names, though. > model.div.start, model.div.end? > > let's stick with top and bottom for the moment -- we might want start and end for horseification purposes one day. > BTW, the proposal I sketched out was to keep the three models > separate, but it might be cleaner to have only 2 classes that get > referenced from content models. I.e., instead of what I sketched out, > have > > model.divTop = model.divWrapper head opener salute epigraph > model.divBottom = model.divWrapper closed signed trailer ps > model.divWrapper = argument byline dateline docAuthor docDate > > I dont understand this: once a class is defined it can be used anywhere. Or are you proposing macros here? >> divGen is supposed to behave just like a div, except that its >> content can be generated. If it's a div it has to be able to have >> divWrapper elements inside it. It's a convenience for the encoder >> if the divWrapper elements can be explicitly attached to the divGen >> rather than generated along with the content. I don't think it's >> anything to do with <index> particularly. >> > > Hmmm ... I suppose I can see how it might be more convenient to have > some of the stuff surrounding the generated content in the source > XML. > > <divGen type="stats"> > <head>Statistics</head> > </divGen> > > Although it's a little harder to see the case for <argument>, > <epigraph>, or <salute>, let's presume there is a case. But if so, > why not <closed>, <signed>, or <trailer>? > you mean, why does divGen contain divWrapper but not divWrapper.bottom? fair question, and the answer is probably just an oversight. when you've sorted the classes out.... > Why not just > ditch <divGen> entirely, and advise people to use > <div type="generatedIndex"/> > or whatever? Or perhaps we can add <div> to att.typed (taking type= > out of att.divLike), so that there's a subtype=: > <div type="generated" subtype="index"/> > Plausible. But I still think a <divGen> really is quite a different sort of beast from a <div> all the same. > The semantics of the suggested value "generated" could be applied to > other elements as well. <ab> jumps to mind, but I chuckle when I > think what it means to see <lg type="generated" subtype="sonnet"> :-) > > That way madness lies. From Syd_Bauman at Brown.edu Thu Apr 19 18:38:02 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 19 Apr 2007 18:38:02 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <4627E3F2.3010307@computing-services.oxford.ac.uk> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <4627E3F2.3010307@computing-services.oxford.ac.uk> Message-ID: <17959.61258.201695.143086@emt.wwp.brown.edu> > Did I really. But that doesn't actually answer my question, does > it? No, I don't think there is a specific SFFR or Trac ticket for postscript. There probably should be. Sebastian probably even asked me to make one. I will shortly. > I assume that what you're objecting to is <div><p/><head/></div> > which i agree looks decidedly broken. Exactly. > If you have a proposed revision of the divWrapper bit of the class > system which provides a solution to this then so much the better: I do and I posted it. > let's see it properly worked out and tested. I was just making sure there were no objections before I implemented it. However, now that I've thought about it, I would like opinions on which is better, three separate classes: model.divTop = head opener salute epigraph model.divBottom = closed signed trailer ps model.divWrapper = argument byline dateline docAuthor docDate In which case use things like "(model.divWrapper|model.divTop)*"; OR making model.divWrapper a member of model.divTop and model.divBottom: model.divTop = model.divWrapper head opener salute epigraph model.divBottom = model.divWrapper closed signed trailer ps model.divWrapper = argument byline dateline docAuthor docDate In which case use things like "model.divTop*". > let's stick with top and bottom for the moment -- we might want > start and end for horseification purposes one day. Fine w/ me. > I dont understand this: once a class is defined it can be used > anywhere. Or are you proposing macros here? No, I'm proposing classes. But if model.divWrapper is a member of model.divTop (2nd, above), then there is no way in a content model to access only <head>, <opener>, etc., without also getting <argument>, <byline>, etc. I'm just trying to figure out if this is a problem or not. (One solution, of course is to invent two new classes: model.divWrapper = argument byline dateline docAuthor docDate model.openerLike = head opener salute epigraph model.closerLike = closer signed trailer ps model.divTop = model.divWrapper model.openerLike model.divBottom = model.divWrapper model.closerLike but that may be overkill.) > you mean, why does divGen contain divWrapper but not > divWrapper.bottom? fair question, and the answer is probably just > an oversight. when you've sorted the classes out.... Check. > Plausible. But I still think a <divGen> really is quite a different > sort of beast from a <div> all the same. Indeed it is semantically, but syntactically the line is getting quite fuzzy nowadays. From lou.burnard at computing-services.oxford.ac.uk Thu Apr 19 19:01:31 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2007 00:01:31 +0100 Subject: [tei-council] New draft on Modification and Conformance Message-ID: <4627F4CB.4030500@computing-services.oxford.ac.uk> Council members will recall that there was quite a flurry of debate on the topic of conformance following James's work on producing a "straw person" set of recommendations on the topic. In consultation with James, Sebastian, Veronika, and just about anyone else within earshot over the last couple of weeks, I have now finalized a new draft, which I would very much like Council to read over before Berlin. The draft is quite short, but the topic is important. The draft is at http://www.tei-c.org/Drafts/USE.html -- it consists of the first two subsections of a new chapter of the Guidelines, one on "Modification", and one on "Conformance". As some of you will know, the Board is anxious that the Council should be in a position to define what is meant by "TEI Conformance" sooner rather than later. I apologize therefore for having taken longer than intended to get this set of proposals into a shape where they can be discussed sensibly. Although the exact text of these chapters is obviously not going to be settled any time soon, and although P5 1.0 could go ahead without an exact definition of conformance, I would really like us to go away from Berlin with a clear consensus as to whether this draft is at least in the right general area, addressing the right topics, and reaching plausible conclusions we can all live with, and (indeed) enthusiastically support! Lou From cwittern at gmail.com Fri Apr 20 02:38:27 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 20 Apr 2007 08:38:27 +0200 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17959.48739.941886.134351@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> Message-ID: <46285FE3.4050302@gmail.com> Syd Bauman wrote: > > model.divTop = model.divWrapper head opener salute epigraph > model.divBottom = model.divWrapper closed signed trailer ps > model.divWrapper = argument byline dateline docAuthor docDate > > This looks good to me so far. But here you lost me: > Appendix > -------- > There might well be other content that I'd prefer not to bother > auto-generating, too. E.g. > > <divGen type="stats"> > <head>Statistics</head> > <p>The following table summarizes ...</p> > </divGen> > > If we're going to have some mechanism for "put the generated content > here", why not call it <divGen>? E.g.: > > <div type="stats"> > <head>Statistics</head> > <p>The following table summarizes ...</p> > <divGen type="genStats"/> > <p>Any discrepancies in the table above ...</p> > </div> > > > The answer is, of course, because the statics example above is > neither valid nor in harmony with the semantics of divisions. > Why not? You will only have to properly wrap the part after <divGen>: <div type="stats"> <head>Statistics</head> <p>The following table summarizes ...</p> <divGen type="genStats"/> <div> <p>Any discrepancies in the table above ...</p> </div> </div> and the whole bunch should be fine. But I do not really see how this relates to your argument about abolishing divGen, since this seems to be exactly the semantics as we have it now? Or is it that divGen can't be nested into other divs? Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Fri Apr 20 06:24:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 06:24:04 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46285FE3.4050302@gmail.com> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> Message-ID: <17960.38084.861225.128471@emt.wwp.brown.edu> > This looks good to me so far. Check, thanks. I appreciate some input. > But here you lost me: Probably should defer serious discussions about this until someone chimes in (I should say if & when someone chimes in) and says it might be a good idea to either: * revert <divGen> to being an empty element, or * get rid of <divGen> > Why not? You will only have to properly wrap the part after > <divGen>: True. But if the thing-to-be-generated is only a <table> ... > But I do not really see how this relates to your argument about > abolishing divGen, since this seems to be exactly the semantics as > we have it now? It wasn't part of the argument for abolishing <divGen>, it was just part of the train of thought that got me there. It was part of my asking myself the question "is it helpful to permit content in <divGen>". From James.Cummings at computing-services.oxford.ac.uk Fri Apr 20 06:37:46 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 20 Apr 2007 11:37:46 +0100 Subject: [tei-council] Draft Agenda for Berlin meeting (Conformance) In-Reply-To: <46258955.4010705@gmail.com> References: <46258955.4010705@gmail.com> Message-ID: <462897FA.7070605@computing-services.oxford.ac.uk> Wittern Christian wrote: > DRAFT Agenda for the TEI Council meeting in Berlin, April 26 to 27 <snip/> > 4) Conformance Draft (JC) To save time at the meeting itself I will make a report here. As tasked by the last (tele) meeting of the council I produced a strawPerson draft of the CF chapter (now CF section in the USE chapter). This was then debated in some detail on the council list. I revised the chapter in accordance with what I viewed as the consensus on many of the aspects. At that point I handed it over to an editor (Lou) for reshaping and rewriting as the entire reason for me writing this was to get a draft for council to argue about and it had. Lou rewrote the draft changing things in a number of significant ways, and I provided some additional tidying up/proofreading. In a meeting with a number of interested parties (inc. Lou, Sebastian, Veronika, and I), we attempted to flesh out the criteria for Conformance in more depth and create a matrix of example types of conformance. Lou revised the draft further as a result, and he has both checked this into Sourceforge and made a nice HTML version for Council to read.[1] I'm just clarifying in the Council's mind that it is this latest draft by Lou which we will be debating in Berlin, not any of the earlier drafts for which I can really take credit. I would strongly reiterate Lou's message[2] that the Council needs to agree a clear consensus on whether this draft is basically right or not by Berlin. As such, I would suggest that everyone read it as soon as possible. -James [1] http://www.tei-c.org/Drafts/USE.html [2] http://lists.village.virginia.edu/pipermail/tei-council/2007/002821.html -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Fri Apr 20 06:56:20 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Apr 2007 11:56:20 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.38084.861225.128471@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> <17960.38084.861225.128471@emt.wwp.brown.edu> Message-ID: <46289C54.7010400@kcl.ac.uk> Syd Bauman wrote: omeone chimes in) and says it > might be a good idea to either: > * revert <divGen> to being an empty element, or > * get rid of <divGen> In general, I am in favour to keep it as an empty element. Indeed, if it's purpose is to be used to mark some automatically generated text division (and this is the way we use it here), I don't see why it should contain anything else (besides model.divWrapper) that could go within more appropriate elements. However, I can see your point for having something automatically generated at a level that is different than the divisional one. Arianna > > >> Why not? You will only have to properly wrap the part after >> <divGen>: > > True. But if the thing-to-be-generated is only a <table> ... > > >> But I do not really see how this relates to your argument about >> abolishing divGen, since this seems to be exactly the semantics as >> we have it now? > > It wasn't part of the argument for abolishing <divGen>, it was just > part of the train of thought that got me there. It was part of my > asking myself the question "is it helpful to permit content in > <divGen>". > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Fri Apr 20 07:04:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2007 12:04:11 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46289C54.7010400@kcl.ac.uk> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> <17960.38084.861225.128471@emt.wwp.brown.edu> <46289C54.7010400@kcl.ac.uk> Message-ID: <46289E2B.8060503@oucs.ox.ac.uk> I have already expressed my view on this, but let me reiterate two things here: a. allowing divGen to contain (optionally) model.divWrapper content is a simple, useful, and in my view therefore should not change; b. expanding the semantic of divGen to mean "some other kind of virtual or generated element" is in my view neither simple nor necessary, and would be an undesirable change. We should resist the temptation to introduce change just because it looks like it might be fun. Arianna Ciula wrote: > > > Syd Bauman wrote: > omeone chimes in) and says it >> might be a good idea to either: >> * revert <divGen> to being an empty element, or >> * get rid of <divGen> > > In general, I am in favour to keep it as an empty element. Indeed, if > it's purpose is to be used to mark some automatically generated text > division (and this is the way we use it here), I don't see why it should > contain anything else (besides model.divWrapper) that could go within > more appropriate elements. > > However, I can see your point for having something automatically > generated at a level that is different than the divisional one. > > Arianna > >> >> >>> Why not? You will only have to properly wrap the part after >>> <divGen>: >> >> True. But if the thing-to-be-generated is only a <table> ... >> >> >>> But I do not really see how this relates to your argument about >>> abolishing divGen, since this seems to be exactly the semantics as >>> we have it now? >> >> It wasn't part of the argument for abolishing <divGen>, it was just >> part of the train of thought that got me there. It was part of my >> asking myself the question "is it helpful to permit content in >> <divGen>". >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From Syd_Bauman at Brown.edu Fri Apr 20 07:07:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 07:07:35 -0400 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <46289C54.7010400@kcl.ac.uk> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> <17960.38084.861225.128471@emt.wwp.brown.edu> <46289C54.7010400@kcl.ac.uk> Message-ID: <17960.40695.680006.273808@emt.wwp.brown.edu> > In general, I am in favour to keep it as an empty element. ... I > don't see why it should contain anything else (besides > model.divWrapper) ... These seem contradictory. By "empty" I mean not allowed to have any content at all. (No text, Not even model.divWrapper or model.global; attributes are OK, of course.) > However, I can see your point for having something automatically > generated at a level that is different than the divisional one. I think it is a good idea to consider carefully. I.e., something to be put on the docket for 1.1 or later. From arianna.ciula at kcl.ac.uk Fri Apr 20 07:51:06 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 20 Apr 2007 12:51:06 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.40695.680006.273808@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> <17960.38084.861225.128471@emt.wwp.brown.edu> <46289C54.7010400@kcl.ac.uk> <17960.40695.680006.273808@emt.wwp.brown.edu> Message-ID: <4628A92A.8080000@kcl.ac.uk> Syd Bauman wrote: >> In general, I am in favour to keep it as an empty element. ... I >> don't see why it should contain anything else (besides >> model.divWrapper) ... > > These seem contradictory. By "empty" I mean not allowed to have any > content at all. (No text, Not even model.divWrapper or model.global; > attributes are OK, of course.) Yes, sorry. I should have said: it's fine as an empty element for the way we use it, but the addition of model.divWrapper within it doesn't compromise this use and actually may be useful. > > >> However, I can see your point for having something automatically >> generated at a level that is different than the divisional one. > > I think it is a good idea to consider carefully. I.e., something to > be put on the docket for 1.1 or later. Yep. Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From James.Cummings at computing-services.oxford.ac.uk Fri Apr 20 08:58:13 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Fri, 20 Apr 2007 13:58:13 +0100 Subject: [tei-council] proposed re-org of div wrapping In-Reply-To: <17960.40695.680006.273808@emt.wwp.brown.edu> References: <17959.30773.719929.754597@emt.wwp.brown.edu> <46277D05.8090604@oucs.ox.ac.uk> <17959.48739.941886.134351@emt.wwp.brown.edu> <46285FE3.4050302@gmail.com> <17960.38084.861225.128471@emt.wwp.brown.edu> <46289C54.7010400@kcl.ac.uk> <17960.40695.680006.273808@emt.wwp.brown.edu> Message-ID: <4628B8E5.8000506@computing-services.oxford.ac.uk> Syd Bauman wrote: >> In general, I am in favour to keep it as an empty element. ... I >> don't see why it should contain anything else (besides >> model.divWrapper) ... > > These seem contradictory. By "empty" I mean not allowed to have any > content at all. (No text, Not even model.divWrapper or model.global; > attributes are OK, of course.) For the record I would probably always use divGen as empty, but could understand why someone might want a heading associated with it, so having divWrapper or divTop doesn't seem too problematic to me. It would seem better to have this only be head or a headLike class rather than divWrapper though. I can't think of a reasonable argument which would need the other members. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Fri Apr 20 14:06:14 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 14:06:14 -0400 Subject: [tei-council] Tegal -> Angleterre? Message-ID: <17961.278.544357.998640@emt.wwp.brown.edu> I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre Hotel. Any one else arriving at Tegal at a similar time? Anyone know what the best ground transport option is? From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 20 13:13:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2007 18:13:10 +0100 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <17961.278.544357.998640@emt.wwp.brown.edu> References: <17961.278.544357.998640@emt.wwp.brown.edu> Message-ID: <4628F4A6.7010403@oucs.ox.ac.uk> Syd Bauman wrote: > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre > Hotel. Any one else arriving at Tegal at a similar time? Anyone know > what the best ground transport option is? > "Tegel", actually From memory, there is a bus to the centre of town and then another bus. But that was a few years ago. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From dporter at uky.edu Fri Apr 20 14:26:50 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 20 Apr 2007 14:26:50 -0400 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <4628F4A6.7010403@oucs.ox.ac.uk> References: <17961.278.544357.998640@emt.wwp.brown.edu> <4628F4A6.7010403@oucs.ox.ac.uk> Message-ID: <96f3df640704201126tbfa5b4dxbd09afe9ab8e8327@mail.gmail.com> This site will search public transport for you: http://www.vbb-fahrinfo.de/hafas/query.exe/en?L=vs_intermodal& It looks like there are various bus routs for getting from "Flughafen Tegel (Berlin)" to "U Kochstr./Checkpoint Charlie" (the stop up the street from the hotel), depending on the arrival/departure times and how quickly you want to transfer between legs. I'm arriving at 11:25 am on 4/24 and was thinking about taking a taxi, just to make things easier on myself. It's about 10km from the airport to the Angleterre. Dot On 4/20/07, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote: > Syd Bauman wrote: > > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre > > Hotel. Any one else arriving at Tegal at a similar time? Anyone know > > what the best ground transport option is? > > > "Tegel", actually > > From memory, there is a bus to the centre of town > and then another bus. But that was a few years ago. > > -- > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From daniel.odonnell at uleth.ca Fri Apr 20 15:06:57 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Apr 2007 13:06:57 -0600 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <4628F4A6.7010403@oucs.ox.ac.uk> References: <17961.278.544357.998640@emt.wwp.brown.edu> <4628F4A6.7010403@oucs.ox.ac.uk> Message-ID: <1177096017.32506.3.camel@caedmon> It'll come as no surprise to those who know me that my travel agent and I--with a good dose of me--have managed to screw up my hotel reservation. Does anybody have a street address/building name for where we'll be? Being used to me, she'll find me accommodation that way. -dan On Fri, 2007-04-20 at 18:13 +0100, Sebastian Rahtz wrote: > Syd Bauman wrote: > > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre > > Hotel. Any one else arriving at Tegal at a similar time? Anyone know > > what the best ground transport option is? > > > "Tegel", actually > > From memory, there is a bus to the centre of town > and then another bus. But that was a few years ago. > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Fri Apr 20 15:21:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 20 Apr 2007 13:21:07 -0600 Subject: [tei-council] Tegal -> Angleterre? In-Reply-To: <1177096017.32506.3.camel@caedmon> References: <17961.278.544357.998640@emt.wwp.brown.edu> <4628F4A6.7010403@oucs.ox.ac.uk> <1177096017.32506.3.camel@caedmon> Message-ID: <1177096867.32506.11.camel@caedmon> Dot has rescued me. On Fri, 2007-04-20 at 13:06 -0600, Daniel O'Donnell wrote: > It'll come as no surprise to those who know me that my travel agent and > I--with a good dose of me--have managed to screw up my hotel > reservation. Does anybody have a street address/building name for where > we'll be? Being used to me, she'll find me accommodation that way. > > -dan > > On Fri, 2007-04-20 at 18:13 +0100, Sebastian Rahtz wrote: > > Syd Bauman wrote: > > > I'll be arriving at Tegal 04-24 10:00, and staying at the Angleterre > > > Hotel. Any one else arriving at Tegal at a similar time? Anyone know > > > what the best ground transport option is? > > > > > "Tegel", actually > > > > From memory, there is a bus to the centre of town > > and then another bus. But that was a few years ago. > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Fri Apr 20 15:45:46 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 20 Apr 2007 15:45:46 -0400 Subject: [tei-council] updated Guidelines Message-ID: <17961.6250.83020.506471@emt.wwp.brown.edu> BTW, just so everyone knows, I've been repeatedly updating my website with the current version of the Guidelines as we work away on it feverishly. (Except for when we had those power failures...)-: I expect to continue to do so until roughly Mon 04-23 15:00 UTC. http://bauman.zapto.org/~syd/temp/Guidelines-web/en/html/ http://bauman.zapto.org/~syd/temp/Guidelines-web/fr/html/ There is also http://bauman.zapto.org/~syd/temp/Guidelines/, but that is the entirety of P5 in one big HTML file, and thus takes a long time to load, even from the basement to my desk! Currently up to version 2340. From dporter at uky.edu Fri Apr 20 16:25:42 2007 From: dporter at uky.edu (Dot Porter) Date: Fri, 20 Apr 2007 16:25:42 -0400 Subject: [tei-council] TEI Week in Berlin In-Reply-To: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> References: <018069D2-33AA-495C-B392-689D9D67726C@loria.fr> Message-ID: <96f3df640704201325k48236507r7e7f4983d4569ada@mail.gmail.com> Laurent, I'm happy to comment on session 2, or to chair any other session. Dot On 4/17/07, Laurent Romary <laurent.romary at loria.fr> wrote: > Dear all, > Here's some update information about the TEI related events in Berlin > next week. You will see below the outline of 3 events (you're not > involved in the first one, but it's just to keep you informed), and I > would like to ask at this stage for some volunteer to chair and ask > as commentators for the workshop some of you have agreed to > participate to (see program). > Viele Gr??e, > Laurent > > Summary of the TEI week in Berlin: > > "eSciDoc-Textgrid TEI expert workshop" [you are not concerned by this > - it's a joint tutorial between the two projects > date: 24.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 13-17:30h > > "Putting the TEI to the test" [see program below - I need two > volunteers per session: one to chair and one to comment on the fly > after the talks] > date: 25.04.07 > place: > Tagungsst?tte Harnack-Haus > Ihnestra?e 16-20 > 14195 Berlin > http://www.harnackhaus-berlin.mpg.de > timeframe: 10:30 - 17:20h > > "TEI Council Meeting" [well you know about it, don't you?] > date: 26.04.-27.04.07 > place: > Berlin-Brandenburgische Akademie der Wissenschaften > Jaegerstr. 22/23 > 10117 Berlin > timeframe: 9-18h > > ---------------------------------------------------- > Program TEI workshop Putting the TEI to the test, 25.04.07 > > 10:30 ? 11:00 > Introductory Talk > 10:30 ? 10:45 Christian Wittern: > P5: current state and prospects > > 10:45 ? 11:00 Lou Burnard: > P5: technical overview > -------- > 11:00 ? 13:10 > 1. Session: Text-based projects > Chair: N.N. > > 11:00 ? 11:15 Fotis Jannidis: > Searching TEI texts in TextGrid using basic encodings > > 11:15 ? 11:30 Torsten Scha?an: > Aspects of the integration of TEI in the workflows of the > Wolfenbuettel digital library (WDB) > > 11:30 ? 12:00 > joint discussion > > 12:00 ? 12:15 Christian Mahnke: > Fulltext processing at the GDZ > > 12:15 ? 12:25 Bernhard Assmann: > The application of TEI in the digitalization project of the work of > Frederick the Great > (status report, presentation in German) > > 12:25 ? 12:35 Thomas Burch: > The Heinrich-Heine-Portal: TEI-based encoding of the letter corpus > (status report) > > 12:35 ? 13:10 > joint discussion > ----------- > 13:10 - 14:00 > lunch break > --------- > 14:00 ? 15:00 > 2. Session: Charter > Chair: N.N. > > 14:00 ? 14:30 Georg Vogeler: > How to standardize XML-encoding of medieval and early modern charters > and > instruments > > 14:30 ? 15:00 > discussion > -------- > 15:00 ? 16:00 > 3. Session: Dictionaries > Chair: N.N. > > 15:00 ? 15:15 Alexander Geyken: > Representation of the German "Woerterbuch der Gegenwartssprache" in TEI: > encoding strategies and limitations > > 15:15 ? 15:30 Werner Wegstein: > The Wuerzburg Jean-Paul-Projects: Multimedia Editions & Text Analyses > > 15:30 ? 16:00 > joint discussion > --------- > 16:00 ? 16:20 > coffee break > ------- > 16:20 ? 17:20 > 4. Session: Linguistic Annotations > Chair: N.N. > > 16:20 ? 16:35 Susanne Alt: > TEI encoding of parallel texts: issues and proposals > > 16:35 ? 16:50 Andreas Witt: > The Role of TEI-Annotations for the Sustainable Representation of > Linguistic > Resources > > 16:50 ? 17:20 > joint discussion > -------- > 17:20 > end of workshop > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From Syd_Bauman at Brown.edu Sat Apr 21 13:34:42 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 21 Apr 2007 13:34:42 -0400 Subject: [tei-council] updated Guidelines In-Reply-To: <17961.6250.83020.506471@emt.wwp.brown.edu> References: <17961.6250.83020.506471@emt.wwp.brown.edu> Message-ID: <17962.19250.64119.309292@emt.wwp.brown.edu> David just gently reminded me that it is not always convenient to access the Guidelines on the web. If you want the whole HTML kit 'n kaboodle on your laptop, grab it all once: http://bauman.zapto.org/~syd/temp/GLs.tgz That tarball contains two directories; you'll find the useful bits are in: Guidelines/ Guidelines-web/en/html/ Guidelines-web/fr/html/ Again, I'll try to be updating that very freuqently until Monday (next in < 1/2 hr I suspect) ... after that depends on internet connectivity in Berlin :-) From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 15:51:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 20:51:45 +0100 Subject: [tei-council] up to date Guidelines Message-ID: <462A6B51.4070907@oucs.ox.ac.uk> I have set up http://tei.oucs.ox.ac.uk/Guidelines/index.xml (and points south) to dynamically render the Guidelines to HTML, using Cocoon. It is reading a checkout from Subversion, updated every 5 minutes. Some flaws (ie all the notes appearing on the index page) which I will endeavour to correct, but I believe it is perfectly useable. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 15:57:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 20:57:56 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A6B51.4070907@oucs.ox.ac.uk> References: <462A6B51.4070907@oucs.ox.ac.uk> Message-ID: <462A6CC4.5070906@oucs.ox.ac.uk> If its not obvious, the HTML is cached. So each time the source changes, it'll take a few tens of seconds for the first person to visit a given chapter. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Sat Apr 21 18:00:51 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 21 Apr 2007 23:00:51 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A6B51.4070907@oucs.ox.ac.uk> References: <462A6B51.4070907@oucs.ox.ac.uk> Message-ID: <462A8993.70209@oucs.ox.ac.uk> Sebastian Rahtz wrote: > I have set up http://tei.oucs.ox.ac.uk/Guidelines/index.xml (and points > south) to dynamically render > the Guidelines to HTML, using Cocoon. It is reading a checkout from > Subversion, updated every 5 minutes. Great idea, thanks Sebastian. > Some flaws (ie all the notes appearing on the index page) which I > will endeavour to correct, but I believe it is perfectly useable. How is this different from the situation at the following? http://www.tei-c.org/release/doc/tei-p5-doc/html/ (All the notes appear on the index page there). It was one of the things on a short list I've been compiling of "stuff in the presentation of the Guidelines that maybe should change", as a prelude to the task Dot and I have volunteered for (but which has been taking a back seat to chapters etc. -James From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 18:06:35 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2007 23:06:35 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A8993.70209@oucs.ox.ac.uk> References: <462A6B51.4070907@oucs.ox.ac.uk> <462A8993.70209@oucs.ox.ac.uk> Message-ID: <462A8AEB.2020903@oucs.ox.ac.uk> James Cummings wrote: > > How is this different from the situation at the following? > > http://www.tei-c.org/release/doc/tei-p5-doc/html/ > > (All the notes appear on the index page there). yes, its wrong there too. > It was one of the things on a short list I've been compiling of "stuff > in the presentation of the Guidelines that maybe should change", as a > prelude to the task Dot and I have volunteered for (but which has been > taking a back seat to chapters etc. > for some reason, I have always found handling <note> immensely hard to get right. Its a generic error in my XSL, not special for the Guidelines, I think. I have pro tem turned off caching on this thing, by the way, as it as noting taking account of changes in the chapter files as I had expected. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Sat Apr 21 20:47:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sat, 21 Apr 2007 20:47:29 -0400 Subject: [tei-council] up to date Guidelines In-Reply-To: <462A8AEB.2020903@oucs.ox.ac.uk> References: <462A6B51.4070907@oucs.ox.ac.uk> <462A8993.70209@oucs.ox.ac.uk> <462A8AEB.2020903@oucs.ox.ac.uk> Message-ID: <17962.45217.544772.641719@emt.wwp.brown.edu> Cool, Sebastian. Does this mean I can quit updating my server-in-the-basement? (Its name is "garak", BTW -- 2 points to anyone who recognizes the reference *without* looking using Google, Wikipedia, etc.) I'm inclined to say not, because the tarball is probably a very useful thing. Anyway ... > dynamically render the Guidelines to HTML, using Cocoon. It is > reading a checkout from Subversion, updated every 5 minutes. > I have pro tem turned off caching on this thing, Dynamically rendering seems like it might be a serious waste of computational resources and perhaps even a mild delay for the users. Why not transform them statically? In any case, thanks. P.S. Version on garak is current as of now, version 2354. From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 22 06:21:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 22 Apr 2007 11:21:57 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <17962.45217.544772.641719@emt.wwp.brown.edu> References: <462A6B51.4070907@oucs.ox.ac.uk> <462A8993.70209@oucs.ox.ac.uk> <462A8AEB.2020903@oucs.ox.ac.uk> <17962.45217.544772.641719@emt.wwp.brown.edu> Message-ID: <462B3745.4080202@oucs.ox.ac.uk> Syd Bauman wrote: > Cool, Sebastian. Does this mean I can quit updating my > server-in-the-basement? if you trust my server any better.... > Dynamically rendering seems like it might be a serious waste of > computational resources and perhaps even a mild delay for the users. > indeed. if Cocoon was not so dumb about cacheing, it would be fine. But it does not realize that changing one *Spec.xml file means the document as a whole now needs regenerating > Why not transform them statically? > because then I would have to set up a Subversion trigger to make a rebuild when you submitted something. and because it was interesting to see whether I _could_ make this work! -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Sun Apr 22 08:37:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 22 Apr 2007 08:37:11 -0400 Subject: [tei-council] up to date Guidelines In-Reply-To: <462B3745.4080202@oucs.ox.ac.uk> References: <462A6B51.4070907@oucs.ox.ac.uk> <462A8993.70209@oucs.ox.ac.uk> <462A8AEB.2020903@oucs.ox.ac.uk> <17962.45217.544772.641719@emt.wwp.brown.edu> <462B3745.4080202@oucs.ox.ac.uk> Message-ID: <17963.22263.529033.957508@emt.wwp.brown.edu> > if you trust my server any better.... A little better. But I still think the tarball is useful to people, so version 2360 (downloaded merely a few minutes before Sourceforge went down) is now available on my site. E.g., http://bauman.zapto.org/~syd/temp/GLs.tgz > > Why not transform them statically? > > > because then I would have to set up a Subversion trigger to make a > rebuild when you submitted something. Oh. I was thinking along the lines of regenerating the HTML immediately after one of the every-5-minute Subversion checks (preferably iff something actually changed). > and because it was interesting to see whether I _could_ make this > work! Indeed! Darn good reason. From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 22 08:49:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 22 Apr 2007 13:49:59 +0100 Subject: [tei-council] up to date Guidelines In-Reply-To: <17963.22263.529033.957508@emt.wwp.brown.edu> References: <462A6B51.4070907@oucs.ox.ac.uk> <462A8993.70209@oucs.ox.ac.uk> <462A8AEB.2020903@oucs.ox.ac.uk> <17962.45217.544772.641719@emt.wwp.brown.edu> <462B3745.4080202@oucs.ox.ac.uk> <17963.22263.529033.957508@emt.wwp.brown.edu> Message-ID: <462B59F7.6040102@oucs.ox.ac.uk> Syd Bauman wrote: > Oh. I was thinking along the lines of regenerating the HTML > immediately after one of the every-5-minute Subversion checks > (preferably iff something actually changed). > yes, could do, if this proves unworkable. though boring to check whether things have changed. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 10:23:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 15:23:05 +0100 Subject: [tei-council] New draft on facsimile Message-ID: <462B6FC9.80000@computing-services.oxford.ac.uk> I've taken the liberty of combining the two documents about use of TEI to mark up "digital facsimile" editions which Dot and Conal were working on into a single ODD file, making a few minor syntactic corrections, and producing an HTML version of it as well as a sample schema. You can see the HTML draft at http://www.tei-c.org/Drafts/testfacs.doc.html and the ODD source is in the P5/Test library in subversion. I did this because I think Dot and Conal have done some excellent work here and it would be a shame if we can't go the extra 500 metres to get it into 1.0. The main thing we're missing here is a samples document, which Conal was (I believe) working on and some (much) more explanatory prose. However I think we have enough here to start discussing the topic next week, if only to ask stupid questions! From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 11:23:04 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 16:23:04 +0100 Subject: [tei-council] stoa comments on place proposals Message-ID: <462B7DD8.40002@computing-services.oxford.ac.uk> Tom Elliott, of the Stoa project, has done us the honour of a careful read and makes several interesting comments on the current draft for encoding of placenames on the following web page: http://icon.stoa.org/trac/pleiades/wiki/TEIPlaceDraft (which is now linked to from the relevant trac item in our tracker) We should look at these comments together with those from Arianna last week when deciding what the next step should be for these proposals. From lou.burnard at computing-services.oxford.ac.uk Sun Apr 22 11:59:34 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 22 Apr 2007 16:59:34 +0100 Subject: [tei-council] Comments on Place proposals from TEI Message-ID: <462B8666.9070209@computing-services.oxford.ac.uk> Dear Tom Many thanks for your timely comments. I've alerted the Council to your wiki page and also I think we have a link to it from the relevant trac item for our own agenda. Here are my personal reactions to your comments, not to pre-empt the further discussion I expect to take place next week : 1. If accepted, the testplace proposals will probably be integrated into the existing chapter on Names of Places and Persons which has also undergone quite a lot of revision as you note. You might like therefore to point to the current state of that chapter which is (as of this morning) at http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=ND rather than the unrevised last stable version -- this is dynamically generated from the svn repository in which changes are being made at a great rate of knots 2. Thank you for the nice remarks about what distinguishes the TEI from the rest. You're right that we need to be clear about why the TEI goes down this particular muddy well trodden track at all, and certainly to alert readers of the Guidelines to other possibilities where they exist. 3. Named time periods. The treatment of dates and times has just undergone major surgery in order to support various kinds of automatic processing and validation, mappings to both ISO and W3C date formats etc. When the patient is mobile again, I agree that we need to start thinking about "named" dates. It should not be too difficult. 4. Linking assertions with responsibility statements is a recurrent thread. We have discussed a generic <assert> element, to combine an assertion with an indication of responsibility and certainty, but backed away from it as being too complex, and not adding much beyond what the existing @resp and @cert attributes provide; also there is an existing method for marking certainty (http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml.ID=CE) which should be taken into consideration. 5. Adding GeoRSS is definitely an option. We only specified GML because that was the one we found on the web... no intention of being exclusive. 6. <relation> vs containment. It always makes me uneasy to have too many ways of doing exactly the same thing, but it's hard to see what containment could mean for <place>s within <place>s other than what is proposed, nor to argue against allowing for relationships other than containment, so we wound up with both. Contrast this with the discussion of what <nym> within <nym> means -- something quite different. 7. <locale> was a pre-existing TEI element which we pressganged into service here. It does seem a bit problematic as to name, and its overlap with other ways of characterizing a place. 8. Ethnica sounds interesting. But I think it's a kind of placeName still, not a new kind of name, even though its location may be hard to pin down. After all whether we think of Bristol as "the place with a bridge" or "the place where the Bristolians hang out", it's still a place. 9. Absolutely no intention or need for TEI to re-invent detailed geographic metadata already done better by GML and similar. We could do with some real examples though, as you note. 10. SpatialML is an interesting one which I have glanced at but not studied in detail: it comes from the very different world of "named entity recognition" . Certainly we ought to review it and the others you mention, before rushing ahead, if only as a fruitful source of examples. best wishes Lou From Conal.Tuohy at vuw.ac.nz Sun Apr 22 22:28:18 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Mon, 23 Apr 2007 14:28:18 +1200 Subject: [tei-council] see you in Berlin Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> I'm packed, and I'm off to catch my plane. See you all in Berlin! If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. Tschuss! Con From Syd_Bauman at Brown.edu Mon Apr 23 09:29:27 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 23 Apr 2007 09:29:27 -0400 Subject: [tei-council] updated; mode= of <alt> Message-ID: <17964.46263.51819.216278@emt.wwp.brown.edu> Version on my website is up to r2379. I'm wondering if the mode= attribute of <alt> and <altGrp>, which take only the two values "inclusive" and "exclusive" should instead be the exclusive= attribute which has values "true" and "false". This change would make better use of datatypes, and would mean one fewer attribute with the same name and different semantics. From dporter at uky.edu Mon Apr 23 09:30:24 2007 From: dporter at uky.edu (Dot Porter) Date: Mon, 23 Apr 2007 09:30:24 -0400 Subject: [tei-council] updated; mode= of <alt> In-Reply-To: <17964.46263.51819.216278@emt.wwp.brown.edu> References: <17964.46263.51819.216278@emt.wwp.brown.edu> Message-ID: <96f3df640704230630t723afabdu5435cda5201ffdf9@mail.gmail.com> This change sounds good to me. Dot On 4/23/07, Syd Bauman <Syd_Bauman at brown.edu> wrote: > Version on my website is up to r2379. > > I'm wondering if the mode= attribute of <alt> and <altGrp>, which > take only the two values "inclusive" and "exclusive" should instead > be the exclusive= attribute which has values "true" and "false". > > This change would make better use of datatypes, and would mean one > fewer attribute with the same name and different semantics. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From laurent.romary at loria.fr Mon Apr 23 09:32:13 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 23 Apr 2007 15:32:13 +0200 Subject: [tei-council] updated; mode= of <alt> In-Reply-To: <17964.46263.51819.216278@emt.wwp.brown.edu> References: <17964.46263.51819.216278@emt.wwp.brown.edu> Message-ID: <0CE0E07F-98FF-4D55-BD74-EC58EB107A49@loria.fr> I would keep things as they are. Just looking at the description I can think of fancy combination modes which one would want to have there. Despite my intrinsic bend on simpifying things... Laurent Le 23 avr. 07 ? 15:29, Syd Bauman a ?crit : > Version on my website is up to r2379. > > I'm wondering if the mode= attribute of <alt> and <altGrp>, which > take only the two values "inclusive" and "exclusive" should instead > be the exclusive= attribute which has values "true" and "false". > > This change would make better use of datatypes, and would mean one > fewer attribute with the same name and different semantics. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From Syd_Bauman at Brown.edu Mon Apr 23 09:45:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 23 Apr 2007 09:45:04 -0400 Subject: [tei-council] xtext vs xText Message-ID: <17964.47200.674090.115006@emt.wwp.brown.edu> An example in TD referred to rng:text, where it is probably better to refer to a TEI structure. But as I changed it, I wondered ... shouldn't "macro.xtext" really be "macro.xText"? From Conal.Tuohy at vuw.ac.nz Tue Apr 24 08:57:01 2007 From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 25 Apr 2007 00:57:01 +1200 Subject: [tei-council] see you in Berlin References: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> I have arrived in Berlin and checked into my hotel, which is a few hundred m from the Angleterre where I believe several of you are staying. http://tinyurl.com/2fel5j Anyone else about, yet? Does anyone have any plans for dinner? Unfortunately my phone is not roaming in Germany, so I'm only contactable via email (I'm glad I brought a power cable for my computer this time!) or I guess by phone at the hotel. My room number is 306. Cheers! Con -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Conal Tuohy Sent: Mon 23/04/07 14:28 To: TEI Council Subject: [tei-council] see you in Berlin I'm packed, and I'm off to catch my plane. See you all in Berlin! If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. Tschuss! Con _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From daniel.odonnell at uleth.ca Tue Apr 24 09:07:00 2007 From: daniel.odonnell at uleth.ca (Daniel Paul O'Donnell) Date: Tue, 24 Apr 2007 15:07:00 +0200 Subject: [tei-council] see you in Berlin Message-ID: <20070424130706.TQJJ29757.to5email1.gprs.rogers.com@COM> I'm on the bus still. Near Gedenkenst?tte Pl?tzenzee and stuck in traffic :-( From arianna.ciula at kcl.ac.uk Tue Apr 24 09:14:46 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Tue, 24 Apr 2007 14:14:46 +0100 Subject: [tei-council] see you in Berlin In-Reply-To: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> References: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <462E02C6.4020509@kcl.ac.uk> I will arrive tonight, but I guess too late to join you for dinner...I'll see you tomorrow. Arianna Conal Tuohy wrote: > I have arrived in Berlin and checked into my hotel, which is a few hundred m from the Angleterre where I believe several of you are staying. > http://tinyurl.com/2fel5j > > Anyone else about, yet? Does anyone have any plans for dinner? Unfortunately my phone is not roaming in Germany, so I'm only contactable via email (I'm glad I brought a power cable for my computer this time!) or I guess by phone at the hotel. My room number is 306. > > Cheers! > > Con > > > -----Original Message----- > From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Conal Tuohy > Sent: Mon 23/04/07 14:28 > To: TEI Council > Subject: [tei-council] see you in Berlin > > > I'm packed, and I'm off to catch my plane. See you all in Berlin! > > If anyone needs to know, I am arriving at Tegel on flight LH178, Tuesday 24 April, at 12:45. My hotel is the NH Berlin-Mitte, Leipziger Strasse 106-111. It's very near the BBAW, apparently. > > Tschuss! > > Con > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Tue Apr 24 09:29:24 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 24 Apr 2007 14:29:24 +0100 Subject: [tei-council] cu in berlin Message-ID: <462E0634.60806@oucs.ox.ac.uk> Sebastian and I will be arriving at 0800 tomorrow morning, and will go straight to the Harnackhaus. We look forward to your reports on suitable dining places near the hotel! a bientot... Lou From Syd_Bauman at Brown.edu Tue Apr 24 11:44:35 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 24 Apr 2007 11:44:35 -0400 Subject: [tei-council] see you in Berlin In-Reply-To: <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> References: <F7642587567EC648BB0AE46EF0BCA5AF014B1D89@STAWINCOMAILCL1.staff.vuw.ac.nz> <F7642587567EC648BB0AE46EF0BCA5AF014B1D8A@STAWINCOMAILCL1.staff.vuw.ac.nz> Message-ID: <17966.9699.475023.430728@emt.wwp.brown.edu> > Anyone else about, yet? Does anyone have any plans for dinner? David, John, Dot, and perhaps I will meet in the lobby of the Angleterre at 18:30 (i.e., in 45 mins). John & David have picked out an Autrian resteraount that is a bit of a hike away. From cwittern at gmail.com Wed Apr 25 10:51:02 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 25 Apr 2007 16:51:02 +0200 Subject: [tei-council] updated agenda for berlin meeting Message-ID: <462F6AD6.3050901@gmail.com> Dear Council members, here is the updated agenda. The most important changes have been the addition of time & place of the meeting. Agenda for the TEI Council meeting in Berlin, April 26 to 27 Place: Berlin-Brandenburgische Akademie der Wissenschaften, Gendarmenmarkt, Berlin (http://veranstaltungszentrum.bbaw.de/anfahrt/) Time: 9:00 to 17:00(?) Expected to participate: Syd Bauman, David Birnbaum, Tone Merete Bruvik, Lou Burnard, Arianna Ciula, James Cummings, Matthew Driscoll, Dan O'Donnel, Dot Porter, Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern PART I 1) Adotion of Agenda 2) Minutes, work items, progress since last meeting: http://www.tei-c.org.uk/Council/tcm29.xml?style=printable Please look at the action items and report progress here before the meeting! 3) Reports on Chapter reviews Council members are expected to report on the outcome of the chapter review they have undertaken in the last weeks. It would be helpful, if you could provide a short summary of your findings, including the outstanding issues that have to be adressed. We will collect these issues during this phase and resolve them later. 4) Conformance Draft (JC) 5) Formatting of Guidelines (JC & DP) PART II 6) Resolution of outstanding issues: - proposal to add a metadata element to record application information (SR) - nyms (LB) - proposal for places & placenames (MD) - fascsimile markup (TC) - (other essential items collected in Part I) 7) Adoption of Resolutions -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Wed Apr 25 11:27:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 25 Apr 2007 11:27:55 -0400 Subject: [tei-council] Re: [Fwd: the easter egg has hatched] In-Reply-To: <2431.141.14.243.47.1177514233.squirrel@webmail.pitt.edu> References: <2431.141.14.243.47.1177514233.squirrel@webmail.pitt.edu> Message-ID: <17967.29563.608685.211756@emt.wwp.brown.edu> Dear Syd, Thank you for forwarding this to the Council list. Cheers, David ---------------------------- Original Message ---------------------------- Subject: the easter egg has hatched From: djbpitt at pitt.edu Date: Wed, April 25, 2007 11:11 am To: "TEI Council" <tei-council at lists.village.virginia.edu> -------------------------------------------------------------------------- Dear Council, How does one find a trac ticket anyway? In any case, comments on my assigned chapters and a few others are below. Best, David ________ passim: Can we add links for references to classes, e.g.: measure.attributes = att.measurement.attributes, attribute type { data.enumerated }? Here data.enumerated is a link but att.measurement.attributes isn't, although it might be useful if it were. Note also that references to model groups are links, but references to attribute groups are not; why should these be rendered differently? Need examples for all ref-*.html pages (some have them, e.g., <equiv>, and some don't, e.g., <altIdent>) Am I the last person on earth who cares about the distinguishing restrictive and non-restrictive clauses? guidelines.css: add "white-space: pre;" for all .pre elements fix line spacing to avoid extra space above lines with footnote reference numbers (ask me how if necessary) bulleted list in fn 52 in CO is rendered with bullets and text overlapping (indentation set incorrectly?) AB (Preamble/preface): Pervasive references to SGML, DTDs, WSDs, etc. Also references to transition from P3; should these be to P4? SG (Gentle introduction): Needs a thorough rewrite; a discussion of content models in RelaxNG compact syntax is needed because this syntax is used in the documentation in the Guidelines, but DTD syntax doesn't fit. typo: documwents in "has the value draft", "draft" isn't typographicaly distinct (unlike the attribute value "P1" in the same line); this problem recurs frequently in other sections, including Documentation; is this a markup problem or a problem with the stylesheet? says that XML predefines & and <, but there are three others (>, ', and ")? fix alignment in declaration of parameter entity a.global there are lots of references, especially toward the end (entities, marked sections), to "the TEI DTD"; since this suggests that TEI structure is modeled directly with DTDs, should it be updated to refer instead to ODDs? example of marked section for <eg> should be wrapped; otherwise pre rendering extends beyond right margin example including/ignoring stanzas/couplets is garbled how comfortably do namespaces coexist with DTDs? tei2.dtd? Did we change the filename, or just the name of the root element? CH (Character Sets): "modeling the value of @xml:lang parallels the modeling of the value of @xml:lang"?? do we want French "coeur" to match only the four-character string, and not the five-? This isn't a TEI problem, but the guidelines seem to assert that a user would not want to search for the five-character string I got spanked (rhymes with but differs from "thanked" :-( ) for proofreading last time there was a call for *only* content-related feedback, but "are encoded in ISO-8859-n as a singlebyte with the same value as the code-point" needs a space between "single" and "byte". If this non-content-related observation is unwelcome, just ignore it, and I apologize for wasting your time. :-( ST (Infrastructure): missing word in "may be combined more less freely" (see snarky note above about proofreading) identifies three ways to specify (ODD, RelaxNG, DTD), but shouldn't we specify only ODD (not only recommended, but we mention no other; the others are possible, but neither recommended nor supported)? should "for a text to combine different kinds of object" read "objects"? two missing spaces in fn 34 Remove the sentence that reads "The values of xml:id attributes must be legal names with respect to the SGML declaration in force." and adjust the following one. That is, XML isn't an implementation of SGML as far as the TEI is concerned, and as far as TEI users are concerned (although they don't need to know that), there is only one SGML declaration in the world, and that's the XML one. what's the meaning of the SGML reference in "Declare TEI.XML marked section to permit SGML support"? The description of the order for DTD components lists user-defined element declarations at the end, but don't they need to come early for DTD purposes, since early definitions take precedence over later ones? do we need separate data.TruthValue and data.xTruthValue classes? Isn't this like specifying language where it has to be European, i.e., a formal restriction where user error is unlikely? Should att.declaring be broader? Why can't a <p> (for example) be associated with a declaration in the header (especially because <u> can)? line break missing in example of n.X notation references to use "in SGML mode" at the end CO (core): where does apostrophe mark a plural in English? "Parentheses and other marks of suspension" should omit "other" Lose the last comma in "light, buttery, pastry" "Element foreign" has some "include" notes The example that purports to illustrate a <bo> element doesn't seem to do so; no reference to <bo> and no uri, although the description above promises one "All members of this class carry the following optional attributes:" is not followed by a list of attributes (grabbed the description instead of the attributes/values?) "reg" erroneously tagged as attribute instead of element in the source underlying "This use should be distinguished from the use of a nested @reg (regularization) element ..." Stray leading backslash in "\list = element list { list.content, list.attributes }" In the discussion of indexing, the <index> element is inserted after the string being indexed, and does not contain it. Is this post-posed milestone strategy the best approach? Note that the use of <anchor> to mark the endpoint of a large target range becomes peculiar because the start point (the location of the <index> element begins only *after* the beginning of the logical target. The indexing term always comes from the <term> child, which is often necessary, but excludes the potential economy of using real text from the body when <term> is not specified. Reference to SGML in 4.10.3 (also just above and in 4.13) In structured bibliographies, are multiple authors/editors entered together in a single <author>/<editor> element or separately? There are examples of both, but no explicit statement about best practice (or about the conditions under which one or the other might be preferred). "include" notes at the end TD (Documentation Elements): Garbling in "In the remainder of this chapter we refer to software which provides such as a processing environment as an ODD processor" comma after "i.e." in "i.e. a named" reference to "SGML dtds" (aside from the problem of the reference to "SGML," should "dtds" be capitalized?) The text says "<egXML> contains a single well-formed XML example demonstrating the use of some XML element or attribute," but the first example (and others?) has no root element, and therefore is not well formed. If it is intended that <egXML> is itself the root, then it doesn't *contain* well-formed XML. The immediately following example with escaped XML has non-bold <term> tags, but does not clearly illustrate how the markup differs (that is, they are character-for-character identical). erroneous angle brackets (instead of leading "@") in: either a @bar attribute or a <baz> attribute missing space in "value ofsequenceRepeatable" some values in this section are not typographically distinct, while some earlier are. Is there missing markup in the source? Also in other chapters. the class name in "the class model.hiLike" is bold, but other class names are not typographically distinct. Missing markup in the source? is the plural of "child element" "children elements" (as here), or "child elements" (sounds better?) if you specify "delete" mode and no declaration exists, how can you remove the existing declaration (which doesn't exist), as the chart states? "include" notes at end From James.Cummings at computing-services.oxford.ac.uk Wed Apr 25 18:10:14 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Thu, 26 Apr 2007 00:10:14 +0200 Subject: [tei-council] Re: [Fwd: the easter egg has hatched] In-Reply-To: <17967.29563.608685.211756@emt.wwp.brown.edu> References: <2431.141.14.243.47.1177514233.squirrel@webmail.pitt.edu> <17967.29563.608685.211756@emt.wwp.brown.edu> Message-ID: <462FD1C6.2040603@computing-services.oxford.ac.uk> > passim: Can we add links for references to classes, e.g.: > measure.attributes = > att.measurement.attributes, > attribute type { data.enumerated }? > Here data.enumerated is a link but att.measurement.attributes isn't, > although it might be useful if it were. Note also that references to model > groups are links, but references to attribute groups are not; why should > these be rendered differently? I think this belongs in formatting desiderata, so I have added it to the list that Dot and I are compiling. > guidelines.css: add "white-space: pre;" for all .pre elements > fix line spacing to avoid extra space above lines with footnote reference > numbers (ask me how if necessary) > bulleted list in fn 52 in CO is rendered with bullets and text overlapping > (indentation set incorrectly?) Both now added to list to check when looking at the CSS. > in "has the value draft", "draft" isn't typographicaly distinct (unlike > the attribute value "P1" in the same line); this problem recurs frequently > in other sections, including Documentation; is this a markup problem or a > problem with the stylesheet? What element is the word wrapped in in the source? > I got > spanked (rhymes with but differs from "thanked" :-( ) for > proofreading last time there was a call for *only* content-related > feedback, I thought I indeed thanked you... but simply wanted to point out that the grammar was lax because it was a strawman draft so I hadn't improved it even to my usual barely-literate standards. It has now almost entirely been rewritten. (Good thing I didn't sort out all the restrictive clauses, Lou deleted almost everything I wrote anyways.) > the class name in "the class model.hiLike" is bold, but other class names > are not typographically distinct. Missing markup in the source? Added to the list of formatting concerns to double-check. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From Syd_Bauman at Brown.edu Wed May 2 08:21:33 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 08:21:33 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting Message-ID: <17976.33357.397972.941785@emt.wwp.brown.edu> The first draft of the minutes from our meeting our now available at http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although some of you may prefer to download http://www.tei-c.org/Council/tcm30.xml?style=raw.) A lot was covered at this meeting, and though the notes are extensive, I missed a lot, too. At some point before the next conference call, each of us should read the entire document pretty carefully. But *right now* you should quickly scan it, looking for your initials and passages flagged with "[?", and send in corrections ASAP, before (even more) details fade from memory, and so that we get the record straight as soon as we can. From James.Cummings at computing-services.oxford.ac.uk Wed May 2 09:07:37 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 02 May 2007 14:07:37 +0100 Subject: [tei-council] Berlin Message-ID: <46388D19.3060102@computing-services.oxford.ac.uk> Just to say that I had a good time in Berlin and think that we got some useful work done. Also, while I was there I promised to send some URLs to various people on various topics (both TEI and non-TEI related) that we were discussing. I have now, of course, completely forgotten who had asked for what. So if that jogs your memory, please do email me and tell me what it was I was referring you to. :-) Sorry for the dull wits, -James --- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From laurent.romary at loria.fr Wed May 2 09:08:39 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 2 May 2007 15:08:39 +0200 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <90D03973-1561-4FB8-A484-7F2A085C8B67@loria.fr> Thanks for the notes. Two qiuck updates: - the name of the person is Eva Radermacher - Yes we decided on the change of names Lou: can you make the connexion with your technical student at Oxford? Best, Laurent Le 2 mai 07 ? 14:21, Syd Bauman a ?crit : > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From dporter at uky.edu Wed May 2 09:14:03 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 2 May 2007 09:14:03 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <96f3df640705020614u419abadamedeeca9bb8e2e8db@mail.gmail.com> 1.2 all: Attempt to encode a place ? Should be: DO, *AC*, JC report they've done this Though I'm always flattered to be confused with Arianna :-) Dot On 5/2/07, Syd Bauman <Syd_Bauman at brown.edu> wrote: > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From Syd_Bauman at Brown.edu Wed May 2 09:52:59 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 09:52:59 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <90D03973-1561-4FB8-A484-7F2A085C8B67@loria.fr> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <90D03973-1561-4FB8-A484-7F2A085C8B67@loria.fr> Message-ID: <17976.38843.206272.321563@emt.wwp.brown.edu> [DB sent some errors in directly to me -- fixed.] Thanks, Laurent! (Or should I say "LR" :-) > - the name of the person is Eva Radermacher Check, entered. > - Yes we decided on the change of names Check, fixed. From Syd_Bauman at Brown.edu Wed May 2 09:55:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 09:55:41 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <96f3df640705020614u419abadamedeeca9bb8e2e8db@mail.gmail.com> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <96f3df640705020614u419abadamedeeca9bb8e2e8db@mail.gmail.com> Message-ID: <17976.39005.634365.89542@emt.wwp.brown.edu> DP> Should be: DO, *AC*, JC report they've done this DP> Though I'm always flattered to be confused with Arianna :-) A forgivalbe error, then? Whew! Of course, if you hurry, you too could attempt to encode a placename with the new proposed encoding, and I wouldn't have to change the minutes! Oh well, too late. Fixed. Thanks, Dot! From tone.bruvik at aksis.uib.no Wed May 2 10:02:27 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Wed, 2 May 2007 16:02:27 +0200 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <B7A28D22-31CF-444D-94B7-F82265B10595@aksis.uib.no> Some comments from me: 1. My name is abrivitated in to two different ways, TMB and TB. I prefer the first one. 2. By the way, who or what is MM in "MM says it's a good opportunity to work further on proposals" Messieurs?? 3. "DB suggests changing the name of this chapter to ?Dictionaries?. [? was this decided? ?]" Yes, I think so. 4. And I believe that I and Syd volunteered in 11.3.29. NH- MultipleHierarchies.xml to rewrite the chapter. Tone Merete Den 2. mai. 2007 kl. 14.21 skrev Syd Bauman: > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From Syd_Bauman at Brown.edu Wed May 2 10:13:44 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 10:13:44 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <B7A28D22-31CF-444D-94B7-F82265B10595@aksis.uib.no> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <B7A28D22-31CF-444D-94B7-F82265B10595@aksis.uib.no> Message-ID: <17976.40088.68637.86930@emt.wwp.brown.edu> > 1. My name is abrivitated in to two different ways, TMB and TB. I > prefer the first one. Fixed. > 2. By the way, who or what is MM in "MM says it's a good opportunity > to work further on proposals" Messieurs?? Oooh, good point. MM is Murray McGillivray, chair of the Physical Bibliography working group. I'll put his whole name in. > 3. "DB suggests changing the name of this chapter to ?Dictionaries?. > [? was this decided? ?]" Yes, I think so. LR agrees; fixed. > 4. And I believe that I and Syd volunteered in 11.3.29. NH- > MultipleHierarchies.xml to rewrite the chapter. Right. Already says that, I think. Thanks, TMB! From arianna.ciula at kcl.ac.uk Wed May 2 12:23:59 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 02 May 2007 17:23:59 +0100 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <4638BB1F.9050303@kcl.ac.uk> Thank-you Syd. Here my notes: 1.3.20. ND-NamesDates.xml --> I believe there was another action on you to add explanation on the difference w3c/iso in the prose (it's already in the specs). MD and AC are hoping to put together a meeting soon (in London?) of MD, Oxfordians, Londoners, and Alex Czmiel to work further on the proposal once participants have put it to the test of encoding real data. --> Yes, In London Get information from [? Alex Czmiel ?] --> yes Alex Czmiel 0. LB work out what GP? really wants. --> Gautier Poupeau, I believe 1.3.8. DS-DefaultTextStructure.xml [? whose chapter was this? ?] --> mine Arianna Syd Bauman wrote: > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Wed May 2 12:36:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 12:36:38 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <4638BB1F.9050303@kcl.ac.uk> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <4638BB1F.9050303@kcl.ac.uk> Message-ID: <17976.48662.322933.32110@emt.wwp.brown.edu> > 1.3.20. ND-NamesDates.xml --> I believe there was another action on > you to add explanation on the difference w3c/iso in the prose (it's > already in the specs). Yes, that's already on my list of things to do, as it were, but no harm in adding another action item as an additional reminder. Thanks, done. > MD and AC are hoping to put together a meeting soon (in London?) of MD, > Yes, In London Check, thanks. Fixed. > Get information from [? Alex Czmiel ?] --> yes Alex Czmiel Check, thanks. Fixed. > work out what GP? really wants. --> Gautier Poupeau, I believe Right. Thanks. Done. > 1.3.8. DS-DefaultTextStructure.xml > [? whose chapter was this? ?] --> mine Sorry. Is it safe to say "AC found no occurences of DTDs, P4, or SGML" or some such? From lou.burnard at computing-services.oxford.ac.uk Wed May 2 12:56:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 02 May 2007 17:56:05 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] Message-ID: <4638C2A5.2080309@oucs.ox.ac.uk> This is really a datatype problem. Is there any desire on Council to review the datatype of the @lem attribute so as to address the issue? Making it xsd:token rather than data.word would help with the specific case Elena raises, at the expense of making this attribute inconsistent with all the other cases of "texty" attributes. -------- Original Message -------- Subject: Re: recording multiword expression in lemma attribute Date: Wed, 02 May 2007 17:03:41 +0100 From: Elena Pierazzo <elena.pierazzo at kcl.ac.uk> To: Lou Burnard <lou.burnard at COMPUTING-SERVICES.OXFORD.AC.UK> CC: TEI-L at listserv.brown.edu References: <20070502152350.59BF2EB04D at webmail221.herald.ox.ac.uk> Dear Lou, thanks for your example: I'll think about it. I just argue that from a linguistic point of view a lemma is not necessarily a single word (in case of Romance languages for sure). As it is, it seems that any project that is trying to lemmatize a text in a language that has multiword expressions cannot use the <w> element as it is and need to customize it either modifying the class or creating new elements. Furthermore, if the attribute approach is suitable for simple cases, why TEI should not support complex cases? In many other modules we have the opportunity to choose which granularity to adopt in the encoding, while for this it seems that complex cases and projects that will adopt a complex linguistic approach has to decide on their own how to customize. Cheers, Elena Lou Burnard ha scritto: > In my opinion, you would do better to put the lemma value into an element of its > own. The attribute value approach is really only suitable for simple cases. > > So if it was me, I would define new elements <form> and <lem> as specialised > kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and > then mark it up thusly: > > > <w> > <lem>in primis</lem> > <form>in prrrrrimmmmissss</form> > </w> > > This means you can put markup into the <lem> as well as spaces > > Alternatively, you could adopt a simple convention like this: > > <w lem="in_primis">....</w> > > Redefining the datatype of the @lem attribute to accept spaces as you propose > would be a bit problematic since that changes the definition. Of course, you > could also argue that it *shouldn't* be defined as data.word... but it currently is! > > > > message <200705021450.l42CiBmN008989 at listserv.brown.edu> Elena Pierazzo > <elena.pierazzo at KCL.AC.UK> writes: > >> This is a multi-part message in MIME format. >> --------------010005090407060100080705 >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Dear all, >> >> I'm working in a project with a strong lexicographical component so we >> are lemmatizing all the words. For this purpose we are using: >> >> <w lemma="">word</w> >> >> but we are in trouble with multiword expressions (e.g. "in primis"). >> From a lexicographical point of view it is matter of a single entry >> (separating the expression in "in" and "primis" is simply nonsensical). >> The problem is that >> >> <w lemma="in primis">in primis</w> >> >> is not valid as the lemma definition is >> >> <attList> >> <attDef ident="lemma" mode="change"> >> <desc>identifies the word's lemma (dictionary entry form).</desc> >> <datatype minOccurs="1" maxOccurs="1"> >> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" >> name="data.word"/> >> </datatype> >> ... >> </attDef> >> </attList> >> >> >> I can modify the definition, but I was thinking that my problem can be >> rather common (for instance, Italian language contains thousands of >> multiword expressions...) and would like to submit the question to >> everybody. >> >> Bests >> >> Elena >> >> >> >> -- >> Elena Pierazzo >> Associate Researcher >> Centre for Computing in the Humanities >> King's College London >> Kay House 7 Arundel St >> London WC2R 3DX >> >> Phone: 0207-848-1949 >> Fax: 0207-848-2980 >> >> --------------010005090407060100080705 >> Content-Type: text/html; charset=ISO-8859-15 >> Content-Transfer-Encoding: 8bit >> >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >> <html> >> <head> >> <meta content="text/html;charset=ISO-8859-15" >> http-equiv="Content-Type"> >> </head> >> <body bgcolor="#ffffff" text="#000000"> >> <font size="-1"><font face="Verdana">Dear all,<br> >> <br> >> I'm working in a project with a strong lexicographical component so we >> are lemmatizing all the words. For this purpose we are using:<br> >> <br> >> <w lemma="">word</w><br> >> <br> >> but we are in trouble with multiword expressions (e.g. "in primis"). <br> >> From a lexicographical point of view it is matter of a single entry >> (separating the expression in "in" and "primis" is simply >> nonsensical). The problem is that <br> >> <br> >> <w lemma="in primis">in primis</w><br> >> <br> >> is not valid as the lemma definition is<br> >> <br> >> <attList><br> >> <attDef ident="lemma" mode="change"><br> >> <desc>identifies the word's lemma (dictionary entry >> form).</desc><br> >> <datatype minOccurs="1" maxOccurs="1"><br> >> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" >> > href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> > >> name="data.word"/><br> >> </datatype><br> >> ...<br> >> </attDef><br> >> </attList><br> >> <br> >> <br> >> I can modify the definition, but I was thinking that my problem can be >> rather common (for instance, Italian language contains thousands of >> multiword expressions...) and would like to submit the question to >> everybody.<br> >> <br> >> Bests<br> >> <br> >> Elena<br> >> <br> >> <br> >> <br> >> </font></font><span class="moz-txt-tag">-- <br> >> </span>Elena Pierazzo >> <br> >> Associate Researcher >> <br> >> Centre for Computing in the Humanities >> <br> >> King's College London >> <br> >> Kay House 7 Arundel St >> <br> >> London WC2R 3DX >> <br> >> <br> >> Phone: 0207-848-1949 >> <br> >> Fax: 0207-848-2980 >> <br> >> </body> >> </html> >> >> --------------010005090407060100080705-- >> >> From Syd_Bauman at Brown.edu Thu May 3 07:13:36 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Thu, 3 May 2007 07:13:36 -0400 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> References: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <17977.50144.504417.384115@emt.wwp.brown.edu> > Making it xsd:token rather than data.word would help with the > specific case Elena raises, at the expense of making this attribute > inconsistent with all the other cases of "texty" attributes. But I would shy away from using xsd:token (which itself imposes no syntactic constraints at all -- any sequence of Unicode characters is permitted except for those XML itself does not allow) in any case. The more appropriate datatype would probably be one or more occurrences of data.word, which already appears 30 times in the Guidelines. Personally, I think I'm in favor, but I don't consider myself an expert in this arena whatsoever. From Syd_Bauman at brown.edu Thu May 3 06:20:12 2007 From: Syd_Bauman at brown.edu (Syd Bauman) Date: Thu, 3 May 2007 06:20:12 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <4639A517.1000600@kcl.ac.uk> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <4638BB1F.9050303@kcl.ac.uk> <17976.48662.322933.32110@emt.wwp.brown.edu> <4639A517.1000600@kcl.ac.uk> Message-ID: <17977.46940.890485.297311@emt.wwp.brown.edu> > All reported on Trac and already fixed by Lou. Check, thanks. Done. From cwittern at gmail.com Wed May 2 19:30:52 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 03 May 2007 08:30:52 +0900 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <46391F2C.4050107@gmail.com> Council members, Thanks to all of you again for contributing to the intense discussions which turned the two days in Berlin into a very successful meeting. Syd Bauman wrote: > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > Thanks for getting this up. I think you did a fair job at recording the deliberations. As far as I am concerned, here is a correction: <quote> 1.3.25. FD-FeatureSystemDeclaration.xml CW reports that he found some references to DTDs in this chapter. *Action CW by *: fix or post references to DTDs in FS </quote> As I said during the meeting, these references have already been fixed and a revised chapter was send to Lou and subsequently checked into svn. > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > The planning committee discussed the issues immediately after the meeting. The result is a list of items for which Sebastian will create trac tickets. Not all the actions are covered, some are so trivial that it did not really make sense to put them into trac. Please dispose with them immediately. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Wed May 2 19:47:28 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 2 May 2007 19:47:28 -0400 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <46391F2C.4050107@gmail.com> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <46391F2C.4050107@gmail.com> Message-ID: <17977.8976.299707.139222@emt.wwp.brown.edu> > As I said during the meeting, these references have already been > fixed and a revised chapter was send to Lou and subsequently > checked into svn. Ooops. Sorry. Corrected. From arianna.ciula at kcl.ac.uk Thu May 3 05:02:15 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 03 May 2007 10:02:15 +0100 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.48662.322933.32110@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> <4638BB1F.9050303@kcl.ac.uk> <17976.48662.322933.32110@emt.wwp.brown.edu> Message-ID: <4639A517.1000600@kcl.ac.uk> Syd Bauman wrote: >> 1.3.8. DS-DefaultTextStructure.xml >> [? whose chapter was this? ?] --> mine > > Sorry. Is it safe to say "AC found no occurences of DTDs, P4, or > SGML" or some such? All reported on Trac and already fixed by Lou. Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Thu May 3 05:08:59 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 03 May 2007 10:08:59 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> References: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <4639A6AB.8010707@kcl.ac.uk> As I said to Elena face to face, I think her point is quite right and I would vote for changing the datatype of the @lemma attribute to xsd:token. Arianna Lou Burnard wrote: > This is really a datatype problem. Is there any desire on Council to > review the datatype of the @lem attribute so as to address the issue? > > Making it xsd:token rather than data.word would help with the specific > case Elena raises, at the expense of making this attribute inconsistent > with all the other cases of "texty" attributes. > > > -------- Original Message -------- > Subject: Re: recording multiword expression in lemma attribute > Date: Wed, 02 May 2007 17:03:41 +0100 > From: Elena Pierazzo <elena.pierazzo at kcl.ac.uk> > To: Lou Burnard <lou.burnard at COMPUTING-SERVICES.OXFORD.AC.UK> > CC: TEI-L at listserv.brown.edu > References: <20070502152350.59BF2EB04D at webmail221.herald.ox.ac.uk> > > > > Dear Lou, > > thanks for your example: I'll think about it. > > I just argue that from a linguistic point of view a lemma is not > necessarily a single word (in case of Romance languages for sure). > > As it is, it seems that any project that is trying to lemmatize a text > in a language that has multiword expressions cannot use the <w> element > as it is and need to customize it either modifying the class or creating > new elements. > > Furthermore, if the attribute approach is suitable for simple cases, why > TEI should not support complex cases? In many other modules we have the > opportunity to choose which granularity to adopt in the encoding, while > for this it seems that complex cases and projects that will adopt a > complex linguistic approach has to decide on their own how to customize. > > Cheers, > > Elena > > Lou Burnard ha scritto: >> In my opinion, you would do better to put the lemma value into an >> element of its >> own. The attribute value approach is really only suitable for simple >> cases. >> >> So if it was me, I would define new elements <form> and <lem> as >> specialised >> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg >> type="lem">) and >> then mark it up thusly: >> >> >> <w> >> <lem>in primis</lem> >> <form>in prrrrrimmmmissss</form> >> </w> >> >> This means you can put markup into the <lem> as well as spaces >> >> Alternatively, you could adopt a simple convention like this: >> >> <w lem="in_primis">....</w> >> >> Redefining the datatype of the @lem attribute to accept spaces as you >> propose >> would be a bit problematic since that changes the definition. Of >> course, you >> could also argue that it *shouldn't* be defined as data.word... but it >> currently is! >> >> >> >> message <200705021450.l42CiBmN008989 at listserv.brown.edu> Elena Pierazzo >> <elena.pierazzo at KCL.AC.UK> writes: >> >>> This is a multi-part message in MIME format. >>> --------------010005090407060100080705 >>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Dear all, >>> >>> I'm working in a project with a strong lexicographical component so >>> we are lemmatizing all the words. For this purpose we are using: >>> >>> <w lemma="">word</w> >>> >>> but we are in trouble with multiword expressions (e.g. "in primis"). >>> From a lexicographical point of view it is matter of a single entry >>> (separating the expression in "in" and "primis" is simply >>> nonsensical). The problem is that >>> >>> <w lemma="in primis">in primis</w> >>> >>> is not valid as the lemma definition is >>> >>> <attList> >>> <attDef ident="lemma" mode="change"> >>> <desc>identifies the word's lemma (dictionary entry >>> form).</desc> >>> <datatype minOccurs="1" maxOccurs="1"> >>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" >>> name="data.word"/> >>> </datatype> >>> ... >>> </attDef> >>> </attList> >>> >>> >>> I can modify the definition, but I was thinking that my problem can >>> be rather common (for instance, Italian language contains thousands >>> of multiword expressions...) and would like to submit the question to >>> everybody. >>> >>> Bests >>> >>> Elena >>> >>> >>> >>> -- >>> Elena Pierazzo >>> Associate Researcher >>> Centre for Computing in the Humanities >>> King's College London >>> Kay House 7 Arundel St >>> London WC2R 3DX >>> >>> Phone: 0207-848-1949 >>> Fax: 0207-848-2980 >>> >>> --------------010005090407060100080705 >>> Content-Type: text/html; charset=ISO-8859-15 >>> Content-Transfer-Encoding: 8bit >>> >>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >>> <html> >>> <head> >>> <meta content="text/html;charset=ISO-8859-15" >>> http-equiv="Content-Type"> >>> </head> >>> <body bgcolor="#ffffff" text="#000000"> >>> <font size="-1"><font face="Verdana">Dear all,<br> >>> <br> >>> I'm working in a project with a strong lexicographical component so we >>> are lemmatizing all the words. For this purpose we are using:<br> >>> <br> >>> <w lemma="">word</w><br> >>> <br> >>> but we are in trouble with multiword expressions (e.g. "in primis"). >>> <br> >>> From a lexicographical point of view it is matter of a single entry >>> (separating the expression in "in" and "primis" is simply >>> nonsensical). The problem is that <br> >>> <br> >>> <w lemma="in primis">in primis</w><br> >>> <br> >>> is not valid as the lemma definition is<br> >>> <br> >>> <attList><br> >>> <attDef ident="lemma" mode="change"><br> >>> <desc>identifies the word's lemma (dictionary entry >>> form).</desc><br> >>> <datatype minOccurs="1" maxOccurs="1"><br> >>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" >>> >> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> >> >> >>> name="data.word"/><br> >>> </datatype><br> >>> ...<br> >>> </attDef><br> >>> </attList><br> >>> <br> >>> <br> >>> I can modify the definition, but I was thinking that my problem can be >>> rather common (for instance, Italian language contains thousands of >>> multiword expressions...) and would like to submit the question to >>> everybody.<br> >>> <br> >>> Bests<br> >>> <br> >>> Elena<br> >>> <br> >>> <br> >>> <br> >>> </font></font><span class="moz-txt-tag">-- <br> >>> </span>Elena Pierazzo >>> <br> >>> Associate Researcher >>> <br> >>> Centre for Computing in the Humanities >>> <br> >>> King's College London >>> <br> >>> Kay House 7 Arundel St >>> <br> >>> London WC2R 3DX >>> <br> >>> <br> >>> Phone: 0207-848-1949 >>> <br> >>> Fax: 0207-848-2980 >>> <br> >>> </body> >>> </html> >>> >>> --------------010005090407060100080705-- >>> >>> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Wed May 2 23:47:15 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 02 May 2007 21:47:15 -0600 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <4638C2A5.2080309@oucs.ox.ac.uk> References: <4638C2A5.2080309@oucs.ox.ac.uk> Message-ID: <1178164035.9068.15.camel@localhost> Before we tamper with something like this, I'd like to see some real examples of multiword lemmas... and, how does that affect w? Isn't it lemma that's affected? On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: > This is really a datatype problem. Is there any desire on Council to > review the datatype of the @lem attribute so as to address the issue? > > Making it xsd:token rather than data.word would help with the specific > case Elena raises, at the expense of making this attribute inconsistent > with all the other cases of "texty" attributes. > > > -------- Original Message -------- > Subject: Re: recording multiword expression in lemma attribute > Date: Wed, 02 May 2007 17:03:41 +0100 > From: Elena Pierazzo <elena.pierazzo at kcl.ac.uk> > To: Lou Burnard <lou.burnard at COMPUTING-SERVICES.OXFORD.AC.UK> > CC: TEI-L at listserv.brown.edu > References: <20070502152350.59BF2EB04D at webmail221.herald.ox.ac.uk> > > > > Dear Lou, > > thanks for your example: I'll think about it. > > I just argue that from a linguistic point of view a lemma is not > necessarily a single word (in case of Romance languages for sure). > > As it is, it seems that any project that is trying to lemmatize a text > in a language that has multiword expressions cannot use the <w> element > as it is and need to customize it either modifying the class or creating > new elements. > > Furthermore, if the attribute approach is suitable for simple cases, why > TEI should not support complex cases? In many other modules we have the > opportunity to choose which granularity to adopt in the encoding, while > for this it seems that complex cases and projects that will adopt a > complex linguistic approach has to decide on their own how to customize. > > Cheers, > > Elena > > Lou Burnard ha scritto: > > In my opinion, you would do better to put the lemma value into an element of its > > own. The attribute value approach is really only suitable for simple cases. > > > > So if it was me, I would define new elements <form> and <lem> as specialised > > kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and > > then mark it up thusly: > > > > > > <w> > > <lem>in primis</lem> > > <form>in prrrrrimmmmissss</form> > > </w> > > > > This means you can put markup into the <lem> as well as spaces > > > > Alternatively, you could adopt a simple convention like this: > > > > <w lem="in_primis">....</w> > > > > Redefining the datatype of the @lem attribute to accept spaces as you propose > > would be a bit problematic since that changes the definition. Of course, you > > could also argue that it *shouldn't* be defined as data.word... but it currently is! > > > > > > > > message <200705021450.l42CiBmN008989 at listserv.brown.edu> Elena Pierazzo > > <elena.pierazzo at KCL.AC.UK> writes: > > > >> This is a multi-part message in MIME format. > >> --------------010005090407060100080705 > >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >> Content-Transfer-Encoding: 7bit > >> > >> Dear all, > >> > >> I'm working in a project with a strong lexicographical component so we > >> are lemmatizing all the words. For this purpose we are using: > >> > >> <w lemma="">word</w> > >> > >> but we are in trouble with multiword expressions (e.g. "in primis"). > >> From a lexicographical point of view it is matter of a single entry > >> (separating the expression in "in" and "primis" is simply nonsensical). > >> The problem is that > >> > >> <w lemma="in primis">in primis</w> > >> > >> is not valid as the lemma definition is > >> > >> <attList> > >> <attDef ident="lemma" mode="change"> > >> <desc>identifies the word's lemma (dictionary entry form).</desc> > >> <datatype minOccurs="1" maxOccurs="1"> > >> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" > >> name="data.word"/> > >> </datatype> > >> ... > >> </attDef> > >> </attList> > >> > >> > >> I can modify the definition, but I was thinking that my problem can be > >> rather common (for instance, Italian language contains thousands of > >> multiword expressions...) and would like to submit the question to > >> everybody. > >> > >> Bests > >> > >> Elena > >> > >> > >> > >> -- > >> Elena Pierazzo > >> Associate Researcher > >> Centre for Computing in the Humanities > >> King's College London > >> Kay House 7 Arundel St > >> London WC2R 3DX > >> > >> Phone: 0207-848-1949 > >> Fax: 0207-848-2980 > >> > >> --------------010005090407060100080705 > >> Content-Type: text/html; charset=ISO-8859-15 > >> Content-Transfer-Encoding: 8bit > >> > >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > >> <html> > >> <head> > >> <meta content="text/html;charset=ISO-8859-15" > >> http-equiv="Content-Type"> > >> </head> > >> <body bgcolor="#ffffff" text="#000000"> > >> <font size="-1"><font face="Verdana">Dear all,<br> > >> <br> > >> I'm working in a project with a strong lexicographical component so we > >> are lemmatizing all the words. For this purpose we are using:<br> > >> <br> > >> <w lemma="">word</w><br> > >> <br> > >> but we are in trouble with multiword expressions (e.g. "in primis"). <br> > >> From a lexicographical point of view it is matter of a single entry > >> (separating the expression in "in" and "primis" is simply > >> nonsensical). The problem is that <br> > >> <br> > >> <w lemma="in primis">in primis</w><br> > >> <br> > >> is not valid as the lemma definition is<br> > >> <br> > >> <attList><br> > >> <attDef ident="lemma" mode="change"><br> > >> <desc>identifies the word's lemma (dictionary entry > >> form).</desc><br> > >> <datatype minOccurs="1" maxOccurs="1"><br> > >> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" > >> > > href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> > > > >> name="data.word"/><br> > >> </datatype><br> > >> ...<br> > >> </attDef><br> > >> </attList><br> > >> <br> > >> <br> > >> I can modify the definition, but I was thinking that my problem can be > >> rather common (for instance, Italian language contains thousands of > >> multiword expressions...) and would like to submit the question to > >> everybody.<br> > >> <br> > >> Bests<br> > >> <br> > >> Elena<br> > >> <br> > >> <br> > >> <br> > >> </font></font><span class="moz-txt-tag">-- <br> > >> </span>Elena Pierazzo > >> <br> > >> Associate Researcher > >> <br> > >> Centre for Computing in the Humanities > >> <br> > >> King's College London > >> <br> > >> Kay House 7 Arundel St > >> <br> > >> London WC2R 3DX > >> <br> > >> <br> > >> Phone: 0207-848-1949 > >> <br> > >> Fax: 0207-848-2980 > >> <br> > >> </body> > >> </html> > >> > >> --------------010005090407060100080705-- > >> > >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From daniel.odonnell at uleth.ca Wed May 2 23:55:49 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 02 May 2007 21:55:49 -0600 Subject: [tei-council] first draft of TC M 30, minutes from Berlin meeting In-Reply-To: <17976.33357.397972.941785@emt.wwp.brown.edu> References: <17976.33357.397972.941785@emt.wwp.brown.edu> Message-ID: <1178164549.9068.20.camel@localhost> I don't want to speak for Christian while he sleeps, but I'd like to add that the planning committee met right after the meeting and did some triage on the action items, as discussed at the end of the council. We'll need to integrate these in the minutes. They're on Christian's computer. I agree the meeting went very well. -dan On Wed, 2007-05-02 at 08:21 -0400, Syd Bauman wrote: > The first draft of the minutes from our meeting our now available at > http://www.tei-c.org/Council/tcm30.xml?style=printable. (Although > some of you may prefer to download > http://www.tei-c.org/Council/tcm30.xml?style=raw.) > > A lot was covered at this meeting, and though the notes are > extensive, I missed a lot, too. At some point before the next > conference call, each of us should read the entire document pretty > carefully. But *right now* you should quickly scan it, looking for > your initials and passages flagged with "[?", and send in > corrections ASAP, before (even more) details fade from memory, and so > that we get the record straight as soon as we can. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Associate Professor and Chair, Department of English University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 403 329-2378 Fax: +1 403 382-7191 From cwittern at gmail.com Wed May 2 19:38:44 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 03 May 2007 08:38:44 +0900 Subject: [tei-council] Next telco Message-ID: <46392104.8040507@gmail.com> Council members, I would like to schedule the next teleconference for the second week of June, that is between June 11 and 15. The time has to be UTC 1200 as usual. Please indicate which of these dates are suitable to you by visiting http://www.meetomatic.com/respond.php?id=LNCCG5 in the next few days. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Thu May 3 04:39:43 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 03 May 2007 09:39:43 +0100 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <1178164035.9068.15.camel@localhost> References: <4638C2A5.2080309@oucs.ox.ac.uk> <1178164035.9068.15.camel@localhost> Message-ID: <46399FCF.4080507@computing-services.oxford.ac.uk> There is one example in Elena's mail. As she points out there are plenty of times when it is convenient to regard as a single "word" something which is conventionally written as several orthographically distinct strings. Examples include "of course" "n'est-ce pas" "che bella" "et caetera" etc. Now, whether or not you regard the use of <w> to tag such things as legitimate you have the problem that at present we recommend using an attribute @lemma to carry the lemmatized version of the whatever it is (it somehow survived the war on attributes). And the lemma corresponding with a multiword may very well be a multiword itself (for example you might decide to mark phrasal verbs in this way and want to show that "putting up with" should have the lemma "put up with"). So yes, @lemma is the issue. Should it be abolished or should it have its datatype changed? Daniel O'Donnell wrote: > Before we tamper with something like this, I'd like to see some real > examples of multiword lemmas... and, how does that affect w? Isn't it > lemma that's affected? > > On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: > >> This is really a datatype problem. Is there any desire on Council to >> review the datatype of the @lem attribute so as to address the issue? >> >> Making it xsd:token rather than data.word would help with the specific >> case Elena raises, at the expense of making this attribute inconsistent >> with all the other cases of "texty" attributes. >> >> >> -------- Original Message -------- >> Subject: Re: recording multiword expression in lemma attribute >> Date: Wed, 02 May 2007 17:03:41 +0100 >> From: Elena Pierazzo <elena.pierazzo at kcl.ac.uk> >> To: Lou Burnard <lou.burnard at COMPUTING-SERVICES.OXFORD.AC.UK> >> CC: TEI-L at listserv.brown.edu >> References: <20070502152350.59BF2EB04D at webmail221.herald.ox.ac.uk> >> >> >> >> Dear Lou, >> >> thanks for your example: I'll think about it. >> >> I just argue that from a linguistic point of view a lemma is not >> necessarily a single word (in case of Romance languages for sure). >> >> As it is, it seems that any project that is trying to lemmatize a text >> in a language that has multiword expressions cannot use the <w> element >> as it is and need to customize it either modifying the class or creating >> new elements. >> >> Furthermore, if the attribute approach is suitable for simple cases, why >> TEI should not support complex cases? In many other modules we have the >> opportunity to choose which granularity to adopt in the encoding, while >> for this it seems that complex cases and projects that will adopt a >> complex linguistic approach has to decide on their own how to customize. >> >> Cheers, >> >> Elena >> >> Lou Burnard ha scritto: >> >>> In my opinion, you would do better to put the lemma value into an element of its >>> own. The attribute value approach is really only suitable for simple cases. >>> >>> So if it was me, I would define new elements <form> and <lem> as specialised >>> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and >>> then mark it up thusly: >>> >>> >>> <w> >>> <lem>in primis</lem> >>> <form>in prrrrrimmmmissss</form> >>> </w> >>> >>> This means you can put markup into the <lem> as well as spaces >>> >>> Alternatively, you could adopt a simple convention like this: >>> >>> <w lem="in_primis">....</w> >>> >>> Redefining the datatype of the @lem attribute to accept spaces as you propose >>> would be a bit problematic since that changes the definition. Of course, you >>> could also argue that it *shouldn't* be defined as data.word... but it currently is! >>> >>> >>> >>> message <200705021450.l42CiBmN008989 at listserv.brown.edu> Elena Pierazzo >>> <elena.pierazzo at KCL.AC.UK> writes: >>> >>> >>>> This is a multi-part message in MIME format. >>>> --------------010005090407060100080705 >>>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Dear all, >>>> >>>> I'm working in a project with a strong lexicographical component so we >>>> are lemmatizing all the words. For this purpose we are using: >>>> >>>> <w lemma="">word</w> >>>> >>>> but we are in trouble with multiword expressions (e.g. "in primis"). >>>> From a lexicographical point of view it is matter of a single entry >>>> (separating the expression in "in" and "primis" is simply nonsensical). >>>> The problem is that >>>> >>>> <w lemma="in primis">in primis</w> >>>> >>>> is not valid as the lemma definition is >>>> >>>> <attList> >>>> <attDef ident="lemma" mode="change"> >>>> <desc>identifies the word's lemma (dictionary entry form).</desc> >>>> <datatype minOccurs="1" maxOccurs="1"> >>>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" >>>> name="data.word"/> >>>> </datatype> >>>> ... >>>> </attDef> >>>> </attList> >>>> >>>> >>>> I can modify the definition, but I was thinking that my problem can be >>>> rather common (for instance, Italian language contains thousands of >>>> multiword expressions...) and would like to submit the question to >>>> everybody. >>>> >>>> Bests >>>> >>>> Elena >>>> >>>> >>>> >>>> -- >>>> Elena Pierazzo >>>> Associate Researcher >>>> Centre for Computing in the Humanities >>>> King's College London >>>> Kay House 7 Arundel St >>>> London WC2R 3DX >>>> >>>> Phone: 0207-848-1949 >>>> Fax: 0207-848-2980 >>>> >>>> --------------010005090407060100080705 >>>> Content-Type: text/html; charset=ISO-8859-15 >>>> Content-Transfer-Encoding: 8bit >>>> >>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >>>> <html> >>>> <head> >>>> <meta content="text/html;charset=ISO-8859-15" >>>> http-equiv="Content-Type"> >>>> </head> >>>> <body bgcolor="#ffffff" text="#000000"> >>>> <font size="-1"><font face="Verdana">Dear all,<br> >>>> <br> >>>> I'm working in a project with a strong lexicographical component so we >>>> are lemmatizing all the words. For this purpose we are using:<br> >>>> <br> >>>> <w lemma="">word</w><br> >>>> <br> >>>> but we are in trouble with multiword expressions (e.g. "in primis"). <br> >>>> From a lexicographical point of view it is matter of a single entry >>>> (separating the expression in "in" and "primis" is simply >>>> nonsensical). The problem is that <br> >>>> <br> >>>> <w lemma="in primis">in primis</w><br> >>>> <br> >>>> is not valid as the lemma definition is<br> >>>> <br> >>>> <attList><br> >>>> <attDef ident="lemma" mode="change"><br> >>>> <desc>identifies the word's lemma (dictionary entry >>>> form).</desc><br> >>>> <datatype minOccurs="1" maxOccurs="1"><br> >>>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" >>>> >>>> >>> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> >>> >>> >>>> name="data.word"/><br> >>>> </datatype><br> >>>> ...<br> >>>> </attDef><br> >>>> </attList><br> >>>> <br> >>>> <br> >>>> I can modify the definition, but I was thinking that my problem can be >>>> rather common (for instance, Italian language contains thousands of >>>> multiword expressions...) and would like to submit the question to >>>> everybody.<br> >>>> <br> >>>> Bests<br> >>>> <br> >>>> Elena<br> >>>> <br> >>>> <br> >>>> <br> >>>> </font></font><span class="moz-txt-tag">-- <br> >>>> </span>Elena Pierazzo >>>> <br> >>>> Associate Researcher >>>> <br> >>>> Centre for Computing in the Humanities >>>> <br> >>>> King's College London >>>> <br> >>>> Kay House 7 Arundel St >>>> <br> >>>> London WC2R 3DX >>>> <br> >>>> <br> >>>> Phone: 0207-848-1949 >>>> <br> >>>> Fax: 0207-848-2980 >>>> <br> >>>> </body> >>>> </html> >>>> >>>> --------------010005090407060100080705-- >>>> >>>> >>>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> From dporter at uky.edu Thu May 3 15:57:27 2007 From: dporter at uky.edu (Dot Porter) Date: Thu, 3 May 2007 15:57:27 -0400 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <46399FCF.4080507@computing-services.oxford.ac.uk> References: <4638C2A5.2080309@oucs.ox.ac.uk> <1178164035.9068.15.camel@localhost> <46399FCF.4080507@computing-services.oxford.ac.uk> Message-ID: <96f3df640705031257y5cd5b468h78210fc751ce67ae@mail.gmail.com> On 5/3/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> wrote: > So yes, @lemma is the issue. Should it be abolished or should it have > its datatype changed? > My first choice is to have the datatype changed to a pointer, with my second preference being @lemma becoming <lemma> Dot > > Daniel O'Donnell wrote: > > Before we tamper with something like this, I'd like to see some real > > examples of multiword lemmas... and, how does that affect w? Isn't it > > lemma that's affected? > > > > On Wed, 2007-05-02 at 17:56 +0100, Lou Burnard wrote: > > > >> This is really a datatype problem. Is there any desire on Council to > >> review the datatype of the @lem attribute so as to address the issue? > >> > >> Making it xsd:token rather than data.word would help with the specific > >> case Elena raises, at the expense of making this attribute inconsistent > >> with all the other cases of "texty" attributes. > >> > >> > >> -------- Original Message -------- > >> Subject: Re: recording multiword expression in lemma attribute > >> Date: Wed, 02 May 2007 17:03:41 +0100 > >> From: Elena Pierazzo <elena.pierazzo at kcl.ac.uk> > >> To: Lou Burnard <lou.burnard at COMPUTING-SERVICES.OXFORD.AC.UK> > >> CC: TEI-L at listserv.brown.edu > >> References: <20070502152350.59BF2EB04D at webmail221.herald.ox.ac.uk> > >> > >> > >> > >> Dear Lou, > >> > >> thanks for your example: I'll think about it. > >> > >> I just argue that from a linguistic point of view a lemma is not > >> necessarily a single word (in case of Romance languages for sure). > >> > >> As it is, it seems that any project that is trying to lemmatize a text > >> in a language that has multiword expressions cannot use the <w> element > >> as it is and need to customize it either modifying the class or creating > >> new elements. > >> > >> Furthermore, if the attribute approach is suitable for simple cases, why > >> TEI should not support complex cases? In many other modules we have the > >> opportunity to choose which granularity to adopt in the encoding, while > >> for this it seems that complex cases and projects that will adopt a > >> complex linguistic approach has to decide on their own how to customize. > >> > >> Cheers, > >> > >> Elena > >> > >> Lou Burnard ha scritto: > >> > >>> In my opinion, you would do better to put the lemma value into an element of its > >>> own. The attribute value approach is really only suitable for simple cases. > >>> > >>> So if it was me, I would define new elements <form> and <lem> as specialised > >>> kinds of <seg> (i.e. as synonyms for <seg type="form"> and <seg type="lem">) and > >>> then mark it up thusly: > >>> > >>> > >>> <w> > >>> <lem>in primis</lem> > >>> <form>in prrrrrimmmmissss</form> > >>> </w> > >>> > >>> This means you can put markup into the <lem> as well as spaces > >>> > >>> Alternatively, you could adopt a simple convention like this: > >>> > >>> <w lem="in_primis">....</w> > >>> > >>> Redefining the datatype of the @lem attribute to accept spaces as you propose > >>> would be a bit problematic since that changes the definition. Of course, you > >>> could also argue that it *shouldn't* be defined as data.word... but it currently is! > >>> > >>> > >>> > >>> message <200705021450.l42CiBmN008989 at listserv.brown.edu> Elena Pierazzo > >>> <elena.pierazzo at KCL.AC.UK> writes: > >>> > >>> > >>>> This is a multi-part message in MIME format. > >>>> --------------010005090407060100080705 > >>>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >>>> Content-Transfer-Encoding: 7bit > >>>> > >>>> Dear all, > >>>> > >>>> I'm working in a project with a strong lexicographical component so we > >>>> are lemmatizing all the words. For this purpose we are using: > >>>> > >>>> <w lemma="">word</w> > >>>> > >>>> but we are in trouble with multiword expressions (e.g. "in primis"). > >>>> From a lexicographical point of view it is matter of a single entry > >>>> (separating the expression in "in" and "primis" is simply nonsensical). > >>>> The problem is that > >>>> > >>>> <w lemma="in primis">in primis</w> > >>>> > >>>> is not valid as the lemma definition is > >>>> > >>>> <attList> > >>>> <attDef ident="lemma" mode="change"> > >>>> <desc>identifies the word's lemma (dictionary entry form).</desc> > >>>> <datatype minOccurs="1" maxOccurs="1"> > >>>> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" > >>>> name="data.word"/> > >>>> </datatype> > >>>> ... > >>>> </attDef> > >>>> </attList> > >>>> > >>>> > >>>> I can modify the definition, but I was thinking that my problem can be > >>>> rather common (for instance, Italian language contains thousands of > >>>> multiword expressions...) and would like to submit the question to > >>>> everybody. > >>>> > >>>> Bests > >>>> > >>>> Elena > >>>> > >>>> > >>>> > >>>> -- > >>>> Elena Pierazzo > >>>> Associate Researcher > >>>> Centre for Computing in the Humanities > >>>> King's College London > >>>> Kay House 7 Arundel St > >>>> London WC2R 3DX > >>>> > >>>> Phone: 0207-848-1949 > >>>> Fax: 0207-848-2980 > >>>> > >>>> --------------010005090407060100080705 > >>>> Content-Type: text/html; charset=ISO-8859-15 > >>>> Content-Transfer-Encoding: 8bit > >>>> > >>>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > >>>> <html> > >>>> <head> > >>>> <meta content="text/html;charset=ISO-8859-15" > >>>> http-equiv="Content-Type"> > >>>> </head> > >>>> <body bgcolor="#ffffff" text="#000000"> > >>>> <font size="-1"><font face="Verdana">Dear all,<br> > >>>> <br> > >>>> I'm working in a project with a strong lexicographical component so we > >>>> are lemmatizing all the words. For this purpose we are using:<br> > >>>> <br> > >>>> <w lemma="">word</w><br> > >>>> <br> > >>>> but we are in trouble with multiword expressions (e.g. "in primis"). <br> > >>>> From a lexicographical point of view it is matter of a single entry > >>>> (separating the expression in "in" and "primis" is simply > >>>> nonsensical). The problem is that <br> > >>>> <br> > >>>> <w lemma="in primis">in primis</w><br> > >>>> <br> > >>>> is not valid as the lemma definition is<br> > >>>> <br> > >>>> <attList><br> > >>>> <attDef ident="lemma" mode="change"><br> > >>>> <desc>identifies the word's lemma (dictionary entry > >>>> form).</desc><br> > >>>> <datatype minOccurs="1" maxOccurs="1"><br> > >>>> <rng:ref xmlns:rng=<a class="moz-txt-link-rfc2396E" > >>>> > >>>> > >>> href="http://relaxng.org/ns/structure/1.0">"http://relaxng.org/ns/structure/1.0"</a> > >>> > >>> > >>>> name="data.word"/><br> > >>>> </datatype><br> > >>>> ...<br> > >>>> </attDef><br> > >>>> </attList><br> > >>>> <br> > >>>> <br> > >>>> I can modify the definition, but I was thinking that my problem can be > >>>> rather common (for instance, Italian language contains thousands of > >>>> multiword expressions...) and would like to submit the question to > >>>> everybody.<br> > >>>> <br> > >>>> Bests<br> > >>>> <br> > >>>> Elena<br> > >>>> <br> > >>>> <br> > >>>> <br> > >>>> </font></font><span class="moz-txt-tag">-- <br> > >>>> </span>Elena Pierazzo > >>>> <br> > >>>> Associate Researcher > >>>> <br> > >>>> Centre for Computing in the Humanities > >>>> <br> > >>>> King's College London > >>>> <br> > >>>> Kay House 7 Arundel St > >>>> <br> > >>>> London WC2R 3DX > >>>> <br> > >>>> <br> > >>>> Phone: 0207-848-1949 > >>>> <br> > >>>> Fax: 0207-848-2980 > >>>> <br> > >>>> </body> > >>>> </html> > >>>> > >>>> --------------010005090407060100080705-- > >>>> > >>>> > >>>> > >> _______________________________________________ > >> tei-council mailing list > >> tei-council at lists.village.Virginia.EDU > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From lou.burnard at computing-services.oxford.ac.uk Fri May 4 10:51:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 04 May 2007 15:51:57 +0100 Subject: [tei-council] tcm30 Message-ID: <463B488D.3000709@oucs.ox.ac.uk> One suggestion and some amplifications: 1. If you tag the actions as <note type="action"><label>...</label>plain text </note> (as usual), rather than as <note type="action"><label>...</label><p>plain text</p> </note>, then the resulting formatted text will be easier to read on screen, and waste fewer trees when printed out 2. the reference to 4/5 character issue in CH is the point raised in David's email http://lists.village.virginia.edu/pipermail/tei-council/2007/002860.html about whether the French word "coeur" for example has five characters or four. 3. Under ST, my notes read "amplify discussion of classes; module names need review" -- we should find some more consistent and sensible way of naming modules (once we've decided that we want to keep them, of course) 4. Under HD, - the action on Dot was also specifically to recommend whether or not the phrase "a machine readable version" vel sim shd be retained in a TEI title. - in the discussion of rendition, it was suggested that a global @style attribute might be useful, distinct from @rend - I have added the mimetype attribute to the <rendition> element but it needs more documentation - MJD supplied a list of typos in HD; I have corrected these The place where @xml:id was used instead of @ident was on <language> and I fixed it during the meeting. 5. VE -- I think I fixed the typos noted by JW in the meeting too, but I'll check 6. TS : my notes suggest that Dot's corrections are in TRAC 89 and that she agreed to update them 7. DI: my notes specify that there are too many examples of numbered divs in this chapter 8. TC/PH: I don't remember the point about re-ordering them being quite so clearcut; and I am quite sure that we didn't make any particular decision about <app> vs <choice>. The Beowulf example (Klaeber's use of parentheses) has been clarified in the source already. GD: The rather cryptic note "stemma modeling" means that DB and MD agreed to experiment with using the tagset in GD for representing a ms stemma, a point repeated in the minutes further on FT : Conal also pointed out that we should give more info on how to use e.g. SVG in a TEI document here, or at least reference MD .... oops must dash to a meeting, more later Lou From Syd_Bauman at Brown.edu Fri May 4 20:48:04 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Fri, 4 May 2007 20:48:04 -0400 (EDT) Subject: [tei-council] tcm30 In-Reply-To: <463B488D.3000709@oucs.ox.ac.uk> References: <463B488D.3000709@oucs.ox.ac.uk> Message-ID: <200705050048.l450m486017209@perseus.services.brown.edu> > 1. If you tag the actions as <note > type="action"><label>...</label>plain text </note> (as usual), > rather than as <note type="action"><label>...</label><p>plain > text</p> </note>, then the resulting formatted text will be easier > to read on screen, and waste fewer trees when printed out Uh ... yes, that is true. Of course, it would be better to fix the stylesheet IMHO. > 2. the reference to 4/5 character issue in CH is the point raised > in David's email > http://lists.village.virginia.edu/pipermail/tei-council/2007/002860.html > about whether the French word "coeur" for example has five > characters or four. Ah! Thank you. Fixed. > 3. Under ST, my notes read "amplify discussion of classes; module names > need review" -- we should find some more consistent and sensible > way of naming modules (once we've decided that we want to keep > them, of course) I'm not sure if you're suggesting this should replace the last sentence and action item or augment them. > 4. Under HD, - the action on Dot was also specifically to recommend > whether or not the phrase "a machine readable version" vel sim shd > be retained in a TEI title. Check, added. > - in the discussion of rendition, it was suggested that a global > @style attribute might be useful, distinct from @rend Right. JW is supposedly writing up this portion of the minutes. > - I have added the mimetype attribute to the <rendition> element > but it needs more documentation Check, noted. > - MJD supplied a list of typos in HD; I have corrected these Check, noted. > The place where @xml:id was used instead of @ident was on > <language> and I fixed it during the meeting. Check, thanks. Noted. > 5. VE -- I think I fixed the typos noted by JW in the meeting too, > but I'll check Standing by ... > 6. TS : my notes suggest that Dot's corrections are in TRAC 89 and that > she agreed to update them There is nothing in ticket #89. > 7. DI: my notes specify that there are too many examples of numbered > divs in this chapter I don't remember that being said, but I agree wholeheartedly! > 8. TC/PH: I don't remember the point about re-ordering them being > quite so clearcut; I remember it as being very clear-cut, primarily because I didn't understand it. Seemed to me you'd want to know how to encode a normal book before trying to work on an aparatus, but I was told there are a lot of references from PH to TC. Any one else have recollections of this? Opinions? > ... and I am quite sure that we didn't make any particular decision > about <app> vs <choice>. Check, so noted. > The Beowulf example (Klaeber's use of parentheses) has been > clarified in the source already. Check, which is why the action item says "done" for the date. > GD: The rather cryptic note "stemma modeling" means that DB and MD > agreed to experiment with using the tagset in GD for representing a > ms stemma, a point repeated in the minutes further on Check, thanks; so noted. > FT : Conal also pointed out that we should give more info on how to > use e.g. SVG in a TEI document here, or at least reference MD Check. So noted. > .... oops must dash to a meeting, more later Thanks for all these, and sorry I didn't get to them earlier today, but I had a bunch of meetings, too. From sebastian.rahtz at oucs.ox.ac.uk Sat May 5 17:44:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 05 May 2007 22:44:22 +0100 Subject: [tei-council] actions from last week Message-ID: <463CFAB6.7060804@oucs.ox.ac.uk> I have been through the minutes of Berlin, and put in links to a set of tickets in trac which formalize the set of activites for coming 6 weeks. This is hopefully as per a planning meeting between self, Dan and Christian in Berlin. Please look at http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=Actions+from+chapter+review and make sure you know what is on your plate. Also read the minutes carefully. Any actions in there which no link to a trac ticket should be either so trivial that you have done them already, or so vague that I could not make a worthwhile ticket. If you are doing anything substantial this month for P5 which does not correspond to a trac item, please tell me so that I can record it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sat May 5 18:24:34 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 05 May 2007 23:24:34 +0100 Subject: [tei-council] Tite for real Message-ID: <463D0422.8060301@oucs.ox.ac.uk> have a look at http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite.odd and consider http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite1.xml?style=xml http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite2.xml?style=xml http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite3.xml?style=xml http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite4.xml?style=xml http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite5.xml?style=xml http://tei.oucs.ox.ac.uk/Guidelines/Test/testtite5.xml?style=xml these are all representations of a test Tite document, showing how the different namespace needed for the syntactic sugar elements in Tite can be handled. They all validate against a RELAXNG or XSD schema, but not all against the a DTD. testtite4.xml shows what a DTD-friendly version looks like - the DTD provides all the xmlns declarations. I'll have more to say on this, but I wanted to show concrete examples of what genuine Tite documents might look like, if we follow the proposal. For the cognoscenti, in Guidelines/Exemplars you can find make-acdc.xsl, which is an XSLT script to generate an XSLT transform from the <equiv> elements in testtite.odd, which makes a genuinely conformant TEI document from a TEI Tite one. I'm now off to bed and then away on holiday for a day, so don't expect me to answer questions on this until late Monday :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From cwittern at gmail.com Mon May 7 01:11:45 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:11:45 +0900 Subject: [tei-council] Berlin extra tour Message-ID: <463EB511.1000108@gmail.com> Dear Council members, For those who went with me on our little impromptu Berlin excursion, I have now put up a GPS log of my steps of that evening at http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tmp/berlin-walk.zip You will find three files in there: berlin-walk.html will display a google map with the walk overlaid, you can use the play button to replay W*.log two files, one for the way to the restaurant, the other for the way back, for those who want to georeference the pictures taken during the excursion. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From cwittern at gmail.com Mon May 7 01:19:28 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:19:28 +0900 Subject: [tei-council] next telco date: June 12, 2007 Message-ID: <463EB6E0.8040308@gmail.com> Dear Council members, Meetomatic has sent me the following recommendation: So far, 11 responses have been received, and Meet-O-Matic is currently recommending the following date for the meeting: Tuesday 12th June 2007 On closer inspection, David Birnbaum is the only one who will not be available on this date out of those who responded. Another contender for the meeting date would be Friday, 15th, were we would have to do without Tone Merete. However, for the moment I would like to set the meeting to Tuesday 12th June 2007 , 12:00 GMT We expect a report on all action items from the Berlin meeting there at the latest, but please feel free to report at your earliest convenience:-) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From cwittern at gmail.com Mon May 7 01:21:50 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 07 May 2007 14:21:50 +0900 Subject: [tei-council] [Fwd: Re: recording multiword expression in lemma attribute] In-Reply-To: <96f3df640705031257y5cd5b468h78210fc751ce67ae@mail.gmail.com> References: <4638C2A5.2080309@oucs.ox.ac.uk> <1178164035.9068.15.camel@localhost> <46399FCF.4080507@computing-services.oxford.ac.uk> <96f3df640705031257y5cd5b468h78210fc751ce67ae@mail.gmail.com> Message-ID: <463EB76E.4090802@gmail.com> Dot Porter wrote: > On 5/3/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> > wrote: >> So yes, @lemma is the issue. Should it be abolished or should it have >> its datatype changed? >> > My first choice is to have the datatype changed to a pointer, with my > second preference being @lemma becoming <lemma> > This seems preferable to me as well. We will need examples to illustrate the usage then as well. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Mon May 7 05:49:28 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 07 May 2007 10:49:28 +0100 Subject: [tei-council] Berlin extra tour In-Reply-To: <463EB511.1000108@gmail.com> References: <463EB511.1000108@gmail.com> Message-ID: <463EF628.9050404@computing-services.oxford.ac.uk> Now that's what I call cool. If only I'd known I was participating in a scientific experiment! Wittern Christian wrote: > Dear Council members, > > For those who went with me on our little impromptu Berlin excursion, I > have now put up a GPS log of my steps of that evening at > http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tmp/berlin-walk.zip > > You will find three files in there: > berlin-walk.html will display a google map with the walk overlaid, you > can use the play button to replay > > W*.log two files, one for the way to the restaurant, the > other for the way back, for those who want to georeference the pictures > taken during the excursion. > > All the best, > > Christian > > From Syd_Bauman at Brown.edu Mon May 7 22:54:29 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 7 May 2007 22:54:29 -0400 Subject: [tei-council] Berlin extra tour In-Reply-To: <463EB511.1000108@gmail.com> References: <463EB511.1000108@gmail.com> Message-ID: <17983.58981.476158.887427@emt.wwp.brown.edu> Oh that's cool. I can just hear Joan Jett or Pat Benetar now: I saw directions there on the computer screen I knew it was a place I had never been Me walkin' in my thongs, Singin' spoof X-M-L songs, An' I could tell it's gonna be long, Till we get to eat, yeah eat, singin' I love Google Earth, Please take me for a walk around Berlin, Christian; I love Google Earth, So come an' take your time an' walk with me. (For original lyrics see, e.g., http://www.lyred.com/lyrics/Joan+Jett+And+The+Blackhearts/I+Love+Rock+&+Roll/I+Love+Rock+N%27+Roll/) From cwittern at gmail.com Tue May 8 16:19:35 2007 From: cwittern at gmail.com (Wittern Christian) Date: Wed, 09 May 2007 05:19:35 +0900 Subject: [tei-council] facsimile markup Message-ID: <4640DB57.1060609@gmail.com> Dear Conal and Dot, Looking at the Berlin minutes again, I now see that there is no action item to follow up on the facsimile markup. While it might not be necessary for 1.0, I think now that the work has progressed so far it would be a pity not to include it, especially given the frequent requests for this. So I wonder if you could adress the concerns mentioned and revise your propsosal in a way that could go into the Guidelines. Maybe you could as a starter post the things we looked at during the meeting somewhere (at the Wiki?) so that we can have a closer look. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From conal.tuohy at vuw.ac.nz Tue May 8 22:00:46 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 09 May 2007 14:00:46 +1200 Subject: [tei-council] facsimile markup In-Reply-To: <4640DB57.1060609@gmail.com> References: <4640DB57.1060609@gmail.com> Message-ID: <1178676046.3107.128.camel@localhost> I finished my holiday in the UK and I'm now at work and catching up on a backlog of email. On Wed, 2007-05-09 at 05:19 +0900, Wittern Christian wrote: > Dear Conal and Dot, > > Looking at the Berlin minutes again, I now see that there is no action > item to follow up on the facsimile markup. While it might not be > necessary for 1.0, I think now that the work has progressed so far it > would be a pity not to include it, especially given the frequent > requests for this. My memory was that I had an action item to compile a "full" set of examples, including the Comenius example, marked up according to that draft, and also to write it up as a chapter (or section of a chapter). > So I wonder if you could adress the concerns mentioned and revise your > propsosal in a way that could go into the Guidelines. Maybe you could > as a starter post the things we looked at during the meeting somewhere > (at the Wiki?) so that we can have a closer look. Will do > > All the best, > > Christian > From dporter at uky.edu Tue May 8 22:14:27 2007 From: dporter at uky.edu (Dot Porter) Date: Wed, 9 May 2007 04:14:27 +0200 Subject: [tei-council] facsimile markup In-Reply-To: <1178676046.3107.128.camel@localhost> References: <4640DB57.1060609@gmail.com> <1178676046.3107.128.camel@localhost> Message-ID: <96f3df640705081914m71af0ddi4ee9c751b7a1adc9@mail.gmail.com> Lou was keen on having us look at the proposal next to what already appears in the Linking chapter. This wasn't assigned to me at the time but I am happy to take it on. Dot On 5/9/07, Conal Tuohy <conal.tuohy at vuw.ac.nz> wrote: > I finished my holiday in the UK and I'm now at work and catching up on a > backlog of email. > > On Wed, 2007-05-09 at 05:19 +0900, Wittern Christian wrote: > > Dear Conal and Dot, > > > > Looking at the Berlin minutes again, I now see that there is no action > > item to follow up on the facsimile markup. While it might not be > > necessary for 1.0, I think now that the work has progressed so far it > > would be a pity not to include it, especially given the frequent > > requests for this. > > My memory was that I had an action item to compile a "full" set of > examples, including the Comenius example, marked up according to that > draft, and also to write it up as a chapter (or section of a chapter). > > > So I wonder if you could adress the concerns mentioned and revise your > > propsosal in a way that could go into the Guidelines. Maybe you could > > as a starter post the things we looked at during the meeting somewhere > > (at the Wiki?) so that we can have a closer look. > > Will do > > > > > All the best, > > > > Christian > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From jawalsh at indiana.edu Wed May 9 00:39:27 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 00:39:27 -0400 Subject: [tei-council] rendition, rend, and style Message-ID: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Hi all, I'm supposed to write up my thoughts on proposed changes to <rendition> and @rend, including the possible addition of an @style attribute. The current P5 guidelines state that @rend "indicates how the element in question was rendered or presented in the source text." But my sense is that in practice @rend is used both to indicate how an element was rendered in the source text and/or how it should be rendered in a display environment such as a Web browser or printed output. The addition of @style could be used to distinguish between rendering in the source text (@rend) and rendering in an output format (@style). *OR* the addition of @style could be used to provided the @class/@style functionality of HTML. @rend (like @class) could refer to predefined style classes, which could be defined in the <rendition> element of the TEI Header. @style could be used to embed style information directly in an element. If we simply want to distinguish between source rendering and output rendering with the addition of an @style attribute, then my task is easy. If on the other hand we want to provide the @class/@style functionality of HTML, the task is more difficult and would involve prescribing or recommending practice that is not common at the moment, and would also likely involve changes to the <rendition> element and perhaps a new element in <encodingDesc> where folks could explain their implementation. For instance, users may define their styles using CSS, XSL-FO, rendition ladders, or some other mechanism, and this will need to be explained in <encodingDesc>. I believe we touched on all these various distinctions in Berlin, so I would like members of the council to weigh in on which way to go with this. Please select A. or B. (or a new letter and proposal of your own invention): A. @rend/@style should distinguish between source rendering and output rendering. B. @rend/@style should distinguish between HTML-like @class functionality and HTML-like @style functionality. Incidentally, if we go with B. and style classes are defined in <rendition> elements of the TEI Header, then we could add an attribute to <rendition> that indicates whether the "target" of this rendition "class" is the source text or the output format. The @style attribute would remain ambiguous in terms of source/output, but this ambiguity could be addressed and clarified in the <encodingDesc>. Once I hear back from others on the Council, I'll proceed with a more formal document on this topic. John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> From daniel.odonnell at uleth.ca Wed May 9 00:53:43 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 08 May 2007 22:53:43 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <1178686423.26240.2.camel@caedmon> I like option a) @rend=input document, @style=output document with no guideline constraints on language used to describe them. However, I can easily see that somebody might want to use CSS as a style shorthand for @style and maybe even @rend, and that in such cases this should be machine checkable. Perhaps an optional reference in the header to the language used on the attributes if applicable? I.e. something that would have text/css and maybe xslt-fo as a valid attribute. -dan On Wed, 2007-05-09 at 00:39 -0400, John A. Walsh wrote: > Hi all, > > I'm supposed to write up my thoughts on proposed changes to > <rendition> and @rend, including the possible addition of an @style > attribute. > > The current P5 guidelines state that @rend "indicates how the element > in question was rendered or presented in the source text." But my > sense is that in practice @rend is used both to indicate how an > element was rendered in the source text and/or how it should be > rendered in a display environment such as a Web browser or printed > output. > > The addition of @style could be used to distinguish between rendering > in the source text (@rend) and rendering in an output format > (@style). *OR* the addition of @style could be used to provided the > @class/@style functionality of HTML. @rend (like @class) could refer > to predefined style classes, which could be defined in the > <rendition> element of the TEI Header. @style could be used to embed > style information directly in an element. > > If we simply want to distinguish between source rendering and output > rendering with the addition of an @style attribute, then my task is > easy. > > If on the other hand we want to provide the @class/@style > functionality of HTML, the task is more difficult and would involve > prescribing or recommending practice that is not common at the > moment, and would also likely involve changes to the <rendition> > element and perhaps a new element in <encodingDesc> where folks could > explain their implementation. For instance, users may define their > styles using CSS, XSL-FO, rendition ladders, or some other mechanism, > and this will need to be explained in <encodingDesc>. > > I believe we touched on all these various distinctions in Berlin, so > I would like members of the council to weigh in on which way to go > with this. Please select A. or B. (or a new letter and proposal of > your own invention): > > A. @rend/@style should distinguish between source rendering and > output rendering. > > B. @rend/@style should distinguish between HTML-like @class > functionality and HTML-like @style functionality. > > Incidentally, if we go with B. and style classes are defined in > <rendition> elements of the TEI Header, then we could add an > attribute to <rendition> that indicates whether the "target" of this > rendition "class" is the source text or the output format. The > @style attribute would remain ambiguous in terms of source/output, > but this ambiguity could be addressed and clarified in the > <encodingDesc>. > > Once I hear back from others on the Council, I'll proceed with a more > formal document on this topic. > > John > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed May 9 04:08:11 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 09 May 2007 09:08:11 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <4641816B.2010208@computing-services.oxford.ac.uk> > > Incidentally, if we go with B. and style classes are defined in > <rendition> elements of the TEI Header, then we could add an attribute > to <rendition> that indicates whether the "target" of this rendition > "class" is the source text or the output format. The @style attribute > would remain ambiguous in terms of source/output, but this ambiguity > could be addressed and clarified in the <encodingDesc>. Why would you want to use e.g. CSS to describe the *original* rendition? surely it lacks many features you'd need (nothing about page layout, for example) and has too many irrelevant ones (because it assumes you are going to render it on a screen)? To my mind it makes sense to keep @rend with the proviso that it's for describing the original. If we add @style (and I'm not yet convinced it's a good idea) it should refer only to desired output. Mixing input/output definitions within <rendition> doesn't bother me particularly, though. > > Once I hear back from others on the Council, I'll proceed with a more > formal document on this topic. > > John > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 04:13:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 09:13:10 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <46418296.1060708@oucs.ox.ac.uk> we could just recommend using "html:class" and "html:style" attributes sebastian From lou.burnard at computing-services.oxford.ac.uk Wed May 9 04:20:51 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 09 May 2007 09:20:51 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> <46418296.1060708@oucs.ox.ac.uk> Message-ID: <46418463.80007@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > we could just recommend using "html:class" and "html:style" attributes > > sebastian > duh! of course! These namespace things really are tricksy little fellows eh? From arianna.ciula at kcl.ac.uk Wed May 9 06:44:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 09 May 2007 11:44:32 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> <46418296.1060708@oucs.ox.ac.uk> Message-ID: <4641A610.4020507@kcl.ac.uk> Sebastian Rahtz wrote: > we could just recommend using "html:class" and "html:style" attributes Yes, I think namespaces offer a good service here. So I agree the definition for @rend should still refer to the representation of the source (even if this may correspond to what we want the output to look like, but that's another matter). Arianna > > sebastian > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From jawalsh at indiana.edu Wed May 9 07:58:40 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 07:58:40 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <565EEECA-CC88-455F-9E3E-E7E9D01F9755@indiana.edu> On May 9, 2007, at 4:08 AM, Lou Burnard wrote: > >> >> Incidentally, if we go with B. and style classes are defined in >> <rendition> elements of the TEI Header, then we could add an >> attribute to <rendition> that indicates whether the "target" of >> this rendition "class" is the source text or the output format. >> The @style attribute would remain ambiguous in terms of source/ >> output, but this ambiguity could be addressed and clarified in the >> <encodingDesc>. > > Why would you want to use e.g. CSS to describe the *original* > rendition? surely it lacks many features you'd need (nothing about > page layout, for example) and has too many irrelevant ones (because > it assumes you are going to render it on a screen)? > I'm imagining people might use a mix of CSS and XSL-FO and their own custom definitions to describe things. I believe CSS covers most of what people use rend for (font styles, indentation, superscript, subscript, alignment, margins, color, line spacing, etc.) From jawalsh at indiana.edu Wed May 9 08:02:03 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 08:02:03 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46418296.1060708@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> <46418296.1060708@oucs.ox.ac.uk> Message-ID: <E163C1F2-BA22-48E3-99C1-56626C69A132@indiana.edu> On May 9, 2007, at 4:13 AM, Sebastian Rahtz wrote: > we could just recommend using "html:class" and "html:style" > attributes > True, although I like the idea of formalizing a relationship between <rendition> and @rend, and using the header to be more explicit about what exactly is going on with rendering issues in a document. Nothing prevents people from doing so now, but there is not much guidance in the guidelines on this particular issue. Although, perhaps practice and preferences vary so much that we want to leave it open and flexible. John > sebastian > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 09:11:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 14:11:41 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> Message-ID: <4641C88D.6030304@oucs.ox.ac.uk> I think that anyone who wants the equivalent of HTML's @style should literally use html:style, and it would only be used on born-digital stuff. So lets consider just HTML's class vs rend. If rend is to be used for what we _see_, we'll also very often use it for how we render. So <hi rend="italic"> will want to rendered as <span class="italic">, usually. We don't want to force people to say <hi rend="italic" style="italic">, so it makes sense for "italic" be a link to a place in <rendition> where it is mapped to a) an expansion of what we say (did we differentiate italic from slanted?), and b) a rendition class (HTML, FO, whatever). So I am wondering whether we should not just keep the single rend, but change its datatype to be a pointer to a composite source/ rendering pair? If forced to go A or B, I incline to] A. @rend/@style should distinguish between source rendering and output rendering. in which @rend is a token which is expected to be explained in <rendition>, and @style is system dependent, but normally equivalent to HTML @class -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From jawalsh at indiana.edu Wed May 9 12:14:52 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 12:14:52 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641C88D.6030304@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641C88D.6030304@oucs.ox.ac.uk> Message-ID: <3D946E83-DB54-416E-BA19-B8467FBFCFD5@indiana.edu> On May 9, 2007, at 9:11 AM, Sebastian Rahtz wrote: > I think that anyone who wants the equivalent of HTML's @style > should literally > use html:style, and it would only be used on born-digital stuff. So > lets consider > just HTML's class vs rend. > > If rend is to be used for what we _see_, we'll > also very often use it for how we render. So <hi rend="italic"> > will want to rendered as <span class="italic">, usually. We > don't want to force people to say <hi rend="italic" style="italic">, > so it makes sense for "italic" be a link to a place in <rendition> > where it is mapped to a) an expansion of what we say (did > we differentiate italic from slanted?), and b) a rendition class > (HTML, FO, whatever). > > So I am wondering whether we should not just keep the single > rend, but change its datatype to be a pointer to a composite > source/ rendering pair? > Sebastian, There seems to be wise agreement not to duplicate @html:style with a new @tei:style. For @rend, what you describe above-- at rend as a pointer to <rendition>--is what I was planning to document if there is agreement to move @rend more in the direction of @html:class. @rend would be different from @html:class because of its (potential) linkage with <rendition>. I think this proposed change to @rend is a good idea (and something I've used for years in my P4 extension files and P5 ODD files). It helps prevent sloppy use of @rend (e.g., @rend="i", @rend="italic", @rend="italics", @rend="italicize", etc.-- all in the same document). It potentially allows easy automatic generation of CSS (or XSL-FO) styles from information documented in the <rendition> elements of the TEI Header. But changing the datatype of @rend would break lots of stuff, e.g., rendition ladders. It's a fairly radical change to a widely used global element. Is such a change worth pursuing as part of the Guidelines, or is an ODD and documentation about how to use @rend in this manner something for a separate paper? John From jawalsh at indiana.edu Wed May 9 12:29:51 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 9 May 2007 12:29:51 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641B808.5000600@pitt.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> Message-ID: <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> David, I agree about the descriptive vs. presentational issue...but the stylesheets you mention often need triggers in the TEI source, and they @rend attribute is often the trigger one uses. Also, since we have an @rend attribute, it would seem useful to provide a standard mechanism for documenting how that attribute is used and defining the meaning of its content. @rend="big" could mean lots of things, but if it points to <rendition xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: bold</rendition>, then one has a clear idea of what @rend="big" means, and this rendition definition may well refer to the source text, not any output format. A stylesheet can still take the "big" trigger and do something else with it. The Guidelines do already state that the content of rendition may be "expressed in running prose, or in some more formal language such as CSS." John -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: > Dear John, > > Option C, please. XML isn't Microsoft Word and TEI markup should be > descriptive, rather than presentational. The ability to specify > output rendering is often very important to projects, but the place > to declare it is the stylesheet, not the document instance. > > Best, > > David > > John A. Walsh wrote: >> Hi all, >> >> I'm supposed to write up my thoughts on proposed changes to >> <rendition> and @rend, including the possible addition of an >> @style attribute. >> >> The current P5 guidelines state that @rend "indicates how the >> element in question was rendered or presented in the source >> text." But my sense is that in practice @rend is used both to >> indicate how an element was rendered in the source text and/or how >> it should be rendered in a display environment such as a Web >> browser or printed output. >> >> The addition of @style could be used to distinguish between >> rendering in the source text (@rend) and rendering in an output >> format (@style). *OR* the addition of @style could be used to >> provided the @class/@style functionality of HTML. @rend (like >> @class) could refer to predefined style classes, which could be >> defined in the <rendition> element of the TEI Header. @style >> could be used to embed style information directly in an element. >> >> If we simply want to distinguish between source rendering and >> output rendering with the addition of an @style attribute, then my >> task is easy. >> >> If on the other hand we want to provide the @class/@style >> functionality of HTML, the task is more difficult and would >> involve prescribing or recommending practice that is not common at >> the moment, and would also likely involve changes to the >> <rendition> element and perhaps a new element in <encodingDesc> >> where folks could explain their implementation. For instance, >> users may define their styles using CSS, XSL-FO, rendition >> ladders, or some other mechanism, and this will need to be >> explained in <encodingDesc>. >> >> I believe we touched on all these various distinctions in Berlin, >> so I would like members of the council to weigh in on which way to >> go with this. Please select A. or B. (or a new letter and >> proposal of your own invention): >> >> A. @rend/@style should distinguish between source rendering and >> output rendering. >> >> B. @rend/@style should distinguish between HTML-like @class >> functionality and HTML-like @style functionality. >> >> Incidentally, if we go with B. and style classes are defined in >> <rendition> elements of the TEI Header, then we could add an >> attribute to <rendition> that indicates whether the "target" of >> this rendition "class" is the source text or the output format. >> The @style attribute would remain ambiguous in terms of source/ >> output, but this ambiguity could be addressed and clarified in the >> <encodingDesc>. >> >> Once I hear back from others on the Council, I'll proceed with a >> more formal document on this topic. >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From daniel.odonnell at uleth.ca Wed May 9 13:35:20 2007 From: daniel.odonnell at uleth.ca (Dan O'Donnell) Date: Wed, 09 May 2007 11:35:20 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <4641816B.2010208@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641816B.2010208@computing-services.oxford.ac.uk> Message-ID: <1178732120.27069.49.camel@odonned-eng06> Thinking about the option presented so far, I have a modified option. I still prefer option A. But I like the idea of html:style for real CSS. I think there is a fair bit of anecdotal evidence that people would like the idea of being able to describe the output rendition. But I suppose it does raise the question of whether that is a structural issue or not something better handled by stylesheets. -dan On Wed, 2007-09-05 at 09:08 +0100, Lou Burnard wrote: > > > > Incidentally, if we go with B. and style classes are defined in > > <rendition> elements of the TEI Header, then we could add an attribute > > to <rendition> that indicates whether the "target" of this rendition > > "class" is the source text or the output format. The @style attribute > > would remain ambiguous in terms of source/output, but this ambiguity > > could be addressed and clarified in the <encodingDesc>. > > Why would you want to use e.g. CSS to describe the *original* rendition? > surely it lacks many features you'd need (nothing about page layout, for > example) and has too many irrelevant ones (because it assumes you are > going to render it on a screen)? > > To my mind it makes sense to keep @rend with the proviso that it's for > describing the original. If we add @style (and I'm not yet convinced > it's a good idea) it should refer only to desired output. > > Mixing input/output definitions within <rendition> doesn't bother me > particularly, though. > > > > > > > > Once I hear back from others on the Council, I'll proceed with a more > > formal document on this topic. > > > > John > > -- > > | John A. Walsh > > | Assistant Professor, School of Library and Information Science > > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> > > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Chair, Text Encoding Initiative <http://www.tei-c.org/> Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Associate Professor and Chair of English University of Lethbridge Lethbridge AB T1K 3M4 Vox: +1 403 329 2378 Fax: +1 403 382-7191 Homepage: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed May 9 17:44:57 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 09 May 2007 22:44:57 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <3D946E83-DB54-416E-BA19-B8467FBFCFD5@indiana.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641C88D.6030304@oucs.ox.ac.uk> <3D946E83-DB54-416E-BA19-B8467FBFCFD5@indiana.edu> Message-ID: <464240D9.1060405@oucs.ox.ac.uk> John A. Walsh wrote: > > There seems to be wise agreement not to duplicate @html:style with a > new @tei:style. For @rend, what you describe above-- at rend as a > pointer to <rendition>--is what I was planning to document if there is > agreement to move @rend more in the direction of @html:class. @rend > would be different from @html:class because of its (potential) linkage > with <rendition>. I think this proposed change to @rend is a good > idea (and something I've used for years in my P4 extension files and > P5 ODD files). It helps prevent sloppy use of @rend (e.g., @rend="i", > @rend="italic", @rend="italics", @rend="italicize", etc.--all in the > same document). It potentially allows easy automatic generation of > CSS (or XSL-FO) styles from information documented in the <rendition> > elements of the TEI Header. But changing the datatype of @rend would > break lots of stuff, e.g., rendition ladders. It's a fairly radical > change to a widely used global element. Having @rend as a pointer would be nice, but I can see it would be horrid disruptive. Lets suppose @rend='foo' gets you to a part of <rendition>. are you proposing a notation there to distinguish input from output? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From djbpitt+tei at pitt.edu Wed May 9 18:51:28 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Wed, 09 May 2007 18:51:28 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> Message-ID: <46425070.3070004@pitt.edu> Dear John (cc Council), In David's Magical World of Descriptive Markup, markup is never procedural/presentational and output rendering is governed by mapping descriptive markup to rendering details in a stylesheet. If I want my code snippets output in a monospaced font, I tag them as <code> (or something similar) and in my stylesheet (not my document instance) I map the content of <code> elements to a CSS instruction to use that font (or FO or some other stylesheet-level specification). I never specify "monospaced font" as part of my markup of my born-electric source. Similarly, I can't imagine specifying in my descriptive markup that an element should be rendered as "big" in my output document. I might specify that it was big in my source document (not the same thing, as we've noted), or I might specify that it is important or that it is a section heading, but if I want any of these three features to produce rendering as big (however I interpret that) in the output, it would be because "big in the source document" or "important" or "section heading" was mapped to "render this in big type" in the stylesheet. I have no problem with mapping of @rend="big" to a font specification in a <rendition> element when this is part of a description of the source document. My only objection is to specifying output rendering in the document instance. For what it's worth ... Best, David John A. Walsh wrote: > David, > > I agree about the descriptive vs. presentational issue...but the > stylesheets you mention often need triggers in the TEI source, and > they @rend attribute is often the trigger one uses. Also, since we > have an @rend attribute, it would seem useful to provide a standard > mechanism for documenting how that attribute is used and defining the > meaning of its content. @rend="big" could mean lots of things, but if > it points to <rendition xml:id="big">font-family: Granjon; font-size: > 16pt; font-weight: bold</rendition>, then one has a clear idea of what > @rend="big" means, and this rendition definition may well refer to the > source text, not any output format. A stylesheet can still take the > "big" trigger and do something else with it. The Guidelines do > already state that the content of rendition may be "expressed in > running prose, or in some more formal language such as CSS." > > John > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> > > > On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: > >> Dear John, >> >> Option C, please. XML isn't Microsoft Word and TEI markup should be >> descriptive, rather than presentational. The ability to specify >> output rendering is often very important to projects, but the place >> to declare it is the stylesheet, not the document instance. >> >> Best, >> >> David >> >> John A. Walsh wrote: >>> Hi all, >>> >>> I'm supposed to write up my thoughts on proposed changes to >>> <rendition> and @rend, including the possible addition of an @style >>> attribute. >>> >>> The current P5 guidelines state that @rend "indicates how the >>> element in question was rendered or presented in the source text." >>> But my sense is that in practice @rend is used both to indicate how >>> an element was rendered in the source text and/or how it should be >>> rendered in a display environment such as a Web browser or printed >>> output. >>> >>> The addition of @style could be used to distinguish between >>> rendering in the source text (@rend) and rendering in an output >>> format (@style). *OR* the addition of @style could be used to >>> provided the @class/@style functionality of HTML. @rend (like >>> @class) could refer to predefined style classes, which could be >>> defined in the <rendition> element of the TEI Header. @style could >>> be used to embed style information directly in an element. >>> >>> If we simply want to distinguish between source rendering and output >>> rendering with the addition of an @style attribute, then my task is >>> easy. >>> >>> If on the other hand we want to provide the @class/@style >>> functionality of HTML, the task is more difficult and would involve >>> prescribing or recommending practice that is not common at the >>> moment, and would also likely involve changes to the <rendition> >>> element and perhaps a new element in <encodingDesc> where folks >>> could explain their implementation. For instance, users may define >>> their styles using CSS, XSL-FO, rendition ladders, or some other >>> mechanism, and this will need to be explained in <encodingDesc>. >>> >>> I believe we touched on all these various distinctions in Berlin, so >>> I would like members of the council to weigh in on which way to go >>> with this. Please select A. or B. (or a new letter and proposal of >>> your own invention): >>> >>> A. @rend/@style should distinguish between source rendering and >>> output rendering. >>> >>> B. @rend/@style should distinguish between HTML-like @class >>> functionality and HTML-like @style functionality. >>> >>> Incidentally, if we go with B. and style classes are defined in >>> <rendition> elements of the TEI Header, then we could add an >>> attribute to <rendition> that indicates whether the "target" of this >>> rendition "class" is the source text or the output format. The >>> @style attribute would remain ambiguous in terms of source/output, >>> but this ambiguity could be addressed and clarified in the >>> <encodingDesc>. >>> >>> Once I hear back from others on the Council, I'll proceed with a >>> more formal document on this topic. >>> >>> John >>> --| John A. Walsh >>> | Assistant Professor, School of Library and Information Science >>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 04:36:32 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 09:36:32 +0100 Subject: [tei-council] cleanup release of P5 Message-ID: <4642D990.6040700@oucs.ox.ac.uk> I propose to make a 0.7 release of P5 in a few days, to get a level playing field with a new release of Roma and stylesheets for ODD processing. Any objections? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 04:37:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 09:37:58 +0100 Subject: [tei-council] release Message-ID: <4642D9E6.9000806@oucs.ox.ac.uk> in fact, I would propose to say now that we make a 0.8 release on 1st July and a 0.9 release on 1st September, to firm up the schedule even more. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu May 10 09:41:20 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 10 May 2007 14:41:20 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46425070.3070004@pitt.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> Message-ID: <46432100.2060404@computing-services.oxford.ac.uk> This is both defensible and coherent as TEI policy. What changes are needed (if any) in P5 to reinforce that position? David J Birnbaum wrote: > Dear John (cc Council), > > In David's Magical World of Descriptive Markup, markup is never > procedural/presentational and output rendering is governed by mapping > descriptive markup to rendering details in a stylesheet. If I want my > code snippets output in a monospaced font, I tag them as <code> (or > something similar) and in my stylesheet (not my document instance) I > map the content of <code> elements to a CSS instruction to use that > font (or FO or some other stylesheet-level specification). I never > specify "monospaced font" as part of my markup of my born-electric > source. > > Similarly, I can't imagine specifying in my descriptive markup that an > element should be rendered as "big" in my output document. I might > specify that it was big in my source document (not the same thing, as > we've noted), or I might specify that it is important or that it is a > section heading, but if I want any of these three features to produce > rendering as big (however I interpret that) in the output, it would be > because "big in the source document" or "important" or "section > heading" was mapped to "render this in big type" in the stylesheet. > > I have no problem with mapping of @rend="big" to a font specification > in a <rendition> element when this is part of a description of the > source document. My only objection is to specifying output rendering > in the document instance. > > For what it's worth ... > > Best, > > David > > John A. Walsh wrote: >> David, >> >> I agree about the descriptive vs. presentational issue...but the >> stylesheets you mention often need triggers in the TEI source, and >> they @rend attribute is often the trigger one uses. Also, since we >> have an @rend attribute, it would seem useful to provide a standard >> mechanism for documenting how that attribute is used and defining the >> meaning of its content. @rend="big" could mean lots of things, but if >> it points to <rendition xml:id="big">font-family: Granjon; font-size: >> 16pt; font-weight: bold</rendition>, then one has a clear idea of >> what @rend="big" means, and this rendition definition may well refer >> to the source text, not any output format. A stylesheet can still >> take the "big" trigger and do something else with it. The Guidelines >> do already state that the content of rendition may be "expressed in >> running prose, or in some more formal language such as CSS." >> >> John >> -- >> | John A. Walsh >> | Assistant Professor, School of Library and Information Science >> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >> >> >> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >> >>> Dear John, >>> >>> Option C, please. XML isn't Microsoft Word and TEI markup should be >>> descriptive, rather than presentational. The ability to specify >>> output rendering is often very important to projects, but the place >>> to declare it is the stylesheet, not the document instance. >>> >>> Best, >>> >>> David >>> >>> John A. Walsh wrote: >>>> Hi all, >>>> >>>> I'm supposed to write up my thoughts on proposed changes to >>>> <rendition> and @rend, including the possible addition of an @style >>>> attribute. >>>> >>>> The current P5 guidelines state that @rend "indicates how the >>>> element in question was rendered or presented in the source text." >>>> But my sense is that in practice @rend is used both to indicate how >>>> an element was rendered in the source text and/or how it should be >>>> rendered in a display environment such as a Web browser or printed >>>> output. >>>> >>>> The addition of @style could be used to distinguish between >>>> rendering in the source text (@rend) and rendering in an output >>>> format (@style). *OR* the addition of @style could be used to >>>> provided the @class/@style functionality of HTML. @rend (like >>>> @class) could refer to predefined style classes, which could be >>>> defined in the <rendition> element of the TEI Header. @style could >>>> be used to embed style information directly in an element. >>>> >>>> If we simply want to distinguish between source rendering and >>>> output rendering with the addition of an @style attribute, then my >>>> task is easy. >>>> >>>> If on the other hand we want to provide the @class/@style >>>> functionality of HTML, the task is more difficult and would involve >>>> prescribing or recommending practice that is not common at the >>>> moment, and would also likely involve changes to the <rendition> >>>> element and perhaps a new element in <encodingDesc> where folks >>>> could explain their implementation. For instance, users may define >>>> their styles using CSS, XSL-FO, rendition ladders, or some other >>>> mechanism, and this will need to be explained in <encodingDesc>. >>>> >>>> I believe we touched on all these various distinctions in Berlin, >>>> so I would like members of the council to weigh in on which way to >>>> go with this. Please select A. or B. (or a new letter and proposal >>>> of your own invention): >>>> >>>> A. @rend/@style should distinguish between source rendering and >>>> output rendering. >>>> >>>> B. @rend/@style should distinguish between HTML-like @class >>>> functionality and HTML-like @style functionality. >>>> >>>> Incidentally, if we go with B. and style classes are defined in >>>> <rendition> elements of the TEI Header, then we could add an >>>> attribute to <rendition> that indicates whether the "target" of >>>> this rendition "class" is the source text or the output format. >>>> The @style attribute would remain ambiguous in terms of >>>> source/output, but this ambiguity could be addressed and clarified >>>> in the <encodingDesc>. >>>> >>>> Once I hear back from others on the Council, I'll proceed with a >>>> more formal document on this topic. >>>> >>>> John >>>> --| John A. Walsh >>>> | Assistant Professor, School of Library and Information Science >>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>> >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From djbpitt+tei at pitt.edu Thu May 10 10:12:50 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 10:12:50 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432100.2060404@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> Message-ID: <46432862.9010907@pitt.edu> Dear Lou (cc John, Council), We might want to review the description of @rend in the guidelines to ensure that the TEI recommends that it be used to indicate rendering in the source document, but not to specify output rendering. Since new users will then ask "so how do I specify output rendering?", we might also add a note that output rendering is governed by associations in stylesheets between the descriptive TEI markup and the desired output final form, and that output rendering is not specified in the document instance. If we are feeling ambitious, we can point them to a discussion in the Gentle Introduction of the difference between descriptive and procedural/presentational markup as away of explaining why specifying output rendering in the document instance is a Bad Idea (that is, why the TEI isn't supposed to be a typesetting spec). If we need an example, John and I discussed a specific issue from his projects in private email yesterday, and he's welcome to introduce that into the discussion if he thinks it would be constructive. In other words, I think the current TEI syntax is probably fine, and we just need to make sure that we provide clear advice about the semantics. We may already do that. Best, David Lou's Laptop wrote: > This is both defensible and coherent as TEI policy. What changes are > needed (if any) in P5 to reinforce that position? > > > David J Birnbaum wrote: >> Dear John (cc Council), >> >> In David's Magical World of Descriptive Markup, markup is never >> procedural/presentational and output rendering is governed by mapping >> descriptive markup to rendering details in a stylesheet. If I want my >> code snippets output in a monospaced font, I tag them as <code> (or >> something similar) and in my stylesheet (not my document instance) I >> map the content of <code> elements to a CSS instruction to use that >> font (or FO or some other stylesheet-level specification). I never >> specify "monospaced font" as part of my markup of my born-electric >> source. >> >> Similarly, I can't imagine specifying in my descriptive markup that >> an element should be rendered as "big" in my output document. I might >> specify that it was big in my source document (not the same thing, as >> we've noted), or I might specify that it is important or that it is a >> section heading, but if I want any of these three features to produce >> rendering as big (however I interpret that) in the output, it would >> be because "big in the source document" or "important" or "section >> heading" was mapped to "render this in big type" in the stylesheet. >> >> I have no problem with mapping of @rend="big" to a font specification >> in a <rendition> element when this is part of a description of the >> source document. My only objection is to specifying output rendering >> in the document instance. >> >> For what it's worth ... >> >> Best, >> >> David >> >> John A. Walsh wrote: >>> David, >>> >>> I agree about the descriptive vs. presentational issue...but the >>> stylesheets you mention often need triggers in the TEI source, and >>> they @rend attribute is often the trigger one uses. Also, since we >>> have an @rend attribute, it would seem useful to provide a standard >>> mechanism for documenting how that attribute is used and defining >>> the meaning of its content. @rend="big" could mean lots of things, >>> but if it points to <rendition xml:id="big">font-family: Granjon; >>> font-size: 16pt; font-weight: bold</rendition>, then one has a clear >>> idea of what @rend="big" means, and this rendition definition may >>> well refer to the source text, not any output format. A stylesheet >>> can still take the "big" trigger and do something else with it. The >>> Guidelines do already state that the content of rendition may be >>> "expressed in running prose, or in some more formal language such as >>> CSS." >>> >>> John >>> -- >>> | John A. Walsh >>> | Assistant Professor, School of Library and Information Science >>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>> >>> >>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >>> >>>> Dear John, >>>> >>>> Option C, please. XML isn't Microsoft Word and TEI markup should be >>>> descriptive, rather than presentational. The ability to specify >>>> output rendering is often very important to projects, but the place >>>> to declare it is the stylesheet, not the document instance. >>>> >>>> Best, >>>> >>>> David >>>> >>>> John A. Walsh wrote: >>>>> Hi all, >>>>> >>>>> I'm supposed to write up my thoughts on proposed changes to >>>>> <rendition> and @rend, including the possible addition of an >>>>> @style attribute. >>>>> >>>>> The current P5 guidelines state that @rend "indicates how the >>>>> element in question was rendered or presented in the source >>>>> text." But my sense is that in practice @rend is used both to >>>>> indicate how an element was rendered in the source text and/or how >>>>> it should be rendered in a display environment such as a Web >>>>> browser or printed output. >>>>> >>>>> The addition of @style could be used to distinguish between >>>>> rendering in the source text (@rend) and rendering in an output >>>>> format (@style). *OR* the addition of @style could be used to >>>>> provided the @class/@style functionality of HTML. @rend (like >>>>> @class) could refer to predefined style classes, which could be >>>>> defined in the <rendition> element of the TEI Header. @style >>>>> could be used to embed style information directly in an element. >>>>> >>>>> If we simply want to distinguish between source rendering and >>>>> output rendering with the addition of an @style attribute, then my >>>>> task is easy. >>>>> >>>>> If on the other hand we want to provide the @class/@style >>>>> functionality of HTML, the task is more difficult and would >>>>> involve prescribing or recommending practice that is not common at >>>>> the moment, and would also likely involve changes to the >>>>> <rendition> element and perhaps a new element in <encodingDesc> >>>>> where folks could explain their implementation. For instance, >>>>> users may define their styles using CSS, XSL-FO, rendition >>>>> ladders, or some other mechanism, and this will need to be >>>>> explained in <encodingDesc>. >>>>> >>>>> I believe we touched on all these various distinctions in Berlin, >>>>> so I would like members of the council to weigh in on which way to >>>>> go with this. Please select A. or B. (or a new letter and >>>>> proposal of your own invention): >>>>> >>>>> A. @rend/@style should distinguish between source rendering and >>>>> output rendering. >>>>> >>>>> B. @rend/@style should distinguish between HTML-like @class >>>>> functionality and HTML-like @style functionality. >>>>> >>>>> Incidentally, if we go with B. and style classes are defined in >>>>> <rendition> elements of the TEI Header, then we could add an >>>>> attribute to <rendition> that indicates whether the "target" of >>>>> this rendition "class" is the source text or the output format. >>>>> The @style attribute would remain ambiguous in terms of >>>>> source/output, but this ambiguity could be addressed and clarified >>>>> in the <encodingDesc>. >>>>> >>>>> Once I hear back from others on the Council, I'll proceed with a >>>>> more formal document on this topic. >>>>> >>>>> John >>>>> --| John A. Walsh >>>>> | Assistant Professor, School of Library and Information Science >>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:22:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:22:31 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432862.9010907@pitt.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> Message-ID: <46432AA7.5000002@oucs.ox.ac.uk> If @rend says it is for source description only, then my born-digital document can't use it. So how _do_ I indicate superscript? Currently I say '2<hi rend="sup">nd</hi>', and all is ok. In future, putting @rend in there is deprecated, but I need _some_ clue. Answers of - use an xml:id and trap it in CSS - define <oxford:sup> are unacceptable. So now I should say: <hi html:class="sup">nd</hi> ? but of course that has an impact on the complexity of my ODD, if I have to add html:class to att.global. Plus, I am not conformant? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Thu May 10 10:36:56 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Thu, 10 May 2007 15:36:56 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432AA7.5000002@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> Message-ID: <46432E08.5040408@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > If @rend says it is for source description only, > then my born-digital document > can't use it. Hmm, I may be logic chopping here, but I don't think I agree. If your doc is born digital, then you *are* describing the source when you say @rend=sup, surely? Maybe this is one of the points that needs more careful elaboration. Can we imagine a case where @rend in a born-digital document does not describe how it should be rendered? @rend="done in emacs without benefit of markup" doesnt seem very likely. From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:40:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:40:15 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <46432ECF.50308@oucs.ox.ac.uk> Lou's Laptop wrote: > Hmm, I may be logic chopping here, but I don't think I agree. If your > doc is born digital, then you *are* describing the source when you say > @rend=sup, surely? hmm. suppose so. maybe. the change then is the recommendation to use the value of @rend to look at a section of <rendition>, no more no less. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 10:52:51 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 15:52:51 +0100 Subject: [tei-council] the "key" attribute Message-ID: <464331C3.8040102@oucs.ox.ac.uk> Useful little beast, but I don't think we are 100% clear on its use yet. Here is @key's ODD: <attDef ident="key" usage="opt"> <desc>provides a means of locating a full definition for the entity being named such as a database record key or a URI.</desc> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.key"/></datatype> </attDef> so if I say key="foo", is that a URI or a database record key? I simply can't tell from the context. look at some of our test files: <name type="person" key="ThorJon08">Þorgeir Jónsson</name> <country key="#FR"/> <placeName key="http://www.activitaly.it/monument/portspaolo.htm">Porta <persName key="#CESTIUS">Cestius</persName> <placeName key="http://en.wikipedia.org/wiki/Aurelian_walls"> Aurelian <placeName key="#DK">Denmark</placeName></p></placeState> <country key="#place2"></country> <settlement key="place3"></settlement> <addrLine><name key="ota" type="organisation">Oxford Text Archive</name></addrLine> we're not even internally consistent! So, to # or not to #? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Thu May 10 13:01:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 10 May 2007 18:01:43 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <46434FF7.4020107@kcl.ac.uk> I totally agree with what David says about the meaning of @rend for not born digital material. As far as born digital material regard though, I can imagine the situation where someone wants to differentiate the semantics (not big or small, but myIntrepret_category1 and myIntrepret_category2) of the information so that some style could be applied - possibly - later on. We should remember that in some cases the people who do the markup are not bothered (should they be?) about what style is going to be applied to their documents, but they do want to differentiate between different things that may need a different visualisation. So while I can see the advantages of a good practice in pointing @rend to <rendition> in the header for born digital material, I am still not sure this is the only use we should support for @rend in this case. Arianna Lou's Laptop wrote: > Sebastian Rahtz wrote: >> If @rend says it is for source description only, >> then my born-digital document >> can't use it. > Hmm, I may be logic chopping here, but I don't think I agree. If your > doc is born digital, then you *are* describing the source when you say > @rend=sup, surely? > > Maybe this is one of the points that needs more careful elaboration. Can > we imagine a case where @rend in a born-digital document does not > describe how it should be rendered? @rend="done in emacs without benefit > of markup" doesnt seem very likely. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From daniel.odonnell at uleth.ca Thu May 10 13:22:32 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:22:32 -0600 Subject: [tei-council] the "key" attribute In-Reply-To: <464331C3.8040102@oucs.ox.ac.uk> References: <464331C3.8040102@oucs.ox.ac.uk> Message-ID: <1178817752.19411.4.camel@caedmon> > > So, to # or not to #? # always means equivalent to xml:id? > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu May 10 13:23:04 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:23:04 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432ECF.50308@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46432ECF.50308@oucs.ox.ac.uk> Message-ID: <1178817784.19411.6.camel@caedmon> On Thu, 2007-05-10 at 15:40 +0100, Sebastian Rahtz wrote: > Lou's Laptop wrote: > > Hmm, I may be logic chopping here, but I don't think I agree. If your > > doc is born digital, then you *are* describing the source when you say > > @rend=sup, surely? > hmm. suppose so. maybe. > > the change then is the recommendation to use the value of @rend > to look at a section of <rendition>, no more no less. Offloading seems yet again a good solution. > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu May 10 13:31:25 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:31:25 -0600 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432E08.5040408@computing-services.oxford.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> Message-ID: <1178818285.19989.5.camel@caedmon> On Thu, 2007-05-10 at 15:36 +0100, Lou's Laptop wrote: > Sebastian Rahtz wrote: > > If @rend says it is for source description only, > > then my born-digital document > > can't use it. > Hmm, I may be logic chopping here, but I don't think I agree. If your > doc is born digital, then you *are* describing the source when you say > @rend=sup, surely? > > Maybe this is one of the points that needs more careful elaboration. Can > we imagine a case where @rend in a born-digital document does not > describe how it should be rendered? Well following David's observation, I'd have thought the answer to this question is always: i.e. even @rend="font-decoration:underline;" is a description of rendition in the digitally born document, not "how it should be rendered." Speaking of digitally born documents and rendition: what do we do a) about including stylesheet information as rendition information in the tei-xml document, and b) about declaring the language used in rendition if the our Born Digital Document is styled using a recognisable language. In the case of a) I am not wondering about how to attach a CSS sheet or the like for output processing, but how to include it as a rendition description on input: if I have a CSS stylesheet that formats the front page of the NYTimes, for example, the style information seems to me to be as much a valid rendition description as "written in a big looping hand" is for a manuscript. > @rend="done in emacs without benefit > of markup" doesnt seem very likely. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu May 10 13:37:12 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 11:37:12 -0600 Subject: [tei-council] release In-Reply-To: <4642D9E6.9000806@oucs.ox.ac.uk> References: <4642D9E6.9000806@oucs.ox.ac.uk> Message-ID: <1178818632.19989.11.camel@caedmon> Sounds fine to me. On Thu, 2007-05-10 at 09:37 +0100, Sebastian Rahtz wrote: > in fact, I would propose to say now that we > make a 0.8 release on 1st July and a 0.9 > release on 1st September, to firm up > the schedule even more. > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From djbpitt+tei at pitt.edu Thu May 10 13:39:54 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 13:39:54 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> Message-ID: <464358EA.2000100@pitt.edu> Dear Arianna (cc Lou, Council), I agree completely that we may need to tag information according to interpretive categories, but since @rend is supposed to be about rendering and interpretive categories are not essentially about rendering (although we may, of course, ultimately render different interpretive categories differently in certain views of our data), I don't think @rend is the right attribute semantically. To press something intended to indicate rendering into service as an indicator of interpretive categories that are not essentially about rendering suggests tag abuse. If we don't already have a way to flag interpretive categories, I'd certainly support implementing one. It's a very important need; my only objection is that @rend is the wrong way to address it. Cheers, David Arianna Ciula wrote: > I totally agree with what David says about the meaning of @rend for > not born digital material. > > As far as born digital material regard though, I can imagine the > situation where someone wants to differentiate the semantics (not big > or small, but myIntrepret_category1 and myIntrepret_category2) of the > information so that some style could be applied - possibly - later on. > We should remember that in some cases the people who do the markup are > not bothered (should they be?) about what style is going to be applied > to their documents, but they do want to differentiate between > different things that may need a different visualisation. So while I > can see the advantages of a good practice in pointing @rend to > <rendition> in the header for born digital material, I am still not > sure this is the only use we should support for @rend in this case. > > Arianna > > Lou's Laptop wrote: >> Sebastian Rahtz wrote: >>> If @rend says it is for source description only, >>> then my born-digital document >>> can't use it. >> Hmm, I may be logic chopping here, but I don't think I agree. If your >> doc is born digital, then you *are* describing the source when you >> say @rend=sup, surely? >> >> Maybe this is one of the points that needs more careful elaboration. >> Can we imagine a case where @rend in a born-digital document does not >> describe how it should be rendered? @rend="done in emacs without >> benefit of markup" doesnt seem very likely. >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From jawalsh at indiana.edu Thu May 10 13:52:55 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 13:52:55 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> Message-ID: <20070510135255.64gyni6d8gso4kkc@webmail.iu.edu> > So > while I can see the advantages of a good practice in pointing @rend > to <rendition> in the header for born digital material, I am still > not sure this is the only use we should support for @rend in this > case. The practice of pointing @rend to <rendition> is not just for born digital material. I think CSS (or XSL-FO) properties such as font-family, font-size, font-weight, text-indent, etc. can be used to describe accurately and precisely the appearance of a source document, at least for printed source documents, though many properties can also be useful in the description of manuscript documents. From jawalsh at indiana.edu Thu May 10 14:00:13 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 14:00:13 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46432862.9010907@pitt.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> Message-ID: <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> I've been persuaded by David's position and his clear and strong distinction between descriptive and procedural/presentation. I'm also persuaded that @rend should only refer to description of the source material (which may be the TEI document itself in the case of born digital material). I still believe though in the benefits of changing @rend to be a pointer to one or more <rendition> elements which provide a fuller and more formal description of what exactly is being described in the source document. John Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: > Dear Lou (cc John, Council), > > We might want to review the description of @rend in the guidelines to > ensure that the TEI recommends that it be used to indicate rendering > in the source document, but not to specify output rendering. Since > new users will then ask "so how do I specify output rendering?", we > might also add a note that output rendering is governed by > associations in stylesheets between the descriptive TEI markup and > the desired output final form, and that output rendering is not > specified in the document instance. If we are feeling ambitious, we > can point them to a discussion in the Gentle Introduction of the > difference between descriptive and procedural/presentational markup > as away of explaining why specifying output rendering in the document > instance is a Bad Idea (that is, why the TEI isn't supposed to be a > typesetting spec). > > If we need an example, John and I discussed a specific issue from his > projects in private email yesterday, and he's welcome to introduce > that into the discussion if he thinks it would be constructive. > > In other words, I think the current TEI syntax is probably fine, and > we just need to make sure that we provide clear advice about the > semantics. We may already do that. > > Best, > > David > > Lou's Laptop wrote: >> This is both defensible and coherent as TEI policy. What changes are >> needed (if any) in P5 to reinforce that position? >> >> >> David J Birnbaum wrote: >>> Dear John (cc Council), >>> >>> In David's Magical World of Descriptive Markup, markup is never >>> procedural/presentational and output rendering is governed by >>> mapping descriptive markup to rendering details in a stylesheet. If >>> I want my code snippets output in a monospaced font, I tag them as >>> <code> (or something similar) and in my stylesheet (not my document >>> instance) I map the content of <code> elements to a CSS instruction >>> to use that font (or FO or some other stylesheet-level >>> specification). I never specify "monospaced font" as part of my >>> markup of my born-electric source. >>> >>> Similarly, I can't imagine specifying in my descriptive markup that >>> an element should be rendered as "big" in my output document. I >>> might specify that it was big in my source document (not the same >>> thing, as we've noted), or I might specify that it is important or >>> that it is a section heading, but if I want any of these three >>> features to produce rendering as big (however I interpret that) in >>> the output, it would be because "big in the source document" or >>> "important" or "section heading" was mapped to "render this in big >>> type" in the stylesheet. >>> >>> I have no problem with mapping of @rend="big" to a font >>> specification in a <rendition> element when this is part of a >>> description of the source document. My only objection is to >>> specifying output rendering in the document instance. >>> >>> For what it's worth ... >>> >>> Best, >>> >>> David >>> >>> John A. Walsh wrote: >>>> David, >>>> >>>> I agree about the descriptive vs. presentational issue...but the >>>> stylesheets you mention often need triggers in the TEI source, and >>>> they @rend attribute is often the trigger one uses. Also, since >>>> we have an @rend attribute, it would seem useful to provide a >>>> standard mechanism for documenting how that attribute is used and >>>> defining the meaning of its content. @rend="big" could mean lots >>>> of things, but if it points to <rendition >>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: >>>> bold</rendition>, then one has a clear idea of what @rend="big" >>>> means, and this rendition definition may well refer to the source >>>> text, not any output format. A stylesheet can still take the >>>> "big" trigger and do something else with it. The Guidelines do >>>> already state that the content of rendition may be "expressed in >>>> running prose, or in some more formal language such as CSS." >>>> >>>> John >>>> -- >>>> | John A. Walsh >>>> | Assistant Professor, School of Library and Information Science >>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>> >>>> >>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >>>> >>>>> Dear John, >>>>> >>>>> Option C, please. XML isn't Microsoft Word and TEI markup should >>>>> be descriptive, rather than presentational. The ability to >>>>> specify output rendering is often very important to projects, but >>>>> the place to declare it is the stylesheet, not the document >>>>> instance. >>>>> >>>>> Best, >>>>> >>>>> David >>>>> >>>>> John A. Walsh wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm supposed to write up my thoughts on proposed changes to >>>>>> <rendition> and @rend, including the possible addition of an >>>>>> @style attribute. >>>>>> >>>>>> The current P5 guidelines state that @rend "indicates how the >>>>>> element in question was rendered or presented in the source >>>>>> text." But my sense is that in practice @rend is used both to >>>>>> indicate how an element was rendered in the source text and/or >>>>>> how it should be rendered in a display environment such as a Web >>>>>> browser or printed output. >>>>>> >>>>>> The addition of @style could be used to distinguish between >>>>>> rendering in the source text (@rend) and rendering in an output >>>>>> format (@style). *OR* the addition of @style could be used to >>>>>> provided the @class/@style functionality of HTML. @rend (like >>>>>> @class) could refer to predefined style classes, which could be >>>>>> defined in the <rendition> element of the TEI Header. @style >>>>>> could be used to embed style information directly in an element. >>>>>> >>>>>> If we simply want to distinguish between source rendering and >>>>>> output rendering with the addition of an @style attribute, then >>>>>> my task is easy. >>>>>> >>>>>> If on the other hand we want to provide the @class/@style >>>>>> functionality of HTML, the task is more difficult and would >>>>>> involve prescribing or recommending practice that is not common >>>>>> at the moment, and would also likely involve changes to the >>>>>> <rendition> element and perhaps a new element in <encodingDesc> >>>>>> where folks could explain their implementation. For instance, >>>>>> users may define their styles using CSS, XSL-FO, rendition >>>>>> ladders, or some other mechanism, and this will need to be >>>>>> explained in <encodingDesc>. >>>>>> >>>>>> I believe we touched on all these various distinctions in >>>>>> Berlin, so I would like members of the council to weigh in on >>>>>> which way to go with this. Please select A. or B. (or a new >>>>>> letter and proposal of your own invention): >>>>>> >>>>>> A. @rend/@style should distinguish between source rendering and >>>>>> output rendering. >>>>>> >>>>>> B. @rend/@style should distinguish between HTML-like @class >>>>>> functionality and HTML-like @style functionality. >>>>>> >>>>>> Incidentally, if we go with B. and style classes are defined in >>>>>> <rendition> elements of the TEI Header, then we could add an >>>>>> attribute to <rendition> that indicates whether the "target" of >>>>>> this rendition "class" is the source text or the output format. >>>>>> The @style attribute would remain ambiguous in terms of >>>>>> source/output, but this ambiguity could be addressed and >>>>>> clarified in the <encodingDesc>. >>>>>> >>>>>> Once I hear back from others on the Council, I'll proceed with a >>>>>> more formal document on this topic. >>>>>> >>>>>> John >>>>>> --| John A. Walsh >>>>>> | Assistant Professor, School of Library and Information Science >>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> > > From djbpitt+tei at pitt.edu Thu May 10 14:19:00 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 14:19:00 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> Message-ID: <46436214.8020907@pitt.edu> Dear John (cc Lou, Council), Are you suggesting that @rend should always be a pointer to a <rendition> element, or that it should have the option of being either a pointer or an in-line specification? Best, David John A. Walsh wrote: > I've been persuaded by David's position and his clear and strong > distinction between descriptive and procedural/presentation. I'm also > persuaded that @rend should only refer to description of the source > material (which may be the TEI document itself in the case of born > digital material). I still believe though in the benefits of changing > @rend to be a pointer to one or more <rendition> elements which > provide a fuller and more formal description of what exactly is being > described in the source document. > > John > > Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: > >> Dear Lou (cc John, Council), >> >> We might want to review the description of @rend in the guidelines to >> ensure that the TEI recommends that it be used to indicate rendering >> in the source document, but not to specify output rendering. Since >> new users will then ask "so how do I specify output rendering?", we >> might also add a note that output rendering is governed by >> associations in stylesheets between the descriptive TEI markup and >> the desired output final form, and that output rendering is not >> specified in the document instance. If we are feeling ambitious, we >> can point them to a discussion in the Gentle Introduction of the >> difference between descriptive and procedural/presentational markup >> as away of explaining why specifying output rendering in the document >> instance is a Bad Idea (that is, why the TEI isn't supposed to be a >> typesetting spec). >> >> If we need an example, John and I discussed a specific issue from his >> projects in private email yesterday, and he's welcome to introduce >> that into the discussion if he thinks it would be constructive. >> >> In other words, I think the current TEI syntax is probably fine, and >> we just need to make sure that we provide clear advice about the >> semantics. We may already do that. >> >> Best, >> >> David >> >> Lou's Laptop wrote: >>> This is both defensible and coherent as TEI policy. What changes are >>> needed (if any) in P5 to reinforce that position? >>> >>> >>> David J Birnbaum wrote: >>>> Dear John (cc Council), >>>> >>>> In David's Magical World of Descriptive Markup, markup is never >>>> procedural/presentational and output rendering is governed by >>>> mapping descriptive markup to rendering details in a stylesheet. If >>>> I want my code snippets output in a monospaced font, I tag them as >>>> <code> (or something similar) and in my stylesheet (not my document >>>> instance) I map the content of <code> elements to a CSS instruction >>>> to use that font (or FO or some other stylesheet-level >>>> specification). I never specify "monospaced font" as part of my >>>> markup of my born-electric source. >>>> >>>> Similarly, I can't imagine specifying in my descriptive markup that >>>> an element should be rendered as "big" in my output document. I >>>> might specify that it was big in my source document (not the same >>>> thing, as we've noted), or I might specify that it is important or >>>> that it is a section heading, but if I want any of these three >>>> features to produce rendering as big (however I interpret that) in >>>> the output, it would be because "big in the source document" or >>>> "important" or "section heading" was mapped to "render this in big >>>> type" in the stylesheet. >>>> >>>> I have no problem with mapping of @rend="big" to a font >>>> specification in a <rendition> element when this is part of a >>>> description of the source document. My only objection is to >>>> specifying output rendering in the document instance. >>>> >>>> For what it's worth ... >>>> >>>> Best, >>>> >>>> David >>>> >>>> John A. Walsh wrote: >>>>> David, >>>>> >>>>> I agree about the descriptive vs. presentational issue...but the >>>>> stylesheets you mention often need triggers in the TEI source, and >>>>> they @rend attribute is often the trigger one uses. Also, since >>>>> we have an @rend attribute, it would seem useful to provide a >>>>> standard mechanism for documenting how that attribute is used and >>>>> defining the meaning of its content. @rend="big" could mean lots >>>>> of things, but if it points to <rendition >>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: >>>>> bold</rendition>, then one has a clear idea of what @rend="big" >>>>> means, and this rendition definition may well refer to the source >>>>> text, not any output format. A stylesheet can still take the >>>>> "big" trigger and do something else with it. The Guidelines do >>>>> already state that the content of rendition may be "expressed in >>>>> running prose, or in some more formal language such as CSS." >>>>> >>>>> John >>>>> -- >>>>> | John A. Walsh >>>>> | Assistant Professor, School of Library and Information Science >>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>> >>>>> >>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >>>>> >>>>>> Dear John, >>>>>> >>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should >>>>>> be descriptive, rather than presentational. The ability to >>>>>> specify output rendering is often very important to projects, but >>>>>> the place to declare it is the stylesheet, not the document >>>>>> instance. >>>>>> >>>>>> Best, >>>>>> >>>>>> David >>>>>> >>>>>> John A. Walsh wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm supposed to write up my thoughts on proposed changes to >>>>>>> <rendition> and @rend, including the possible addition of an >>>>>>> @style attribute. >>>>>>> >>>>>>> The current P5 guidelines state that @rend "indicates how the >>>>>>> element in question was rendered or presented in the source >>>>>>> text." But my sense is that in practice @rend is used both to >>>>>>> indicate how an element was rendered in the source text and/or >>>>>>> how it should be rendered in a display environment such as a Web >>>>>>> browser or printed output. >>>>>>> >>>>>>> The addition of @style could be used to distinguish between >>>>>>> rendering in the source text (@rend) and rendering in an output >>>>>>> format (@style). *OR* the addition of @style could be used to >>>>>>> provided the @class/@style functionality of HTML. @rend (like >>>>>>> @class) could refer to predefined style classes, which could be >>>>>>> defined in the <rendition> element of the TEI Header. @style >>>>>>> could be used to embed style information directly in an element. >>>>>>> >>>>>>> If we simply want to distinguish between source rendering and >>>>>>> output rendering with the addition of an @style attribute, then >>>>>>> my task is easy. >>>>>>> >>>>>>> If on the other hand we want to provide the @class/@style >>>>>>> functionality of HTML, the task is more difficult and would >>>>>>> involve prescribing or recommending practice that is not common >>>>>>> at the moment, and would also likely involve changes to the >>>>>>> <rendition> element and perhaps a new element in <encodingDesc> >>>>>>> where folks could explain their implementation. For instance, >>>>>>> users may define their styles using CSS, XSL-FO, rendition >>>>>>> ladders, or some other mechanism, and this will need to be >>>>>>> explained in <encodingDesc>. >>>>>>> >>>>>>> I believe we touched on all these various distinctions in >>>>>>> Berlin, so I would like members of the council to weigh in on >>>>>>> which way to go with this. Please select A. or B. (or a new >>>>>>> letter and proposal of your own invention): >>>>>>> >>>>>>> A. @rend/@style should distinguish between source rendering and >>>>>>> output rendering. >>>>>>> >>>>>>> B. @rend/@style should distinguish between HTML-like @class >>>>>>> functionality and HTML-like @style functionality. >>>>>>> >>>>>>> Incidentally, if we go with B. and style classes are defined in >>>>>>> <rendition> elements of the TEI Header, then we could add an >>>>>>> attribute to <rendition> that indicates whether the "target" of >>>>>>> this rendition "class" is the source text or the output format. >>>>>>> The @style attribute would remain ambiguous in terms of >>>>>>> source/output, but this ambiguity could be addressed and >>>>>>> clarified in the <encodingDesc>. >>>>>>> >>>>>>> Once I hear back from others on the Council, I'll proceed with a >>>>>>> more formal document on this topic. >>>>>>> >>>>>>> John >>>>>>> --| John A. Walsh >>>>>>> | Assistant Professor, School of Library and Information Science >>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> >> >> > > > From jawalsh at indiana.edu Thu May 10 14:31:35 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 14:31:35 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46436214.8020907@pitt.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> <46436214.8020907@pitt.edu> Message-ID: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: > Dear John (cc Lou, Council), > > Are you suggesting that @rend should always be a pointer to a > <rendition> element, or that it should have the option of being > either a pointer or an in-line specification? I think this question is now the major issue we have left to tackle. I would argue that we need to decide one way or another, rather than providing an option. Of course, we need a datatype on @rend, and I don't think there is one that would accomodate both pointers and inline specs. I think people understand the advantages of the pointer system. We end up with a tightly coupled system of <rendtion> elements and @rend pointers, which provides, I think, more accuracy and clarity, but it's a bit more rigid and more complicated. It also breaks a lot of existing practice. With all this feedback, I believe I can write up some useful clarifications for @rend, but do we simply clarify existing usage or propose a more radical change? > > Best, > > David > > John A. Walsh wrote: >> I've been persuaded by David's position and his clear and strong >> distinction between descriptive and procedural/presentation. I'm >> also persuaded that @rend should only refer to description of the >> source material (which may be the TEI document itself in the case of >> born digital material). I still believe though in the benefits of >> changing @rend to be a pointer to one or more <rendition> elements >> which provide a fuller and more formal description of what exactly >> is being described in the source document. >> >> John >> >> Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: >> >>> Dear Lou (cc John, Council), >>> >>> We might want to review the description of @rend in the guidelines to >>> ensure that the TEI recommends that it be used to indicate rendering >>> in the source document, but not to specify output rendering. Since >>> new users will then ask "so how do I specify output rendering?", we >>> might also add a note that output rendering is governed by >>> associations in stylesheets between the descriptive TEI markup and >>> the desired output final form, and that output rendering is not >>> specified in the document instance. If we are feeling ambitious, we >>> can point them to a discussion in the Gentle Introduction of the >>> difference between descriptive and procedural/presentational markup >>> as away of explaining why specifying output rendering in the document >>> instance is a Bad Idea (that is, why the TEI isn't supposed to be a >>> typesetting spec). >>> >>> If we need an example, John and I discussed a specific issue from his >>> projects in private email yesterday, and he's welcome to introduce >>> that into the discussion if he thinks it would be constructive. >>> >>> In other words, I think the current TEI syntax is probably fine, and >>> we just need to make sure that we provide clear advice about the >>> semantics. We may already do that. >>> >>> Best, >>> >>> David >>> >>> Lou's Laptop wrote: >>>> This is both defensible and coherent as TEI policy. What changes are >>>> needed (if any) in P5 to reinforce that position? >>>> >>>> >>>> David J Birnbaum wrote: >>>>> Dear John (cc Council), >>>>> >>>>> In David's Magical World of Descriptive Markup, markup is never >>>>> procedural/presentational and output rendering is governed by >>>>> mapping descriptive markup to rendering details in a stylesheet. If >>>>> I want my code snippets output in a monospaced font, I tag them as >>>>> <code> (or something similar) and in my stylesheet (not my document >>>>> instance) I map the content of <code> elements to a CSS instruction >>>>> to use that font (or FO or some other stylesheet-level >>>>> specification). I never specify "monospaced font" as part of my >>>>> markup of my born-electric source. >>>>> >>>>> Similarly, I can't imagine specifying in my descriptive markup that >>>>> an element should be rendered as "big" in my output document. I >>>>> might specify that it was big in my source document (not the same >>>>> thing, as we've noted), or I might specify that it is important or >>>>> that it is a section heading, but if I want any of these three >>>>> features to produce rendering as big (however I interpret that) in >>>>> the output, it would be because "big in the source document" or >>>>> "important" or "section heading" was mapped to "render this in big >>>>> type" in the stylesheet. >>>>> >>>>> I have no problem with mapping of @rend="big" to a font >>>>> specification in a <rendition> element when this is part of a >>>>> description of the source document. My only objection is to >>>>> specifying output rendering in the document instance. >>>>> >>>>> For what it's worth ... >>>>> >>>>> Best, >>>>> >>>>> David >>>>> >>>>> John A. Walsh wrote: >>>>>> David, >>>>>> >>>>>> I agree about the descriptive vs. presentational issue...but the >>>>>> stylesheets you mention often need triggers in the TEI source, and >>>>>> they @rend attribute is often the trigger one uses. Also, since >>>>>> we have an @rend attribute, it would seem useful to provide a >>>>>> standard mechanism for documenting how that attribute is used and >>>>>> defining the meaning of its content. @rend="big" could mean lots >>>>>> of things, but if it points to <rendition >>>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: >>>>>> bold</rendition>, then one has a clear idea of what @rend="big" >>>>>> means, and this rendition definition may well refer to the source >>>>>> text, not any output format. A stylesheet can still take the >>>>>> "big" trigger and do something else with it. The Guidelines do >>>>>> already state that the content of rendition may be "expressed in >>>>>> running prose, or in some more formal language such as CSS." >>>>>> >>>>>> John >>>>>> -- >>>>>> | John A. Walsh >>>>>> | Assistant Professor, School of Library and Information Science >>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>>> >>>>>> >>>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >>>>>> >>>>>>> Dear John, >>>>>>> >>>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should >>>>>>> be descriptive, rather than presentational. The ability to >>>>>>> specify output rendering is often very important to projects, but >>>>>>> the place to declare it is the stylesheet, not the document >>>>>>> instance. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> David >>>>>>> >>>>>>> John A. Walsh wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm supposed to write up my thoughts on proposed changes to >>>>>>>> <rendition> and @rend, including the possible addition of an >>>>>>>> @style attribute. >>>>>>>> >>>>>>>> The current P5 guidelines state that @rend "indicates how the >>>>>>>> element in question was rendered or presented in the source >>>>>>>> text." But my sense is that in practice @rend is used both to >>>>>>>> indicate how an element was rendered in the source text and/or >>>>>>>> how it should be rendered in a display environment such as a Web >>>>>>>> browser or printed output. >>>>>>>> >>>>>>>> The addition of @style could be used to distinguish between >>>>>>>> rendering in the source text (@rend) and rendering in an output >>>>>>>> format (@style). *OR* the addition of @style could be used to >>>>>>>> provided the @class/@style functionality of HTML. @rend (like >>>>>>>> @class) could refer to predefined style classes, which could be >>>>>>>> defined in the <rendition> element of the TEI Header. @style >>>>>>>> could be used to embed style information directly in an element. >>>>>>>> >>>>>>>> If we simply want to distinguish between source rendering and >>>>>>>> output rendering with the addition of an @style attribute, then >>>>>>>> my task is easy. >>>>>>>> >>>>>>>> If on the other hand we want to provide the @class/@style >>>>>>>> functionality of HTML, the task is more difficult and would >>>>>>>> involve prescribing or recommending practice that is not common >>>>>>>> at the moment, and would also likely involve changes to the >>>>>>>> <rendition> element and perhaps a new element in <encodingDesc> >>>>>>>> where folks could explain their implementation. For instance, >>>>>>>> users may define their styles using CSS, XSL-FO, rendition >>>>>>>> ladders, or some other mechanism, and this will need to be >>>>>>>> explained in <encodingDesc>. >>>>>>>> >>>>>>>> I believe we touched on all these various distinctions in >>>>>>>> Berlin, so I would like members of the council to weigh in on >>>>>>>> which way to go with this. Please select A. or B. (or a new >>>>>>>> letter and proposal of your own invention): >>>>>>>> >>>>>>>> A. @rend/@style should distinguish between source rendering and >>>>>>>> output rendering. >>>>>>>> >>>>>>>> B. @rend/@style should distinguish between HTML-like @class >>>>>>>> functionality and HTML-like @style functionality. >>>>>>>> >>>>>>>> Incidentally, if we go with B. and style classes are defined in >>>>>>>> <rendition> elements of the TEI Header, then we could add an >>>>>>>> attribute to <rendition> that indicates whether the "target" of >>>>>>>> this rendition "class" is the source text or the output format. >>>>>>>> The @style attribute would remain ambiguous in terms of >>>>>>>> source/output, but this ambiguity could be addressed and >>>>>>>> clarified in the <encodingDesc>. >>>>>>>> >>>>>>>> Once I hear back from others on the Council, I'll proceed with a >>>>>>>> more formal document on this topic. >>>>>>>> >>>>>>>> John >>>>>>>> --| John A. Walsh >>>>>>>> | Assistant Professor, School of Library and Information Science >>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> tei-council mailing list >>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>> >>> >>> >> >> >> > > From djbpitt+tei at pitt.edu Thu May 10 14:36:45 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Thu, 10 May 2007 14:36:45 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> <46436214.8020907@pitt.edu> <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> Message-ID: <4643663D.1070509@pitt.edu> Dear John (cc Council), For what it's worth, my instinct is to support only the pointer. As you note, it provides greater accuracy and clarity (much harder to have rendition values of "ital" and "i" with the same semantics in the same document if you've grouped <rendition> elements in one place), it can do everything that the inline spec can do and then some, giving a choice would just complicate processing and reduce interoperability, and if we're going to break existing practice, P5 is the time to do it. Best, David John A. Walsh wrote: > Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: > >> Dear John (cc Lou, Council), >> >> Are you suggesting that @rend should always be a pointer to a >> <rendition> element, or that it should have the option of being >> either a pointer or an in-line specification? > > I think this question is now the major issue we have left to tackle. > I would argue that we need to decide one way or another, rather than > providing an option. Of course, we need a datatype on @rend, and I > don't think there is one that would accomodate both pointers and > inline specs. I think people understand the advantages of the pointer > system. We end up with a tightly coupled system of <rendtion> > elements and @rend pointers, which provides, I think, more accuracy > and clarity, but it's a bit more rigid and more complicated. It also > breaks a lot of existing practice. > > With all this feedback, I believe I can write up some useful > clarifications for @rend, but do we simply clarify existing usage or > propose a more radical change? > >> >> Best, >> >> David >> >> John A. Walsh wrote: >>> I've been persuaded by David's position and his clear and strong >>> distinction between descriptive and procedural/presentation. I'm >>> also persuaded that @rend should only refer to description of the >>> source material (which may be the TEI document itself in the case of >>> born digital material). I still believe though in the benefits of >>> changing @rend to be a pointer to one or more <rendition> elements >>> which provide a fuller and more formal description of what exactly >>> is being described in the source document. >>> >>> John >>> >>> Quoting David J Birnbaum <djbpitt+tei at pitt.edu>: >>> >>>> Dear Lou (cc John, Council), >>>> >>>> We might want to review the description of @rend in the guidelines to >>>> ensure that the TEI recommends that it be used to indicate rendering >>>> in the source document, but not to specify output rendering. Since >>>> new users will then ask "so how do I specify output rendering?", we >>>> might also add a note that output rendering is governed by >>>> associations in stylesheets between the descriptive TEI markup and >>>> the desired output final form, and that output rendering is not >>>> specified in the document instance. If we are feeling ambitious, we >>>> can point them to a discussion in the Gentle Introduction of the >>>> difference between descriptive and procedural/presentational markup >>>> as away of explaining why specifying output rendering in the document >>>> instance is a Bad Idea (that is, why the TEI isn't supposed to be a >>>> typesetting spec). >>>> >>>> If we need an example, John and I discussed a specific issue from his >>>> projects in private email yesterday, and he's welcome to introduce >>>> that into the discussion if he thinks it would be constructive. >>>> >>>> In other words, I think the current TEI syntax is probably fine, and >>>> we just need to make sure that we provide clear advice about the >>>> semantics. We may already do that. >>>> >>>> Best, >>>> >>>> David >>>> >>>> Lou's Laptop wrote: >>>>> This is both defensible and coherent as TEI policy. What changes are >>>>> needed (if any) in P5 to reinforce that position? >>>>> >>>>> >>>>> David J Birnbaum wrote: >>>>>> Dear John (cc Council), >>>>>> >>>>>> In David's Magical World of Descriptive Markup, markup is never >>>>>> procedural/presentational and output rendering is governed by >>>>>> mapping descriptive markup to rendering details in a stylesheet. If >>>>>> I want my code snippets output in a monospaced font, I tag them as >>>>>> <code> (or something similar) and in my stylesheet (not my document >>>>>> instance) I map the content of <code> elements to a CSS instruction >>>>>> to use that font (or FO or some other stylesheet-level >>>>>> specification). I never specify "monospaced font" as part of my >>>>>> markup of my born-electric source. >>>>>> >>>>>> Similarly, I can't imagine specifying in my descriptive markup that >>>>>> an element should be rendered as "big" in my output document. I >>>>>> might specify that it was big in my source document (not the same >>>>>> thing, as we've noted), or I might specify that it is important or >>>>>> that it is a section heading, but if I want any of these three >>>>>> features to produce rendering as big (however I interpret that) in >>>>>> the output, it would be because "big in the source document" or >>>>>> "important" or "section heading" was mapped to "render this in big >>>>>> type" in the stylesheet. >>>>>> >>>>>> I have no problem with mapping of @rend="big" to a font >>>>>> specification in a <rendition> element when this is part of a >>>>>> description of the source document. My only objection is to >>>>>> specifying output rendering in the document instance. >>>>>> >>>>>> For what it's worth ... >>>>>> >>>>>> Best, >>>>>> >>>>>> David >>>>>> >>>>>> John A. Walsh wrote: >>>>>>> David, >>>>>>> >>>>>>> I agree about the descriptive vs. presentational issue...but the >>>>>>> stylesheets you mention often need triggers in the TEI source, and >>>>>>> they @rend attribute is often the trigger one uses. Also, since >>>>>>> we have an @rend attribute, it would seem useful to provide a >>>>>>> standard mechanism for documenting how that attribute is used and >>>>>>> defining the meaning of its content. @rend="big" could mean lots >>>>>>> of things, but if it points to <rendition >>>>>>> xml:id="big">font-family: Granjon; font-size: 16pt; font-weight: >>>>>>> bold</rendition>, then one has a clear idea of what @rend="big" >>>>>>> means, and this rendition definition may well refer to the source >>>>>>> text, not any output format. A stylesheet can still take the >>>>>>> "big" trigger and do something else with it. The Guidelines do >>>>>>> already state that the content of rendition may be "expressed in >>>>>>> running prose, or in some more formal language such as CSS." >>>>>>> >>>>>>> John >>>>>>> -- >>>>>>> | John A. Walsh >>>>>>> | Assistant Professor, School of Library and Information Science >>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 >>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> >>>>>>> >>>>>>> >>>>>>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote: >>>>>>> >>>>>>>> Dear John, >>>>>>>> >>>>>>>> Option C, please. XML isn't Microsoft Word and TEI markup should >>>>>>>> be descriptive, rather than presentational. The ability to >>>>>>>> specify output rendering is often very important to projects, but >>>>>>>> the place to declare it is the stylesheet, not the document >>>>>>>> instance. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> John A. Walsh wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm supposed to write up my thoughts on proposed changes to >>>>>>>>> <rendition> and @rend, including the possible addition of an >>>>>>>>> @style attribute. >>>>>>>>> >>>>>>>>> The current P5 guidelines state that @rend "indicates how the >>>>>>>>> element in question was rendered or presented in the source >>>>>>>>> text." But my sense is that in practice @rend is used both to >>>>>>>>> indicate how an element was rendered in the source text and/or >>>>>>>>> how it should be rendered in a display environment such as a Web >>>>>>>>> browser or printed output. >>>>>>>>> >>>>>>>>> The addition of @style could be used to distinguish between >>>>>>>>> rendering in the source text (@rend) and rendering in an output >>>>>>>>> format (@style). *OR* the addition of @style could be used to >>>>>>>>> provided the @class/@style functionality of HTML. @rend (like >>>>>>>>> @class) could refer to predefined style classes, which could be >>>>>>>>> defined in the <rendition> element of the TEI Header. @style >>>>>>>>> could be used to embed style information directly in an element. >>>>>>>>> >>>>>>>>> If we simply want to distinguish between source rendering and >>>>>>>>> output rendering with the addition of an @style attribute, then >>>>>>>>> my task is easy. >>>>>>>>> >>>>>>>>> If on the other hand we want to provide the @class/@style >>>>>>>>> functionality of HTML, the task is more difficult and would >>>>>>>>> involve prescribing or recommending practice that is not common >>>>>>>>> at the moment, and would also likely involve changes to the >>>>>>>>> <rendition> element and perhaps a new element in <encodingDesc> >>>>>>>>> where folks could explain their implementation. For instance, >>>>>>>>> users may define their styles using CSS, XSL-FO, rendition >>>>>>>>> ladders, or some other mechanism, and this will need to be >>>>>>>>> explained in <encodingDesc>. >>>>>>>>> >>>>>>>>> I believe we touched on all these various distinctions in >>>>>>>>> Berlin, so I would like members of the council to weigh in on >>>>>>>>> which way to go with this. Please select A. or B. (or a new >>>>>>>>> letter and proposal of your own invention): >>>>>>>>> >>>>>>>>> A. @rend/@style should distinguish between source rendering and >>>>>>>>> output rendering. >>>>>>>>> >>>>>>>>> B. @rend/@style should distinguish between HTML-like @class >>>>>>>>> functionality and HTML-like @style functionality. >>>>>>>>> >>>>>>>>> Incidentally, if we go with B. and style classes are defined in >>>>>>>>> <rendition> elements of the TEI Header, then we could add an >>>>>>>>> attribute to <rendition> that indicates whether the "target" of >>>>>>>>> this rendition "class" is the source text or the output format. >>>>>>>>> The @style attribute would remain ambiguous in terms of >>>>>>>>> source/output, but this ambiguity could be addressed and >>>>>>>>> clarified in the <encodingDesc>. >>>>>>>>> >>>>>>>>> Once I hear back from others on the Council, I'll proceed with a >>>>>>>>> more formal document on this topic. >>>>>>>>> >>>>>>>>> John >>>>>>>>> --| John A. Walsh >>>>>>>>> | Assistant Professor, School of Library and Information Science >>>>>>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN >>>>>>>>> 47405 >>>>>>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/> >>>>>>>>> | Voice:812-856-0707 Fax:812-856-2062 >>>>>>>>> <mailto:jawalsh at indiana.edu> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> tei-council mailing list >>>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 14:59:02 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 19:59:02 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <20070510140013.isyfrzgt4ccw8404@webmail.iu.edu> <46436214.8020907@pitt.edu> <20070510143135.7xjqdzu04kko0kg8@webmail.iu.edu> Message-ID: <46436B76.1060901@oucs.ox.ac.uk> Switching to rend="#italic" is quite attractive, especially as it can refer to a common set of <rendition> elements, eg rend="mymasterdocument.xml#italic". This matters, cos if I write 3000 small web pages in TEI XML, I don't want each one to have a <rendition> section. HOWEVER, the overhead of rend="document.xml#italic" over rend="italic" is pretty big, with lots of scope for error. Using pointers would break every processor of TEI documents, but in an understandable way; I could cope with that, after swallowing hard, but I fear the Goblin Rebellions might seem like a picnic when we announce this. John, maybe you could lead some discussion on TEI-L? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 15:01:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 20:01:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1178817752.19411.4.camel@caedmon> References: <464331C3.8040102@oucs.ox.ac.uk> <1178817752.19411.4.camel@caedmon> Message-ID: <46436BF0.1030304@oucs.ox.ac.uk> Daniel O'Donnell wrote: >> So, to # or not to #? >> > > # always means equivalent to xml:id? > if its #foo, it means that there is expected to be a corresponding object with an ID of "foo", yes. It could also be "http://www.example.com/tei.xml#foo", of course. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Thu May 10 15:07:45 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 10 May 2007 20:07:45 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46434FF7.4020107@kcl.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> Message-ID: <46436D81.4020102@oucs.ox.ac.uk> Arianna Ciula wrote: > > As far as born digital material regard though, I can imagine the > situation where someone wants to differentiate the semantics (not big > or small, but myIntrepret_category1 and myIntrepret_category2) of the > information so that some style could be applied - possibly - later on. surely they'll use other data containers for semantics? such as the "type" attribute? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From jawalsh at indiana.edu Thu May 10 18:05:58 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Thu, 10 May 2007 18:05:58 -0400 Subject: Fwd: [tei-council] rendition, rend, and style References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> Message-ID: <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> On May 10, 2007, at 2:59 PM, Sebastian Rahtz wrote: > Switching to rend="#italic" is quite attractive, especially > as it can refer to a common set of <rendition> elements, > eg rend="mymasterdocument.xml#italic". This matters, > cos if I write 3000 small web pages in TEI XML, I don't > want each one to have a <rendition> section. HOWEVER, > the overhead of rend="document.xml#italic" over > rend="italic" is pretty big, with lots of scope for error. Sebastian, you raise a good point. My current solution to this problem is a common set of <rendition> elements that I include in all my documents using XInclude. Perhaps this is obvious, but I think that if we go this direction, rend should clearly provide pionters (plural) rather than a single pointer, thus allowing rend="#bold #italic" and avoiding inane things like rend="#bold_italic_underline". > > Using pointers would break every processor of TEI documents, > but in an understandable way; I could cope with that, > after swallowing hard, but I fear the Goblin Rebellions > might seem like a picnic when we announce this. > > John, maybe you could lead some discussion on TEI-L? TEI-L discussion is another good suggestion. I'll do this. John > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > From daniel.odonnell at uleth.ca Thu May 10 18:27:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Thu, 10 May 2007 16:27:33 -0600 Subject: [tei-council] Finishing off our easter eggs Message-ID: <1178836053.11190.14.camel@caedmon> Hi all, I've just finished add my detailed notes--i.e. the ones that weren't raised in the meeting--to my easter eggs in trac. My question is what to do with them now. I reassigned them to "eds" as a temporary device to indicate that I'd finished with them, but I was wondering what I should do with them. Most of the notes are identification of loci and suggestions for editorial interventions rather than corrections. -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From arianna.ciula at kcl.ac.uk Fri May 11 04:56:00 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 09:56:00 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46436D81.4020102@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> <46436D81.4020102@oucs.ox.ac.uk> Message-ID: <46442FA0.9010404@kcl.ac.uk> Sebastian Rahtz wrote: > Arianna Ciula wrote: >> >> As far as born digital material regard though, I can imagine the >> situation where someone wants to differentiate the semantics (not big >> or small, but myIntrepret_category1 and myIntrepret_category2) of the >> information so that some style could be applied - possibly - later on. > surely they'll use other data containers for semantics? such as the > "type" attribute? Sure. What I meant was interpretative categories related to the rendition of the document but at the same time not as procedural as 'italic bold'. So for instance if I have two different tables and they both contain images of text, my @type could be used to specify the type of text they contain (e.g. images of different scribal abbreviations vs. images of different scribal headings), while my @rend could be used to say that both tables contain images of text and therefore have different rendition from those that contain other type of images. Arianna > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Fri May 11 04:59:31 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 11 May 2007 09:59:31 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46442FA0.9010404@kcl.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> <46436D81.4020102@oucs.ox.ac.uk> <46442FA0.9010404@kcl.ac.uk> Message-ID: <46443073.70801@oucs.ox.ac.uk> Arianna Ciula wrote: > > So for instance if I have two different tables and they both contain > images of text, my @type could be used to specify the type of text > they contain (e.g. images of different scribal abbreviations vs. > images of different scribal headings), while my @rend could be used to > say that both tables contain images of text and therefore have > different rendition from those that contain other type of images. > multiple values for the @type attribute? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Fri May 11 04:59:50 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 09:59:50 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <20070510135255.64gyni6d8gso4kkc@webmail.iu.edu> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> <20070510135255.64gyni6d8gso4kkc@webmail.iu.edu> Message-ID: <46443086.8090008@kcl.ac.uk> John A. Walsh wrote: > The practice of pointing @rend to <rendition> is not just for born > digital material. I think CSS (or XSL-FO) properties such as > font-family, font-size, font-weight, text-indent, etc. can be used to > describe accurately and precisely the appearance of a source document, > at least for printed source documents, though many properties can also > be useful in the description of manuscript documents. Good point. I don't want to seem against this. As I said, I think the precision of the encoding would only gain. The issue is, as always, the balance between the precision of a good practice and the flexible tolerance of the single user's practices. We will see what the TEI-L has to say. Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Fri May 11 05:05:33 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 10:05:33 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <46443073.70801@oucs.ox.ac.uk> References: <3C924F99-791E-4276-A516-9E1EDE8E3FA2@indiana.edu> <4641B808.5000600@pitt.edu> <C2A11665-FAF1-4954-9110-5AAD910F9A6D@indiana.edu> <46425070.3070004@pitt.edu> <46432100.2060404@computing-services.oxford.ac.uk> <46432862.9010907@pitt.edu> <46432AA7.5000002@oucs.ox.ac.uk> <46432E08.5040408@computing-services.oxford.ac.uk> <46434FF7.4020107@kcl.ac.uk> <46436D81.4020102@oucs.ox.ac.uk> <46442FA0.9010404@kcl.ac.uk> <46443073.70801@oucs.ox.ac.uk> Message-ID: <464431DD.4030301@kcl.ac.uk> Sebastian Rahtz wrote: > Arianna Ciula wrote: >> >> So for instance if I have two different tables and they both contain >> images of text, my @type could be used to specify the type of text >> they contain (e.g. images of different scribal abbreviations vs. >> images of different scribal headings), while my @rend could be used to >> say that both tables contain images of text and therefore have >> different rendition from those that contain other type of images. >> > multiple values for the @type attribute? could do, but could also use @rend since its purpose it to represent the rendition of the source. > > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From jawalsh at indiana.edu Fri May 11 07:01:05 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Fri, 11 May 2007 07:01:05 -0400 Subject: [tei-council] More on rend Message-ID: <30F3DAD4-067A-456E-A77E-029DB1101799@indiana.edu> Hi all, Yesterday David mentioned a private exchange we had about a specific example of rend usage. The example is somewhat analogous to the interpretive categories issue we discussed yesterday and provides further amplification to David's thoughtful commentary on the issue of descriptive vs. presentation/procedural markup. The exchange is less relevant to the specific discussion of rend as pointer to <rendition>, so I don't want the message to confuse that issue, but here it is for your enjoyment: > From: djbpitt+tei at pitt.edu > Subject: Re: [tei-council] rendition, rend, and style > Date: May 9, 2007 10:31:45 PM EDT > To: jawalsh at indiana.edu > Reply-To: djbpitt+tei at pitt.edu > > Dear John, > >> I'm wanting to succumb to the rigorous purity of your descriptive >> vs. presentational distinction, but find I've perhaps irrevocably >> polluted my own personal encoding practice. >> > > The purity of which you speak is a hypothesis I am continually > testing, but so far I haven't run into trouble. When I really need > to focus on a specific output format, I use Word or PowerPoint or > presentationally-oriented HTML. When I want to focus on structure, > I use XML with descriptive markup and impose presentational > features during XSLT transformation. So far I've been able to > maintain my principles and get the results I need. > > [By the way, concerning purity and principles more generally, I may > have mentioned that one of the first papers I ever delivered at an > SGML conference was entitled "In Defense of Invalid SGML," where I > told several hundred people who write massive electronic > documentation files for government and industry why it might be > desirable to produce SGML that failed validation. I got a laugh > when I said "I'm an academic; I don't have to build working > systems," but the paper was serious, and I hope I dealt seriously > with the consequences. (If you're curious, the paper, with a less > polemical title, is at http://clover.slavic.pitt.edu/~djb/sgml/ > invalid.html .)] > > In any case ... > > >> Here's an example. My documents are full of <persName> elements. >> In some cases, I want the <persName> element "rendered" as (or >> with) a mouseover gloss that describes a potentially unfamiliar >> person. So <persName key="bill">William Shakespeare</persName> >> may not need a gloss, but <persName key="villon">Fran?ois Villon</ >> persName> may indeed need a gloss. I've done something like this, >> <persName rend="gloss" key="villon">Fra?ois Villon</persName>. >> What other semantics (other than @rend) are available to me to >> make the distinction between names needing a gloss? Perhaps my >> person database could contain a field indicating whether the >> person requires a gloss. But I may be using the same database for >> multiple projects and multiple source documents, and the need for >> a gloss may not be consistent across all these projects/documents. >> > > I like the syntax of your solution, but I would approach the > semantics differently. Instead of @rend="gloss" I would have > something like @unfamiliar="yes". The descriptive fact is that the > name is unfamiliar, and the way you deal with it in one view is to > provide a mouseover gloss. You might, in an alternative view, > render all of the unfamiliar names in a different color and ask > your students to identify them for a test, and in that view you > wouldn't be glossing them at all. Or you might collect a list of > unfamiliar names as an appendix for scholars or a study guide for > students, with or without glosses. In other words, the > unfamiliarity is the descriptive fact, and the glossing an artifact > of a particular view. Both of our approaches tag the unfamiliar > names, but mine separates the fact that they are unfamiliar (and > therefore might need special treatment, with the exact special > treatment subject to variation) from the way they are rendered in a > particular view / application / environment. > > Another approach might be assemble the information about who gets > glossed for a particular project not in your general database of > persons (since the need for glossing may vary from project to > project) and not in the <persName> elements in the document > instance, but in a separate structure in the header in the document > instance, one that listed the names that should be considered > unfamiliar within the context of that instance. This has the added > advantage of letting you indicate once in the header that every > occurence of Fran??ois Villon should be considered unfamiliar in a > particular document without having to add the @rend element each > time the name occurs. > > >> Without taking up too much more of your time, could you offer some >> advice on this particular case? It's something I've been >> wrestling with, and I would value your input. >> > > I'm happy to spend time this way. And, unlike with my invalid SGML > presentation, I think the approaches described above should be able > to maintain markup that is rigorously descriptive while also > providing a working system that affords the functionality needed > for the projects you describe. > > Does this help? > > Cheers, > > David -- | John A. Walsh | Assistant Professor, School of Library and Information Science | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 | www: <http://www.slis.indiana.edu/faculty/jawalsh/> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> From daniel.odonnell at uleth.ca Fri May 11 12:13:21 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 11 May 2007 10:13:21 -0600 Subject: [tei-council] Venues for distributing MM posters? Message-ID: <1178900001.31143.32.camel@caedmon> Hi all, I have a question for the whole band of plugged in people: Susan Schreibman, who is organising this fall's members meeting/markup conference, has a poster ready that she'd like to distribute at conferences of relevant organisations over the course of the summer. What conferences/meetings would you suggest? She is going to get them into DH and DRHA. Any other suggestions? -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Fri May 11 12:15:00 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 11 May 2007 10:15:00 -0600 Subject: [tei-council] More on rend In-Reply-To: <30F3DAD4-067A-456E-A77E-029DB1101799@indiana.edu> References: <30F3DAD4-067A-456E-A77E-029DB1101799@indiana.edu> Message-ID: <1178900100.31143.34.camel@caedmon> I think if there has been a trend throughout our P5 council discussions it has been towards purity. So I'm happy with how things are going. On Fri, 2007-05-11 at 07:01 -0400, John A. Walsh wrote: > Hi all, > > Yesterday David mentioned a private exchange we had about a specific > example of rend usage. The example is somewhat analogous to the > interpretive categories issue we discussed yesterday and provides > further amplification to David's thoughtful commentary on the issue > of descriptive vs. presentation/procedural markup. The exchange is > less relevant to the specific discussion of rend as pointer to > <rendition>, so I don't want the message to confuse that issue, but > here it is for your enjoyment: > > > From: djbpitt+tei at pitt.edu > > Subject: Re: [tei-council] rendition, rend, and style > > Date: May 9, 2007 10:31:45 PM EDT > > To: jawalsh at indiana.edu > > Reply-To: djbpitt+tei at pitt.edu > > > > Dear John, > > > >> I'm wanting to succumb to the rigorous purity of your descriptive > >> vs. presentational distinction, but find I've perhaps irrevocably > >> polluted my own personal encoding practice. > >> > > > > The purity of which you speak is a hypothesis I am continually > > testing, but so far I haven't run into trouble. When I really need > > to focus on a specific output format, I use Word or PowerPoint or > > presentationally-oriented HTML. When I want to focus on structure, > > I use XML with descriptive markup and impose presentational > > features during XSLT transformation. So far I've been able to > > maintain my principles and get the results I need. > > > > [By the way, concerning purity and principles more generally, I may > > have mentioned that one of the first papers I ever delivered at an > > SGML conference was entitled "In Defense of Invalid SGML," where I > > told several hundred people who write massive electronic > > documentation files for government and industry why it might be > > desirable to produce SGML that failed validation. I got a laugh > > when I said "I'm an academic; I don't have to build working > > systems," but the paper was serious, and I hope I dealt seriously > > with the consequences. (If you're curious, the paper, with a less > > polemical title, is at http://clover.slavic.pitt.edu/~djb/sgml/ > > invalid.html .)] > > > > In any case ... > > > > > >> Here's an example. My documents are full of <persName> elements. > >> In some cases, I want the <persName> element "rendered" as (or > >> with) a mouseover gloss that describes a potentially unfamiliar > >> person. So <persName key="bill">William Shakespeare</persName> > >> may not need a gloss, but <persName key="villon">Fran?ois Villon</ > >> persName> may indeed need a gloss. I've done something like this, > >> <persName rend="gloss" key="villon">Fra?ois Villon</persName>. > >> What other semantics (other than @rend) are available to me to > >> make the distinction between names needing a gloss? Perhaps my > >> person database could contain a field indicating whether the > >> person requires a gloss. But I may be using the same database for > >> multiple projects and multiple source documents, and the need for > >> a gloss may not be consistent across all these projects/documents. > >> > > > > I like the syntax of your solution, but I would approach the > > semantics differently. Instead of @rend="gloss" I would have > > something like @unfamiliar="yes". The descriptive fact is that the > > name is unfamiliar, and the way you deal with it in one view is to > > provide a mouseover gloss. You might, in an alternative view, > > render all of the unfamiliar names in a different color and ask > > your students to identify them for a test, and in that view you > > wouldn't be glossing them at all. Or you might collect a list of > > unfamiliar names as an appendix for scholars or a study guide for > > students, with or without glosses. In other words, the > > unfamiliarity is the descriptive fact, and the glossing an artifact > > of a particular view. Both of our approaches tag the unfamiliar > > names, but mine separates the fact that they are unfamiliar (and > > therefore might need special treatment, with the exact special > > treatment subject to variation) from the way they are rendered in a > > particular view / application / environment. > > > > Another approach might be assemble the information about who gets > > glossed for a particular project not in your general database of > > persons (since the need for glossing may vary from project to > > project) and not in the <persName> elements in the document > > instance, but in a separate structure in the header in the document > > instance, one that listed the names that should be considered > > unfamiliar within the context of that instance. This has the added > > advantage of letting you indicate once in the header that every > > occurence of Fran??ois Villon should be considered unfamiliar in a > > particular document without having to add the @rend element each > > time the name occurs. > > > > > >> Without taking up too much more of your time, could you offer some > >> advice on this particular case? It's something I've been > >> wrestling with, and I would value your input. > >> > > > > I'm happy to spend time this way. And, unlike with my invalid SGML > > presentation, I think the approaches described above should be able > > to maintain markup that is rigorously descriptive while also > > providing a working system that affords the functionality needed > > for the projects you describe. > > > > Does this help? > > > > Cheers, > > > > David > > > > > -- > | John A. Walsh > | Assistant Professor, School of Library and Information Science > | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405 > | www: <http://www.slis.indiana.edu/faculty/jawalsh/> > | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu> > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From arianna.ciula at kcl.ac.uk Fri May 11 12:45:32 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Fri, 11 May 2007 17:45:32 +0100 Subject: [tei-council] Venues for distributing MM posters? In-Reply-To: <1178900001.31143.32.camel@caedmon> References: <1178900001.31143.32.camel@caedmon> Message-ID: <46449DAC.60504@kcl.ac.uk> May be: DIGIMED workshop Paris (June, Ecole des Chartes) DIGIMED Arezzo (September) IMC Kalamazoo (May) IMC Leeds (July) Arianna Daniel O'Donnell wrote: > Hi all, > > I have a question for the whole band of plugged in people: Susan > Schreibman, who is organising this fall's members meeting/markup > conference, has a poster ready that she'd like to distribute at > conferences of relevant organisations over the course of the summer. > > What conferences/meetings would you suggest? She is going to get them > into DH and DRHA. Any other suggestions? > > -dan -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From dporter at uky.edu Sat May 12 10:42:16 2007 From: dporter at uky.edu (Dot Porter) Date: Sat, 12 May 2007 10:42:16 -0400 Subject: [tei-council] Venues for distributing MM posters? In-Reply-To: <46449DAC.60504@kcl.ac.uk> References: <1178900001.31143.32.camel@caedmon> <46449DAC.60504@kcl.ac.uk> Message-ID: <96f3df640705120742y26fdb5b7qec555a74de32a16@mail.gmail.com> Kalamazoo is happening right now, so too late for that, though I have been spreading the word to anyone I meet here who is in the eastern US (including folks from UVA and at the JHU Roman de la Rose project). James and I (at least - probably others too) will both be at Leeds so we can take posters there, if Susan could provide them for us. Thanks, Susan and Dan! Dot On 5/11/07, Arianna Ciula <arianna.ciula at kcl.ac.uk> wrote: > May be: > > DIGIMED workshop Paris (June, Ecole des Chartes) > DIGIMED Arezzo (September) > IMC Kalamazoo (May) > IMC Leeds (July) > > Arianna > > Daniel O'Donnell wrote: > > Hi all, > > > > I have a question for the whole band of plugged in people: Susan > > Schreibman, who is organising this fall's members meeting/markup > > conference, has a poster ready that she'd like to distribute at > > conferences of relevant organisations over the course of the summer. > > > > What conferences/meetings would you suggest? She is going to get them > > into DH and DRHA. Any other suggestions? > > > > -dan > > -- > Dr Arianna Ciula > Research Associate > Centre for Computing in the Humanities > King's College London > Strand > London WC2R 2LS (UK) > Tel: +44 (0)20 78481945 > http://www.kcl.ac.uk/cch > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From James.Cummings at oucs.ox.ac.uk Tue May 15 15:17:48 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 15 May 2007 15:17:48 -0400 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> Message-ID: <464A075C.2080707@oucs.ox.ac.uk> Hi, I've been away (still am), and have just now been wading through the discussion on @rend. My thoughts so far are: - @rend should only refer to the rendition in the original source - @rend shouldn't be used to indicate output style (something else trapped in the xslt should, but I think I basically agree with David on purity of descriptive markup) - @rend should be a datatype of one or more data.pointer which the Guidelines prose states should ideally be pointing to one or more <rendition> elements in the header of this or another document. This should help create internal document consistency. - I'd be tempted to do @rend="#bigFunnyLooking5" and then have a <ptr/> inside <rendition xml:id="bigFunnyLooking5"> to point to an external source for rendition information kept elsewhere. (rather than have @rend="http://www.example.com/foo/renditions.xml#bigFunnyLooking5" on various <hi> elements. John's XIncluding is another solution. - Importing @html:style is a use of namespaces I've been fearing -- I know people are going to do it, but I personally prefer to have little or no output style information in my TEI documents if possible. But, since people are going to do it anyway, maybe the Guidelines should mention it. - Importing @html:class isn't as necessary I think. In most cases where I would want to do this the elements already have @tei:type which is more specific in terms of its semantics. (It applying to the type of that element, rather than a generalistic class regardless of element.) I'd catch @tei:type in my xslt and provide style information there (or load it in from elsewhere), or base it on structure. I'm sure I've missed or misunderstood some of the issues, but I've been ploughing through all the messages while on holiday ;-) -James John A. Walsh wrote: > On May 10, 2007, at 2:59 PM, Sebastian Rahtz wrote: > >> Switching to rend="#italic" is quite attractive, especially >> as it can refer to a common set of <rendition> elements, >> eg rend="mymasterdocument.xml#italic". This matters, >> cos if I write 3000 small web pages in TEI XML, I don't >> want each one to have a <rendition> section. HOWEVER, >> the overhead of rend="document.xml#italic" over >> rend="italic" is pretty big, with lots of scope for error. > > Sebastian, you raise a good point. My current solution to this problem > is a common set of <rendition> elements that I include in all my > documents using XInclude. > Perhaps this is obvious, but I think that if we go this direction, rend > should clearly provide pionters (plural) rather than a single pointer, > thus allowing rend="#bold #italic" and avoiding inane things like > rend="#bold_italic_underline". > >> >> Using pointers would break every processor of TEI documents, >> but in an understandable way; I could cope with that, >> after swallowing hard, but I fear the Goblin Rebellions >> might seem like a picnic when we announce this. >> >> John, maybe you could lead some discussion on TEI-L? > > TEI-L discussion is another good suggestion. I'll do this. > > John >> >> --Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 05:37:19 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 10:37:19 +0100 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <464A075C.2080707@oucs.ox.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> Message-ID: <464AD0CF.5060901@oucs.ox.ac.uk> James Cummings wrote: > > - I'd be tempted to do @rend="#bigFunnyLooking5" and then have a > <ptr/> inside <rendition xml:id="bigFunnyLooking5"> to point to an > external source for rendition information kept elsewhere. (rather than > have > @rend="http://www.example.com/foo/renditions.xml#bigFunnyLooking5" on > various <hi> elements. John's XIncluding is another solution. You can make it a little easier by going via <rendition>, but it does not obviate the need to maintain a great gross wodge of identical material in the header of every document. Using XInclude works, of course, but it still seems to bloat things. Those XIncludes will keep on getting expanded. if you want consistency across docs, avoiding rend="italic vs rend="it", then put fixed value lists on the rend attribute in your schema. that answers most of the practical criticisms of @rend as it stands, surely? its actually _better_ that pointers, because it is validated, and prompts you during editing. Due to the wonders of ODD, you can provide different value lists for each element if you want. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From cwittern at gmail.com Wed May 16 07:44:18 2007 From: cwittern at gmail.com (Christian Wittern) Date: Wed, 16 May 2007 20:44:18 +0900 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <464AD0CF.5060901@oucs.ox.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> Message-ID: <5268d87d0705160444r7e696ffey9770b1f01e9d0cfd@mail.gmail.com> On 16/05/07, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote: > James Cummings wrote: > if you want consistency across docs, avoiding rend="italic vs > rend="it", then > put fixed value lists on the rend attribute in your schema. that answers > most > of the practical criticisms of @rend as it stands, surely? its actually > _better_ > that pointers, because it is validated, and prompts you during editing. > Due to the wonders of ODD, you can provide different value lists for > each element if you want. But this will prevent you from getting the highest grades in Conformance-School, right? Christian -- Christian Wittern, Kyoto From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 07:53:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 12:53:43 +0100 Subject: Fwd: [tei-council] rendition, rend, and style In-Reply-To: <5268d87d0705160444r7e696ffey9770b1f01e9d0cfd@mail.gmail.com> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <5268d87d0705160444r7e696ffey9770b1f01e9d0cfd@mail.gmail.com> Message-ID: <464AF0C7.1070505@oucs.ox.ac.uk> Christian Wittern wrote: > > But this will prevent you from getting the highest grades in > Conformance-School, right? > not all. its a clean modification, subsetting the TEI. you get full marks. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From jawalsh at indiana.edu Wed May 16 08:12:13 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 16 May 2007 08:12:13 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464AD0CF.5060901@oucs.ox.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> Message-ID: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> On May 16, 2007, at 5:37 AM, Sebastian Rahtz wrote: > if you want consistency across docs, avoiding rend="italic vs > rend="it", then > put fixed value lists on the rend attribute in your schema. that > answers most > of the practical criticisms of @rend as it stands, surely? its > actually _better_ > that pointers, because it is validated, and prompts you during > editing. > Due to the wonders of ODD, you can provide different value lists for > each element if you want. The problem is with a fixed value list is that you can't combine rendition styles. With the pointers (note the plural) method, I can have <rendition> elements defining italic, bold, underline, and center styles. If my source includes an element that is all of these, I can do rend="#i #b #u #center". With the fixed value list, I'd have to have an unwieldy number of values to accommodate all the combinations. John From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 08:53:22 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 13:53:22 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> Message-ID: <464AFEC2.9040304@oucs.ox.ac.uk> John A. Walsh wrote: > > The problem is with a fixed value list is that you can't combine > rendition styles. With the pointers (note the plural) method, I can > have <rendition> elements defining italic, bold, underline, and center > styles. If my source includes an element that is all of these, I can > do rend="#i #b #u #center". With the fixed value list, I'd have to > have an unwieldy number of values to accommodate all the combinations. > but the datatype of rend is "multiple tokens"[1], so you can say rend="a b c" and each of a, b and c will be checked against the list. honest. [1] <datatype maxOccurs="unbounded"> <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.word"/> </datatype> -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From jawalsh at indiana.edu Wed May 16 09:14:11 2007 From: jawalsh at indiana.edu (John A. Walsh) Date: Wed, 16 May 2007 09:14:11 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464AFEC2.9040304@oucs.ox.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> <464AFEC2.9040304@oucs.ox.ac.uk> Message-ID: <A25EA971-3FC4-44D1-9B23-F2251EC40FC8@indiana.edu> On May 16, 2007, at 8:53 AM, Sebastian Rahtz wrote: > John A. Walsh wrote: >> >> The problem is with a fixed value list is that you can't combine >> rendition styles. With the pointers (note the plural) method, I >> can have <rendition> elements defining italic, bold, underline, >> and center styles. If my source includes an element that is all >> of these, I can do rend="#i #b #u #center". With the fixed value >> list, I'd have to have an unwieldy number of values to accommodate >> all the combinations. >> > but the datatype of rend is "multiple tokens"[1], so you can say > rend="a b c" and each of a, b and > c will be checked against the list. honest. > > > [1] <datatype maxOccurs="unbounded"> > <rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" > name="data.word"/> > </datatype> > Thanks for the clarification, Sebastian. I guess I was still thinking in terms of the more limited enumerated lists in DTDs which only allow one value. The value list approach provides better validation but still does not provide the benefit of linking to explicit and formally defined styles in the <rendition> element in the header, but I'm probably beating a horse (whether it's a dead horse or not remains to be seen :-). John From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:07:49 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:07:49 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <EE478735-6CF8-47F9-99C6-74B6B2BF71DE@indiana.edu> Message-ID: <464B0225.4080901@oucs.ox.ac.uk> ok, here is the demonstration. This is the input file, with different rend values for <p> and <hi>: <TEI xmlns="http://www.tei-c.org/ns/1.0"> <teiHeader> <fileDesc> <titleStmt> <title>The title

hello

hello

 and here is the ODD from which you can generate a schema to validate the above. Note that I have changed the global rend attribute to a fixed list, then overridden that for

. I claim this is *better* than pointers, cos it is validated, and you can do all the documentation in the ODD file at the project level rather than the file level. The CSS could be included in the ODD file and generated from there. If anyone believes this is not conformant, I'll see you outside the school gates later for a fight. TEI with rend setup Sebastian Rahtz

authored from scratch
My schema to check rend values

Here is the introduction to your document

Here is the schema:

 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:20:42 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:20:42 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <464AFEC2.9040304@oucs.ox.ac.uk> Message-ID: <464B052A.5080109@oucs.ox.ac.uk> John A. Walsh wrote: > Thanks for the clarification, Sebastian. I guess I was still thinking > in terms of the more limited enumerated lists in DTDs which only allow > one value. ah well, a DTD will simply not do any data checking at all in this situation. but who uses DTDs any more? > The value list approach provides better validation but still does not > provide the benefit of linking to explicit and formally defined styles > in the element in the header no, but it does provide a formal link to an element in the ODD, and can argue that is even better. > , but I'm probably beating a horse (whether it's a dead horse or not > remains to be seen :-). > Your horse can get up and run, it's a good horse. But I think my ODD horse may at least make a race of it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 09:23:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 14:23:10 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> Message-ID: <464B05BE.20802@oucs.ox.ac.uk> John A. Walsh wrote: > > I can do rend="#i #b #u #center" Note that the schema will not stop you writing "#it" or just "it" here by mistake. You have to write your own validator for that. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Wed May 16 17:22:12 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Wed, 16 May 2007 17:22:12 -0400 Subject: [tei-council] rendition, rend, and style In-Reply-To: References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <464AFEC2.9040304@oucs.ox.ac.uk> Message-ID: <464B7604.1030102@computing-services.oxford.ac.uk> John A. Walsh wrote: > On May 16, 2007, at 8:53 AM, Sebastian Rahtz wrote: >> John A. Walsh wrote: >>> The problem is with a fixed value list is that you can't combine >>> rendition styles. >> but the datatype of rend is "multiple tokens"[1], so you can say >> rend="a b c" and each of a, b and >> c will be checked against the list. honest. > Thanks for the clarification, Sebastian. > The value list approach provides better validation but still > does not provide the benefit of linking to explicit and formally defined > styles in the element in the header, but I'm probably > beating a horse (whether it's a dead horse or not remains to be seen :-). I still agree that there is a benefit of being able to point back to a in the header to document it more fully than one does with an attribute value. Yes, I like the validation that a closed value list provides, and I think I'd seriously recommend that approach for most uses, but being able to point to a place in the header which has even a prose description is in many ways much more powerful. Because doing rend="bigWobbly" where I define that by a paragraph in my ODD necessitates the ODD to accompany the instance (not a bad thing!), but point to a element in the header where I have a paragraph describing it means my document instance stands on its own in terms of documenting the meaning of the values it contains. Is there an easy clear way to have something be multiple tokens and/or multiple pointers? Or is that just getting icky? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Wed May 16 17:28:29 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 16 May 2007 22:28:29 +0100 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464B7604.1030102@computing-services.oxford.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <464AFEC2.9040304@oucs.ox.ac.uk> <464B7604.1030102@computing-services.oxford.ac.uk> Message-ID: <464B777D.7000304@oucs.ox.ac.uk> James Cummings wrote: > Because doing rend="bigWobbly" where I define that by a paragraph in > my ODD necessitates the ODD to accompany the instance (not a bad > thing!), but point to a element in the header where I have > a paragraph describing it means my document instance stands on its own > in terms of documenting the meaning of the values it contains. true. but why single out this one element for documentation of attribute values in the header? you could say the same about @type > > Is there an easy clear way to have something be multiple tokens and/or > multiple pointers? Or is that just getting icky? you cant distinguish. rend="big" could mean either. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From conal.tuohy at vuw.ac.nz Wed May 16 21:14:32 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Thu, 17 May 2007 13:14:32 +1200 Subject: [tei-council] rendition, rend, and style In-Reply-To: <464B777D.7000304@oucs.ox.ac.uk> References: <338119B6-BE70-4282-BE7D-E0CB9D2B2589@indiana.edu> <57791E2B-4D10-4BB7-BF90-CDEB7CB8BAB0@indiana.edu> <464A075C.2080707@oucs.ox.ac.uk> <464AD0CF.5060901@oucs.ox.ac.uk> <464AFEC2.9040304@oucs.ox.ac.uk> <464B7604.1030102@computing-services.oxford.ac.uk> <464B777D.7000304@oucs.ox.ac.uk> Message-ID: <1179364472.3735.7.camel@localhost> On Wed, 2007-05-16 at 22:28 +0100, Sebastian Rahtz wrote: > James Cummings wrote: > > Because doing rend="bigWobbly" where I define that by a paragraph in > > my ODD necessitates the ODD to accompany the instance (not a bad > > thing!), but point to a element in the header where I have > > a paragraph describing it means my document instance stands on its own > > in terms of documenting the meaning of the values it contains. > true. but why single out this one element for documentation of attribute > values in the header? you > could say the same about @type I think the main advantage of this would be when using a common rendition language (i.e. CSS), which opens up the prospect of automated rendering of diverse instance docs, with rendition. Clearly, the same doesn't apply to @type. From lou.burnard at computing-services.oxford.ac.uk Sat May 19 14:09:42 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sat, 19 May 2007 19:09:42 +0100 Subject: [tei-council] witList/Group query Message-ID: <464F3D66.10301@computing-services.oxford.ac.uk> TRAC ticket 332 states gnomically "change witList to witGroup, allow it to self-nest, and drop @included." I'm just about to make the recommended changes but would like to check that Council's recommendation was made in full understanding of the implication that a given witness can only appear in one witGroup (or witList). Certainly makes things simpler and clearer, but does it correspond with reality? Do textual critix never talk about overlapping groups of witnesses, or witnesses which appear in more than one group? From sebastian.rahtz at oucs.ox.ac.uk Sat May 19 17:03:21 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 19 May 2007 22:03:21 +0100 Subject: [tei-council] cleaning up after your easter egg Message-ID: <464F6619.7080701@oucs.ox.ac.uk> Could I beg you all to look again at the list at http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=First+pass+technical+chapter+review What I need for each ticket is one of the following: * confirmation that what you wanted done has been implemented (you can check at http://tei.oucs.ox.ac.uk/Guidelines/Source/Guidelines/en/guidelines-en.xml) * a note that the necessary actions are visible in http://tei.oucs.ox.ac.uk/trac/TEIP5/query?status=new&status=assigned&status=reopened&milestone=Actions+from+chapter+review and thus the easter ticket can be closed * a promise that the necessary changes have been fully reported to Lou or Syd, and that you are on the case of badgering to see that they get done wouldn't it be great to get all these tickets closed in the next week? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sun May 20 16:00:59 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 20 May 2007 21:00:59 +0100 Subject: [tei-council] the "key" attribute Message-ID: <4650A8FB.3050301@oucs.ox.ac.uk> I have raised this before, but it did not not stimulate any response, so I am bringing it up again, with the reiteration that it a _mess_. The key attribute is used in two situations: 1. on elements moduleRef, memberOf and specDesc to point to objects in the TEI universe which are identifiable by having @ident. It's like the old ID/IDREF pairing. 2. on elements like persName (all the things to do with naming people and places) to point to the canonical object. Unfortunately, our examples use it in two different ways 2a. as a URI pointer eg 2b as a database lookup somewhere eg so that's three distinct data types used on one attribute, differering in our examples even on the same element! What are the choices? 1. shrug our shoulders and say "bof, compared to the loss of Mourinho's dog it ees a nothing". 2. regularize all uses of @key to be URIs (screws up royally) 3. regularize all uses of @key to be database pointers, undefined (loses chance to use external URLs) 4. replace @key with @target in all the naming contexts 5a. allow both @key and @target on all naming objects (5b. making them mutually exclusive) I can live with 4, 5a or 5b. What say the rest of you? I think it is very important that we decide this before the meeting at month's end to finish places, as it is intimately caught up with all that persons/places stuff. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Sun May 20 16:07:04 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Sun, 20 May 2007 21:07:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650A8FB.3050301@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> Message-ID: <4650AA68.1060000@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > I have raised this before, but it did not not stimulate any response, so > I am bringing it up again, with the reiteration that it a _mess_. > > The key attribute is used in two situations: > > 1. on elements moduleRef, memberOf and specDesc to point to objects > in the TEI universe > which are identifiable by having @ident. It's like the old ID/IDREF > pairing. > > 2. on elements like persName (all the things to do with naming people > and places) > to point to the canonical object. Unfortunately, our examples use it > in two different > ways > 2a. as a URI pointer eg > 2b as a database lookup somewhere eg key="ThorJon08"> > > so that's three distinct data types used on one attribute, > differering in our examples even on the same element! > > What are the choices? > > 1. shrug our shoulders and say "bof, compared to the loss of > Mourinho's dog it ees a nothing". > > 2. regularize all uses of @key to be URIs (screws up royally) > > 3. regularize all uses of @key to be database pointers, undefined > (loses chance to use external URLs) > > 4. replace @key with @target in all the naming contexts > > 5a. allow both @key and @target on all naming objects (5b. making them > mutually exclusive) > > I can live with 4, 5a or 5b. What say the rest of you? > > I think it is very important that we decide this before the meeting at > month's > end to finish places, as it is intimately caught up with all that > persons/places stuff. > In order of decreasing preference: 4 5b 5a I agree with Sebastian that we *must* do something about this. I think 4 would be the least painful option, but like him can live with either of the 5s. Neither 1 nor 2 is acceptable. 3 would only be an option if we were also willing to revise all the , like things to use @ident rather than xml:id. From sebastian.rahtz at oucs.ox.ac.uk Sun May 20 16:22:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 20 May 2007 21:22:46 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650AA68.1060000@computing-services.oxford.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <4650AA68.1060000@computing-services.oxford.ac.uk> Message-ID: <4650AE16.7010602@oucs.ox.ac.uk> Lou Burnard wrote: > e. 3 would only be an option if we were also willing to revise all the > , like things to use @ident rather than xml:id. Which would be OK, if we accepted the limitation that the records would have to be in the same XML document. For this sort of work, pointing to an external document seems like a good and powerful facility. But its a possibility. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Sun May 20 20:45:33 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 20 May 2007 18:45:33 -0600 Subject: [tei-council] witList/Group query In-Reply-To: <464F3D66.10301@computing-services.oxford.ac.uk> References: <464F3D66.10301@computing-services.oxford.ac.uk> Message-ID: <1179708333.7616.5.camel@localhost> On Sat, 2007-05-19 at 19:09 +0100, Lou Burnard wrote: > TRAC ticket 332 states gnomically "change witList to witGroup, allow it > to self-nest, and drop @included." > > I'm just about to make the recommended changes but would like to check > that Council's recommendation was made in full understanding of the > implication that a given witness can only appear in one witGroup (or > witList). Certainly makes things simpler and clearer, but does it > correspond with reality? Do textual critix never talk about overlapping > groups of witnesses, or witnesses which appear in more than one group? Because witgroup overlaps, you can have subdivisions--I.e. I can be in a group within a group. So a witness can still be in a larger group as well as its own group. The main thing here, as I remember, was to avoid the situation where you end up with the following: wit a wit b wit c wit sigma (consensus of a,b,c) this should now be: witgroup/sigma|witgroup/wit a|wit b|wit c You could get more complicated, of course and have things like witgroup/sigma|witgroup/wit a|witgroup/wit b|wit c -d > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Sun May 20 22:53:12 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 20 May 2007 22:53:12 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4650AE16.7010602@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <4650AA68.1060000@computing-services.oxford.ac.uk> <4650AE16.7010602@oucs.ox.ac.uk> Message-ID: <18001.2456.218488.358701@emt.wwp.brown.edu> The problem (ti seems to me) was caused when we overloaded the semantics of the attribute name "key=" when son of ODD was born. I'm inclined to say the best way to fix it is to fix the original error, and rename the attribute used by et al. That is, there are three kinds of semantics: * I am a pointer, and point to a digital resource via a URI * I am a pointer, and point to an element inside this current document by matching the value of its (possibly non-unique) ident= attribute * I am a key into a database In cases where there are no special semantics (like next= and prev=) we use target= for the first, and key= for both the second and third. I think we need separate names for the 2nd and 3rd. My conservative instinct was to leave the P4 use for names as key= and change the name used by ODD elements. But in fact, since we are permitted to "break" existing documents, and it is just another template in the transformation from P4 to P5, there really isn't any strong reason not to use key= for the ODD elements and make up a new name for the database looker-upper attribute for names. While I'd be fine with adding a new attribute in the naming contexts that is explicitly a URI reference to the regularization or disambiguation information, I would be very hesitant to completely remove key= and thus the capability to refer to databases that are not addressable via URI. (As I said above, I have no problem renaming it; nor do I currently have any opinion on whether if there are two attributes, one for database record identification and one for a URI, they should be mutually exclusive or not.) From James.Cummings at computing-services.oxford.ac.uk Mon May 21 01:58:59 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 06:58:59 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4650A8FB.3050301@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> Message-ID: <46513523.8060007@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > 5a. allow both @key and @target on all naming objects (5b. making them > mutually exclusive) I'd vote for 5a or if others feel strongly that they should be exclusive 5b. I don't feel strongly about the need for mutual exclusivity and think that the two attributes have (slightly) different meanings. I feel memberOf should be using @target. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From cwittern at gmail.com Mon May 21 03:02:13 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 21 May 2007 16:02:13 +0900 Subject: [tei-council] the "key" attribute In-Reply-To: <18001.2456.218488.358701@emt.wwp.brown.edu> References: <4650A8FB.3050301@oucs.ox.ac.uk> <4650AA68.1060000@computing-services.oxford.ac.uk> <4650AE16.7010602@oucs.ox.ac.uk> <18001.2456.218488.358701@emt.wwp.brown.edu> Message-ID: <465143F5.5080100@gmail.com> Syd Bauman wrote: > The problem (ti seems to me) was caused when we overloaded the > semantics of the attribute name "key=" when son of ODD was born. I'm > inclined to say the best way to fix it is to fix the original error, > and rename the attribute used by et al. > > Well, I am with Syd here, why don't we change @key on the stuff (pointing to @ident) and leave key as it is, with its double face as either URL or database key. For the name for the new attribute, I have no preferences, but @target seems to suggest a @xml:id at the other end in most cases, so I think we should rather use something else. Christian From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 03:46:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 08:46:18 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18001.2456.218488.358701@emt.wwp.brown.edu> References: <4650A8FB.3050301@oucs.ox.ac.uk> <4650AA68.1060000@computing-services.oxford.ac.uk> <4650AE16.7010602@oucs.ox.ac.uk> <18001.2456.218488.358701@emt.wwp.brown.edu> Message-ID: <46514E4A.1020605@oucs.ox.ac.uk> Syd Bauman wrote: > While I'd be fine with adding a new attribute in the naming contexts > that is explicitly a URI reference to the regularization or > disambiguation information, I would be very hesitant to completely > remove key= and thus the capability to refer to databases that are > not addressable via URI. so this is possibly 6a. allow any (but only one) of @target, @key and @lookup on the object elements or, more likely, 6b. allow either (but only one) @target or @lookup on the object elements You may well be right, though, that we should take @key away from specDesc, memberOf and moduleRef and give them @teiKey instead. It would be a pain, because people _have_ been using Odds and have their customization files, and I'd have an unpleasant evening scouring ODD software for @key; but it is doable, and we could justify it to the world. in which case, I'd be happy with 7. give the TEI ODD elements a new @teiKey, and allow the object elements a choice of @key or @target. @key keeps its vague semantics of "a database lookup key" -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:25:58 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:25:58 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46513523.8060007@computing-services.oxford.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> Message-ID: <46515796.3030805@oucs.ox.ac.uk> James Cummings wrote: > I feel memberOf should be using @target. butthat's tricky. your ODD file says . You can't change that to , as "att.naming" is not in the current document (and by the way does not have an xml:id of "att.naming"...), but neither is it a web resource. You'd have to say which would - be a mess - preclude you working offline - stop you transparently switching to French - make a big hole in Roma (mendable, but big) specDesc more arguably could use target (though we'd have to change all the IDs) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:27:20 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:27:20 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465143F5.5080100@gmail.com> References: <4650A8FB.3050301@oucs.ox.ac.uk> <4650AA68.1060000@computing-services.oxford.ac.uk> <4650AE16.7010602@oucs.ox.ac.uk> <18001.2456.218488.358701@emt.wwp.brown.edu> <465143F5.5080100@gmail.com> Message-ID: <465157E8.2080009@oucs.ox.ac.uk> Wittern Christian wrote: > leave key as it is, with its double face as either URL or database key. surely this is evil. as a processor, if I meet , how do I what to do with it? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 04:28:43 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 09:28:43 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515796.3030805@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> Message-ID: <4651583B.3070208@oucs.ox.ac.uk> Sebastian Rahtz wrote: > You'd > have to say > > target="http://www.tei-c.org/release/xml/tei/odd/Source/Guidelines/en/guidelines-xml.xml#core"/> > > sorry, switched context half-way; for "-xml.xml#core" read ".xml#att.naming" -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Mon May 21 04:57:17 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 09:57:17 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515796.3030805@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> Message-ID: <46515EED.5060709@computing-services.oxford.ac.uk> Hrmmm, you are right, I hadn't thought through the implications. So the attribute used on memberOf should be 'key' or something similar (though I don't like 'teikey'). In most other cases does having a choice of target or key make sense? What's the logic of making them mutually exclusive? My original thought with regard to allowing @target on memberOf (and similar) was that it might help with (possibly non-TEI) ODDs that incorporate bits and pieces from other standards. -James Sebastian Rahtz wrote: > James Cummings wrote: >> I feel memberOf should be using @target. > butthat's tricky. your ODD file says . > You can't change that to , > as "att.naming" is not in the current document (and by the way does > not have an xml:id of "att.naming"...), but neither is it a web > resource. You'd > have to say > > target="http://www.tei-c.org/release/xml/tei/odd/Source/Guidelines/en/guidelines-xml.xml#core"/> > > > which would > > - be a mess > - preclude you working offline > - stop you transparently switching to French > - make a big hole in Roma (mendable, but big) > > specDesc more arguably could use target (though we'd have to change all > the IDs) > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 05:05:40 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 10:05:40 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46515EED.5060709@computing-services.oxford.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> Message-ID: <465160E4.2040705@oucs.ox.ac.uk> James Cummings wrote: > In most other cases does having a choice of target > or key make sense? What's the logic of making them mutually exclusive? to assist processors. If I see both, which do I operate on? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon May 21 05:36:15 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 10:36:15 +0100 Subject: [tei-council] witList/Group query In-Reply-To: <1179708333.7616.5.camel@localhost> References: <464F3D66.10301@computing-services.oxford.ac.uk> <1179708333.7616.5.camel@localhost> Message-ID: <4651680F.9040301@oucs.ox.ac.uk> Thanks Daniel, but this does not address the question. By "overlapping" I did not mean "containing". Let me rephrase the question: if to witness A is allocated to witGroup sigma, does that always preclude it simultaneously being allocated to witGroup delta? I have modified the text on the assumption that it does, but would just like to check that that is indeed the case. (The former state of affairs, using the attribute @included, did not enforce such a rule, of course) More significantly, looking at this again, I really want to know why we need this element at all. Why isn't it a (possibly abbreviated) ? Daniel O'Donnell wrote: > On Sat, 2007-05-19 at 19:09 +0100, Lou Burnard wrote: >> TRAC ticket 332 states gnomically "change witList to witGroup, allow it >> to self-nest, and drop @included." >> >> I'm just about to make the recommended changes but would like to check >> that Council's recommendation was made in full understanding of the >> implication that a given witness can only appear in one witGroup (or >> witList). Certainly makes things simpler and clearer, but does it >> correspond with reality? Do textual critix never talk about overlapping >> groups of witnesses, or witnesses which appear in more than one group? > > Because witgroup overlaps, you can have subdivisions--I.e. I can be in a > group within a group. So a witness can still be in a larger group as > well as its own group. > > The main thing here, as I remember, was to avoid the situation where you > end up with the following: > > wit a > wit b > wit c > wit sigma (consensus of a,b,c) > > this should now be: > > witgroup/sigma|witgroup/wit a|wit b|wit c > > You could get more complicated, of course and have things like > > witgroup/sigma|witgroup/wit a|witgroup/wit b|wit c > > -d > >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at computing-services.oxford.ac.uk Mon May 21 06:47:21 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 11:47:21 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465160E4.2040705@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> Message-ID: <465178B9.8030601@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > James Cummings wrote: >> In most other cases does having a choice of target >> or key make sense? What's the logic of making them mutually exclusive? > to assist processors. If I see both, which do I operate on? Whichever you know how to handle? I view them sort of as different things. To me @key gives a record that can (if understood) be used to provide more information about the element content, whereas @target provides a reference to something. i.e. the first is a key for metadata, while the second is more a form of transclusion and/or citation. But, thinking about it, maybe that isn't really much of a distinction. Are you proposing that anywhere that @target exists, this could be replaced by a mutually exclusive @key? i.e. ref ? -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 06:52:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 11:52:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465178B9.8030601@computing-services.oxford.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> Message-ID: <465179D4.2030709@oucs.ox.ac.uk> James Cummings wrote: > Whichever you know how to handle? I view them sort of as different things. > To me @key gives a record that can (if understood) be used to provide more > information about the element content, whereas @target provides a reference > to something. i.e. the first is a key for metadata, while the second is > more a form of transclusion and/or citation. But, thinking about it, maybe > that isn't really much of a distinction. > I can see the argument for allowing both, yes. But on the whole I think it gives an irritating possibility of confusion without buying a huge amount. I'd put my money on "just switch object elements to use @target" if I had to choose. > Are you proposing that anywhere that @target exists, this could be replaced > by a mutually exclusive @key? i.e. ref ? > No, I was not; but that would not be an impossible argument -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at computing-services.oxford.ac.uk Mon May 21 07:02:22 2007 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Mon, 21 May 2007 12:02:22 +0100 Subject: [tei-council] witList/Group query In-Reply-To: <4651680F.9040301@oucs.ox.ac.uk> References: <464F3D66.10301@computing-services.oxford.ac.uk> <1179708333.7616.5.camel@localhost> <4651680F.9040301@oucs.ox.ac.uk> Message-ID: <46517C3E.60703@computing-services.oxford.ac.uk> Lou Burnard wrote: > Thanks Daniel, but this does not address the question. By "overlapping" > I did not mean "containing". Let me rephrase the question: if to witness > A is allocated to witGroup sigma, does that always preclude it > simultaneously being allocated to witGroup delta? I have modified the > text on the assumption that it does, but would just like to check that > that is indeed the case. (The former state of affairs, using the > attribute @included, did not enforce such a rule, of course) I'm not sure, I suppose it makes sense that at any one time a witness is part of a particular witGroup and that precludes it being part of any other (non-ancestor) witGroup. But I'm not confident enough in that to say that it always precludes it. I view these groupings as possibly very fluid and dependent on future analysis of the apparatus in the document instance. > More significantly, looking at this again, I really want to know why we > need this element at all. Why isn't it a (possibly > abbreviated) ? That is the problem, I believe that Dot and I had with Gautier's proposed revisions, most of what he wanted to do, I believe, could be done in an msDesc. But, the short answer being, I suppose, that msDesc is for manuscripts, and not all witnesses are manuscripts. Thus, some people might feel it is semantically inaccurate to use msDesc for other text-bearing objects which witness the same text as some manuscripts. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From mjd at hum.ku.dk Mon May 21 10:21:47 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 21 May 2007 16:21:47 +0200 Subject: [tei-council] witList/Group query Message-ID: <5FA95E40EE2AD51190380090272724BB0F7F254A@humxsrv1.hum.ku.dk> Dot and you and Matthew. We discussed this in Berlin, I remember, although I can't now remember what we decided (apart from changing witList to witGroup). It seems clear enough, though, that witness is essentially a pared down msDesc, with only those subelements necessary for describing manuscripts in a specific context or perhaps rather a specific role, as text witnesses. My feeling is still that as such it's not necessary. Whether msDesc can be used for TBOs other than manuscripts is obviously a much larger issue. But as regards your question, Lou, I think James's answer, that a witness is only likely to be part of a single witGroup AT ANY ONE TIME is the right one. Nesting should be able to take of any overlaps. Matthew -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of James Cummings Sent: Monday, May 21, 2007 1:02 PM To: Lou Burnard Cc: TEI Council Subject: Re: [tei-council] witList/Group query Lou Burnard wrote: > Thanks Daniel, but this does not address the question. By "overlapping" > I did not mean "containing". Let me rephrase the question: if to witness > A is allocated to witGroup sigma, does that always preclude it > simultaneously being allocated to witGroup delta? I have modified the > text on the assumption that it does, but would just like to check that > that is indeed the case. (The former state of affairs, using the > attribute @included, did not enforce such a rule, of course) I'm not sure, I suppose it makes sense that at any one time a witness is part of a particular witGroup and that precludes it being part of any other (non-ancestor) witGroup. But I'm not confident enough in that to say that it always precludes it. I view these groupings as possibly very fluid and dependent on future analysis of the apparatus in the document instance. > More significantly, looking at this again, I really want to know why we > need this element at all. Why isn't it a (possibly > abbreviated) ? That is the problem, I believe that Dot and I had with Gautier's proposed revisions, most of what he wanted to do, I believe, could be done in an msDesc. But, the short answer being, I suppose, that msDesc is for manuscripts, and not all witnesses are manuscripts. Thus, some people might feel it is semantically inaccurate to use msDesc for other text-bearing objects which witness the same text as some manuscripts. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at computing-services.oxford.ac.uk Mon May 21 11:56:32 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 16:56:32 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465179D4.2030709@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> Message-ID: <4651C130.6090509@oucs.ox.ac.uk> How do we feel about pos tagging? At present the Guiidelines say you have to do things like bum and point off stage to some definition for noun (an or a or something). But why shouldn't I do bum meaning "Everyone knows what a NOUN is, but if you insist on finding out use this magic string 'NOUN' and some mechanism external to this document will enlighten you" From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 16:58:10 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 21:58:10 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4651C130.6090509@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> <4651C130.6090509@oucs.ox.ac.uk> Message-ID: <465207E2.5010106@oucs.ox.ac.uk> Lou Burnard wrote: > How do we feel about pos tagging? At present the Guiidelines say you > have to do things like > bum > > and point off stage to some definition for noun (an or a > or something). > > But why shouldn't I do > > bum > > meaning "Everyone knows what a NOUN is, but if you insist on finding > out use this magic string 'NOUN' and some mechanism external to this > document will enlighten you" If Boney is right, I assume your example should be by the same argument. It is a slippery (and seductive) slope if we appear to let ID/IDREF back in, which is what will happen if we allow key="NOUN", cos people will use it to point to that , instead of "the universe". I am fairly sure we should switch all the @keys on objects to @target forthwith, and then consider separately whether to allow @key back in. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Mon May 21 17:35:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 21 May 2007 22:35:06 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465207E2.5010106@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> <4651C130.6090509@oucs.ox.ac.uk> <465207E2.5010106@oucs.ox.ac.uk> Message-ID: <4652108A.7040200@computing-services.oxford.ac.uk> Sebastian Rahtz wrote: > Lou Burnard wrote: >> How do we feel about pos tagging? At present the Guiidelines say you >> have to do things like >> bum >> >> and point off stage to some definition for noun (an or a >> or something). >> >> But why shouldn't I do >> >> bum >> >> meaning "Everyone knows what a NOUN is, but if you insist on finding >> out use this magic string 'NOUN' and some mechanism external to this >> document will enlighten you" > If Boney is right, I assume your > example should be by > the same argument. Well, @ana is defined for this very purpose, so no, I wouldn't use @target. > > It is a slippery (and seductive) slope if we appear to let ID/IDREF > back in, which is what > will happen if we allow key="NOUN", cos people will use it to point to > that , > instead of "the universe". > But that's Wrong. If you want to point to the you need a pointer, not a key. > I am fairly sure we should switch all the @keys on objects to @target > forthwith, > and then consider separately whether to allow @key back in. > I'm happy with turning all the @keys on ect into @target s (or @ana, or @ref) Actually @ref might be clearer. It's what we use for , which is very similar. I have no problem leaving @key in places where it's clear that a URI won't fit, i.e. where you might need to do some more processing to turn the @key value into what you want. But I don't see why might not fall into that category. From sebastian.rahtz at oucs.ox.ac.uk Mon May 21 17:46:04 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 21 May 2007 22:46:04 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4652108A.7040200@computing-services.oxford.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> <4651C130.6090509@oucs.ox.ac.uk> <465207E2.5010106@oucs.ox.ac.uk> <4652108A.7040200@computing-services.oxford.ac.uk> Message-ID: <4652131C.4010702@oucs.ox.ac.uk> Lou Burnard wrote: > I'm happy with turning all the @keys on ect > into @target s (or @ana, or @ref) > Actually @ref might be clearer. It's what we use for , which is > very similar. sure, no disagreement with @ref instead of @target. > > I have no problem leaving @key in places where it's clear that a URI > won't fit, i.e. where you might need to do some more processing to > turn the @key value into what you want. like on memberOf, you mean? should @key stay on some object things? I find slightly weird. I'd rather have that as personally. its more like your POS stuff, no? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From Syd_Bauman at Brown.edu Mon May 21 22:52:55 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 21 May 2007 22:52:55 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4652131C.4010702@oucs.ox.ac.uk> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> <4651C130.6090509@oucs.ox.ac.uk> <465207E2.5010106@oucs.ox.ac.uk> <4652108A.7040200@computing-services.oxford.ac.uk> <4652131C.4010702@oucs.ox.ac.uk> Message-ID: <18002.23303.258022.297312@emt.wwp.brown.edu> I'm sorry, it is likely I have not been able to follow the conversation well enough from here, but could you define what an "object thing" is? While I actually prefer to add a URI attribute that is probably mutually exclusive with key= (whether renamed or not) to the naming elements rather than overload key= with "either a URI or a database thingy", I think Sebastian's argument does not hold much water ... asking the qustion "If I'm trying to process this, and I come across a key=, what should I do?" is a bit silly. If you haven't read the local documentation on how key= is used, you have to ignore it whether it's a URI or not. And every project is going to use the non-URI keys differently. So this is not a place where interoperability concerns come into play. But again, I still think it's probably better to separate these things. I also still think key= of , , et al. should remain a "match the ident=" attribute, but should undergo a name change. I'm also still happy to consider leaving its name key=, and coming up with a better name for the use for naming elements. From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 05:07:56 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 10:07:56 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18002.23303.258022.297312@emt.wwp.brown.edu> References: <4650A8FB.3050301@oucs.ox.ac.uk> <46513523.8060007@computing-services.oxford.ac.uk> <46515796.3030805@oucs.ox.ac.uk> <46515EED.5060709@computing-services.oxford.ac.uk> <465160E4.2040705@oucs.ox.ac.uk> <465178B9.8030601@computing-services.oxford.ac.uk> <465179D4.2030709@oucs.ox.ac.uk> <4651C130.6090509@oucs.ox.ac.uk> <465207E2.5010106@oucs.ox.ac.uk> <4652108A.7040200@computing-services.oxford.ac.uk> <4652131C.4010702@oucs.ox.ac.uk> <18002.23303.258022.297312@emt.wwp.brown.edu> Message-ID: <4652B2EC.1070907@oucs.ox.ac.uk> Syd Bauman wrote: > I'm sorry, it is likely I have not been able to follow the > conversation well enough from here, but could you define what an > "object thing" is? > all the things which are members of att.naming > And every project is going to use the > non-URI keys differently. So this is not a place where > interoperability concerns come into play. > ok, fair enough; we could allow both > I also still think key= of , , et al. should > remain a "match the ident=" attribute, but should undergo a name > change. I'm also still happy to consider leaving its name key=, and > coming up with a better name for the use for naming elements. > OK, how about we do this: - leave @key on etc as is - change att.naming to remove @key and put in @ref as pointer instead - discuss at places meeting next week whether they need the @key functionality back, and if so ask them to choose a name Matthew, are you awake? do you have a view on this, as a big proponent of keys on naming objects? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From mjd at hum.ku.dk Tue May 22 07:50:02 2007 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Tue, 22 May 2007 13:50:02 +0200 Subject: [tei-council] the "key" attribute Message-ID: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> Yes, quite awake, but up to my oxters in work (by which I mean what I'm actually paid to do). Still, I've been following this debate very closely, for the reason you indicate, viz. that this issue is of such importance to all this name stuff. Unfortunately, but not for the first time, I'm not sure I understand the technical issues sufficiently to try and voice an opinion. It would be helpful if I had a clearer idea of the difference between key, ana and target (and ref), all of which seem to do similar, but subtly different, things. It's the "subtly different" bit that gets me. key "provides a means of locating a full definition for the entity being named such as a database record key or a URI" ana "indicates one or more elements containing interpretations of the element on which the ana attribute appears" target "specifies the destination of the reference by supplying one or more URI References" ref "points to a description of the character or glyph intended" The first of these is datatype data.key ("defines the range of attribute values expressing a coded value by means of an arbitrary identifier, typically taken from a set of externally-defined possibilities=), while the last 3 are data.pointer ("defines the range of attribute values used to provide a single pointer to any other resource, either within the current document or elsewhere"). Anybody want to try to explain to me wherein the subtle difference lies? Matthew -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Sebastian Rahtz Sent: Tuesday, May 22, 2007 11:08 AM To: Syd_Bauman at Brown.edu Cc: TEI Council Subject: Re: [tei-council] the "key" attribute Syd Bauman wrote: > I'm sorry, it is likely I have not been able to follow the > conversation well enough from here, but could you define what an > "object thing" is? > all the things which are members of att.naming > And every project is going to use the > non-URI keys differently. So this is not a place where > interoperability concerns come into play. > ok, fair enough; we could allow both > I also still think key= of , , et al. should > remain a "match the ident=" attribute, but should undergo a name > change. I'm also still happy to consider leaving its name key=, and > coming up with a better name for the use for naming elements. > OK, how about we do this: - leave @key on etc as is - change att.naming to remove @key and put in @ref as pointer instead - discuss at places meeting next week whether they need the @key functionality back, and if so ask them to choose a name Matthew, are you awake? do you have a view on this, as a big proponent of keys on naming objects? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 09:14:03 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 14:14:03 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> Message-ID: <4652EC9B.8030904@oucs.ox.ac.uk> Matthew James Driscoll wrote: > It would be helpful if I had a clearer idea of the difference between key, > ana and target (and ref), all of which seem to do similar, but subtly > different, things. It's the "subtly different" bit that gets me. > > key "provides a means of locating a full definition for the entity being > named such as a database record key or a URI" ] > no, scrub that "or a URI" bit. It can't work. > ana "indicates one or more elements containing interpretations of the > element on which the ana attribute appears" > > target "specifies the destination of the reference by supplying one or more > URI References" > > ref "points to a description of the character or glyph intended" > these are three different semantics for the same action, pointing at something by an explicit route ("http://www.example.com/person#OF08").Using the data.key method points at things by an implicit route ("you know what I mean by HOF08") > Anybody want to try to explain to me wherein the subtle difference lies? > whether you want explicit routing to the resource by means of a URI, or just a system-specific token which will help you find it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From conal.tuohy at vuw.ac.nz Tue May 22 17:34:38 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 23 May 2007 09:34:38 +1200 Subject: [tei-council] the "key" attribute In-Reply-To: <4652EC9B.8030904@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> Message-ID: <1179869678.6486.18.camel@localhost> On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote: > Matthew James Driscoll wrote: > > It would be helpful if I had a clearer idea of the difference between key, > > ana and target (and ref), all of which seem to do similar, but subtly > > different, things. It's the "subtly different" bit that gets me. > > > > key "provides a means of locating a full definition for the entity being > > named such as a database record key or a URI" ] > > > no, scrub that "or a URI" bit. It can't work. Can you explain why? Do you mean because of your earlier point that there's no failsafe way to determine whether a @key is intended to represent a db record key on the one hand, or a URI on the other? I have to say I am very much a fan of @key as a URI (and of URIs as a preferred reference mechanism is general). If the problem with "or a URI" is as I supposed, another approach would be to require that @key always contains a URI, and recommend to encoders who wish to encode a locally-defined database record key that they encode the record key, slightly more verbosely, in some kind of URI syntax. Conal The @key above is actually a key in a database here at work. There are several usable http URLs I could construct from it, e.g.: Conal Without using http or another resolution protocol, the key could still be encoded in URI syntax using the "tag" URI scheme: Conal From sebastian.rahtz at oucs.ox.ac.uk Tue May 22 17:55:53 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 22 May 2007 22:55:53 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1179869678.6486.18.camel@localhost> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> Message-ID: <465366E9.4000508@oucs.ox.ac.uk> Conal Tuohy wrote: > Can you explain why? Do you mean because of your earlier point that > there's no failsafe way to determine whether a @key is intended to > represent a db record key on the one hand, or a URI on the other? > yes. what does mean? > If the problem with "or a URI" is as I supposed, another approach would > be to require that @key always contains a URI thats fine, but then we have two elements with the same "key" attribute, but different datatypes. this just seems wrong. > Without using http or another resolution protocol, the key could still > be encoded in URI syntax using the "tag" URI scheme: > > > Conal > > thats an interesting idea. bit verbose, tho? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Tue May 22 17:57:50 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 22 May 2007 22:57:50 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <1179869678.6486.18.camel@localhost> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> Message-ID: <4653675E.6000305@computing-services.oxford.ac.uk> I wondered about this, even as I made the changes proposed. It's clear that there is going to be some overlap: if for example my special database actually provides a web front end, then I might be able to access it either by means of the (magic) key "blort", or by means of a URI such as "http://mySpecialDatabase/frontEnd?key=blort" But I don't think this affects the issue. The idea is that there are two ways of finding something: (a) you point at it with a URI. (b) you do it some other way In the latter case, the value supplied in your document is a magic token. We make no assumptions about how you will use that magic token to find the thing you're looking for: that's up to you. You might look it up in a database, you might stick some extra stuff on the front and turn it into a URL, you might attach it to a carrier pigeon. There are probably only a few cases where (b) is the best way of doing things, but they do exist: the way we hook modules and elements into a TEI schema spec is one -- we supply an identifier (the magic token) and the Odd processor Does The Right Thing with it. Another case might be where everybody *just knows* what you mean by a given code -- say, for example, identifying the books of the Bible. You don't want to have to spell out in every single Biblical commentary you encode that "Gen" means "Genesis", etc. You just want to say "Gen". Yes, of course it's better to spell things like that out. But there are limits to people's willingness to be explicit! The proposal (now implemented) is to reserve @key, with datatype data.key, for that latter usage. Case (a), using a URI, is of course far and away the better solution for the vast majority of practical usages. The attribute name in this case varies, depending on the semantics: so we have @ref, @target, @ana, @corresp, inter alia. Conal Tuohy wrote: > On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote: > >> Matthew James Driscoll wrote: >> >>> It would be helpful if I had a clearer idea of the difference between key, >>> ana and target (and ref), all of which seem to do similar, but subtly >>> different, things. It's the "subtly different" bit that gets me. >>> >>> key "provides a means of locating a full definition for the entity being >>> named such as a database record key or a URI" ] >>> >>> >> no, scrub that "or a URI" bit. It can't work. >> > > Can you explain why? Do you mean because of your earlier point that > there's no failsafe way to determine whether a @key is intended to > represent a db record key on the one hand, or a URI on the other? > > I have to say I am very much a fan of @key as a URI (and of URIs as a > preferred reference mechanism is general). > > If the problem with "or a URI" is as I supposed, another approach would > be to require that @key always contains a URI, and recommend to encoders > who wish to encode a locally-defined database record key that they > encode the record key, slightly more verbosely, in some kind of URI > syntax. > > > Conal > > The @key above is actually a key in a database here at work. There are > several usable http URLs I could construct from it, e.g.: > > key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal > > Without using http or another resolution protocol, the key could still > be encoded in URI syntax using the "tag" URI scheme: > > > Conal > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From Syd_Bauman at Brown.edu Tue May 22 23:00:32 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 22 May 2007 23:00:32 -0400 Subject: [tei-council] the "key" attribute In-Reply-To: <4653675E.6000305@computing-services.oxford.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> Message-ID: <18003.44624.650363.406838@emt.wwp.brown.edu> SR> all the things which are members of att.naming Thank you. SR> OK, how about we do this: SR> - leave @key on etc as is sure SR> - change att.naming to remove @key and put in @ref as pointer SR> instead I am not in favor. I don't mind renaming @key, but I think its functionality has to stay.[1] E.g., the US LOC may have changed recently, but as of a few years ago you could not access an LOC name authority record via a URI. SR> - discuss at places meeting next week whether they need the @key SR> functionality back, and if so ask them to choose a name I don't think there is really any need for discussion -- it has to stay.[1] (Its name, on the other hand ... :-) LB> The idea is that there are two LB> ways of finding something: LB> (a) you point at it with a URI. LB> (b) you do it some other way LB> In the latter case, the value supplied in your document is a magic LB> token. We make no assumptions about how you will use that magic token to LB> find the thing you're looking for: that's up to you. You might look it LB> up in a database, you might stick some extra stuff on the front and turn LB> it into a URL, In which case it really should be a cRef=. Which makes some sense. LB> There are probably only a few cases where (b) is the best way of LB> doing things, but they do exist: the way we hook modules and LB> elements into a TEI schema spec is one -- we supply an identifier LB> (the magic token) and the Odd processor Does The Right Thing with LB> it. I am unconvinced that this is a correct analysis. As I've said, I see three categories: 1. point at it with a URI 1a. use the cRef= mechanism for shorthand of a URI 2. point at it by matching its ident= (remember this is used not only be key= of et al., but also by xml:lang=) 3. a user-defined magic token The usage is not a user-defined black box method of finding something. This is clearly defined: the value has to match an ident= in the same document, no? LB> Another case might be where everybody *just knows* what you mean LB> by a given code -- say, for example, identifying the books of the LB> Bible. You don't want to have to spell out in every single LB> Biblical commentary you encode that "Gen" means "Genesis", etc. LB> You just want to say "Gen". Yes, of course it's better to spell LB> things like that out. But there are limits to people's LB> willingness to be explicit! This is a really good example, and a potential reason why the tag: URL scheme won't really solve the problem -- people who don't want to bother being explicit are certainly not going to want to develop tag: URLs. LB> I wondered about this, even as I made the changes proposed. ... LB> The proposal (now implemented) is to reserve @key, with datatype LB> data.key, for that latter usage. I'm sorry, what has now been implemented? What change (if any) has been made? Notes ----- [1] However, Conal's suggestion of using the tag: URI scheme bears further thought and discussion -- it may actually provide sufficient functionality, but I'm not convinced yet. And I don't really have the capability to read up on it right now from dial-up land, but it's worth reading up on: http://www.rfc-editor.org/rfc/rfc4151.txt From conal.tuohy at vuw.ac.nz Wed May 23 00:01:44 2007 From: conal.tuohy at vuw.ac.nz (Conal Tuohy) Date: Wed, 23 May 2007 16:01:44 +1200 Subject: [tei-council] the "key" attribute In-Reply-To: <18003.44624.650363.406838@emt.wwp.brown.edu> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <18003.44624.650363.406838@emt.wwp.brown.edu> Message-ID: <1179892904.27602.14.camel@localhost> On Tue, 2007-05-22 at 23:00 -0400, Syd Bauman wrote: > SR> - change att.naming to remove @key and put in @ref as pointer > SR> instead > > I am not in favor. I don't mind renaming @key, but I think its > functionality has to stay.[1] E.g., the US LOC may have changed > recently, but as of a few years ago you could not access an LOC name > authority record via a URI. I think it's still true that you can't "access" an LoC name record via a URL, but it's certainly possible to encode a Library of Congress Control Number (LCCN) in a URI, in a standard way: e.g. "info:lccn/n2002153210" is the URI for a certain Syd Bauman. Disappointingly, on the LoC web page for this record (I won't post a more specific URL than http://authorities.loc.gov/ because their rubbish URLs don't persist from one moment to the next) the LCCN is nowhere presented in the form of an "info" URI. However, I believe that using the "info" URI scheme is the recommended practice for URI-encoding of LCCN identifiers. This URI does not have a well-defined resolution mechanism, however, it is still a valuable standard, and a useful key for Syd Bauman. From daniel.odonnell at uleth.ca Wed May 23 00:08:51 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 22 May 2007 22:08:51 -0600 Subject: [tei-council] the "key" attribute In-Reply-To: <1179892904.27602.14.camel@localhost> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <18003.44624.650363.406838@emt.wwp.brown.edu> <1179892904.27602.14.camel@localhost> Message-ID: <1179893331.12852.9.camel@localhost> Another group I'm working on is busy implementing a LOC URL scheme called SRU: http://refdb.sourceforge.net/sru.html -dan On Wed, 2007-05-23 at 16:01 +1200, Conal Tuohy wrote: > On Tue, 2007-05-22 at 23:00 -0400, Syd Bauman wrote: > > SR> - change att.naming to remove @key and put in @ref as pointer > > SR> instead > > > > I am not in favor. I don't mind renaming @key, but I think its > > functionality has to stay.[1] E.g., the US LOC may have changed > > recently, but as of a few years ago you could not access an LOC name > > authority record via a URI. > > I think it's still true that you can't "access" an LoC name record via a > URL, but it's certainly possible to encode a Library of Congress Control > Number (LCCN) in a URI, in a standard way: > > e.g. "info:lccn/n2002153210" is the URI for a certain Syd Bauman. > > Disappointingly, on the LoC web page for this record (I won't post a > more specific URL than http://authorities.loc.gov/ because their rubbish > URLs don't persist from one moment to the next) the LCCN is nowhere > presented in the form of an "info" URI. However, I believe that using > the "info" URI scheme is the recommended practice for URI-encoding of > LCCN identifiers. > > This URI does not have a well-defined resolution mechanism, however, it > is still a valuable standard, and a useful key for Syd Bauman. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 04:03:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 09:03:38 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <18003.44624.650363.406838@emt.wwp.brown.edu> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <18003.44624.650363.406838@emt.wwp.brown.edu> Message-ID: <4653F55A.702@oucs.ox.ac.uk> Syd Bauman wrote: > functionality has to stay.[1] E.g., the US LOC may have changed > recently, but as of a few years ago you could not access an LOC name > authority record via a URI. > you could use Conal's trick maybe we _should_ all use cRef for some of these things; possibly that should be added to att.naming? If, for example, Matthew has a canonical way of referring to dead Icelanders, he should document it in a and point using a cRef. is cRef used in the wild? > I'm sorry, what has now been implemented? What change (if any) has > been made? > Lou has added @ref to att.naming -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Wed May 23 09:19:55 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 23 May 2007 14:19:55 +0100 Subject: [tei-council] Berlin Photos Message-ID: <46543F7B.2000105@oucs.ox.ac.uk> By the way I finally got around to posting the numerous photos I took in Berlin, in case anyone is interested. If anyone has any objections to the public posting of photos they appear in, let me know which photos you object to and I will remove them (or change their permissions). http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/ My favourites (for various reasons) include: http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_018.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_060.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_063.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_120.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_121.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_151.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_162.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_202.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_218.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_275.jpg.html http://gallery.cummingsfamily.org.uk/v/James_and_Luci/2007/Berlin/Berlin_296.jpg.html -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Wed May 23 09:58:23 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 23 May 2007 14:58:23 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4653675E.6000305@computing-services.oxford.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> Message-ID: <4654487F.4030602@kcl.ac.uk> I think this is quite a complex issue to tackle since the use of implicit @key to refer to something else implies some sort of user-defined method to transform it into a real reference but at the same time requires the guidelines to be more explicit in suggested practices (e.g. use the TEI header, store your more explicit paths somewhere, create a TEI authority list of people/places). In general I think I agree with the proposal Lou Burnard wrote: > to reserve @key, with datatype > data.key, for that latter usage. i.e. for references that don't have necessarily the format of a pointer....but more to be done on the names and dates chapter to show how @key can be REALLY used. Arianna > > > > Conal Tuohy wrote: >> On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote: >> >>> Matthew James Driscoll wrote: >>> >>>> It would be helpful if I had a clearer idea of the difference >>>> between key, >>>> ana and target (and ref), all of which seem to do similar, but subtly >>>> different, things. It's the "subtly different" bit that gets me. >>>> >>>> key "provides a means of locating a full definition for the entity >>>> being >>>> named such as a database record key or a URI" ] >>>> >>> no, scrub that "or a URI" bit. It can't work. >>> >> >> Can you explain why? Do you mean because of your earlier point that >> there's no failsafe way to determine whether a @key is intended to >> represent a db record key on the one hand, or a URI on the other? >> >> I have to say I am very much a fan of @key as a URI (and of URIs as a >> preferred reference mechanism is general). >> If the problem with "or a URI" is as I supposed, another approach would >> be to require that @key always contains a URI, and recommend to encoders >> who wish to encode a locally-defined database record key that they >> encode the record key, slightly more verbosely, in some kind of URI >> syntax. >> >> >> Conal >> >> The @key above is actually a key in a database here at work. There are >> several usable http URLs I could construct from it, e.g.: >> >> > key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal >> >> Without using http or another resolution protocol, the key could still >> be encoded in URI syntax using the "tag" URI scheme: >> >> >> Conal >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 10:41:47 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 15:41:47 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <4654487F.4030602@kcl.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <4654487F.4030602@kcl.ac.uk> Message-ID: <465452AB.8060002@oucs.ox.ac.uk> Arianna Ciula wrote: > I think this is quite a complex issue to tackle since the use of > implicit @key to refer to something else implies some sort of > user-defined method to transform it into a real reference but at the > same time requires the guidelines to be more explicit in suggested > practices (e.g. use the TEI header, store your more explicit paths > somewhere, create a TEI authority list of people/places). you mean that in general show people better how to use @ref instead of @key? > i.e. for references that don't have necessarily the format of a > pointer....but more to be done on the names and dates chapter to show > how @key can be REALLY used. can you expand? in general, we discourage use of @key, don't we? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Wed May 23 13:30:56 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 23 May 2007 18:30:56 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <465452AB.8060002@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <4654487F.4030602@kcl.ac.uk> <465452AB.8060002@oucs.ox.ac.uk> Message-ID: <46547A50.1080308@kcl.ac.uk> Sebastian Rahtz wrote: > Arianna Ciula wrote: >> I think this is quite a complex issue to tackle since the use of >> implicit @key to refer to something else implies some sort of >> user-defined method to transform it into a real reference but at the >> same time requires the guidelines to be more explicit in suggested >> practices (e.g. use the TEI header, store your more explicit paths >> somewhere, create a TEI authority list of people/places). > you mean that in general show people better how to use @ref instead of > @key? I think the use of @key for persons/places is shown (inconsistently as you have also pointed out) but without prose on concrete practices. If I remember well the examples show the use of @key as a pointer to a person element, for instance, in the header. Now, we know this is a practice that work for relative small scenarios. Every project with a good amount of data on persons need a different way (TEI authority file containing only person elements for instance, prosopographical DB etc.) to store this information and recall it (need a better word than 'recall' here) from each single document through @keys. >> i.e. for references that don't have necessarily the format of a >> pointer....but more to be done on the names and dates chapter to show >> how @key can be REALLY used. > can you expand? in general, we discourage use of @key, don't we? I am not sure we should discourage the use of an attribute that allows people to integrate data coming from different resources (e.g. XML source documents separate from DB material, ontology or whatever). I am also a fan of @keys. The XML source file cannot contain ALL the information about its context (e.g. prosopographical context) and shouldn't (IMO). However, I do agree that we could suggest better ways of doing things such as what we are now doing by supporting the use of namespaces: for instance, tell where you could store store the path to get to your DB and transform those keys into actual references and so on. Hope I wasn't too confusing...really busy week. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Wed May 23 14:43:30 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 23 May 2007 19:43:30 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46547A50.1080308@kcl.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <4654487F.4030602@kcl.ac.uk> <465452AB.8060002@oucs.ox.ac.uk> <46547A50.1080308@kcl.ac.uk> Message-ID: <46548B52.7030902@oucs.ox.ac.uk> Arianna Ciula wrote: > that work for relative small scenarios. Every project with a good > amount of data on persons need a different way (TEI authority file > containing only person elements for instance, prosopographical DB > etc.) to store this information and recall it (need a better word than > 'recall' here) from each single document through @keys. by which I hope you mean not old @key, but new @ref..... > > I am not sure we should discourage the use of an attribute that allows > people to integrate data coming from different resources (e.g. XML > source documents separate from DB material, ontology or whatever). I thought we encouraged integration by URLs, pure and simple, except in special cases? > The XML source file cannot contain ALL the information about its > context (e.g. prosopographical context) and shouldn't (IMO). no, which is why a URL which can go inside the file, or out of it, is a good answer. Isn't this basic TEI P5, a move towards Web-style hyperlinking as the primary method? > However, I do agree that we could suggest better ways of doing things > such as what we are now doing by supporting the use of namespaces: for > instance, tell where you could store store the path to get to your DB > and transform those keys into actual references and so on. I don't think you mean namespaces here; you refer, I think, to creative use of different URI protocols. We must make sure we dont spend the whole day next week discussing this.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Thu May 24 05:09:52 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Thu, 24 May 2007 10:09:52 +0100 Subject: [tei-council] the "key" attribute In-Reply-To: <46548B52.7030902@oucs.ox.ac.uk> References: <5FA95E40EE2AD51190380090272724BB0F7F2A8C@humxsrv1.hum.ku.dk> <4652EC9B.8030904@oucs.ox.ac.uk> <1179869678.6486.18.camel@localhost> <4653675E.6000305@computing-services.oxford.ac.uk> <4654487F.4030602@kcl.ac.uk> <465452AB.8060002@oucs.ox.ac.uk> <46547A50.1080308@kcl.ac.uk> <46548B52.7030902@oucs.ox.ac.uk> Message-ID: <46555660.8040701@kcl.ac.uk> Sebastian Rahtz wrote: > Arianna Ciula wrote: >> that work for relative small scenarios. Every project with a good >> amount of data on persons need a different way (TEI authority file >> containing only person elements for instance, prosopographical DB >> etc.) to store this information and recall it (need a better word than >> 'recall' here) from each single document through @keys. > by which I hope you mean not old @key, but new @ref..... well, yes, new @ref when we can have explicit references. >> The XML source file cannot contain ALL the information about its >> context (e.g. prosopographical context) and shouldn't (IMO). > no, which is why a URL which can go inside the file, or out of it, is a > good answer. Isn't this basic TEI P5, a move > towards Web-style hyperlinking as the primary method? >> However, I do agree that we could suggest better ways of doing things >> such as what we are now doing by supporting the use of namespaces: for >> instance, tell where you could store store the path to get to your DB >> and transform those keys into actual references and so on. > I don't think you mean namespaces here; you refer, I think, to creative > use of different URI protocols. sure, namespaces meaning: clean declaration of where things come from that is URI. > > We must make sure we dont spend the whole day next week discussing this.... I meant to agree on an agenda with Matthew but hadn't had time to draft anything yet. > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From arianna.ciula at kcl.ac.uk Mon May 28 07:49:29 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 28 May 2007 12:49:29 +0100 Subject: [tei-council] Re: TEI P5 release 0.7 In-Reply-To: <46585FCC.6040700@oucs.ox.ac.uk> References: <46585FCC.6040700@oucs.ox.ac.uk> Message-ID: <465AC1C9.3080302@kcl.ac.uk> Hi, I have noticed that nymKey has now correctly become nymRef (therefore datat.pointer); however there is still one reference to nymKey in the ND prose. I suppose we could deal with this tomorrow, but since it's an easy fix and the new chapter is already public, I thought useful to point it out. Arianna Sebastian Rahtz wrote: > A new release of P5 has just slipped its mooring and glided away into > the darkling night, > accompanied by its Stylesheets and Roma consorts, intent on havoc across > the text > encoding oceans. > > This release is relatively minor, but is the start of what I hope will > be 4 more releases > before the final 1.0; so expect to see the predators emerging once a > month or so from now on. > > The release includes many small fixes made at the TEI Council's spring > meeting in Berlin, though there are a lot still to come from that. Among > the > (obscure) things you may notice: > > *) the hoary old entities/macros mix.drama, mix.verse etc are all gone. > if conceivably you mourn their passing, let us know > > *) the macro.component object has also gone, replaced by simply > a call to macro.common. You may have this in an existing ODD file > - contact me if you cannot see how to fix. > > *) the att.naming class adds a new @ref attribute to things like . > This removes a confusion whereby the @key attribute was said to allow > either a token or a URL pointer. Now you have to make up your mind - > use @ref if its a pointer, @key if its a private token. > > No, the @rend attribute has NOT changed its datatype > or semantics in this release. > > As ever, the release is on Sourceforge, on the Debian package repository > at http://tei.oucs.ox.ac.uk/teideb/, and on the TEI web site. A Live > CD will be ready shortly, Dr Who permitting (UK readers > will know whta I mean...) > -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Mon May 28 08:33:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 28 May 2007 08:33:10 -0400 Subject: [tei-council] place meeting? Message-ID: <18010.52230.92805.529954@emt.wwp.brown.edu> I am gathering from oblique references in various posts that the place-name meeting has not only been set up, but will be happening tomorrow. Has the Council been kept abreast of its progress (as was actioned in Berlin), and I missed it while away on my various travels? Who is attending? What's the agenda? The expected deliverable? Not that I think it matters much, but are *any* North Americans invited? I've also forgotten what is left in the budget to cover this meeting. Good luck to those attending, I hope you have a very productive meeting and a good time. From arianna.ciula at kcl.ac.uk Mon May 28 08:51:01 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 28 May 2007 13:51:01 +0100 Subject: [tei-council] place meeting? In-Reply-To: <18010.52230.92805.529954@emt.wwp.brown.edu> References: <18010.52230.92805.529954@emt.wwp.brown.edu> Message-ID: <465AD035.1000805@kcl.ac.uk> Syd Bauman wrote: > I am gathering from oblique references in various posts that the > place-name meeting has not only been set up, but will be happening > tomorrow. Yes, it will. Has the Council been kept abreast of its progress (as was > actioned in Berlin), and I missed it while away on my various > travels? No progress so far. The meeting is tomorrow and we will certainly report on the discussion. Who is attending? Lou, Sebastian, James, Matthew, me, Gabriel Bodard, Tom Elliott (on skype), Leif Isaksen (Oxford Archaeology) and Stuart Dunn (methods Network). What's the agenda? we don't have an official agenda ...sorry The expected > deliverable? In general terms: some clear specifications on what to do as far as the encoding of data about places regard (i.e. additions to the ND chapter). I am sure others could give more specific indications. Not that I think it matters much, but are *any* North > Americans invited? Tom Elliott. > > Good luck to those attending, I hope you have a very productive > meeting and a good time. Thank-you, Arianna > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From Syd_Bauman at Brown.edu Mon May 28 09:00:53 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Mon, 28 May 2007 09:00:53 -0400 Subject: [tei-council] place meeting? In-Reply-To: <465AD035.1000805@kcl.ac.uk> References: <18010.52230.92805.529954@emt.wwp.brown.edu> <465AD035.1000805@kcl.ac.uk> Message-ID: <18010.53893.300768.718455@emt.wwp.brown.edu> Thank you, Arianna! > > Has the Council been kept abreast of its progress (as was > > actioned in Berlin), and I missed it while away on my various > > travels? > > No progress so far. ... I meant progress in planning, sorry. From lou.burnard at computing-services.oxford.ac.uk Mon May 28 11:37:33 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 28 May 2007 16:37:33 +0100 Subject: [tei-council] Re: TEI P5 release 0.7 In-Reply-To: <465AC1C9.3080302@kcl.ac.uk> References: <46585FCC.6040700@oucs.ox.ac.uk> <465AC1C9.3080302@kcl.ac.uk> Message-ID: <465AF73D.2060408@computing-services.oxford.ac.uk> Ooops. Thanks for spotting this. Removed. L Arianna Ciula wrote: > > Hi, > > I have noticed that nymKey has now correctly become > nymRef (therefore datat.pointer); however there is still > one reference to nymKey in the ND prose. > > I suppose we could deal with this tomorrow, but since it's an easy fix > and the new chapter is already public, I thought useful to point it out. > > Arianna > > > Sebastian Rahtz wrote: >> A new release of P5 has just slipped its mooring and glided away into >> the darkling night, >> accompanied by its Stylesheets and Roma consorts, intent on havoc >> across the text >> encoding oceans. >> >> This release is relatively minor, but is the start of what I hope >> will be 4 more releases >> before the final 1.0; so expect to see the predators emerging once a >> month or so from now on. >> >> The release includes many small fixes made at the TEI Council's spring >> meeting in Berlin, though there are a lot still to come from that. >> Among the >> (obscure) things you may notice: >> >> *) the hoary old entities/macros mix.drama, mix.verse etc are all gone. >> if conceivably you mourn their passing, let us know >> >> *) the macro.component object has also gone, replaced by simply >> a call to macro.common. You may have this in an existing ODD file >> - contact me if you cannot see how to fix. >> >> *) the att.naming class adds a new @ref attribute to things like . >> This removes a confusion whereby the @key attribute was said to allow >> either a token or a URL pointer. Now you have to make up your mind - >> use @ref if its a pointer, @key if its a private token. >> >> No, the @rend attribute has NOT changed its datatype >> or semantics in this release. >> >> As ever, the release is on Sourceforge, on the Debian package repository >> at http://tei.oucs.ox.ac.uk/teideb/, and on the TEI web site. A Live >> CD will be ready shortly, Dr Who permitting (UK readers >> will know whta I mean...) >> > From Syd_Bauman at Brown.edu Tue May 29 17:01:10 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 29 May 2007 17:01:10 -0400 Subject: [tei-council] place meeting? In-Reply-To: <18010.53893.300768.718455@emt.wwp.brown.edu> References: <18010.52230.92805.529954@emt.wwp.brown.edu> <465AD035.1000805@kcl.ac.uk> <18010.53893.300768.718455@emt.wwp.brown.edu> Message-ID: <18012.38038.754247.734771@emt.wwp.brown.edu> I'm sorry I wasn't able to post this before the place meeting occured earlier today. I never got the chance in Berlin to give my comments on the "Draft proposals for representation of geographic information" document. Most of the scribbles on my hard-copy are typos. But I went over it again and found two substantive issues: * In an example of , the element is used. Per previous Council discussions, the element was removed. I am not sure if this document is recommending that it be brought back for this purpose or not. (Personally, I think will do for this usage.) * There are 3 examples of using latitude and longitude to indicate a place's location (in #MYF, #IS, and #ESB), and they are all different! 41.687142 -74.870109 65 00 N, 18 00 W 40.7484° N 73.9858° W Use of latitude and longitude to locate a place is going to be *extremely* common, and, IMHO, fits squarely into that category of things where it is more important that we all do it the same than that we have the capability to do it however we want. I.e., the TEI Guidelines should recommend one and only one method for encoding these. Note, BTW, that is, as currently defined, not a particularly good way to encode a latitude or longitude (nor a latitude and longitude). This is because latitude and longitude traditionally include a direction, for which does not provide a place for normalization. However, it may be quite reasonable to simply decide to use the common system of using negative values for S and W: 40°44'54.21" N 70°59'06" W 28°00'22" S 153°25'46" E Using negative values for S and W is what's done in digital mapping applications, or so I've read. I think I like this the best. (That second example is the location of Queensland Number One: "At 323 m [it] is the world's tallest all-residential building, when measured to the top of its spire.".) The advantage of using , is that the normalized decimal degrees using negatives for S and W can be stored in the attribute values, and users can do whatever they want for the content. BTW, decimal degrees should be used as the value of quantity=, not degrees, minutes, seconds. (Obviously, because the unit= is "degrees", not "DMS" -- but ISO 31 recommends that the degree be subdivided decimally rather than using the minute and second.) From sebastian.rahtz at oucs.ox.ac.uk Tue May 29 18:45:09 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 29 May 2007 23:45:09 +0100 Subject: [tei-council] place meeting? In-Reply-To: <18012.38038.754247.734771@emt.wwp.brown.edu> References: <18010.52230.92805.529954@emt.wwp.brown.edu> <465AD035.1000805@kcl.ac.uk> <18010.53893.300768.718455@emt.wwp.brown.edu> <18012.38038.754247.734771@emt.wwp.brown.edu> Message-ID: <465CACF5.5010104@oucs.ox.ac.uk> I am glad to say that the issue of representing latitude/longitude got a thorough and constructive airing at the meeting today; I am not sure the scheme we ended up with is perfect yet, but it's well on the way. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From cwittern at gmail.com Thu May 31 00:03:42 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 31 May 2007 13:03:42 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items Message-ID: <465E491E.4070009@gmail.com> Dear Council members, Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like to see the action/trac items resulting from the Berlin meeting cleared out by that time. Please go once again to look at http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example) http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review and make sure that the things on your table get done. I would also like to ask those who are revising / composing working documents, to get the documents ready by June 8, so that we have time to review them before the call. As always, please report work done here (and close/update the corresponding trac ticket) so that we know whats going on. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From James.Cummings at oucs.ox.ac.uk Thu May 31 04:58:56 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 31 May 2007 09:58:56 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465E491E.4070009@gmail.com> References: <465E491E.4070009@gmail.com> Message-ID: <465E8E50.5070108@oucs.ox.ac.uk> Wittern Christian wrote: > Dear Council members, > > Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like > to see the action/trac items resulting from the Berlin meeting cleared > out by that time. Please go once again to look at > http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example) > http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review > and make sure that the things on your table get done. Could I remind all the council that each one of you is meant to send Dot and I (though send to my email address) a minimum of 5 ways you'd improve the formatting of the HTML version of the Guidelines. No deadline was set for that, but I'd like to now suggest that each of you do this by the 5 June 2007.. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Thu May 31 06:53:23 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 11:53:23 +0100 Subject: [tei-council] USE chapter Message-ID: <465EA923.20804@computing-services.oxford.ac.uk> Somewhat later than hoped, I've now done some revision of the CF chapter in line with Council's desire that this should make clearer that there are many paths to the city of righteousness. In the process I also put in a place marker for a new section on ODD implementation and wrote an introductory para for the USE chapter itself (this was a trac item mysteriously associated with the AB chapter and previous assigned to Syd, so he owes me one!) From lou.burnard at computing-services.oxford.ac.uk Thu May 31 07:02:38 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 12:02:38 +0100 Subject: [tei-council] Trac Message-ID: <465EAB4E.5080900@computing-services.oxford.ac.uk> If we are serious about using TRAC to get this job done, could the junta responsible please tidy it up a bit? In particular : is "rahtz" the same sentient being as "sebastian" and do we need both of them? The former has dozens of tickets, most but not all of which I believe are now superannuated; the latter has only three. Sorry if this was explained earlier and I missed it in the welter of other buziness. From lou.burnard at computing-services.oxford.ac.uk Thu May 31 08:53:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 31 May 2007 13:53:05 +0100 Subject: [tei-council] Place meeting at Kings Message-ID: <465EC531.2060500@computing-services.oxford.ac.uk> A brief report on issues discussed and proposals agreed at Tuesday's meeting on Geographical data is now available at http://www.tei-c.org/Activities/PERS/placeMtg.xml (couldnt think of anywhere else to put it) The meeting felt, in summary, that - the places proposal developed in Vilnius should be included in P5, modulo various clarifications and enhancements - to facilitate this, two existing TEI elements would need to be renamed: and - the existing material on etc needed to be completely revised with several elements disappearing - some minor changes were proposed for the treatment of dates and times Feedback from Council members on these specific issues would be much appreciated. Many thanks to Arianna and others at CCH for organizing and hosting the meeting so efficiently! From cwittern at gmail.com Thu May 31 21:31:47 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 01 Jun 2007 10:31:47 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465E8E50.5070108@oucs.ox.ac.uk> References: <465E491E.4070009@gmail.com> <465E8E50.5070108@oucs.ox.ac.uk> Message-ID: <465F7703.1060503@gmail.com> OK, here is my 5 cents: 1) get rid of the sidebar or make it configurable 2) have a "print view" 3) show possible parents of elements in the reference chapter 4) show possible children of elements in the reference chapter 5) Tidy up the display of rng fragments and make the display (and print!) of these passages optional All the best, Christian James Cummings wrote: > Wittern Christian wrote: > >> Dear Council members, >> >> Our next telecon is scheduled for June 15, 2007 12:00 UTC. I would like >> to see the action/trac items resulting from the Berlin meeting cleared >> out by that time. Please go once again to look at >> http://www.tei-c.org/Council/tcm30.xml?style=printable and (for example) >> http://tei.oucs.ox.ac.uk/trac/TEIP5/milestone/Actions%20from%20chapter%20review >> and make sure that the things on your table get done. >> > > Could I remind all the council that each one of you is meant to send Dot > and I (though send to my email address) a minimum of 5 ways you'd improve > the formatting of the HTML version of the Guidelines. > > No deadline was set for that, but I'd like to now suggest that each of you > do this by the 5 June 2007.. > > -James > -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From cwittern at gmail.com Thu May 31 21:43:10 2007 From: cwittern at gmail.com (Wittern Christian) Date: Fri, 01 Jun 2007 10:43:10 +0900 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465EC531.2060500@computing-services.oxford.ac.uk> References: <465EC531.2060500@computing-services.oxford.ac.uk> Message-ID: <465F79AE.2090201@gmail.com> Thanks for the report, which seems to indicate to me that the meeting was very successful. As to the proposals, they all seem plausible and have my support, including the new element (I'd prefer this to . According to the report, would also be among the candidates for renaming. All the best, Christian Lou Burnard wrote: > A brief report on issues discussed and proposals agreed at Tuesday's > meeting on Geographical data is now available at > http://www.tei-c.org/Activities/PERS/placeMtg.xml (couldnt think of > anywhere else to put it) > > The meeting felt, in summary, that > - the places proposal developed in Vilnius should be included in P5, > modulo various clarifications and enhancements > - to facilitate this, two existing TEI elements would need to be > renamed: and > - the existing material on etc needed to be completely > revised with several elements disappearing > - some minor changes were proposed for the treatment of dates and times > > Feedback from Council members on these specific issues would be much > appreciated. > > Many thanks to Arianna and others at CCH for organizing and hosting > the meeting so efficiently! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 1 03:50:16 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 01 Jun 2007 08:50:16 +0100 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465F79AE.2090201@gmail.com> References: <465EC531.2060500@computing-services.oxford.ac.uk> <465F79AE.2090201@gmail.com> Message-ID: <465FCFB8.2030409@oucs.ox.ac.uk> Wittern Christian wrote: > > As to the proposals, they all seem plausible and have my support, > including the new element (I'd prefer this to . > According to the report, would also be among the candidates > for renaming. > its an @period attribute to join all the other dating attributes, actually. and is new, but replaces -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 04:54:48 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 09:54:48 +0100 Subject: [tei-council] Place meeting at Kings In-Reply-To: <465F79AE.2090201@gmail.com> References: <465EC531.2060500@computing-services.oxford.ac.uk> <465F79AE.2090201@gmail.com> Message-ID: <465FDED8.7080308@computing-services.oxford.ac.uk> Wittern Christian wrote: > Thanks for the report, which seems to indicate to me that the meeting > was very successful. > > As to the proposals, they all seem plausible and have my support, > including the new element (I'd prefer this to . It wasn't proposed as an element, but as an attribute. > According to the report, would also be among the candidates > for renaming. eh? From James.Cummings at oucs.ox.ac.uk Fri Jun 1 06:59:39 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 01 Jun 2007 11:59:39 +0100 Subject: [tei-council] @reg on country Message-ID: <465FFC1B.5020306@oucs.ox.ac.uk> Hi there, Now I know this problem might be about to disappear as @reg attributes vanish in a puff of rationalisation, however in answering an enquiry about placenames I had reason to look up the country element. Currently the country element has a @reg attribute whose data-type is {data.code}? where data.code resolves to xsd:anyURI. See: http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-country.html What bothered me was that @reg is defined as supplying "a regularized form of the country name using a name or code from ISO 3166". However, since the datatype of reg is a URI, what the example: Denmark means is that there is a file 'DK' that this element is point at. So ok, it should be #DK and point to the places you've defined up in your header or wherever. But the problem with that is it ignores that this is a fixed value list of codes from ISO 3166 and instead makes it a URI. Just seems wrong to me. Roll on @ref (for those countries not defined by ISO3166) and cref (for those which are, I'd say. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 11:18:05 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 16:18:05 +0100 Subject: [tei-council] What did we decide? Message-ID: <466038AD.5060104@computing-services.oxford.ac.uk> I thought we had some discussion in Berlin about what the Guidelines should say about the feasibility of constructing a TEI schema by non-ODD methods, e.g. by lumping together references to TEI dtd fragments within a doctype, or building a relaxng schema by referencing the TEI Relaxng modules. I cannot however find any reference to it in the minutes (instead they seem to document all sorts of minor corrections which we not only decided but dealt with in the meeting itself) Before I go ahead and rewrite history, here's what I believe the party line to be: 1. TEI Conformance (whether implicit or algorithmic) requires that there be an ODD. Therefore if you don't have an ODD, you cannot be TEI conformant. 2. Nevertheless, we do create TEI modules as distinct schema/DTD fragments, with published names (someone was actioned to review the names I think? sebastian?) and document said names and modules. So, if you're smart, you can go ahead and build yourself a TEI aschema without an ODD. But we don't promise it will always work -- at release 1.n we might (for example) move an element from one module to another. Argal, the discussion in ST.xml#STIN should refer only to ODDs? (which is where I came in) From djbpitt+tei at pitt.edu Fri Jun 1 11:35:22 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 01 Jun 2007 11:35:22 -0400 Subject: [tei-council] What did we decide? In-Reply-To: <46603C95.4010006@pitt.edu> References: <466038AD.5060104@computing-services.oxford.ac.uk> <46603C95.4010006@pitt.edu> Message-ID: <46603CBA.1040609@pitt.edu> Dear Lou (cc Council), My memory about this is a bit foggy, but I thought someone suggested in Berlin that since TEI conformance requires an ODD, the Guidelines should say nothing about modifying the TEI otherwise than through the use of an ODD. That is, although other types of modification can be implemented by someone perverse enough to try, the Guidelines shouldn't get involved in (or even acknowledge the existence of) such non-conformant endeavors. I don't remember whether we agreed on this or whether it just floated around the table, slipped out under the door, headed down in the pater noster, and disappeared across the square, but whatever the disposition, I think it would 1) make our lives easier and 2) make the lives of those who wish to modify the TEI easier. Best, David > > Lou Burnard wrote: >> I thought we had some discussion in Berlin about what the Guidelines >> should say about the feasibility of constructing a TEI schema by >> non-ODD methods, e.g. by lumping together references to TEI dtd >> fragments within a doctype, or building a relaxng schema by >> referencing the TEI Relaxng modules. >> >> I cannot however find any reference to it in the minutes (instead >> they seem to document all sorts of minor corrections which we not >> only decided but dealt with in the meeting itself) >> >> Before I go ahead and rewrite history, here's what I believe the >> party line to be: >> >> 1. TEI Conformance (whether implicit or algorithmic) requires that >> there be an ODD. Therefore if you don't have an ODD, you cannot be >> TEI conformant. >> >> 2. Nevertheless, we do create TEI modules as distinct schema/DTD >> fragments, with published names (someone was actioned to review the >> names I think? sebastian?) and document said names and modules. >> >> So, if you're smart, you can go ahead and build yourself a TEI >> aschema without an ODD. But we don't promise it will always work -- >> at release 1.n we might (for example) move an element from one module >> to another. >> >> Argal, the discussion in ST.xml#STIN should refer only to ODDs? >> (which is where I came in) >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From lou.burnard at computing-services.oxford.ac.uk Fri Jun 1 13:33:52 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 01 Jun 2007 18:33:52 +0100 Subject: [tei-council] What did we decide? In-Reply-To: <46603C95.4010006@pitt.edu> References: <466038AD.5060104@computing-services.oxford.ac.uk> <46603C95.4010006@pitt.edu> Message-ID: <46605880.7030106@computing-services.oxford.ac.uk> Thanks David. If you check http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/33 and http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/54 you'll see that I've at last got round to your helpful comments on those chapters at least. L David J Birnbaum wrote: > Dear Lou (cc Council), > > My memory about this is a bit foggy, but I thought someone suggested in > Berlin that since TEI conformance requires an ODD, the Guidelines should > say nothing about modifying the TEI otherwise than through the use of an > ODD. That is, although other types of modification can be implemented by > someone perverse enough to try, the Guidelines shouldn't get involved in > (or even acknowledge the existence of) such non-conformant endeavors. > > I don't remember whether we agreed on this or whether it just floated > around the table, slipped out under the door, headed down in the pater > noster, and disappeared across the square, but whatever the disposition, > I think it would 1) make our lives easier and 2) make the lives of those > who wish to modify the TEI easier. > > Best, > > David > > Lou Burnard wrote: >> I thought we had some discussion in Berlin about what the Guidelines >> should say about the feasibility of constructing a TEI schema by >> non-ODD methods, e.g. by lumping together references to TEI dtd >> fragments within a doctype, or building a relaxng schema by >> referencing the TEI Relaxng modules. >> >> I cannot however find any reference to it in the minutes (instead they >> seem to document all sorts of minor corrections which we not only >> decided but dealt with in the meeting itself) >> >> Before I go ahead and rewrite history, here's what I believe the party >> line to be: >> >> 1. TEI Conformance (whether implicit or algorithmic) requires that >> there be an ODD. Therefore if you don't have an ODD, you cannot be TEI >> conformant. >> >> 2. Nevertheless, we do create TEI modules as distinct schema/DTD >> fragments, with published names (someone was actioned to review the >> names I think? sebastian?) and document said names and modules. >> >> So, if you're smart, you can go ahead and build yourself a TEI aschema >> without an ODD. But we don't promise it will always work -- at release >> 1.n we might (for example) move an element from one module to another. >> >> Argal, the discussion in ST.xml#STIN should refer only to ODDs? (which >> is where I came in) >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From djbpitt+tei at pitt.edu Fri Jun 1 14:18:30 2007 From: djbpitt+tei at pitt.edu (David J Birnbaum) Date: Fri, 01 Jun 2007 14:18:30 -0400 Subject: [tei-council] What did we decide? In-Reply-To: <46605880.7030106@computing-services.oxford.ac.uk> References: <466038AD.5060104@computing-services.oxford.ac.uk> <46603C95.4010006@pitt.edu> <46605880.7030106@computing-services.oxford.ac.uk> Message-ID: <466062F6.9090008@pitt.edu> Dear Lou (cc Council), Thanks! > where does apostrophe mark a plural in English? /It disambiguates phrases like "the dogs' paws" and "the dog's paws" /Call me an orthographic or linguistic pedant, but the "s" marks the plural in "the dogs' paws" and the apostrophe marks the possessive in both "the dog's paws" and "the dogs' paws". That is, although the relative place of the apostrophe and the "s" distinguishes the singular from the plural, it is not the apostrophe, but the "s", that marks the plural. > "Parentheses and other marks of suspension" should omit "other" /Why? "suspension" is being used in a linguistic sense here /This isn't the meaning of suspension that occurred to me when I read it, but I understand now. > /"Element foreign" has some "include" notes /Sorry, I dont understand this comment There were places (here and elsewhere in my sections) where there were notes that said something like "Include xxx" (with a title or number or something in place of the xxx). That seems like a clumsy sort of link; shouldn't we either actually include the text or word the links as something like "more information about xxx is available at yyy"? "Include xxx" sounds like an instruction in a processing environment, not part of guidelines or documentation. > Stray leading backslash in "\list = element list { list.content, list.attributes }" /Not a stray: RELAXNC needs it / Oops. Sorry! > do we need separate data.TruthValue?? and data.xTruthValue classes? Isn't this like specifying language where it has to be European, i.e., a formal restriction where user error is unlikely? /Not sure I understand this analogy / I think what I meant was that we might consider having a single class that accepts booleans, "unknown", and "inapplicable", and that we don't have to have a separate boolean-only class because users who want the more restricted boolean-only option are likely to select "unknown" or "inapplicable", and don't need to be protect from it by the schema. I think the point of the analogy was that a project that requires us to specify the language of some text doesn't usually provided a narrowly constrained list of languages, and trusts instead that the user does not need to be protected from picking an inappropriate one, and that one might take the same attitude toward the two boolean-like classes. I don't feel strongly about this, but it did seem as if we were using two classes where one would probably meet our users' needs. Best, David / /Lou Burnard wrote: > Thanks David. > > If you check > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/33 > and > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/54 > you'll see that I've at last got round to your helpful comments on > those chapters at least. > > L > > > David J Birnbaum wrote: >> Dear Lou (cc Council), >> >> My memory about this is a bit foggy, but I thought someone suggested >> in Berlin that since TEI conformance requires an ODD, the Guidelines >> should say nothing about modifying the TEI otherwise than through the >> use of an ODD. That is, although other types of modification can be >> implemented by someone perverse enough to try, the Guidelines >> shouldn't get involved in (or even acknowledge the existence of) such >> non-conformant endeavors. >> >> I don't remember whether we agreed on this or whether it just floated >> around the table, slipped out under the door, headed down in the >> pater noster, and disappeared across the square, but whatever the >> disposition, I think it would 1) make our lives easier and 2) make >> the lives of those who wish to modify the TEI easier. >> >> Best, >> >> David >> >> Lou Burnard wrote: >>> I thought we had some discussion in Berlin about what the Guidelines >>> should say about the feasibility of constructing a TEI schema by >>> non-ODD methods, e.g. by lumping together references to TEI dtd >>> fragments within a doctype, or building a relaxng schema by >>> referencing the TEI Relaxng modules. >>> >>> I cannot however find any reference to it in the minutes (instead >>> they seem to document all sorts of minor corrections which we not >>> only decided but dealt with in the meeting itself) >>> >>> Before I go ahead and rewrite history, here's what I believe the >>> party line to be: >>> >>> 1. TEI Conformance (whether implicit or algorithmic) requires that >>> there be an ODD. Therefore if you don't have an ODD, you cannot be >>> TEI conformant. >>> >>> 2. Nevertheless, we do create TEI modules as distinct schema/DTD >>> fragments, with published names (someone was actioned to review the >>> names I think? sebastian?) and document said names and modules. >>> >>> So, if you're smart, you can go ahead and build yourself a TEI >>> aschema without an ODD. But we don't promise it will always work -- >>> at release 1.n we might (for example) move an element from one >>> module to another. >>> >>> Argal, the discussion in ST.xml#STIN should refer only to ODDs? >>> (which is where I came in) >>> >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> > From lou.burnard at computing-services.oxford.ac.uk Sun Jun 3 09:31:01 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 03 Jun 2007 14:31:01 +0100 Subject: [tei-council] intro to XML chapter Message-ID: <4662C295.1020704@computing-services.oxford.ac.uk> I'm working on the overdue revision of this chapter and hope to have a draft ready in a day or so. Meanwhile here's how YOU can help: There's a blithe comment early on in this chapter about the dozens of other places where you can learn about XML, to which is attached a footnote saying "For example...." If every member of the Council sent me their top 5 favourite recommendations for what should be on that list, what a happy bunny I would be. No you may not cite either the chapter I am revising or the Annotated W3C recommendations. I promise to collate and circulate the results of this enquiry whatever gets into the footnote! From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 3 10:04:54 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 03 Jun 2007 15:04:54 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <465F7703.1060503@gmail.com> References: <465E491E.4070009@gmail.com> <465E8E50.5070108@oucs.ox.ac.uk> <465F7703.1060503@gmail.com> Message-ID: <4662CA86.8000208@oucs.ox.ac.uk> Wittern Christian wrote: > 1) get rid of the sidebar or make it configurable > where would you put the table of contents? > 5) Tidy up the display of rng fragments can you elucidate? in what sense are they not tidy? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 3 18:02:01 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 03 Jun 2007 23:02:01 +0100 Subject: [tei-council] @reg on country In-Reply-To: <465FFC1B.5020306@oucs.ox.ac.uk> References: <465FFC1B.5020306@oucs.ox.ac.uk> Message-ID: <46633A59.5000106@oucs.ox.ac.uk> sounds like to me? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From cwittern at gmail.com Sun Jun 3 21:27:26 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 04 Jun 2007 10:27:26 +0900 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <4662CA86.8000208@oucs.ox.ac.uk> References: <465E491E.4070009@gmail.com> <465E8E50.5070108@oucs.ox.ac.uk> <465F7703.1060503@gmail.com> <4662CA86.8000208@oucs.ox.ac.uk> Message-ID: <46636A7E.8020609@gmail.com> Sebastian Rahtz wrote: > Wittern Christian wrote: > >> 1) get rid of the sidebar or make it configurable >> >> > where would you put the table of contents? > I would think you could use breadcrumbs for the uplink back to a full toc and have only the toc for the chapter itself at the beginning of the text. >> 5) Tidy up the display of rng fragments >> > can you elucidate? in what sense are they not > tidy? > When printing, they seem to run occasionally over the edge of the page. Thinking of it, the same also happens to the examples here and there. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 4 03:54:41 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 04 Jun 2007 08:54:41 +0100 Subject: [tei-council] reminder: upcoming telecon, action/trac items In-Reply-To: <46636A7E.8020609@gmail.com> References: <465E491E.4070009@gmail.com> <465E8E50.5070108@oucs.ox.ac.uk> <465F7703.1060503@gmail.com> <4662CA86.8000208@oucs.ox.ac.uk> <46636A7E.8020609@gmail.com> Message-ID: <4663C541.2010609@oucs.ox.ac.uk> Wittern Christian wrote: > > I would think you could use breadcrumbs for the uplink back to a full > toc and have only the toc for the chapter itself at the beginning of the > text. > ok, I see. I'll leave that with James and Dot. > > When printing, they seem to run occasionally over the edge of the page. > Thinking of it, the same also happens to the examples here and there. > oh dear, this is hard to deal with ...:-{ both the schema fragments and examples are pretty-printing. and the algorithm obviously needs more tweaking. sigh. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 4 06:28:46 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 04 Jun 2007 11:28:46 +0100 Subject: [tei-council] What did we decide? In-Reply-To: <466038AD.5060104@computing-services.oxford.ac.uk> References: <466038AD.5060104@computing-services.oxford.ac.uk> Message-ID: <4663E95E.3060204@oucs.ox.ac.uk> Lou Burnard wrote: > > 1. TEI Conformance (whether implicit or algorithmic) requires that > there be an ODD. Therefore if you don't have an ODD, you cannot be TEI > conformant. with the caveat that your ODD can be tei_all > > 2. Nevertheless, we do create TEI modules as distinct schema/DTD > fragments, with published names (someone was actioned to review the > names I think? sebastian?) and document said names and modules. the names are used in an ODD anyway with , so thats needed regardless > > So, if you're smart, you can go ahead and build yourself a TEI aschema > without an ODD. But we don't promise it will always work -- at release > 1.n we might (for example) move an element from one module to another. and then your ODD will break too. You can't have it both ways. If we generate DTD and RELAXNG module fragments and publish them, the punter has a reasonable expectation that a) we won't willfully break them, and b) we will explain how to use them. Otherwise, let's stop generating the wretched creatures! I think you can simply not discuss it, and leave it to IM to document what actually happens -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From laurent.romary at loria.fr Mon Jun 4 11:29:26 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 4 Jun 2007 17:29:26 +0200 Subject: [tei-council] Dictionary chapter update and proposal Message-ID: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> Dear all, Since our last meeting we been going through the PD chapter, trying to see room for improvement. Element descriptions will thus be completed by appropriate examples and tiny editorial improvements made (before the more extensive linguistic editing that Lou would like to do on the chapter). I would like to address here a specific issue related to a change we would like to operate on the technical content of the chapter: using in replacement to and . This follows a discussion I had with Lou (and technical fights with Roma), where we tried to revisit the intrinsic complexity of various elements in the disctionary chapter which seem more or less to express the same structure as , namely and . A replacement by would imply among other thing to introduce a class (model.citDesc) in the content model of to which one could attach whatever kind of descriptive elements (dictionnary elements in the case of the dictionary module, but I could anticipate useful applications in many domains). I think we do have here a very nice simplification of quite a generic structure and would really like to have it endorsed by the council. I am thus asking you: a) your opinion about the thing b) your green light to put it on the P5 1.0 agenda You will find below a set of dictionary examples together with the ODD file. Best wishes, Laurent My TEI Extension generated by Roma 2.11

for use by whoever wants it

created on Wednesday 23rd May 2007 12:24:00 PM by the form at http://www.tei-c.org.uk/Roma/

 Class of descriptive elements for cit constructs data.word
r?moulade Remulad
n f remoulade r?moulade dressing containing mustard and herbs
dresser
Theat habilleur m -euse f Comm
window
?talagiste mf she's a stylish elle s'habille avec chic V. hair tool for wood raboteuse f for stone rabotin m OAS illegal military organization supporting French rule of Algeria
havdalah havdoloh
Judaism the ceremony marking the end of the sabbath or of a festival, including the blessings over wine, candles and spices. literally separation and any are used with more Give me more s@'mO:(r) to horrify elle ?tait horrifi?e par la d?pense she was horrified at the expense. Vx. Vaillance, bravoure (sp?cial., au combat) La valeur n'attend pas le nombre des ann?es Corneille Peinture lit fig palette Boucherie shoulder aube de roue paddle battoir ? linge beetle Manutention Constr pallet reseating rebottoming with straw
ain't eInt
Not standard
contraction of am not is not are not have not has not
I ain't seen it. Although the interrogative form ain't I? would be a natural contraction of am I not?, it is generally avoided in spoken English and never used in formal English.
vag- vago-
vagus nerve al tomy Mr Burton took us for French was quite n with him it's easy to mix her up with her sister Geog
Canary Isles Canaries
?les f pl Canaries f pl From lou.burnard at computing-services.oxford.ac.uk Tue Jun 5 05:51:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 05 Jun 2007 10:51:57 +0100 Subject: [tei-council] Dictionary chapter update and proposal In-Reply-To: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> References: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> Message-ID: <4665323D.3090508@computing-services.oxford.ac.uk> As Laurent and I have already discussed this on a couple of occasions, I will try to repeat here my understanding of the proposed change to (but please note I may have got it wrong!) 1. At present we use as a way of grouping a quote-like thing with a bibl-like thing and/or a pointer-like thing, as a means of asserting that this quote is associated with that source. 2. However, it is certainly the case in dictionaries and not implausibly the case elsewhere, that there lurks in the vicinity of the cit a third thing explaining exactly why or how this quote is being used (plus or minus its attribution) in this context, which it would be more convenient to regard as a child of the cit than as a sibling of it 3. I have suggested that model.noteLike would do for this purpose, but Laurent feels that a more specific class is needed -- his proposed model.citDesc Laurent's note includes a long list of utterly splendid examples, which I would like to read through and comment on at length, but just to illustrate how the proposal works, consider the following one: and any are used with more Give me more s@'mO:(r) Under sense 4 of "some", there is a cit which wraps both a quote "Give me _ more" (the is a reference to the element containing "some", a specialized ptr if you like) and a note about how this particular example should be pronounced. The doesn't belong to the sense, and it doesn't belong, really, to the headword "some" -- just to this quotation. I think we should try to get this change into P5 in some shape: it will simplify the dictionary chapter and may be useful elsewhere. What do others think? Lou Laurent Romary wrote: > Dear all, > Since our last meeting we been going through the PD chapter, trying to > see room for improvement. // From cwittern at gmail.com Thu Jun 7 03:52:12 2007 From: cwittern at gmail.com (Wittern Christian) Date: Thu, 07 Jun 2007 16:52:12 +0900 Subject: [tei-council] Dictionary chapter update and proposal In-Reply-To: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> References: <18855844-D25D-48F2-A2DB-7CE910851F23@loria.fr> Message-ID: <4667B92C.7020406@gmail.com> Laurent Romary wrote: > Dear all, > Since our last meeting we been going through the PD chapter, trying to > see room for improvement. Element descriptions will thus be completed > by appropriate examples and tiny editorial improvements made (before > the more extensive linguistic editing that Lou would like to do on the > chapter). > I would like to address here a specific issue related to a change we > would like to operate on the technical content of the chapter: using > in replacement to and . This follows a > discussion I had with Lou (and technical fights with Roma), where we > tried to revisit the intrinsic complexity of various elements in the > disctionary chapter which seem more or less to express the same > structure as , namely and . > A replacement by would imply among other thing to introduce a > class (model.citDesc) in the content model of to which one could > attach whatever kind of descriptive elements (dictionnary elements in > the case of the dictionary module, but I could anticipate useful > applications in many domains). I think we do have here a very nice > simplification of quite a generic structure and would really like to > have it endorsed by the council. > I am thus asking you: > a) your opinion about the thing The scope and intent seems right on spot. > b) your green light to put it on the P5 1.0 agenda I would like to see this in P5 1.0. I think we already agreed in Berlin that given the timescale no big changes can be made. However, the things you propose look more like a cleanup than a major revision so I think it is very much in the range of things that can be done. (I will need to look at the examples in more detail later.) All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Thu Jun 7 12:31:17 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 07 Jun 2007 17:31:17 +0100 Subject: [tei-council] Gentle intro updated Message-ID: <466832D5.6060508@computing-services.oxford.ac.uk> As promised earlier (in "a few days", hmm), I am pleased to announce that I have now finished a major rewrite of the "Gentle Introduction to XML" chapter of the Guidelines. The draft is checked into SF at the usual place, and there is also a printable PDF for your reading pleasure at http://www.tei-c.org/Drafts/FASC-SG.pdf This revision reflects primarily the action placed on me to get rid of all the DTD specific material, but I've taken the opportunity to rework a lot of the rest as well, bringing it a bit more up to date in line with its primary function of giving the novice reader just enough technical information to stand a chance of understanding the rest of the Guidelines, but certainly no more. I would much appreciate notification of any typos, blunders, materials omitted or egregious nonsense Council members care to identify before posting it more widely. From lou.burnard at computing-services.oxford.ac.uk Thu Jun 7 14:30:06 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Thu, 07 Jun 2007 19:30:06 +0100 Subject: [tei-council] that footnote Message-ID: <46684EAE.8050002@computing-services.oxford.ac.uk> Just for the record, I promised to report the result of my request for suggested reading on XML. Sebastian suggested: http://www.zvon.org/ http://www.w3schools.com/xml/default.asp http://xml.coverpages.org/ James suggested: 1) W3Schools: http://www.w3schools.com/xml/ 2) Zvon: http://www.zvon.org/xxl/XMLTutorial/General/book.html 3) Norm Walsh: http://www.zvon.org/xxl/XMLTutorial/General/book.html (though now dated) 4) XML.org list of resources: http://www.xml.org/xml/resources_focus_beginnerguide.shtml 5) Tizag XML tutorial: http://www.tizag.com/xmlTutorial/ Bonus) I hear that the IBM XML tutorial is good, but I've not tried it: http://www.ibm.com/developerworks/edu/x-dw-xmlintro-i.html Daniel suggested: I don't have five: I came from SGML which I learned from the Gentle introduction and the Spec. But here's one I used to learn XSLT and figure out my transition from SGML to XML: http://www.amazon.com/exec/obidos/ASIN/0764548190/ref=nosim/cafeaulaitA/ Rusty Harold, XML Bible. And the footnote,fwiw, now reads: New textbooks about XML appear at regular intervals and to select any one of them would be invidious. A useful list of pointers to introductory websites is available from ; recommended online course include and From sebastian.rahtz at oucs.ox.ac.uk Thu Jun 7 16:43:55 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 07 Jun 2007 21:43:55 +0100 Subject: [tei-council] Tite Message-ID: <46686E0B.9050004@oucs.ox.ac.uk> I propose to declare Tite finished. I have checked in a revised version to the TEI Exemplars area, ready for the next release. It has records for all the added elements, and an associated XSL stylesheet which does the transformation from algorithmically-conformant to directly-conformant (hence tite-acdc.xsl....). Four points to note: a) is declared to be

xxx

. does any disagree b) this means adding a "place" attribute to
, which Lou is now doing. c) is declared to be d) I told the prose to use @rend on ornament instead of @type Speak now, or forever hold your peace on these matters. Sebastian From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 05:38:57 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 08 Jun 2007 10:38:57 +0100 Subject: [tei-council] Re: Suggestions for P5 + a Manuscripts query In-Reply-To: <46690A59.6020904@ed.ac.uk> References: <46690A59.6020904@ed.ac.uk> Message-ID: <466923B1.6070502@computing-services.oxford.ac.uk> Dear Charlie Thanks for your note which I'm copying with this response to the TEI Council and to Murray McGilvray. The existing element isn't really meant for this kind of detailed codicological description: as it currently stands it's just a prose essay. Murray McGilvray's "physical bibliography" activity (PB) produced some more detailed proposals which certainly do address this need (see http://www.tei-c.org/Activities/PB/draft-0714.html) but which were not accepted by the TEI Council in their present form; the minutes (rather flatteringly for me!) express a preference for the approach Richard Gartner and I sketched out ages ago (see http://users.ox.ac.uk/~lou/wip/MS/msodd.htm#MSCOLL); more recent work in this area has also been carried out by Dot Porter at UKY (but I can't for the moment find a reference to it). There was some active discussion of the PB proposals on the PB mailing list last summer, but the TEI Council's attention has been fairly solidly engaged elsewhere in P5 since then. Sadly, I think it's now too late to get a properly worked out proposal for markup of physical document structure into the 1.0 release. But I certainly think it ought to be being planned and worked on now, and doing it as a P5 extension will make the task of subsequently integrating it that much easier. If you'd like to work on that, your input would be most welcome. It's not clear from your note what exactly you're currently doing though: presumably the fragment in your note is validated by a schema of some sort; is there an ODD describing that schema? if not, is there other documentation for it? best wishes Lou Charlie Mansfield wrote: > Dear Lou & Co > We're trying to bend the P5 to describe where miniatures sit within > folded quires in 14th C French manuscripts. See picture in PowerPoint > attached. > > I've dug through > http://www.tei-c.org/P5/Guidelines/ref-foliation.html > to give me the tags, but I need to stretch them further, I think. > > I'm not sure whether I', asking for advice or just wanting to tell > someone all this, but here goes... > > Recording Codicological Position of Miniatures within the Make-Up of > Quire Bundles (with Letter-names of Artists). Note: Some folios within > quires do not follow-through but terminate in a 'talon' or heel. > > > > > > Orpheus playing lyre to fish and birds > > > > > > > Ignore me if this all sounds too complicated but if someone is still > looking at mansucsript description then I'd welcome their thoughts. > > Best Wishes > Charlie > > Charlie Mansfield > AHRC Middle French Project > http://www.pizan.lib.ed.ac.uk/ > From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 10:38:26 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Fri, 08 Jun 2007 15:38:26 +0100 Subject: [tei-council] Action list from TCM30 Message-ID: <466969E2.30701@computing-services.oxford.ac.uk> As the action list from our meeting in Berlin, as presented in TCM 30, is infeasibly long and indigestible, Sebastian and I have now done some work (in consultation with Christian) on refining and prioritizing the items it contains which refer specifically to P5 matters. The revised document is available from http://www.tei-c.org/Council/tcm30-notes.xml?style=printable It combines in one handy list all the actions from the Berlin meeting and also from outstanding TRAC tickets, divided into (a) items still to be done, indicating the person/s allegedly responsible; (b) a few items where the action to be taken is either not clear to us, or needs greater discussion by the Council (c) a heartening number of items where the action is already complete. It would be very helpful if Council members could scan this list for (a) things we have overlooked or misrepresented (b) tasks allocated to them on which they can report Our suggestion is that this document would be a very useful way of organizing our next telecon. If there is a substantial amount of other business we should maybe schedule another call for that? From cwittern at gmail.com Fri Jun 8 18:47:53 2007 From: cwittern at gmail.com (Wittern Christian) Date: Sat, 09 Jun 2007 07:47:53 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC Message-ID: <4669DC99.2040703@gmail.com> Dear Council members, As usual I would like to collect things you think that need our attention and would like to see on the agenda. Please send them either to me or to the Council list. I plan to send out the draft agenda next Monday. All the best, Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From lou.burnard at computing-services.oxford.ac.uk Fri Jun 8 19:42:46 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sat, 09 Jun 2007 00:42:46 +0100 Subject: [tei-council] state and event Message-ID: <4669E976.9050609@computing-services.oxford.ac.uk> Amongst other things reported from the "geog" meeting at CCH a couple of weeks back, it was suggested that we would like to use and as generic states and events (rather than the current persState, placeState, orgState, etc. As these names unfortunately collide with the existing and elements (which got there first) I am now proposing to rename the existing elements, unless anyone has very strong objections. The existing element (used only in the rather obscure context of the Header's ) is the easy one: I propose to change it to The existing element (used in the only slightly less obscure context of the chapter on spoken transcription) is trickier to find a good replacement for. Sebastian suggests which is almost right but a bit long winded. Does anyone have better suggestions? From daniel.odonnell at uleth.ca Fri Jun 8 23:48:00 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Fri, 08 Jun 2007 21:48:00 -0600 Subject: [tei-council] state and event In-Reply-To: <4669E976.9050609@computing-services.oxford.ac.uk> References: <4669E976.9050609@computing-services.oxford.ac.uk> Message-ID: <1181360880.18928.0.camel@localhost> Very good solution. I like them. Another possibility might be occurrence instead of incident. But I don't care. I'm glad we are moving this way. -dan On Sat, 2007-06-09 at 00:42 +0100, Lou's Laptop wrote: > Amongst other things reported from the "geog" meeting at CCH a couple of > weeks back, it was suggested that we would like to use and > as generic states and events (rather than the current persState, > placeState, orgState, etc. > > As these names unfortunately collide with the existing and > elements > (which got there first) I am now proposing to rename the existing > elements, unless anyone has very strong objections. > > The existing element (used only in the rather obscure context of > the Header's ) is the easy one: I propose to change it to > > > The existing element (used in the only slightly less obscure > context of the chapter on spoken transcription) is trickier to find a > good replacement for. Sebastian suggests which is almost > right but a bit long winded. > > Does anyone have better suggestions? > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Sat Jun 9 04:40:36 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 09 Jun 2007 09:40:36 +0100 Subject: [tei-council] state and event In-Reply-To: <4669E976.9050609@computing-services.oxford.ac.uk> References: <4669E976.9050609@computing-services.oxford.ac.uk> Message-ID: <466A6784.6090304@oucs.ox.ac.uk> Lou's Laptop wrote: > > The existing element (used in the only slightly less obscure > context of the chapter on spoken transcription) is trickier to find a > good replacement for. Sebastian suggests which is almost > right but a bit long winded. sebastian From lou.burnard at computing-services.oxford.ac.uk Sun Jun 10 09:09:41 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop) Date: Sun, 10 Jun 2007 14:09:41 +0100 Subject: [tei-council] @key and @ref: recap ok? Message-ID: <466BF815.1010803@computing-services.oxford.ac.uk> About a month ago on this list we had some discussion about the attributes used to associate a name with its referent, i.e. how do you say that "Bill Sniggsw" in the text is actually the same person as "Wm Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis mutandis) how do you say that "Shipton" in your source is actually the place located at lat/long 14.2 13.2 and formerly known as "Brycgstow". As I work on integrating placeography outcomes into the chapter that treats these matters, I have found it helpful to briefly summarize the various linking attributes concerned once for all. This duplicates some matter presented elsewhere in the Guidelines, but it seemed convenient to recap it in this context. I'd be very grateful if you could read it through (it's only a few paras) and confirm (or deny) that it expresses the consensus we reached earlier reasonably well. -------------------------------------
Linking names and their referents

As members of the att.naming class, many of the elements described in this chapter share the following attributes: These attributes are designed to support two different ways of associating a name, of any kind, with its referent. The encoder may use either, neither, or both in combination as appropriate. The ref attribute should be used wherever it is possible to supply a direct link such as a URI to indicate the location of canonical information about the referent. For example: That silly man David Paul Brown has suffered ... This encoding requires that there exist somewhere in the same document a person element with the identifier DBP1, which will contain canonical information about this particular person, marked up using the elements discussed in below. The same element might alternatively be provided by some other document, of course, which the same attribute could refer to by means of a URI, as explained in : That silly man David Paul Brown has suffered ...

The key attribute is provided for cases where no such direct link is required: for example because resolution of the reference is carried out by some local convention, or because the encoder judges that no such resolution is necessary. As an example of the first case, a project might maintain its own local database system containing canonical information about persons and places, each entry in which is accessed by means of some system-specific identifier constructed in a project-specific way from the value supplied for the key attribute. In the module described by chapter a similar method is used to link element descriptions to the modules or classes to which they belong, for example. As an example of the second case, consider the use of well-established codifications such as country or airport codes, which it is probably unnecessary for an encoder to expand further: I never fly from Heathrow Airport to France

From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 12:46:38 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 17:46:38 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466C2AEE.6090403@oucs.ox.ac.uk> it's lovely, and I agree with it. but isn't a paragraph about @nymRef missing at the end? sebastian From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 12:56:27 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 17:56:27 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466C2D3B.20108@oucs.ox.ac.uk> do you also want a sentence mentioning cRef? sebastian From daniel.odonnell at uleth.ca Sun Jun 10 17:50:52 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 15:50:52 -0600 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <1181512252.32504.0.camel@localhost> Seems fine to me, though I don't like unresolvable keys, even for airports. On Sun, 2007-06-10 at 14:09 +0100, Lou's Laptop wrote: > About a month ago on this list we had some discussion about the > attributes used to associate a name with its referent, i.e. how do you > say that "Bill Sniggsw" in the text is actually the same person as "Wm > Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis > mutandis) how do you say that "Shipton" in your source is actually the > place located at lat/long 14.2 13.2 and formerly known as "Brycgstow". > > As I work on integrating placeography outcomes into the chapter that > treats these matters, I have found it helpful to briefly summarize the > various linking attributes concerned once for all. This duplicates some > matter presented elsewhere in the Guidelines, but it seemed convenient > to recap it in this context. > > I'd be very grateful if you could read it through (it's only a few > paras) and confirm (or deny) that it expresses the consensus we reached > earlier reasonably well. > > ------------------------------------- > >
Linking names and their referents > >

As members of the att.naming class, > many of the elements described in this chapter share the following > attributes: > > These attributes are designed to support two different ways of > associating a name, of any kind, with its referent. The encoder may > use either, neither, or both in combination as appropriate. The > ref attribute should be used wherever it is possible to supply > a direct link such as a URI to indicate the location of canonical > information about the referent. For example: > That silly man > David Paul Brown has suffered > ... > This encoding requires that there exist somewhere in the same document > a person element with the identifier DBP1, which > will contain canonical information about this particular person, > marked up using the elements discussed in > below. The same element might alternatively be provided by some other > document, > of course, which the same attribute could refer to by means of a URI, > as explained in : > That silly man > type="person">David Paul Brown has suffered > ...

>

The key attribute is provided for cases where no such > direct link is required: for example because resolution of the reference is > carried out by some local convention, or because the encoder judges > that no such resolution is necessary. As an example of the first case, > a project might maintain its own local database system > containing canonical information about persons and places, each entry > in which is accessed by means of some system-specific identifier > constructed in a project-specific way from the value supplied for the > key attribute. In the module described by > chapter a similar method is used to link element > descriptions to the modules or classes to which they belong, for > example. As an example of the second case, consider the use of > well-established codifications such as country or airport codes, which > it is probably unnecessary for an encoder to expand further: > > I never fly from Heathrow Airport > to France >

>
> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Sun Jun 10 18:00:17 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 10 Jun 2007 23:00:17 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <1181512252.32504.0.camel@localhost> References: <466BF815.1010803@computing-services.oxford.ac.uk> <1181512252.32504.0.camel@localhost> Message-ID: <466C7471.2090003@oucs.ox.ac.uk> Daniel O'Donnell wrote: > Seems fine to me, though I don't like unresolvable keys, even for > airports. > they are not unresolvable; just that they dont play in the world of URLs consider

ich bin ein berliner

- the token "de" there just the same as Lou's FR and LHR. I think @key is following the same datatype. Sebastian From daniel.odonnell at uleth.ca Sun Jun 10 18:22:03 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 16:22:03 -0600 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466C7471.2090003@oucs.ox.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> <1181512252.32504.0.camel@localhost> <466C7471.2090003@oucs.ox.ac.uk> Message-ID: <1181514123.32504.31.camel@localhost> Good 'nuff. On Sun, 2007-06-10 at 23:00 +0100, Sebastian Rahtz wrote: > Daniel O'Donnell wrote: > > Seems fine to me, though I don't like unresolvable keys, even for > > airports. > > > they are not unresolvable; just that they dont > play in the world of URLs > > > consider

ich bin ein berliner

- the > token "de" there just the same as Lou's FR and LHR. > I think @key is following the same datatype. > > Sebastian -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Sun Jun 10 18:24:23 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Sun, 10 Jun 2007 16:24:23 -0600 Subject: [tei-council] state and event In-Reply-To: <466A6784.6090304@oucs.ox.ac.uk> References: <4669E976.9050609@computing-services.oxford.ac.uk> <466A6784.6090304@oucs.ox.ac.uk> Message-ID: <1181514263.32504.33.camel@localhost> Or, begging indulgence and forgiveness in advance: (it also happens). -dan On Sat, 2007-06-09 at 09:40 +0100, Sebastian Rahtz wrote: > Lou's Laptop wrote: > > > > The existing element (used in the only slightly less obscure > > context of the chapter on spoken transcription) is trickier to find a > > good replacement for. Sebastian suggests which is almost > > right but a bit long winded. > > > > > > > > > > sebastian > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From cwittern at gmail.com Sun Jun 10 21:54:56 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 11 Jun 2007 10:54:56 +0900 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466CAB70.6020202@gmail.com> Seems fine to me as well, modulo the possible additions mentioned by SR. All the best, Christian Lou's Laptop wrote: > About a month ago on this list we had some discussion about the > attributes used to associate a name with its referent, i.e. how do you > say that "Bill Sniggsw" in the text is actually the same person as "Wm > Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis > mutandis) how do you say that "Shipton" in your source is actually the > place located at lat/long 14.2 13.2 and formerly known as "Brycgstow". > > As I work on integrating placeography outcomes into the chapter that > treats these matters, I have found it helpful to briefly summarize the > various linking attributes concerned once for all. This duplicates > some matter presented elsewhere in the Guidelines, but it seemed > convenient to recap it in this context. > > I'd be very grateful if you could read it through (it's only a few > paras) and confirm (or deny) that it expresses the consensus we > reached earlier reasonably well. > > ------------------------------------- > >
Linking names and their referents > >

As members of the att.naming class, > many of the elements described in this chapter share the following > attributes: > > These attributes are designed to support two different ways of > associating a name, of any kind, with its referent. The encoder may > use either, neither, or both in combination as appropriate. The > ref attribute should be used wherever it is possible to supply > a direct link such as a URI to indicate the location of canonical > information about the referent. For example: > That silly man > David Paul Brown has suffered > ... > This encoding requires that there exist somewhere in the same document > a person element with the identifier DBP1, which > will contain canonical information about this particular person, > marked up using the elements discussed in > below. The same element might alternatively be provided by some other > document, > of course, which the same attribute could refer to by means of a URI, > as explained in : > That silly man > type="person">David Paul Brown has suffered > ...

>

The key attribute is provided for cases where no such > direct link is required: for example because resolution of the > reference is > carried out by some local convention, or because the encoder judges > that no such resolution is necessary. As an example of the first case, > a project might maintain its own local database system > containing canonical information about persons and places, each entry > in which is accessed by means of some system-specific identifier > constructed in a project-specific way from the value supplied for the > key attribute. In the module described by > chapter a similar method is used to link element > descriptions to the modules or classes to which they belong, for > example. As an example of the second case, consider the use of > well-established codifications such as country or airport codes, which > it is probably unnecessary for an encoder to expand further: > > I never fly from Heathrow Airport > to France >

>
> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From Syd_Bauman at Brown.edu Sun Jun 10 23:14:05 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Sun, 10 Jun 2007 23:14:05 -0400 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <4669DC99.2040703@gmail.com> References: <4669DC99.2040703@gmail.com> Message-ID: <18028.48637.741251.58018@emt.wwp.brown.edu> First, I just want to verify that the upcoming conference call is scheduled for this coming Friday 15 June at 12:00 UTC[1]. > As usual I would like to collect things you think that need our > attention and would like to see on the agenda. Please send them > either to me or to the Council list. I plan to send out the draft > agenda next Monday. I do have one item that, if we had time, I would have wanted to run past Sebastian first for a feasibility check. However ... Council has charged me with implementing Schematron rules in the Guidelines for expressing a variety of constraints that are not expressed in the RELAX NG schemas produced by the ODDs. A very large percentage, probably even a large majority, of these rules are going to be of the form "the X= attribute of should point to a ". While at the DH conference at UIUC, I saw a very interesting poster by Kevin Reiss of CUNY. His major point for our purposes was to better describe the semantics of XML languages by some extensions to ODD. I quickly noticed three major useful suggestions in his poster. One for describing the inheritance of attribute and one for describing the semantics of child elements. I think both of these are good ideas, but I think they require more fleshing out and more work on the Guidelines than is feasible for inclusion in P5 1.0. However, his third suggestion is directly apropos to the issue described above, and I think may well be reasonable to include in P5 1.0. I have revised his extension a little; here it is. We add a references= attribute to which could be used only if the datatype of the attribute being defined was data.pointer.[2] The references= attribute itself has a datatype of data.name, and gives the name of the element type to which the pointer attribute being defined should point. The ODD processor would generate the Schematron needed to validate that instances of the pointer attribute actually pointed to elements of the type named on references=.[3] Problem: what would the message in the generated content of the or be? I haven't even thought about it yet, but I doubt it's a show-stopper. This does, however, violate the "no new additions post Berlin" idea. Notes ----- [1] 06:00 MDT in Calgary, 07:00 CDT in Chicago, 08:00 EDT in New York, 13:00 BST in London, 14:00 CEST in Paris, 21:00 JST in Kyoto, and Sat 06-16 00:00 NZST in Wellington. [2] I.e., The @references attribute may only be used if the attribute being defined is a pointer. [3] I'm not 100% on what the Schematron for this would be, in part because I haven't figured out if ISO Schematron is well enough implemented we can and should use it (I suspect it is), or if the document() function has been implemented properly ala the XSLT 2.0 specification or not. Shouldn't be too hard to test, just haven't gotten to it yet. From cwittern at gmail.com Mon Jun 11 03:16:21 2007 From: cwittern at gmail.com (Wittern Christian) Date: Mon, 11 Jun 2007 16:16:21 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466CF6C5.6050806@gmail.com> Syd Bauman wrote: > First, I just want to verify that the upcoming conference call is > scheduled for this coming Friday 15 June at 12:00 UTC[1]. > Yes, that is correct. > I have revised his extension a little; here it is. > > We add a references= attribute to which could be used only if > the datatype of the attribute being defined was data.pointer.[2] The > references= attribute itself has a datatype of data.name, and gives > the name of the element type to which the pointer attribute being > defined should point. The ODD processor would generate the Schematron > needed to validate that instances of the pointer attribute actually > pointed to elements of the type named on references=.[3] > So the question seems to be whether to add this @references and what implications this might have. I think this is more suitable to discussion here (with some examples and running code), rather than spending time on this at the call. > Problem: what would the message in the generated content of the > or be? I haven't even thought about it yet, > but I doubt it's a show-stopper. This does, however, violate the "no > new additions post Berlin" idea. > This will not so much be a new item, but rather part of your dealing with the existing action item, so I do not see how this is affected by that rule. Christian -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 11 04:05:26 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 11 Jun 2007 09:05:26 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466D0246.8040709@oucs.ox.ac.uk> Syd Bauman wrote: > Council has charged me with implementing Schematron rules in the > Guidelines for expressing a variety of constraints that are not > expressed in the RELAX NG schemas produced by the ODDs. A very large > percentage, probably even a large majority, of these rules are going > to be of the form "the X= attribute of should point to a ". > it might help if you listed the outstanding rules you have to implement using Schematron? I am bit nonplussed by the assertion. Maybe I need a cup of tea > I quickly noticed three major useful suggestions in his poster. One > for describing the inheritance of attribute and one for describing > the semantics of child elements. would be interesting to hear more about these > We add a references= attribute to which could be used only if > the datatype of the attribute being defined was data.pointer.[2] The > references= attribute itself has a datatype of data.name, and gives > the name of the element type to which the pointer attribute being > defined should point. so must point to a somewhere, for example? but that's not true, is it? If it pointed to www.example.com/person.php?ID=SYD, did we ever say that must return a ? are you sure that ISO Schematron supports using of document() to access remote resources? what do you do if the site is unreachable? wearing my ODD programmer hat, implementing your proposal would be pretty easy, I think. My concern is simply whether there are enough cases to justify it. examples, please...... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From James.Cummings at oucs.ox.ac.uk Mon Jun 11 04:15:06 2007 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 11 Jun 2007 09:15:06 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466CAB70.6020202@gmail.com> References: <466BF815.1010803@computing-services.oxford.ac.uk> <466CAB70.6020202@gmail.com> Message-ID: <466D048A.5050305@oucs.ox.ac.uk> Wittern Christian wrote: > Seems fine to me as well, modulo the possible additions mentioned by SR. Me too (esp. a paragraph distinguishing nymKey from key). -James > > All the best, > > Christian > > Lou's Laptop wrote: >> About a month ago on this list we had some discussion about the >> attributes used to associate a name with its referent, i.e. how do you >> say that "Bill Sniggsw" in the text is actually the same person as "Wm >> Sniggeswort" and indeed was a carpenter born in 1602; or (mutatis >> mutandis) how do you say that "Shipton" in your source is actually the >> place located at lat/long 14.2 13.2 and formerly known as "Brycgstow". >> >> As I work on integrating placeography outcomes into the chapter that >> treats these matters, I have found it helpful to briefly summarize the >> various linking attributes concerned once for all. This duplicates >> some matter presented elsewhere in the Guidelines, but it seemed >> convenient to recap it in this context. >> >> I'd be very grateful if you could read it through (it's only a few >> paras) and confirm (or deny) that it expresses the consensus we >> reached earlier reasonably well. >> >> ------------------------------------- >> >>
Linking names and their referents >> >>

As members of the att.naming class, >> many of the elements described in this chapter share the following >> attributes: >> >> These attributes are designed to support two different ways of >> associating a name, of any kind, with its referent. The encoder may >> use either, neither, or both in combination as appropriate. The >> ref attribute should be used wherever it is possible to supply >> a direct link such as a URI to indicate the location of canonical >> information about the referent. For example: >> That silly man >> David Paul Brown has suffered >> ... >> This encoding requires that there exist somewhere in the same document >> a person element with the identifier DBP1, which >> will contain canonical information about this particular person, >> marked up using the elements discussed in >> below. The same element might alternatively be provided by some other >> document, >> of course, which the same attribute could refer to by means of a URI, >> as explained in : >> That silly man >> > type="person">David Paul Brown has suffered >> ...

>>

The key attribute is provided for cases where no such >> direct link is required: for example because resolution of the >> reference is >> carried out by some local convention, or because the encoder judges >> that no such resolution is necessary. As an example of the first case, >> a project might maintain its own local database system >> containing canonical information about persons and places, each entry >> in which is accessed by means of some system-specific identifier >> constructed in a project-specific way from the value supplied for the >> key attribute. In the module described by >> chapter a similar method is used to link element >> descriptions to the modules or classes to which they belong, for >> example. As an example of the second case, consider the use of >> well-established codifications such as country or airport codes, which >> it is probably unnecessary for an encoder to expand further: >> >> I never fly from Heathrow Airport >> to France >>

>>
>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk From arianna.ciula at kcl.ac.uk Mon Jun 11 06:10:43 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Mon, 11 Jun 2007 11:10:43 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466BF815.1010803@computing-services.oxford.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> Message-ID: <466D1FA3.6000900@kcl.ac.uk> I agree with this plus the additions mentioned by Sebastian. A small observation: Lou's Laptop wrote: The > ref attribute should be used wherever it is possible to supply > a direct link such as a URI to indicate the location of canonical > information about the referent. For example: > That silly man > David Paul Brown has suffered > ... > This encoding requires that there exist somewhere in the same document > a person element with the identifier DBP1, which > will contain canonical information about this particular person, > marked up using the elements discussed in > below. The same element might alternatively be provided by some other > document, > of course,... May be I am reading too much here, but it seems that this second option (i.e. having your list of persons/places, for instance, in another TEI document) as it is written in this prose is less preferred, while I think it will be the most used/useful especially for those projects that have a gazetteer or a substantial set of persons. Arianna _______________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From lou.burnard at computing-services.oxford.ac.uk Mon Jun 11 06:10:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Mon, 11 Jun 2007 11:10:55 +0100 Subject: [tei-council] @key and @ref: recap ok? In-Reply-To: <466D1FA3.6000900@kcl.ac.uk> References: <466BF815.1010803@computing-services.oxford.ac.uk> <466D1FA3.6000900@kcl.ac.uk> Message-ID: <466D1FAF.7010200@computing-services.oxford.ac.uk> Arianna Ciula wrote: > > > Lou's Laptop wrote: > The >> ref attribute should be used wherever it is possible to supply >> a direct link such as a URI to indicate the location of canonical >> information about the referent. For example: >> That silly man >> David Paul Brown has suffered >> ... >> This encoding requires that there exist somewhere in the same document >> a person element with the identifier DBP1, which >> will contain canonical information about this particular person, >> marked up using the elements discussed in >> below. The same element might alternatively be provided by some other >> document, >> of course,... > > May be I am reading too much here, but it seems that this second option > (i.e. having your list of persons/places, for instance, in another TEI > document) as it is written in this prose is less preferred, while I > think it will be the most used/useful especially for those projects that > have a gazetteer or a substantial set of persons. "alternatively" certainly isn't meant to imply "second best", as the "of course" is meant to show. But if it doesn't work, I'll try to improve the wording. > > Arianna > > _______________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From cwittern at gmail.com Mon Jun 11 21:04:20 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 12 Jun 2007 10:04:20 +0900 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18028.48637.741251.58018@emt.wwp.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> Message-ID: <466DF114.80703@gmail.com> Syd Bauman wrote: > First, I just want to verify that the upcoming conference call is > scheduled for this coming Friday 15 June at 12:00 UTC[1]. > Now I see why you ask: I just realized that I originally announced the meeting for *today*, Tue 12, 2007. Obviously this can not work anymore and in terms of availability according to meet-o-matic, Friday is as good, except that we have to do without Tone Merete:-(, but on the positive side, we gain David Birnbaum:-). My apologies for this confusion! All the best, -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From cwittern at gmail.com Mon Jun 11 21:14:48 2007 From: cwittern at gmail.com (Wittern Christian) Date: Tue, 12 Jun 2007 10:14:48 +0900 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC Message-ID: <466DF388.9090409@gmail.com> DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC Expected to participate: Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern excused: Tone Merete Bruvik ============================================================ How to connect: We will use the highspeedconferencing.com service again. Participants can use their skype account (www.skype.com) or regular phones to call. When calling via skype, *please use a headset*. If in doubt, it might be better to call via regular phone. Numbers as follow: >From Skype call +99008278525675 In the US, call 1-712-432-4000 Calling from Europe, call In Austria: 0820 400 01562 In Belgium: 0703 59 984 In France: 0826 100 266 In Germany 01805 00 7620 In UK: 0870 119 2350 other places: call to US:-( Enter Conference Room Number : 5326922 (this is Sebastian's Conference room) ============================================================ Please read through the following (including the linked pages) before the meeting. ============================================================ 1) Open action items There are a lot of open action items registered in TRAC. The planning-and-deadline sub committee (DSC) has tried to organize them in a more coherent list also ordered by importance and degree of difficulty, available at http://www.tei-c.org/Council/tcm30-notes.xml?style=printable The DSC members have individually contacted the action holders and inquired about progress. We will start with reports from the DSC. * Consolidated reports on outstanding actions from Daniel, Sebastian and Christian [we will try to get these also in writing to the council list prior to the meeting] 2) To discuss Some of the items scheduled for action in Berlin look a bit unclear or need further discussion. We should briefly try to clarify these issues: * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge corpus chapter into DS. * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think ST and its position in the Guidelines soon * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re-work NH 3) Reports * Places meeting at Kings. (Arianna / Lou) * ISO FSD activity (LR) 4) Further planning * The main question here is how much time we can allow for solving the remaining technical issues and how to divide up the tasks. Again, please have a careful look at http://www.tei-c.org/Council/tcm30-notes.xml?style=printable and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap 5) next meeting Mid/end of July -- Christian Wittern Institute for Research in Humanities, Kyoto University 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN From laurent.romary at loria.fr Tue Jun 12 03:26:25 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 12 Jun 2007 09:26:25 +0200 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466DF114.80703@gmail.com> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466DF114.80703@gmail.com> Message-ID: <10655074-5816-4C8A-A034-6529BBEF8D0E@loria.fr> I see too. I was about to ask the number to which I should connect this afternoon... I have a meeting just before the newly planned call on Friday and may arrive a little late. Best, Laurent Le 12 juin 07 ? 03:04, Wittern Christian a ?crit : > Syd Bauman wrote: >> First, I just want to verify that the upcoming conference call is >> scheduled for this coming Friday 15 June at 12:00 UTC[1]. >> > Now I see why you ask: I just realized that I originally announced > the meeting for *today*, Tue 12, 2007. Obviously this can not work > anymore and in terms of availability according to meet-o-matic, > Friday is as good, except that we have to do without Tone Merete:- > (, but on the positive side, we gain David Birnbaum:-). > My apologies for this confusion! > > All the best, > > -- > > Christian Wittern Institute for Research in Humanities, Kyoto > University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From tone.bruvik at aksis.uib.no Tue Jun 12 06:06:28 2007 From: tone.bruvik at aksis.uib.no (Tone Merete Bruvik) Date: Tue, 12 Jun 2007 12:06:28 +0200 Subject: [tei-council] DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at 1200 UTC In-Reply-To: <466DF388.9090409@gmail.com> References: <466DF388.9090409@gmail.com> Message-ID: <14F39CC5-64AC-413D-AC9E-966E13A10831@aksis.uib.no> As I will not be able to attend the teleconference, I think I should say something on the re-work of NH - Multiple Hierarchies: 1. At the council meeting in Berlin we agreed upon that this chapter has to be rewritten with particularly this in mind: - NH should be make into a chapter again. We did not decide that, but I think we pretty much agreed upon that. Where should it be placed , at the end? - The chapter has to be far clearer about which solutions are available in P5, which are implementable in P5, and which are not. (This is of course a major task.) - I suggested that there should be pointers to template or exemplar ODDs demonstrating how to implement those solutions that can be. 2. There are some minor errors that should be corrected, see Trac Tickets #236, #237 and #238. Syd and me have this job assigned to us, and I have to admit that I have not work much on this lately. My plan was to work on this chapter during the next 2 weeks, and then again in August. What I will do first is to find some new samples (and I has thinking of asking Claus Huitfeldt if he could give some of his samples to be used here). Syd, what are you view on this chapter and our work on it? I guess we need to have a schedule to give to the council on what we should do and when? Tone Merete Bruvik tone.bruvik at aksis.uib.no ---- The Research Group for Text Technology - Aksis (The Department of Culture, Language and Information Technology), Unifob AS All?gaten 27 - N-5020 Bergen, Norway Den 12. jun. 2007 kl. 03.14 skrev Wittern Christian: > > DRAFT Agenda for the TEI Council teleconference on June 15, 2007 at > 1200 UTC > > Expected to participate: > > Syd Bauman, David Birnbaum, Lou Burnard, Arianna Ciula, James > Cummings, Matthew Driscoll, Daniel O'Donnel, Dot Porter, Sebastian > Rahtz, Laurent Romary, Conal Tuohy, John Walsh, Christian Wittern > > excused: Tone Merete Bruvik > > ============================================================ > How to connect: > > We will use the highspeedconferencing.com service again. > > Participants can use their skype account (www.skype.com) or regular > phones to call. When calling via skype, *please use a headset*. If > in doubt, it might be better to call via regular phone. Numbers as > follow: > >> From Skype call +99008278525675 > In the US, call 1-712-432-4000 > Calling from Europe, call > In Austria: 0820 400 01562 > In Belgium: 0703 59 984 > In France: 0826 100 266 > In Germany 01805 00 7620 > In UK: 0870 119 2350 > other places: call to US:-( > Enter Conference Room Number : 5326922 > (this is Sebastian's Conference room) > ============================================================ > > Please read through the following (including the linked pages) before > the meeting. > > ============================================================ > > 1) Open action items > > There are a lot of open action items registered in TRAC. The > planning-and-deadline > sub committee (DSC) has tried to organize them in a more coherent > list also > ordered by importance and degree of difficulty, available at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > The DSC members have individually contacted the action holders and > inquired about progress. We will start with reports from the DSC. > > * Consolidated reports on outstanding actions from Daniel, > Sebastian and > Christian > [we will try to get these also in writing to the council list > prior to > the meeting] > > 2) To discuss > > Some of the items scheduled for action in Berlin look a bit unclear or > need further discussion. We should briefly try to clarify these > issues: > > * (LB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/333. Merge > corpus > chapter into DS. > * (DB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/341 Re-think > ST and its position in the Guidelines soon > * (TMB) TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/343 re- > work NH > > 3) Reports > > * Places meeting at Kings. (Arianna / Lou) > > * ISO FSD activity (LR) > > 4) Further planning > > * The main question here is how much time we can allow for solving the > remaining technical issues and how to divide up the tasks. > Again, please have a careful look at > http://www.tei-c.org/Council/tcm30-notes.xml?style=printable > and http://tei.oucs.ox.ac.uk/trac/TEIP5/roadmap > > 5) next meeting > Mid/end of July > > -- > > Christian Wittern > Institute for Research in Humanities, Kyoto University > 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From Syd_Bauman at Brown.edu Tue Jun 12 14:47:45 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 14:47:45 -0400 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466DF114.80703@gmail.com> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466DF114.80703@gmail.com> Message-ID: <18030.59985.661920.836809@emt.wwp.brown.edu> > Now I see why you ask: I just realized that I originally announced > the meeting for *today*, Tue 12, 2007. Ah! And I thought I just put it on my calendar incorrectly. Thanks for clarifying. Talk to you Fri! From daniel.odonnell at uleth.ca Tue Jun 12 15:09:53 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Tue, 12 Jun 2007 13:09:53 -0600 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <18030.59985.661920.836809@emt.wwp.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466DF114.80703@gmail.com> <18030.59985.661920.836809@emt.wwp.brown.edu> Message-ID: <1181675393.24880.0.camel@localhost> Me too! It was like a confederacy of dunces. -dan On Tue, 2007-06-12 at 14:47 -0400, Syd Bauman wrote: > > Now I see why you ask: I just realized that I originally announced > > the meeting for *today*, Tue 12, 2007. > > Ah! And I thought I just put it on my calendar incorrectly. Thanks > for clarifying. Talk to you Fri! > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From dporter at uky.edu Tue Jun 12 16:25:37 2007 From: dporter at uky.edu (Dot Porter) Date: Tue, 12 Jun 2007 16:25:37 -0400 Subject: [tei-council] List of items from Berlin Message-ID: <96f3df640706121325h39bde542k5005ae89faeea548@mail.gmail.com> Hello all, Here is a complete list of errors from the three chapters I checked for the Berlin meeting. Sorry to take so long to get them to the list, but most of my original comments have already been dealt with by the editors. 19: Language Corpora all recommended changes made 7: Transcription of Speech 7.3: "To enable these modules, the appropriate parameter entities must be declared in the document type declaration subset, as described in section 1.2 Defining a TEI schema." Should there be here instead a reference to specifying modules in the ODD, or just a more general declaring modules in DTD or schema languages? 7.3.1: I believe that there is an incorrect usage of in the second example. According to its definition in 3.4.3, " (deletion) contains a letter, word or passage deleted, marked as deleted, or otherwise indicated as superfluous or spurious in the copy text by an author, scribe, annotator, or corrector." But its usage in the example is described as "This example also uses the core elements and to mark editorial decisions concerning matter completely omitted from the transcript (because of inaudibility), and words which have been transcribed but which the transcriber considers may be deleted, respectively." Either the example needs to be changed to reflect accepted practice or the description needs to be clarified (what does it mean when a transcriber considers that something may be deleted? I don't think that makes sense.) 7.3.4: This section includes an example of defining entities to represent prosodic features. The entire discussion assumes that the editor is using DTDs. If there is another method for doing the same thing in ODD/RNG this section should be changed. OTOH at the end of my notes I say "Chapter needs to be rewritten!" and I believe we discussed this in Berlin. 10: Linking 10.4.3: Three-way alignment. This section needs to be reexamined in light of the current work on facsimile/image markup, and I am working on this currently. These are all the comments I had left over from Berlin. Everything else in my notes has been changed. Thanks, Dot -- *************************************** Dot Porter, University of Kentucky ##### Program Coordinator Collaboratory for Research in Computing for Humanities dporter at uky.edu 859-257-9549 ##### Editorial Assistant, REVEAL Project Center for Visualization and Virtual Environments porter at vis.uky.edu *************************************** From Syd_Bauman at Brown.edu Tue Jun 12 17:20:38 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 17:20:38 -0400 (EDT) Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <466D0246.8040709@oucs.ox.ac.uk> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466D0246.8040709@oucs.ox.ac.uk> Message-ID: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> > it might help if you listed the outstanding rules you have to > implement using Schematron? I am bit nonplussed by the assertion. What assertion? Yes, it would help if I provided a list, but since creating such a list is a large part of the project ... In the meantime, here is a list of some that we considered candidates back in summer 2005: --------- active= should point to a or , pending work on prosopography adj= should point to one or more s adjFrom= should point to one or more s adjTo= should point to one or more s children= should point to one or more s or s children= should point to one or more s or s class= should point to a or child of a ? ask MS class= should point to a or child of a ? ask MS code= should point to a element code= should point to a element end= %tei.timed; should point to a exclude= %tei.linking; should point to one or more members of the tei.declarable class feats= should point to one or more s follow= should point to an or follow= should point to an or from= should point to a given= should point to a different or a

? hand= %tei.readings; should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a hand= should point to a location= %tei.dictionaries; should point to an new= should point to a next= %tei.linking; should point to an element of same type old= should point to a origin= should point to one of its own children parent= should point to an , , or parent= should point to an , , or passive= should point to a or , pending work on prosopography perf= should point to one or more s perf= should point to one or more s prev= %tei.linking; should point to an element of same type ref= should point to a or a render= should point to a element resp= %tei.interpret; should point to a tei.naming or element resp= %tei.readings; should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= should point to a tei.naming or element resp= %tei.intervention; should point to a tei.naming or element role= should point to a ?? role= should point to a ?? scheme= should point to a element scheme= should point to a element scheme= should point to a element scheme= should point to a element scheme= should point to a element scribe= should point to a tei.naming or element? script= should point to a , , , or (maybe) ? select= %tei.linking; should point to one or more of its own descendants since= should point to a sibling source= should point to a tei.naming, , , , , or start= %tei.timed; should point to a target= %tei.formPointers; should point to an , , or

target= should point to elements target= should point to a target= should point to a target= should point to a to= should point to a url= should point to a (file whose root is a) ? who= %tei.ascribed; should point to a or , pending work on prosopography > would be interesting to hear more about these I don't think it's up on the web yet ... > so must point to a > somewhere, for example? but that's not true, is it? > If it pointed to www.example.com/person.php?ID=SYD, > did we ever say that must return a ? I was not privy to the discussions about ref= of , so I can't say. Perhaps it is a reasonable restriction that it point to a TEI or element, though. If you want to refer to some external database either * you shouldn't use ref=, or * you should point to it from the entry, no? > are you sure that ISO Schematron supports using of document() to > access remote resources? Yes, I think it does. I even think that it is supposed to support use of fragment identifiers. What I don't know is if any implementations actually do this or not. > what do you do if the site is unreachable? I would say throw a warning that it can't be tested and go on, but I'm not sure Schematron implementations let you do that or not. From lou.burnard at computing-services.oxford.ac.uk Tue Jun 12 17:40:49 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Tue, 12 Jun 2007 22:40:49 +0100 Subject: [tei-council] List of items from Berlin In-Reply-To: <96f3df640706121325h39bde542k5005ae89faeea548@mail.gmail.com> References: <96f3df640706121325h39bde542k5005ae89faeea548@mail.gmail.com> Message-ID: <466F12E1.5090109@computing-services.oxford.ac.uk> Dot Porter wrote: > > Here is a complete list of errors from the three chapters I checked > for the Berlin meeting. Sorry to take so long to get them to the list, > but most of my original comments have already been dealt with by the > editors. Thanks Dot! > > 7: Transcription of Speech > 7.3: "To enable these modules, the appropriate parameter entities must > be declared in the document type declaration subset, as described in > section 1.2 Defining a TEI schema." Should there be here instead a > reference to specifying modules in the ODD, or just a more general > declaring modules in DTD or schema languages? All such references should refer to the same place and should be in approximately the same form; the one in this chapter seems to have escaped. But not for long! > 7.3.1: I believe that there is an incorrect usage of in the > second example. This is a rather strange use of I agree, but not I think completely wrong. The problem is that the transcriber (this is a real example, by the way, not one I made up!) is interested in the kinds of segment primarily, and wants to show that for the purpose of segmentation the repeated words should be deleted. In the original typescript they do this by transcribing it and then... deleting it (with overstriking). So that's what I have encoded. I have tried to reword it a bit to explain what's going on. > > 7.3.4: This section includes an example of defining entities to > represent prosodic features. The entire discussion assumes that the > editor is using DTDs. If there is another method for doing the same > thing in ODD/RNG this section should be changed. > Indeed it should, and has been. > OTOH at the end of my notes I say "Chapter needs to be rewritten!" and > I believe we discussed this in Berlin. > Well, certainly the chapter is in need of a spring clean, but I can't see that happening in the next month, so it's probably not going to get done for P5. > 10: Linking > 10.4.3: Three-way alignment. This section needs to be reexamined in > light of the current work on facsimile/image markup, and I am working > on this currently. > I see Conal has just posted a whole mass of things. Hoorah! From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 12 17:45:14 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 12 Jun 2007 22:45:14 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466D0246.8040709@oucs.ox.ac.uk> <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> Message-ID: <466F13EA.2020701@oucs.ox.ac.uk> Syd Bauman wrote: > In the meantime, here is a list of some that we considered candidates > back in summer 2005: > your memory or records are better than mine! ok, your list is quite convincing. if you write the spec, I guess I'll try to implement it in due course. HOWEVER, I would suggest that implementing all this (both on your part and my part) is very much a luxury. If all the other work gets done, then it would be nice to get it in place for 1.0. But I'd suggest that most of the long list of other tasks to be done should take precedence. consider than we reshould really freeze the Specs on August 1st for a November 1st release, and then consider that this is about 7 weeks away... Sebastian From Syd_Bauman at Brown.edu Tue Jun 12 20:43:11 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Tue, 12 Jun 2007 20:43:11 -0400 Subject: [tei-council] mimeType= Message-ID: <18031.15775.225195.541353@emt.wwp.brown.edu> We now have 4 elements which each individually declare a mimeType= attribute. attribute mimeType { data.word }?, mwa The MIME type to be used for the object when it is decoded attribute mimeType { data.word }?, opt MIME type of external filter script attribute mimeType { data.word }?, mwa The MIME type attribute mimeType { text }?, [defaults to opt] supplies a MIME type for the content of this element. Recommendation -------------- New class, att.internetMedia (or whatever) that defines the mimeType= attribute as 'mwa' with datatype data.word, and a description of "specifies the applicable multimedia internet mail extension (MIME) media type". These four elements become members of this class. The remarks element for this class would include a reference to the MIME type registry (http://www.iana.org/assignments/media-types/). This means that the information about *what* the attribute is the MIME type for, and (in the case of ) that the contents need to be decoded before the MIME type applies, will need to be noted in the remarks section of the tagdoc for the element. It's also a real change in the case of , from optional to mandatory when applicable. From lou.burnard at computing-services.oxford.ac.uk Wed Jun 13 03:37:59 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 13 Jun 2007 08:37:59 +0100 Subject: [tei-council] mimeType= In-Reply-To: <18031.15775.225195.541353@emt.wwp.brown.edu> References: <18031.15775.225195.541353@emt.wwp.brown.edu> Message-ID: <466F9ED7.8010001@computing-services.oxford.ac.uk> Sounds like an open and shut case to me : plz do it forthwith Syd Bauman wrote: > We now have 4 elements which each individually declare a mimeType= > attribute. > > attribute mimeType { data.word }?, mwa > The MIME type to be used for the object when it is decoded > > attribute mimeType { data.word }?, opt > MIME type of external filter script > > attribute mimeType { data.word }?, mwa > The MIME type > > attribute mimeType { text }?, [defaults to opt] > supplies a MIME type for the content of this element. > > > Recommendation > -------------- > New class, att.internetMedia (or whatever) that defines the mimeType= > attribute as 'mwa' with datatype data.word, and a description of > "specifies the applicable multimedia internet mail extension (MIME) > media type". These four elements become members of this class. The > remarks element for this class would include a reference to the MIME > type registry (http://www.iana.org/assignments/media-types/). > > This means that the information about *what* the attribute is the > MIME type for, and (in the case of ) that the contents > need to be decoded before the MIME type applies, will need to be > noted in the remarks section of the tagdoc for the element. > > It's also a real change in the case of , from optional to > mandatory when applicable. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 03:43:18 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 08:43:18 +0100 Subject: [tei-council] mimeType= In-Reply-To: <18031.15775.225195.541353@emt.wwp.brown.edu> References: <18031.15775.225195.541353@emt.wwp.brown.edu> Message-ID: <466FA016.2020707@oucs.ox.ac.uk> I agree, seems entirely reasonable -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From arianna.ciula at kcl.ac.uk Wed Jun 13 05:28:11 2007 From: arianna.ciula at kcl.ac.uk (Arianna Ciula) Date: Wed, 13 Jun 2007 10:28:11 +0100 Subject: [tei-council] agenda items for Council telecon on 2007-06-15 at 1200 UTC In-Reply-To: <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> References: <4669DC99.2040703@gmail.com> <18028.48637.741251.58018@emt.wwp.brown.edu> <466D0246.8040709@oucs.ox.ac.uk> <200706122120.l5CLKcaJ005420@perseus.services.brown.edu> Message-ID: <466FB8AB.4090606@kcl.ac.uk> Syd Bauman wrote: > --------- > active= should point to a or , pending work on prosopography I think this will need to be updated: it can also point to a or may be also and possibly in the near future. Arianna -- Dr Arianna Ciula Research Associate Centre for Computing in the Humanities King's College London Strand London WC2R 2LS (UK) Tel: +44 (0)20 78481945 http://www.kcl.ac.uk/cch From laurent.romary at loria.fr Wed Jun 13 11:55:06 2007 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 13 Jun 2007 17:55:06 +0200 Subject: [tei-council] Dictionary update Message-ID: <9D8830D1-056A-4F56-A0D9-3AB01C2BA82B@loria.fr> In complement to my previous message related to ? here's the current state of progress with regards the dictionary chapter. I take this opportunity to send my apologies to Seb for the extra work that our activities have put on him (Roma still seems to be laying in bed with fever, it seems...). Laurent Report - dictionary chapter (date: 13. 06. 07) Done * Examples added to the following element descriptions: , , , , , , , , , , , , , , * In order to allow within : Made model.gramPart member of model.formPart (instead of model.morphLike being member of model.formPart) > to be tested! To Do * complete missing examples in element descriptions (working on examples from Campe: , , , ) - modify/discard the examples for , , , , , and depending on the decision concerning * text guidelines: - Changing the passages concerning , , depending on the decision. - Maybe adding examples for the following elements: , , , , , - Maybe adding some examples illustrating the use of some attributes? e.g. sortKey Problems * Until now no (good) examples available for the following elements: , , From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 12:03:00 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 17:03:00 +0100 Subject: [tei-council] Dictionary update In-Reply-To: <9D8830D1-056A-4F56-A0D9-3AB01C2BA82B@loria.fr> References: <9D8830D1-056A-4F56-A0D9-3AB01C2BA82B@loria.fr> Message-ID: <46701534.9000302@oucs.ox.ac.uk> Laurent Romary wrote: > I take this opportunity to send my apologies to Seb for the extra work > that our activities have put on him (Roma still seems to be laying in > bed with fever, it seems...). I am glad to say that I have finally identified the problem with term/@target which has been plaguing us; I don't have a solution yet, but I know where to look. If I can't solve this tonight, I shall probably scream so loudly you'll hear me in Berlin; on the other hand, after almost eveyrthing you can imagine going wrong in the last few days, today has seen several things go right, so I have hopes. I am really pleased to see Eva R getting to grips with the sources, very positive stuff. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Wed Jun 13 12:38:07 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 10:38:07 -0600 Subject: [tei-council] Ticket 110 Message-ID: <1181752687.9538.9.camel@localhost> Hi all, I'd handled the ticket business wrong for three of mine, so I'll be sending the comments for the council (as opposed to typos) out one after the other. http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/110 (MS Description) Here all the typos I'd found have been reported and fixed. There is one issue though: custodialHistory looks to me suspiciously like the newly redefined "event" element. -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 13 12:49:15 2007 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 13 Jun 2007 17:49:15 +0100 Subject: [tei-council] Ticket 110 In-Reply-To: <1181752687.9538.9.camel@localhost> References: <1181752687.9538.9.camel@localhost> Message-ID: <4670200B.3060205@oucs.ox.ac.uk> Daniel O'Donnell wrote: > Here all the typos I'd found have been reported and fixed. There is one > issue though: custodialHistory looks to me suspiciously like the newly > redefined "event" element. > > do you mean ? but anyway, can I suggest that we hold off on this area until the revised ND with persons, places and orgs is done? Then someone should read that, followed by MS, and see whether some bits of MS can be normalized using ND. Maybe Matthew would be the best placed person to do this with Daniel, as representing the two ends of the spectrum.[1] A word of warning, tho - beware of cross-module dependency. To use event, state and trait in MS would really mean putting them in the core, or having a simple model in MS which would be richer if namesdates was loaded. Personally, I think the latter is an elegant way to work, but it would require some delicate work, which I believe would be a distraction this month. [1] you can decide yourself what the spectrum is :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 From daniel.odonnell at uleth.ca Wed Jun 13 13:08:35 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 11:08:35 -0600 Subject: [tei-council] Trac 152 (TC) Message-ID: <1181754515.9538.17.camel@localhost> Here are some changes for TC: http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152 * Reverse TC and PH--This was assigned to Syd * We should mention that app is a special form of choice in TC, because we do so in the element description for choice: "For a specialized version of for encoding multiple witnesses of a single work, see section 15.1 The Apparatus Entry, Readings, and Witnesses." * 15.1.1: "The attributes loc, from, and to, are used to link the apparatus entry to the base text. Several methods may be used for such linkage, each involving a slightly different usage for these attributes. Linkage between text and apparatus is described below in section 15.2 Linking the Apparatus to the Text." * * This needs clarification, since apparatus can also exist without a base text: How about: "The attributes loc, from, and to, are used to link the apparatus entry to the base text , if present. In such cases, s everal methods may be used for such linkage, each involving a slightly different usage for these attributes. Linkage between text and apparatus is described below in section 15.2 Linking the Apparatus to the Text. For the use of the app element without a base text see... " * 15.1.2: The example from Klaeber may need a note explaining that while Klaeber's readings themselves record information about the text, they are treated as typographic features in the variorum apparatus. (Lou made this point most forcefully--perhaps he should supply the language)? * 15.1.4.3: In the example with <witness xml:id="c" included="#Cp #La #Sl2">Constant Group c</witness>, a better approach would be to nest the actual members of this group in an apparatus-like structure: Constant Group c Corpus Christi Oxford MS 198 British Library Lansdowne 851 British Library Sloane MS 1686 -dan -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at computing-services.oxford.ac.uk Wed Jun 13 17:54:55 2007 From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard) Date: Wed, 13 Jun 2007 22:54:55 +0100 Subject: [tei-council] Trac 152 (TC) In-Reply-To: <1181754515.9538.17.camel@localhost> References: <1181754515.9538.17.camel@localhost> Message-ID: <467067AF.7050407@computing-services.oxford.ac.uk> Daniel O'Donnell wrote: > Here are some changes for TC: > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152 > > * Reverse TC and PH--This was assigned to Syd > I'm open-minded as to whether this really needs doing; final disposition of the chapters is something we have already decided to defer anyway. > * We should mention that app is a special form of choice in TC, > because we do so in the element description for choice: "For a > specialized version of for encoding multiple witnesses of a > single work, see section 15.1 The Apparatus Entry, Readings, and > OK, have added a para :

The app element is in one sense a more sophisticated and complex version of the choice element introduced in as a way of marking points where the encoding of a passage in a single source may be carried out in more than one way. Unlike choice, however, the app element allows for the representation of many different versions of the same passage taken from different sources.

> * 15.1.1: "The attributes loc, from, and to, are used to link the > apparatus entry to the base text. Several methods may be used for > such linkage, each involving a slightly different usage for these > attributes. Linkage between text and apparatus is described below in > section 15.2 Linking the Apparatus to the Text." > * * This needs clarification, since apparatus can also exist > without a base text: How about: "The attributes loc, from, and > to, are used to link the apparatus entry to the base text , if > present. In such cases, s everal methods may be used for such > linkage, each involving a slightly different usage for these > attributes. Linkage between text and apparatus is described > below in section 15.2 Linking the Apparatus to the Text. For the > use of the app element without a base text see... " > OK : (TCAPPS) > * 15.1.2: The example from Klaeber may need a note explaining that > while Klaeber's readings themselves record information about the > text, they are treated as typographic features in the variorum > apparatus. (Lou made this point most forcefully--perhaps he should > supply the language)? > Already done, I think. > * 15.1.4.3: In the example with <witness xml:id="c" included="#Cp > #La #Sl2">Constant Group c</witness>, a better approach would be > to nest the actual members of this group in an apparatus-like > structure: > > Constant Group c > > Corpus Christi Oxford MS 198 > British Library Lansdowne 851 > British Library Sloane MS 1686 > > > > > Also already done: I think there was another ticket about removing the @include attribute which caused me to do it, but I cant now find it > -dan > From daniel.odonnell at uleth.ca Wed Jun 13 19:58:54 2007 From: daniel.odonnell at uleth.ca (Daniel O'Donnell) Date: Wed, 13 Jun 2007 17:58:54 -0600 Subject: [tei-council] Trac 152 (TC) In-Reply-To: <467067AF.7050407@computing-services.oxford.ac.uk> References: <1181754515.9538.17.camel@localhost> <467067AF.7050407@computing-services.oxford.ac.uk> Message-ID: <1181779134.13724.0.camel@localhost> Thanks Lou, on both tickets. -dan On Wed, 2007-06-13 at 22:54 +0100, Lou Burnard wrote: > Daniel O'Donnell wrote: > > Here are some changes for TC: > > http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/152 > > > > * Reverse TC and PH--This was assigned to Syd > > > I'm open-minded as to whether this really needs doing; final disposition > of the chapters is something we have already decided to defer anyway. > > * We should mention that app is a special form of choice in TC, > > because we do so in the element description for choice: "For a > > specialized version of for encoding multiple witnesses of a > > single work, see section 15.1 The Apparatus Entry, Readings, and > > > OK, have added a para : > >

The app element is in one sense a more sophisticated and > complex version of the choice element introduced in target="#COEDCOR"/> as a way of marking points where the encoding of a > passage > in a single source may be carried out in more than one way. Unlike > choice, however, the app element allows for the > representation of many different versions of the same passage taken > from different sources.

> > > > * 15.1.1: "The attributes loc, from, and to, are used to link the > > apparatus entry to the base text. Several methods may be used for > > such linkage, each involving a slightly different usage for these > > attributes. Linkage between text and apparatus is described below in > > section 15.2 Linking the Apparatus to the Text." > > * * This needs clarification, since apparatus can also exist > > without a base text: How about: "The attributes loc, from, and > > to, are used to link the apparatus entry to the base text , if > > present. In such cases, s everal methods may be used for such > > linkage, each involving a slightly different usage for these > > attributes. Linkage between text and apparatus is described > > below in section 15.2 Linking the Apparatus to the Text. For the > > use of the app element without a base text see... " > > > > OK : (TCAPPS) > > > * 15.1.2: The example from Klaeber may need a note explaining that > > while Klaeber's readings themselves record information about the > > text, they are treated as typographic features in the variorum > > apparatus. (Lou made this point most forcefully--perhaps he should > > supply the language)? > > > > Already done, I think. > > > * 15.1.4.3: In the example with <witness xml:id="c" included="#Cp > > #La #Sl2">Constant Group c</witness>, a better approach would be > > to nest the actual members of this group in an apparatus-like > > structure: > > > > Constant Group c > > > > Corpus Christi Oxford MS 198 > > British Library Lansdowne 851 > > British Library Sloane MS 1686 > > > > > > > > > > > > Also already done: I think there was another ticket about removing the > @include attribute which caused me to do it, but I cant now find it > > -dan > > > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: daniel.odonnell at uleth.ca WWW: http://people.uleth.ca/~daniel.odonnell/ From Syd_Bauman at Brown.edu Wed Jun 13 23:39:41 2007 From: Syd_Bauman at Brown.edu (Syd Bauman) Date: Wed, 13 Jun 2007 23:39:41 -0400 Subject: [tei-council] change/@date should be change/@when, no? Message-ID: <18032.47229.480045.401203@emt.wwp.brown.edu> I'm thinking that the date= attribute of the element should be renamed to when=. This seems better for 2 reasons: * matches when= of ,